Comments 4
"Внедрять" ADR без нагрузки на команду:
-назначить ответственных за внедрение ADR;
-назначить ответственного за ведение ADR;
- назначить ответственных за актуальность архитектурных решений ;
- "сделать" ведение ADR частью процесса - это же и есть цель!
Отличный рецепт. Именно так обычно "внедряют" "аджайл" (да и любые другие модные слова). Нужен еще комитет по контролю соответствия проектных решений записям ADR.
Спасибо, пойду издам приказ о создании рабочей группы по внедрению и назначу совещание.
Приветствую.
Верно, нагрузка возрастет, но не значительно. Из моего опыта: за внедрение, ведение и актуализацию обычно отвечают 1—3 человек (в зависимости от размера команды). Если у вас такая небольшая команда, думаю ведение документации может быть не особо необходимым, но да — всё зависит от специфики проекта.
Если прочитать статью, можно заметить такие моменты:
Сопротивление команды ... Не всем членам команды нужно писать ADR, только опытным разрабам, за которыми и стоит окончательные решения... показать реальные преимущества, начать с малого, использовать простой шаблон
---
Осознанное применение ... Важно применять ADR осознанно, избегая превращения его в бюрократическую обязанность для всех членов команды.
---
Перегрузка информацией ... Документировать только главные / важные / основные решения
Я понимаю ваши опасения по поводу возможной бюрократии при внедрении ADR и усложнения работы команде и прошу в статье учитывать это. Цель этого процесса — облегчить в результате работу команды, а не усложнить её.
У себя ввели этап дизайна фичи - отдельная сабтаска, в рамках которой разработчик описывает, каким образом фича будет реализована. Проходит дизайн-ревью, и уже после создаются сабтаски по согласованной реализации. В итоге, если есть вопрос по коду - можно посмотреть, в рамках какой фичи был добавлен код и там же посмотреть, почему именно такой.
Не покрывает всю кодовую базу, но там, где процесс работает, вопросов в духе «почему так» практически не возникает.
Как применяющий ADR совместно с практикой Architecture as Code, не вполне понимаю трудности, описанные в статье. Если компания не доросла до необходимости иметь отдельную роль архитектора, ADR не нужен. Это кейс Алексея.
ADR это не ещё одна документация решения, а слой принципов по построению всех решений компании в среднесрочной перспективе. Не только про техстек, но и про минимальную квалификацию, которая этому техстеку нужна, паттерны проектирования, инструменты, степень контроля, его виды, пределы рисков на который бизнес готов идти, стандарты и требования регулятора на рынках присутствия. ADR еще это инструмент выявления технического долга, уголовный кодекс для тех лидов, который снимает холивары и дискуссии об идеальной архитектуре с повестки дня.
Насчёт нехватки материалов, можете глянуть iSAQB, там все открыто разве что кроме ответов на экзамены. У них есть Слак на немецко английском, но могу и тут ответить, если что...
ADR: Как сохранить архитектурные решения и избежать повторения ошибок