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