Можно через оценки. А давайте все задачи оценивать, чтобы знать когда мы их сделаем. А для оценки нужно текстик написать небольшой. А если программист неправильно оценит, пусть за ним архитектор проверит....
Ну да, надо повторно уйти на теханализ. Такое бывает, и это ничем не отличается от «на ревью выяснилось что все надо переделать», только реже случается.
Признаюсь честно, я иногда втихую выкидывал старые требования. Иногда это замечают и приходилось возвращать.
Жесть! А так если что получается взять и написать теханализ с «чтобы это реализовать, мы планируем выкинуть такой-то функционал, а вот этот упростить». И получить галочку от владельца продукта. Или от аналитика, который со всеми все согласует и возьмет на себя ответственность.
Еще добавлю. Рефакторить все подряд под бизнес задачами — плохая практика. Полная непредсказуемость. затягивание сроков, нестабильность, гигантский объем затронутого функционала на ретест. Но от нее отказаться можно только, если мы сможем добиться, что сторька будет решаться несколькими связанными задачами: анализ, рефакторинг блока А с добавлением новых функций, рефакторинг блока Б с добавлением новых функций, создание нового блока В. Каждую сдаем и выпускаем отдельно, тестеры счастливы.
Нужно научиться «продавать» менеджерам и бизнесу эту необходимость. И теханализ тут доп. аргумент — чтобы это сделать, надо предварительно зарефакторить блок А. Почему? А вот документ, мы его все обсудили и согласны. С большим архитектором согласовано.
> Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Хех. В анализе обычно как раз и нужно смотреть на границы между блоками. Вот есть такое API у связанного блока как вам нужно или нет? Если нет — то вы на анализе должны это увидеть, и подзадачу выделить. И кстати там же «похоже с ходу не выйдет, код надо рефакторить».
> Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё.
А часто бывает? В этих случаях надо копать в анализ и его качество, увы. Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
Сочувствую боли. Бывают такие архитекторы и менеджеры (которые сваливают свою обязанность управлять командой на программистов). Как их бороть — ортогональный вопрос. Но если они загружены фуллтайм записыванием за вами мыслей, то это сильно облегчает им доказательство их полезности. Ведь они вот сколько документов подготовили.
У нас архитекторы не только согласуют документы — на них лежат и планируются задачи по discovery, разработке концепций, больших архитектурных изменений. И мы можем от них это требовать благодаря этому. И на встречи с технарями заказчика или других команд тоже можем попросить сходить их, а не программиста — т.к. они все читаю, верхеуровневая картинка в голове у них есть
3.Какой толк от архитектора? Я видел (в том числе в упомянутых компаниях) с подходом, где каждую задачу берет себе архитектор и по ней пишет такой документ. В целом во многих командах при изначальном внедрении этого подхода так и делают — есть лид, он пишет такую доку по всем задачам.
К чему это приводит? В первую очередь к перегрузке архитектора/лида. Документы начинают писаться формально. Сроки затягиваются, те самые менеджеры заставляют программистов параллельно код писать. Документы становятся бесполезнее, пишутся еще формальнее, программисты прекращают их читать.
Попытка «расшива» этого узкого места приводит к найму в архитекторы людей, кто норм к написанию формальных документов и не обладают глубокими техническими знаниями. Они становятся еще бесполезнее, архитекторов прекращают уважать, принятие реальные архитектурных решений в компаний уходит от архитекторов в неформальную иерархию (обычно в руки тимлидов).
Это неудачная попытка внедрения предлагаемой вами схемы. А удачная приводит вот к чему — программисты при успешном внедрении этой схемы снижают свою роль до манкикодинга. У них нет ответственности за качество своего решения, они демотивированы (хорошие программисты не любят этого).
Тут (как я пишу в статье) программисты реально вовлечены в разработку решений, могут проявить свой креатив. Архитекторы консультируют, согласуют и надзирают, да. Но у них освобождается запас времени от текучки.
Если под ТЗ подразумевать бизнес-требования или функциональные требования, то теханализ пишется на основе этих документов. Работу аналитика это не исключает. Почему аналитик не может сразу писать про технические решения — ответ есть в статье.
Менеджер вообще к ТЗ отношения не имеет. Он может организовать его написание, но сам написать не может. Нужен ли менеджер в принципе — ответ для другого поста.
А надо между сотнями таблиц, то есть десятками разных сущностей поддерживать непротиворечивость?
Как правило бизнесу в большинстве случаев достаточно eventual consistensy. Главное понять, где достаточно, а где нет :-)
Как вообще жить в таких системах моднейше можно прочитать в книгах по DDD. Эта моднота придумана кажется 30 лет назад :-)
Быстрого простого нет. Но вообще есть. Самое лучшее время начать описывать что происходит было в начале проекта. Следующее лучшее время сейчас :-)
Почему целый спринт? Вася в этом спринте делает фичу, а Петя делает анализ фичи для следующего спринта и фиксит пять багов.
А ГОСТ если что и сейчас есть.
Можно через оценки. А давайте все задачи оценивать, чтобы знать когда мы их сделаем. А для оценки нужно текстик написать небольшой. А если программист неправильно оценит, пусть за ним архитектор проверит....
Почему в середине проекта? В середине спринта.
Ну да, надо повторно уйти на теханализ. Такое бывает, и это ничем не отличается от «на ревью выяснилось что все надо переделать», только реже случается.
Ну БД с сотнями таблиц ныне считается антипаттерном. А так все правильно.
Так, а по вашему из этой ситуации невозможно выйти? :-)
Где-то эту гонку легаси, в котором хрен разберёшься без залезания в код, надо остановить.
Жесть! А так если что получается взять и написать теханализ с «чтобы это реализовать, мы планируем выкинуть такой-то функционал, а вот этот упростить». И получить галочку от владельца продукта. Или от аналитика, который со всеми все согласует и возьмет на себя ответственность.
Т.е. планируете заставить их все же придумывать все за вас? Думаете удастся? Я думаю нет.
Еще добавлю. Рефакторить все подряд под бизнес задачами — плохая практика. Полная непредсказуемость. затягивание сроков, нестабильность, гигантский объем затронутого функционала на ретест. Но от нее отказаться можно только, если мы сможем добиться, что сторька будет решаться несколькими связанными задачами: анализ, рефакторинг блока А с добавлением новых функций, рефакторинг блока Б с добавлением новых функций, создание нового блока В. Каждую сдаем и выпускаем отдельно, тестеры счастливы.
Нужно научиться «продавать» менеджерам и бизнесу эту необходимость. И теханализ тут доп. аргумент — чтобы это сделать, надо предварительно зарефакторить блок А. Почему? А вот документ, мы его все обсудили и согласны. С большим архитектором согласовано.
> Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Хех. В анализе обычно как раз и нужно смотреть на границы между блоками. Вот есть такое API у связанного блока как вам нужно или нет? Если нет — то вы на анализе должны это увидеть, и подзадачу выделить. И кстати там же «похоже с ходу не выйдет, код надо рефакторить».
> Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё.
А часто бывает? В этих случаях надо копать в анализ и его качество, увы. Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
Сочувствую боли. Бывают такие архитекторы и менеджеры (которые сваливают свою обязанность управлять командой на программистов). Как их бороть — ортогональный вопрос. Но если они загружены фуллтайм записыванием за вами мыслей, то это сильно облегчает им доказательство их полезности. Ведь они вот сколько документов подготовили.
У нас архитекторы не только согласуют документы — на них лежат и планируются задачи по discovery, разработке концепций, больших архитектурных изменений. И мы можем от них это требовать благодаря этому. И на встречи с технарями заказчика или других команд тоже можем попросить сходить их, а не программиста — т.к. они все читаю, верхеуровневая картинка в голове у них есть
Зависит от подхода. Если у нас контрактная разработка, там это придется сделать, но там свои приколы. Я скорее про модную agile продуктовую
Обычно аналитик как раз за предметную область и то, как с ее языка переводить на язык требований
3.Какой толк от архитектора? Я видел (в том числе в упомянутых компаниях) с подходом, где каждую задачу берет себе архитектор и по ней пишет такой документ. В целом во многих командах при изначальном внедрении этого подхода так и делают — есть лид, он пишет такую доку по всем задачам.
К чему это приводит? В первую очередь к перегрузке архитектора/лида. Документы начинают писаться формально. Сроки затягиваются, те самые менеджеры заставляют программистов параллельно код писать. Документы становятся бесполезнее, пишутся еще формальнее, программисты прекращают их читать.
Попытка «расшива» этого узкого места приводит к найму в архитекторы людей, кто норм к написанию формальных документов и не обладают глубокими техническими знаниями. Они становятся еще бесполезнее, архитекторов прекращают уважать, принятие реальные архитектурных решений в компаний уходит от архитекторов в неформальную иерархию (обычно в руки тимлидов).
Это неудачная попытка внедрения предлагаемой вами схемы. А удачная приводит вот к чему — программисты при успешном внедрении этой схемы снижают свою роль до манкикодинга. У них нет ответственности за качество своего решения, они демотивированы (хорошие программисты не любят этого).
Тут (как я пишу в статье) программисты реально вовлечены в разработку решений, могут проявить свой креатив. Архитекторы консультируют, согласуют и надзирают, да. Но у них освобождается запас времени от текучки.
Если под ТЗ подразумевать бизнес-требования или функциональные требования, то теханализ пишется на основе этих документов. Работу аналитика это не исключает. Почему аналитик не может сразу писать про технические решения — ответ есть в статье.
Менеджер вообще к ТЗ отношения не имеет. Он может организовать его написание, но сам написать не может. Нужен ли менеджер в принципе — ответ для другого поста.