Комментарии 73
Почему полезно перед экзаменом писать шпоры, даже если потом не брать их с собой? Потому что они содержат сжатую мысль и план ответа.
Предполагаемую же имплементацию можно и не (только) записывать, а заслушивать исполнителя перед группой - но сверяться с аудиозаписью, и даже транскрипцией гораздо менее удобно. Зато в аудиопризнании есть динамика и интерактив, как в игре в подкидного дурака - синфазные с докладчиком члены команды могут тут же накидать вводных, критики, или идей, которые тут же можно использовать. Когда задачи уже растащили по углам, и возвращаются обратно с листочками - все уже гораздо более спокойно )
ITIL. Начало.
В процессе реализации код и документ могут разойтись.
По моему опыту, что чем сложнее задача, тем больше в реализации всплывает "подводных камней" и тем ближе к единице вероятность расхождения с изначальным планом.
Этим и опасен предварительный теханализ. При работе над задачей, когда что-то пошло не так, появляется два варианта: делать близко к теханализу, хоть и не оптимально или делать как лучше, но забить на теханализ. Я так понимаю, что вы склоняете программеров к первому решению.
Для моей работы просто вредно подписываться под estimate plan. Но это может быть только для моей области характерно, когда бизнес сам не знает, чего он хочет. Поэтому я обычно пилю прототип, показываю и узнаю, чего на самом деле бизнес хотел.
На самом деле тут у нас есть варианты.
Если есть незначительные изменения, то проще всего поправить теханализ в процессе реализации и уведомить ревьюеров. Или вообще не править теханализ (например, новое строковое поле в сущности может вообще не упоминаться в анализе, если это не меняет никаких публичных API за границами команды).
Если речь идет про кардинальные изменения по итогам прототипирования, это две задачи в пайплайне (сделать прототип, сделать вторую итерацию) и каждая задача претендует на теханализ.
В каких-то случаях можно написать прототип без теханализа — ну типа сделать мокап UI и показать, получить фидбек, уточнить задачу и идти в полноценную задачу
Но да. В теории могут быть проекты, где эти вопросы, которые обычно обсуждаются в теханализе — поддерживаемость кода, масштабируемость, архитектура — не важны, а важно быстро согласовать и выдать прототип. В этом случае процессы эти вводить не нужно :-) С соответствующими эффектами.
Вот скорее вопрос про поддерживаемость. На этапе предварительного анализа у меня нет чёткого понимания, как я это могу реализовать. Есть направления, куда можно копнуть. Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё. Очень часто во время реализации приходит понимание, как это сделать прямо вот очень хорошо и правильно. И проще получится и надёжнее. И самое главное, что пока половину не реализуешь - не додумаешься.
А ещё в моей привычке несколько раз рефакторить текущий блок. Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Я понимаю, про что ваша система. Она про то, чтобы котята не устраивали самодеятельность и потом не было мучительно больно всё это поддерживать. Но мне бы такая система стала поперёк горла, просто потому, что она изначально призвана ограничивать выбор вариантов решения.
> Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё.
А часто бывает? В этих случаях надо копать в анализ и его качество, увы. Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
А как же "попробовать"? Что, если надо проверить гипотезу на практике? Что, если в результате исследования оказжется, что это вообще невозможно сделать? Например, используемый инструмент работает не так, как ожидалось, а свой писать слишком долго?
Я неоднократно сокращал время на разработку тем, что реализовывал всякие полезности. И эти полезности я мог описать уже после реализации. Просто у меня было предчувствие, что все должно получиться. :)
В противном случае, разработка пошла бы по очевидному, но при этом длинному пути.
> Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Хех. В анализе обычно как раз и нужно смотреть на границы между блоками. Вот есть такое API у связанного блока как вам нужно или нет? Если нет — то вы на анализе должны это увидеть, и подзадачу выделить. И кстати там же «похоже с ходу не выйдет, код надо рефакторить».
Еще добавлю. Рефакторить все подряд под бизнес задачами — плохая практика. Полная непредсказуемость. затягивание сроков, нестабильность, гигантский объем затронутого функционала на ретест. Но от нее отказаться можно только, если мы сможем добиться, что сторька будет решаться несколькими связанными задачами: анализ, рефакторинг блока А с добавлением новых функций, рефакторинг блока Б с добавлением новых функций, создание нового блока В. Каждую сдаем и выпускаем отдельно, тестеры счастливы.
Нужно научиться «продавать» менеджерам и бизнесу эту необходимость. И теханализ тут доп. аргумент — чтобы это сделать, надо предварительно зарефакторить блок А. Почему? А вот документ, мы его все обсудили и согласны. С большим архитектором согласовано.
Рефакторить все подряд под бизнес задачами — плохая практика.
В ERP-системе возрастом свыше 10 лет основная когнитивная нагрузка - это как раз бизнес-требования кого-то там когда-то. "Кто-то там" уже лет 5 назад уволился, другие люди по-другому думают, жизнь поменялась, поменялись требования. Ну и с приходом нового функционала старые блоки тоже начинают работать несколько иначе. Это нужно учитывать.
Собственно, рефакторинг обычно - это рефакторинг бизнес-логики. Признаюсь честно, я иногда втихую выкидывал старые требования. Иногда это замечают и приходилось возвращать. Ещё рефакторинг UI. Иногда нужно добавить поле, но там уже столько напихано, что с этим надо что-то делать. Надо изобретать. А сначала не ясно, что делать.
Бизнес-задачи - это такие же задачи. Просто в терминах предметной области. И их надо рефакторить. Если основная сложность системы - именно бизнес-логика, то без рефакторинга этой логики система станет невменяемо сложной.
Признаюсь честно, я иногда втихую выкидывал старые требования. Иногда это замечают и приходилось возвращать.
Жесть! А так если что получается взять и написать теханализ с «чтобы это реализовать, мы планируем выкинуть такой-то функционал, а вот этот упростить». И получить галочку от владельца продукта. Или от аналитика, который со всеми все согласует и возьмет на себя ответственность.
Так я о том как раз говорю, что на этапе предварительной архитектуры это просто не видно. Это становится понятно на середине пути. Ну просто старая фича с новой не дружит. А иногда всплывают сотрудники со знаниями, которые не учтены ни мной, ни бизнесом. А ещё я просто не помню, что я писал, к примеру 8 лет назад и почему. И это тоже всплывает во время работы.
Ещё хуже планировать, когда берёшься за чужой легаси-проект. Там вообще непредсказуемые нежданчики выползают. И никто не может объяснить, почему так сделано и зачем.
Оно можно, конечно, на архитектора стрелки перекидывать. Моя проблема была в том, что я и архитектор.
Где-то эту гонку легаси, в котором хрен разберёшься без залезания в код, надо остановить.
Остановите. Я бы с удовольствием на это посмотрел, только этого не будет скорее всего.
У меня был замечательный опыт, когда реализация задачи, выраженная тремя строками кода (задача тоже была сформулирована несложно и кратко) через три месяца в проме чуть не вызвала убытки. После чего приняли решение реализацию откатить, а аналитики ушли на подумать на еще три месяца.
Потому что вам выше сказали - в больших легаси системах никто не знает, где отвалится жопа, если на пузе отвинтить гайку. В моем случае были задействованы четыре системы в двух сетевых зонах, соединенные примерно тремя шинами. Каждая с логикой. И вы можете сколько угодно залезать в код этих семи систем (шины - они тоже системы), только вы все равно не поймете бизнес логики, которая находится в шести системах из семи.
Ну то есть, я бы в целом скорее согласился с изложенными в вашем тексте мыслями, но в данной ветке комментариев вас пытаются убедить, что не всегда так можно. Иногда никто не видит системы в целом, нет такого архитектора в компании.
Так, а по вашему из этой ситуации невозможно выйти? :-)
Мне кажется тут применим термин "Практическая неосуществимость"
Во многих случаях - да, невозможно. Во всяком случае быстрого простого способа выхода нет.
Быстрого простого нет. Но вообще есть. Самое лучшее время начать описывать что происходит было в начале проекта. Следующее лучшее время сейчас :-)
Какого проекта? Ну вот смотрите, в моем совершенно реальном примере задействованы 7 систем. Никакого такого проекта, который бы изначально предполагал, что их будет вот ровно столько и они будут делать вот такие вещи - его отродясь никогда не существовало. Одна из систем - это некий "фронтенд" к АБС Диасофт, который работает коннектором к шинам - потому что оная АБС никогда не предусматривала, что ее будут с кем-то так соединять.
То есть, вся вот эта архитектура - продукт многолетнего развития, начало которого я не застал, потому что это было возможно где-то в 90-х. То есть, этому всему, или самым старым из систем, возможно лет 30. Вы думаете, там остался кто-то из тех, кто изначально их проектировал? И грубо говоря, сегодняшнее (на самом деле я оттуда ушел лет 7 назад) состояние таково, что у каждой из 7 систем есть архитектор, но нет никого, кто мог бы это переварить все целиком. В том числе и потому, что целиком это слишком сложно. Вы думаете, почему аналитики на пару месяцев удалились? Потому что аналитики оного Диасофта ничего не знает о системе источнике Мюрекс. И вряд ли быстро сможет узнать, потому что она большая и сложная сама по себе. И наоборот так же.
Ну и да, сейчас это никому не нужно, по большому счету. Оно как-то развивается, и бизнес это как-то устраивает. А будет ли лучше - никто не знает, а проводить такой эксперимент слишком дорого. Всем хочется лучше - но никто не знает верного пути туда.
Ну и чё, не придумывалось, нет архитектора, штука большая и сложная. В части моего опыта тоже все было в изрядно плохом состоянии.
Не, ну я не говорил, что пытаться не стоит. Я скорее про то, что доказать бизнесу полезность будет ой как непросто. Ну этож как рефакторинг - поди докажи, что без этого будет дольше и дороже? При этом бизнес, особенно большой, в принципе готов делать много странных вещей, если его кто-то убедит, что они полезны.
Аналитики с архитектором сидят и пьют чай.
Менеджер вообще к ТЗ отношения не имеет. Он может организовать его написание, но сам написать не может. Нужен ли менеджер в принципе — ответ для другого поста.
Зависит от подхода. Если у нас контрактная разработка, там это придется сделать, но там свои приколы. Я скорее про модную agile продуктовую
По-моему мнению, ТЗ это не только для расчета трудоемкости (стоимости), но и то, что конкретно должна делать программа, как ее и на каких данных тестить и что является критерием приемки ее заказчиком. Ну и конечно сроки и бюджет.
Вообще-то,в СССР был ГОСТ на ТЗ для программ. А сейчас очевидно все сами изобретают велосипед.
Если под ТЗ подразумевать бизнес-требования или функциональные требования, то теханализ пишется на основе этих документов. Работу аналитика это не исключает. Почему аналитик не может сразу писать про технические решения — ответ есть в статье.
3.Какой толк от архитектора? Я видел (в том числе в упомянутых компаниях) с подходом, где каждую задачу берет себе архитектор и по ней пишет такой документ. В целом во многих командах при изначальном внедрении этого подхода так и делают — есть лид, он пишет такую доку по всем задачам.
К чему это приводит? В первую очередь к перегрузке архитектора/лида. Документы начинают писаться формально. Сроки затягиваются, те самые менеджеры заставляют программистов параллельно код писать. Документы становятся бесполезнее, пишутся еще формальнее, программисты прекращают их читать.
Попытка «расшива» этого узкого места приводит к найму в архитекторы людей, кто норм к написанию формальных документов и не обладают глубокими техническими знаниями. Они становятся еще бесполезнее, архитекторов прекращают уважать, принятие реальные архитектурных решений в компаний уходит от архитекторов в неформальную иерархию (обычно в руки тимлидов).
Это неудачная попытка внедрения предлагаемой вами схемы. А удачная приводит вот к чему — программисты при успешном внедрении этой схемы снижают свою роль до манкикодинга. У них нет ответственности за качество своего решения, они демотивированы (хорошие программисты не любят этого).
Тут (как я пишу в статье) программисты реально вовлечены в разработку решений, могут проявить свой креатив. Архитекторы консультируют, согласуют и надзирают, да. Но у них освобождается запас времени от текучки.
Сочувствую боли. Бывают такие архитекторы и менеджеры (которые сваливают свою обязанность управлять командой на программистов). Как их бороть — ортогональный вопрос. Но если они загружены фуллтайм записыванием за вами мыслей, то это сильно облегчает им доказательство их полезности. Ведь они вот сколько документов подготовили.
У нас архитекторы не только согласуют документы — на них лежат и планируются задачи по discovery, разработке концепций, больших архитектурных изменений. И мы можем от них это требовать благодаря этому. И на встречи с технарями заказчика или других команд тоже можем попросить сходить их, а не программиста — т.к. они все читаю, верхеуровневая картинка в голове у них есть
Спасибо за статью! Я тоже в нашей компании начал в эту сторону склонять коллектив после того как на одном проекте начал зашиваться на код ревью, особенно после того как разраб уходил на несколько дней корпеть над задачей, а возвращался с MR на 50 файлов, половину изменений в которых нужно было отменять. Постепенно пробую распространить похожую практику на другие команды )
Классная статья, плюс и даже подписался
Идея, когда исполнитель должен "расказать" публично что будет делатьЮ, принципиально меняет отношение к вопросу. Можно сидеть, слушать, кивать, задавать вопросы - но ситуация меняется в корне, когда надо рассказать, как это будет от и до
Теперь надо думать, как это внедрить
Спасибо
Waterfall описанный адептами Аджайл и Скрам и прочих -- не более чем маркетинговая страшилка. Этот вариант когда сначала ТЗ писали год, потом программировали два и т д конечно был, в случае разработки софта для спутников и самолетов и аналогичного оборудования, а разве там можно по другому? Так вот, вместо того чтобы работать рационально, как собственно люди делают зачастую даже интуитивно, менеджерам продали эту идею, что ну вообще не нужно ТЗ, документации и т д -- есть же великий Аджайл и прочее, все как то отрефакторят по ходу дела. Естественно, когда без качественного осмысления как правильно делать задачу, начинают делать что то, а потом переделывают, а потом снова переделывают, и в итоге тратят в пять раз больше времени, чем если бы было потрачена может всего 1 неделя на обдумывание архитектуры. А уж не описывать структуры БД может только оптимист, который никогда не работал с БД с сотнями таблиц. В общем, автор понял с опытом -- модные менеджерские технологии которые утверждают что ТЗ или документация не нужны, и все можно на следующем шаге отрефакторить и поменять -- не более чем набор красивых слоганов.
Waterfall описанный адептами Аджайл и Скрам и прочих
Waterfall как плохая практика описан за 30 лет до Agile Manifesto.
ну вообще не нужно ТЗ, документации
А причём тут скрамы с аджайлами? Отсутствие ТЗ и документации допустимо только в методе разработки "бардак на проекте".
Ну так если Waterfall был описан как плохая практика за 30 лет до Agile Manifesto, зачем тогда во всех маркетинговых материалах по Agile и Скраму написано какой он плохой и как они с ним борятся?? Ну это как если бы создатели Питона или C# писали что они создали свои языки чтобы девелоперы не писали на ассемблере -- абсурд же, да?
Ну БД с сотнями таблиц ныне считается антипаттерном. А так все правильно.
И как же модно поддерживать непротиворечивость данных и атомарность транзакций в системах, где структуры данные не укладываются в пару десятков таблиц?
А надо между сотнями таблиц, то есть десятками разных сущностей поддерживать непротиворечивость?
Как правило бизнесу в большинстве случаев достаточно eventual consistensy. Главное понять, где достаточно, а где нет :-)
Как вообще жить в таких системах моднейше можно прочитать в книгах по DDD. Эта моднота придумана кажется 30 лет назад :-)
Сорри, случайно минус поставил.
Так само название статьи как бы не просто намекает, а прямо вопит о том, о чем вы пытаетесь сказать)
А кто отвечает за срыв сроков, если в середине проекта выяснится, что проблема на много глубже, чем предполагалось? Архитектор, который не до конца понимает сложность фичи, или программист, который упустил в своём документе что-то важное?
Чем эта ситуация отличается от ревью "да тут всё надо переделать, иначе в прод не пойдет!"?
Может я как-то иначе интерпретировал посыл статьи, но для меня предложенный здесь вариант -- озвучивание намерения, мыслей; набросок, черновик. Когда лучше заранее (не в конце ревью) услышать от коллеги, что через соседний модуль нечто делается просто, так-то и сяк-то. ("вот как просто оказывается! а мне теперь еще и переписывать >:/" гневно-соглашающийся смайлик)
Автор не единожды подчеркивает неформальность, это не строгий ТЗ на 15 страниц. А "мне кажется придется делать вот так, затронуть тех. Всё сходится?" И если мелочи меняются, обновляется текст, потому что он -- мотивировка на обычном языке. Если нечто большее, то опять за помощью, в дискуссии к тексту.
Я вижу в этом какого-то рода асинхронное парное программирование. Нет не парное, но приближенное к тому, что рядом был кто-то, кто с тобой согласился или внес пару корректур в твою задумку.
Мне непонятно в чём "плохость" услышать на ревью что модуль чем-то плох. Ревью же делается раз в неделю. За следующую неделю и исправится.
Как я понял текст, погер делает некие заметки по которым составляется архитектура и ТЗ. Мой вопрос был по поводу того, кого винить, если прогер ошибся в своих прикидках, а архитектор уже одобрил ТЗ и отослал заказчику. В статье о заказчиках вообще ни слова. Вроде как прогеры кодят для своего удовольствия, а архитектор талантливо указывает им путь в светлое будущее.
Тут есть ещё один момент. Если ваши финансовые отношения с заказчиком строятся по модели контрактной разработки fix price, заказчик в принципе не может получить качественный продукт и качественный код.
По моим впечатлениям, а в особенности после прочтения серии статей уважаемого @XaBoK (реклама в этом случае будет не лишней - сам увидел серию только неделю назад), “особенностей” там просто выше крыши. Сам-то я в этом участвую написанием ConOps-ов (Concept of Operations) и прочей тех-документации, так что тема ответственности за неверно принятые решения в самом начале работы для меня особенно близка.
Почему в середине проекта? В середине спринта.
Ну да, надо повторно уйти на теханализ. Такое бывает, и это ничем не отличается от «на ревью выяснилось что все надо переделать», только реже случается.
Ок. Кто виноват, если в спринте посередине проекта выяснится, что заказчику надо будет заплатить как минимум вдвое больше? И да, реальную сумму мы пока не знаем.
Отличие от ревью и "надо всё переделать" в том, что после ревью надо переделывать работу за неделю, да и то малую её часть. А в случае с глобальной ошибкой, надо будет пересматривать и архитектуру и менять код. Полностью.
Все верно. В каком случае проще совершить глобальную ошибку в архитектуре? Если мы проверяем и обсуждаем ее заранее, до написания кода, или все изменения в архитектуре окажутся видны другим членам команды только на код ревью?
А если вы продаете заказчику каждую задачу в отдельности (представляю такие контракты, это обычно типа поддержка какой-то системы и идёт поток мелких доработок), то вам каждую задачу надо оценивать. Соответственно и анализировать.
По итогу во многих наших командах сейчас наличие теханализа является частью Definition of Ready — увеличение Cycle time окупается предсказуемостью и ростом общей производительности.
Как продавать это менеджерам которые не в состоянии видеть ничего дальше 1 спринта? Они не видят общего роста производительности, они видят что сегодня ты че то там думаешь, а мог бы и код писать
Не нашел пункта про работу по "унижению" программистов за плохой код. Термин не мой, его неоднократно упоминали сами разработчики, ссылаясь на работу код-ревьюера, отдельно отмечая его эффективность.
В продолжении темы поделюсь парой своих постов.
Как у нас в команде практиковалось написание RFC: https://tiendil.org/ru/posts/two-years-writing-rfc-statistics с графиками, статистикой и комментариями.
Про мышление письмом в целом: https://tiendil.org/ru/posts/thinking-through-writing
Кажется неплохое подспорье для борьбы с волками.
Спасибо автору за это
Царëв, а тебе сколько лет?
Три недели кодирования экономят два дня проектирования