Блог
Беклоги Релизного Поезда (ART) и Поезда Решения

Беклоги Релизного Поезда (ART) и Поезда Решения

3 апреля 2024

Беклог Релизного Поезда (ART Backlog) — это список Фич и Энейблеров, предназначенных для улучшения Решения и расширения его Архитектурного Русла. Все элементы работы беклога поезда организуются в единую Kanban систему Релизного Поезда.

Беклог Поезда Решения (Solution Train Backlog) – это список Капабилити (Возможностей) и Энейблеров, предназначенных для улучшения Крупного Решения и расширения его Архитектурного Русла. Все элементы работы беклога поезда организуются в единую Kanban систему Поезда Решения.

Беклоги Релизного Поезда (ART) и Поезда Решения содержат Фичи, Капабилити (Возможности) и нефункциональные требования (NFR) Решения, которые будут взяты в разработку в ближайшее время. Управление беклогом является важным экономическим инструментом для поездов и портфеля.

Менеджмент Продукта отвечает за Беклог Релизного Поезда (ART Backlog), а Менеджмент Решения — за Беклог Поезда Решения (Solution Train Backlog). Эти беклоги визуализируются и управляются с помощью Канбан систем, где Фичи, Возможности (Капабилити) и Энейблеры собираются, определяются, развиваются и расставляются по приоритетам, чтобы обеспечить непрерывный поток ценности для клиентов.

