День 1622. #ProjectManagement
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Начало
Обычно бывает так: опытная команда блестящих инженеров запускает новый продукт, клиентам нравится, фичи релизятся как из автомата. А спустя какое-то время внезапно продуктивность падает, выпускать новые функции всё сложнее, клиенты недовольны, инженеры устают от работы больше, чем когда-либо прежде, и призывают переписать всё с нуля. Время паники. Что случилось?

Первые признаки ухудшения
Команды похожи на огороды. Вначале растения мелкие, сорняков мало. Затем, из-за того, что вы не пропалывали, не поливали и не подкармливали, половина растений погибла, а другая превратилась в джунгли. Три вещи заставляют команды переходить в режим бурлаков:
- Первоначальные архитектурные решения были неверны или основывались на несовершенных предпосылках.
- Команда вынуждена выпускать продукт любой ценой, откладывая работу над техническим долгом.
- У команды нет системного плана решения проблем долга по мере роста системы.

Технический долг — убийца команд. Думайте о функциях и долге как о кредитной карте. Залезать в долги по кредитке каждый месяц — это нормально. Однако высокая процентная ставка разорит вас, если вы не выплатите долг.

Уменьшение объёмов предоставляемых функций при увеличении серьёзности возникающих проблем указывает на то, что команда в опасности. Если команда замедлилась с выпуска пяти средних и крупных функций в квартал до 1 функции с 3-кратным увеличением количества серьёзных ошибок за тот же период без изменений в составе команды, она движется к провалу. Задача для любого хорошего лидера в том, чтобы постоянно поддерживать минимальный уровень технического долга, позволяя команде продолжать выпускать функции.

Хорошая практика №1: постоянные обзоры архитектуры
Обзоры архитектуры распространены в начале проекта. Сначала команда придерживается надёжных архитектурных принципов, система не слишком сложна в обслуживании и т. д. Как только выходит версия 1.0, команда обычно прекращает рассмотрение новых функций с точки зрения влияния на архитектуру в пользу быстрой доставки. Это компромисс. Нет времени пересматривать архитектурные изменения. Но правильно ли это? Понимаем ли мы растущую систему?

Что делать?
Необходим официальный анализ архитектуры каждой новой функции среднего и крупного размера. Назначьте команде фиксированное время для рассмотрения влияния на архитектуру всех новых функций. 3-5 страниц или слайдов обзора с 1-3 диаграммами архитектуры вполне достаточно. Включите требование о проведении архитектурного анализа во все планы проекта. Все участвуют в рассмотрении, и все оценивают.

Зачем?
- Все в команде понимают, что делают все члены команды.
- Команда может взвесить технические компромиссы до того, как код будет написан и помещён в репозиторий — тогда обычно уже слишком поздно.
- Сложность системы и потенциальные проблемы со стабильностью, производительностью и масштабируемостью выявляются заранее.
- Команда создаёт архив диаграмм, чтобы будущим товарищам по команде было проще адаптироваться.
- Младшие инженеры узнают, как легко создавать более сложные системы.
Непрерывные обзоры архитектуры — первая защита от деградации проекта. В конечном счёте 30-минутная встреча в будущем сэкономит месяцы. Поэтому обозревайте архитектуру заранее, регулярно и используйте обзоры как средство раннего предупреждения.

Продолжение следует…

Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43