Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
LeSS
OKR
PMI
Project management
SAFe
Scrum
Scrum-мастер
Архитектура
Бюджетирование
Игра
Инженерия
Конфликты
Обучение
Фасилитация
Применить

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

Как работать с архитектурой в Scrum?

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

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

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

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

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

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

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

Архитектурная фитнес-функция

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

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

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

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

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

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

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

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

Отсутствие монополии на изменения
Отсутствие монополии на изменения

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

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

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

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

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

15 май 2018, Сергей Баранов
Тренинги по теме
Другие статьи
lagging-kpi-square
15 май 2018, Сергей Рогачев
Опережающие и запаздывающие показатели

В управлении результативностью работы мы часто говорим про “запаздывающие” (lagging) и “опережающие” (leading) показатели. Что это такое?

Создание компонентной структуры продукта
15 май 2018, Сергей Баранов
Создание компонентной структуры продукта

Описание воркшопа по созданию компонентной структуры продукта

Многообразие способов описания архитектуры
13 май 2018, Сергей Баранов
Эффективные способы описания архитектуры

Первая из цикла статей, посвященных эффективным способам описания архитектуры.