Архитектура в Scrum

Scrum не предписывает явных правил работы с архитектурой. И правильно — команда вольна сама выбирать практики и процессы для получения максимальной отдачи при разработке продукта. Правда, есть нюанс — без хорошо развитой инженерной культуры достигнуть положительного результата становится в разы сложнее, если вообще возможно. Разберем, как может выглядеть подход к работе над архитектурой в Scrum-команде.

Первое, с чего начинаем — Бэклог. Именно он определяет, что из себя будет представлять продукт. При этом не забываем, что после каждого следующего спринта наше представление о продукте может измениться, а значит — может измениться Бэклог. Архитектура в таком случае должна  быть достаточно гибкой и поддерживать эволюционное развитие.

Возникает противоречие:

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

Круг замкнулся, так как же быть?

В начале разработки архитектура не должна быть сильно детальной, она должна задавать направление эволюционного развития системы. Для того, чтобы определить меру приспособленности решения к изменяющемуся контексту, в котором оно используется, применяются архитектурные фитнес-функции. Например, можно написать тест на то, что все сервисы отвечают менее, чем за 100 мс и тест, определяющий цикломатическую сложность, для которого архитектор может установить максимальные пороговые значения, контролируемые в процессе непрерывной интеграции.

Хорошая практика — проведение архитектурных воркшопов на первый или второй день спринта. Цель такого воркшопа — понимание и информированность всех членов команды о том, как будут реализованы истории текущего спринта и как эти решения вписываются в долгосрочную архитектурную стратегию. Например, можно провести воркшоп, на котором задать фитнес-функцию и создать компонентную структуру продукта.

Последующие встречи по планированию будут проходить вокруг артефактов, полученных на подобных воркшопах. В случае с компонентной диаграммой больше не придется мучительно вспоминать [не всегда успешно] какие компоненты затронут изменения — берем очередную историю, ведем её по диаграмме и выписываем технические истории на изменение каждого компонента. Просто, быстро, эффективно.

По мере разработки продукта команда будет получать обратную связь об архитектуре:

• Насколько просто добавить новую фичу?
• Инсайты, ведущие к изменению архитектуры

Как получать обратную связь об архитектуре при частичной готовности системы?

Например, с помощью mock-объектов, используемых для изоляции зависимостей от баз данных, файловых систем, пользовательских интерфейсов и оборудования. Они позволяют с некоторой долей уверенности посмотреть на то, как система будет вести себя в боевой среде.

С каждой фичей архитектура эволюционирует и в каждый момент времени мы имеем архитектуру, эффективно решающую поставленные задачи. Иными словами, каждый разработчик в Scrum-команде развивает архитектуру, но нужно и важно сделать это ответственностью команды, ведь одна из задач архитектуры — помочь разработчикам в эффективном решении стоящих перед ними задач. Как этого добиться? Обсуждать новые идеи вместе, учитывая интересы не только разработки, но и безопасности, эксплуатации, бизнеса и прочих заинтересованных сторон.

Следует помнить, что когда каждый может изменить архитектуру в контексте решения его конкретной проблемы, локальные архитектурные решения могут быть не оптимальными с точки зрения более широкого контекста. Такие локальные решения должны быть трансформированы в глобальные. Как нельзя лучше этот подход описан в SAFe:

На ретроспективе или отдельной встрече в конце спринта команда проводит архитектурное ревью и решает, требуется ли архитектурный рефакторинг. Это важная часть окончания спринта, о которой часто забывают, что ведет к загниванию дизайна. Например, вы можете посмотреть на соответствие параметров определенной ранее фитнес-функции и в случае отклонений своевременно (с запозданием не более, чем в спринт, а в идеальном случае — непрерывно) принять соответствующие меры.

Так же в конце бывает полезным оценить технический долг:

• Выявить все исправления (rework) за спринт
• Выявить причины их появления
• Если требуется — запланировать архитектурные изменения, позволяющие снизить или устранить причины появления исправлений
• Выявить метрики, помогающие помогающие контролировать уровень технического долга в разрезе обнаруженных причин
• Добавить значения измерений в критерии готовности и, если требуется, в фитнес-функцию системы
• Добавить контроль метрик в процесс непрерывной интеграции

И не забываем про основополагающий принцип:

Валидация архитектуры невозможна через документы. Архитектура является валидной только в том случае, если это подтверждается работающим кодом — инкрементом продукта.