Менеджмент Продукта и Менеджмент Решения разрабатывают, поддерживают и приоритизируют беклоги Релизного Поезда (ART) и Поезда Решения соответственно. Они активно взаимодействуют с заинтересованными лицами, включая Клиентов, Владельцев Бизнеса, Владельцев Продукта, Архитекторов Систем и Решения и других (например, Release Train Engineer (RTE) / Solution Train Engineer (STE), чтобы выявить Фичи и Капабилити, необходимые для развития решения.

Рисунок 1 иллюстрирует беклоги Agile Release Train и Solution Train и источники вводных данных для них:

Эпики Портфеля декомпозируются на Фичи и Капабилити
Капабилити и Энейблеры, которые возникают из локального контекста Поезда Решения
Капабилити Поезда Решения декомпозируются на Фичи и Энейблеры
Фичи и Энейблеры, которые появляются из локального контекста Релизного Поезда (Agile Release Train, ART)

Рисунок 1. Источники вводных данных для беклога Релизного Поезда и беклога Поезда Решения

Правильным образом разработанное решение должно отвечать всем функциональным и нефункциональным требованиям (НФТ, NFR). НФТ, показанные под списком элементов беклога на рисунке 1, служат ограничениями для всего беклога, влияя на дизайн и производительность решения. Они, как правило, фиксируются в критериях приемки или входят в Определение Выполненности (Defition of Done, DoD). НФТ представляют собой постоянно действующие условия, и Agile Release Train регулярно возвращается к ним, чтобы проверить выполнение элементов беклога.

Создание и уточнение беклога

Менеджмент Продукта и Менеджмент Решения непрерывно уточняют свои беклоги и обеспечивают поток доставки ценности для клиентов. В результате беклоги содержат в том числе Фичи и Капабилити, которые готовы к взятию в разработку. По этим элементам были проведены исследования, и они соответствуют допустимому уровню риска.

Уточнение Беклога Релизного Поезда (ART) и Беклога Поезда Решения часто включает в себя следующие действия до перехода в состояние «готово к разработке»:

Изучение и исследование новых Фич и Капабилити
Рассмотрение и обновление определений элементов беклога, включая разработку критериев приемки и гипотезы выгоды
Определение Энейблеров, необходимых для поддержки новых Фич и Возможностей (Капабилити)
Применение техник Разработки на основе Поведения (Behavior-Driven Development, BDD) для внесения ясности в Фичи и Капабилити или проведения мероприятий по выявлению спецификаций
Расстановка приоритетов в беклогах с помощью Weighted Shortest Job First (WSJF) при сотрудничестве с Владельцами Бизнеса, Архитекторами Систем, Владельцами Продукта и другими заинтересованными лицами, такими как Release Train Engineer (RTE) / Solution Train Engineer (STE)
Информирование Agile команд и заинтересованных лиц о Фичах и Капабилити, работа над которыми предстоит на ближайшем PI Планировании
Удаление устаревших и неактуальных элементов

Уточнение беклога часто происходит во время Синхронизации Владельцев Продукта (PO Sync). На этом мероприятии Менеджмент Продукта и Владельцы Продукта определяют новые элементы для беклога, пересматривают уже имеющиеся и удаляют устаревшие элементы. Для эффективного проведения PI Планирования и успешного выполнения всего Интервала Планирования необходимо постоянно поддерживать беклог в актуальном состоянии.

Управление беклогом с помощью Kanban

Канбан-системы Релизного Поезда (ART) и Поезда Решения (Solution Train) создают поток Фич и Капабилити (Возможностей) внутри Конвейера Непрерывной Доставки.

Рисунок 2 демонстрирует Канбан-систему ART с примерами политик и ограничений на количество незавершенной работы (НЗР, WIP), которые регулируют каждое состояние Канбан системы. Создание такой Канбан-системы является хорошей отправной точкой, при этом Канбан система должна быть адаптирована в соответствии с потребностями конкретного поезда, включая определение лимитов НЗР и конкретных политик для каждого шага.

Рисунок 2. Пример Канбан-системы ART или Solution Train

Поток в Канбан-системе ART и Solution Train проходит следующие состояния процесса:

Воронка (Funnel) – Здесь приветствуются все новые большие идеи, которые обычно представлены в виде Фич или Капабилити (Возможностей). Эти идеи могут указывать на необходимость новой функциональности, улучшения существующих функций системы или потребность в Энейблерах.
Анализ (Analyzing) – Новые идеи, которые согласуются с Видением Решения и Стратегическими Темами, дополнительно исследуются Agile командами, когда у них есть доступная ёмкость. Состояние «Анализ» включает в себя Непрерывное Исследование (например, клиентоцентричность, дизайн-мышление) и совместную работу для создания одной или нескольких качественно сформулированных фич (см. уточнение беклога выше). Ограничения по количеству незавершенной работы (НЗР) для этого состояния учитывают доступность Менеджмента Продукта и Менеджмента Решения, ёмкость команд и наличие других экспертов в предметной области.
Готово к разработке (Ready) – Фичи с наивысшим приоритетом, прошедшие стадию «Анализ» и утвержденные Менеджментом Продукта или Менеджментом Решения, переходят в это состояние. Эти Фичи приоритизированы относительно других элементов беклога с помощью WSJF. И они ожидают реализации.
Разработка (Implementing) – Фичи «вытягиваются» в состояние «Разработка» по мере того, как команды начинают работать над ними. Команды разрабатывают их на протяжении всего Интервала Планирования.
Валидация на промежуточной среде (Validating On Staging) – Этот шаг имеет два подсостояния: «В работе» и «Выполнено»:
— В работе (In Progress) – Фичи, которые разработаны и готовы к получению обратной связи, переходят в это состояние. Команды интегрируют и тестируют их с остальной частью системы в промежуточной среде и представляют на утверждение.
— Выполнено (Ready) – Утвержденные фичи перемещаются в буфер «Выполнено» этого состояния, где им снова с помощью WSJF присваивается приоритет в ожидании развертывания.
Развертывание в продуктивной среде (Deploying To Production) – Этот шаг также имеет два подсостояния: «В работе» и «Выполнено»:
— В работе (In Progress) – Фичи незамедлительно перемещаются в рабочую среду, если Непрерывная Доставка автоматизирована. Если доставка не автоматизирована, то Фичи переходят в состояние «В работе» для развертывания вручную, когда появится ёмкость.
— Выполнено (Ready) – Релизные Поезда (ART), которые отделяют развертывание от выпуска, для ожидания выпуска перемещают элемент в буфер «Выполнено» стадии развертывания в рабочей среде. В других случаях Фичи автоматически выпускаются, и пользователи могут сразу же получить к ним доступ. Это состояние ограничено количеством незавершенной работы (НЗР, WIP), чтобы избежать скопления развернутых, но еще не выпущенных Фич.
Выпуск (Releasing) – При наличии достаточной ценности, потребностей рынка и возможностей Фичи выпускаются для некоторой группе клиентов или всем клиентам, чтобы оценить гипотезу об их преимуществах.
Выполнено (Done) — после того, как Фича была выпущена и оценена, она переходит в состояние «Выполнено». При этом на основе полученной обратной связи от клиентов могут быть созданы новые элементы работы.

Управление Эпиками Релизного Поезда (ART) или Поезда Решения

Некоторые инициативы ART и Solution Train слишком велики, чтобы их можно было реализовать в рамках одного Интервала Планирования. Эти Эпики уровня ART или Solution Train идентифицируются и управляются в отдельной Kanban системе, как показано на рисунке 3. Кроме того, для обеспечения инкрементальной разработки для некоторых Эпиков Портфеля может потребоваться декомпозиция на Эпики ART и Solution Train.

Несмотря на то, что эти Эпики в основном связаны с локальной задачей, они могут оказывать достаточно большое влияние на финансовые, человеческие и другие ресурсы. В связи с этим для таких Эпиков потребуется создание Бережливого Бизнес-Кейса, обсуждение и одобрение инвестиций со стороны Lean Portfolio Management (LPM). Команда LPM рассматривает и утверждает Эпики, превышающие порог Эпика Портфеля. Это правило является важной Направляющей для расходования бюджета.

Основной целью Kanban системы Эпиков уровня Поездов является анализ и утверждение Эпиков ART и Solution Train, разделение их на Фичи или Возможности (Капабилити), которые будут в дальнейшем исследованы и реализованы с помощью Канбан системы ART или Solution Train. Отдельные Kanban системы для Эпиков ART и Solution Train могут не потребоваться, если количество таких Эпиков невелико.

Рисунок 3. Пример Канбан системы Эпика ART или Solution Train

Канбан система Эпиков ART или Solution Train похожа на Канбан систему Портфеля и имеет такие же состояния:

Воронка (Funnel) – Все крупные инициативы приветствуются в состоянии «Воронка». Ограничения на НЗР отсутствуют.
Рассмотрение (Reviewing) – Эксперты в предметной области (SME) и заинтересованные лица рассматривают Эпики и расставляют приоритеты, используя WSJF и другие критерии, чтобы определить, какие из Эпиков следует переместить на следующую стадию для более глубокого изучения. Если элемент превышает порог Эпика Портфеля, установленный LPM, он перемещается в Канбан Портфеля. Ограничения на количество незавершенной работы (НЗР) для этой стадии учитывают доступность экспертов в предметной области.
Анализ (Analyzing) – На этом этапе эксперты в предметной области и заинтересованные лица проводят следующие виды анализа:
- Уточнение размера Эпика и WSJF относительно других Эпиков
- Рассмотрение альтернативных решений
- Определение наборов Минимальной Рыночной Функциональности (Минимальные Маркетируемые Фичи, Minimum Marketable Features, MMF) и/или Минимально Жизнеспособных Продуктов (Minimum Viable Products, MVP)
- Прогнозирование затрат и определение технологий, построение архитектуры и инфраструктуры (Энейблеры) с помощью Бережливого Бизнес-Кейса

На основе проведенного анализа и полученной новой информацией, Менеджмент Продукта и Решения, а также Владельцы Бизнеса (и LPM, если это необходимо) утверждают или отклоняют Эпики. Утвержденные Эпики разбиваются на Фичи или Возможности (Капабилити) и перемещаются в состояние «Воронка» Канбан системы ART или Solution Train. Там им присваивается приоритет на основе WSJF. Ограничения на количество незавершенной работы (НЗР) применяются к состоянию «Анализ».

Как и в случае с Канбаном Портфеля, Эпики ART и Solution Train требуют выделение Владельца Эпика, который помогает их определить, исследовать и реализовать.

Баланс между доставкой ценности и обеспечением работоспособности решения с помощью Аллокации Ёмкости

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

Использование WSJF само по себе часто помогает «подсветить» проблемные вопросы и в результате достичь хорошего баланса между элементами работы разного типа. Если WSJF в отдельности недостаточно, то Менеджмент Продукта и Решения работает совместно с Архитекторами, чтобы сначала применить аллокацию ёмкости, и определить, какую часть от общих трудозатрат ART зарезервирует для каждого типа работ в рамках предстоящего Интервала Планирования. Затем в рамках установленных ограничений ёмкости применяется WSJF. На рисунке 4 показан пример распределения ёмкости.

Рисунок 4. Пример аллокации ёмкости на Интервал Планирования (PI)

Несмотря на то, что согласованное распределение ёмкости может сохраняться для нескольких Интервалов Планирования, его следует регулярно проверять на «адекватность» в ходе уточнения беклога при подготовке к PI планированию и при необходимости корректировать.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «ART and Solution Train Backlogs».

Дополнительно почитать:

Статья «Каскадная модель требований в SAFe»

Статья «Фичи и Капабилити»

Статья «Типы Энейблеров в SAFe»

Статья «WSJF»

Статья «Беклог Портфеля»