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, Сергей Баранов
Тренинги по теме
Другие статьи
16 сен 2018, Алексей Гельман
Путешествие в OKR: руководство по внедрению

Основное препятствие при внедрении OKR – отсутствие руководства по внедрению. Как внедрить OKR? Как использовать OKR на масштабе? Как соединить OKR и Agile?

12 сен 2018, Игорь Филипьев
TWiG – The WIP Game – супер-простая игра по Канбану

Фасилитационные материалы для самостоятельного проведения.

26 авг 2018, Сергей Рогачев
OKR для начинающих #2

Перевод книги “OKR для начинающих” Фелипе Кастро, часть 2