Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
eXtreme Manufacturing
HR
JTBD
Kanban
KPI
LeSS
OKR
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Скрам в Производстве
Фасилитация
Финансы
Холакратия
Экстремальное производство
Применить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15 май 2018, Сергей Баранов
Тренинги по теме
Другие статьи
7 июл 2020, Иван Селеверстов
Как сформировать качественные OKR

Чтобы помочь вам сделать OKR лучше, мы придумали критерии оценки и оформили их в чек-лист. При помощи набора вопросов вы можете проверить ваши OKR и получить оценку в баллах. Сумма баллов покажет вам, насколько вы близки к вашему Good enough, стоит ли провести еще один раунд доработок. Сами вопросы в чек-листе подскажут направление для улучшений.

6 июл 2020, Дмитрий Круглов
Темная сторона Agile

Спустя некоторое время после перехода, например, на Scrum, компании начинают сталкиваться с новыми вызовами, порожденными гибкими методологиями. И мало кто рассказывает, что Agile потянет за собой дорогие и долгие задачи по архитектуре, инфраструктуре, процессам и, что особенно сложно, культуре.

6 июл 2020, Сергей Рогачев
Совместное формирование квартальных OKR на сотни человек

OKR в крупных организациях требует изменения мышления сотрудников, поэтому нужны специальные инструменты для выработки целей, обеспечения вертикальной и горизонтальной согласованности.