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

Одной из ценностей SAFe является «Выравнивание» или обеспечение согласованности и со-направленности действий большого числа участников Lean-Agile организации. Одним из, но не самым эффективным способом достижения хотя бы частичного выравнивания является микро-менеджмент, когда лидеры оперируют огромным количеством очень мелких задач, обсуждая каждую из них с большим количеством заинтересованных лиц и еще с большим количеством разработчиков.

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

В SAFe эта проблема решается с помощью настоящей децентрализации системы принятия решений, которая во многом становится возможной благодаря использованию каскадной модели управления задачами. В организации среднего размера появляются как правило 3 уровня задач разного масштаба: Эпики, Фичи и Истории.

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

В результате такого каскадного подхода к управлению требованиями, с одной стороны, все участники разработки действуют в рамках единого списка задач (беклога), декомпозированного на масштабы, а с другой, благодаря наличию этих масштабов, удается на практике децентрализовать принятие решений и управление без «впадания» лидеров в ситуативный микроменеджмент, на практике не приносящий стабильных результатов.

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

Эпики

Эпики – это значительные инициативы предприятия по разработке решений. Бизнес-Эпики ориентированы на клиентов. Энейблер-Эпики создают технические возможности для реализации бизнес-задач.

Характеристики Эпика:

• Реализуется несколькими потоками ценности в рамках нескольких Интервалов Планирования (Planning Interval, PI).
• Управляется в Беклоге Портфеля.
• Содержит обязательные компоненты: определение MVP, понимание ROI, наличие Бережливого Бизнес Кейса и утверждение со стороны LPM.
• Декомпозируется на Фичи и Фичи-Энейблеры. В конфигурации Крупное Решение – на Капабилити.

Эпики могут также существовать на уровне Поезда Решения или Релизного Поезда, когда не требуется управление ими со стороны LPM.

Капабилити

В конфигурации Крупное Решение используются Капабилити (Возможность, Capability). Они представляют собой функциональность для крупных решений. Могут быть Бизнес-Капабилити и Энейблер-Капабилити.

Характеристики Капабилити:

• Появляется в результате декомпозиции Эпиков или из локального контекста Поезда Решения.
• Реализуется несколькими Релейными Поездами (Agile Release Train, ART) в один Интервал Планирования (Planning Interval, PI).
• Требует более высокоуровневого понимания создаваемых MMF.
• Управляется в Беклоге Поезда Решения.
• Декомпозируется на Фичи и Фичи-Энейблеры.
• Содержит обязательные компоненты: название (краткое описание), гипотеза выгоды, критерии приемки

Фичи

(Бизнес) Фича – это функциональность решения, которая доставляет бизнес ценность и удовлетворяет потребности заинтересованных лиц. Фича-Энейблер – это технические возможности для реализации функциональности решения.

Характеристики Фичи:

• Появляется в результате декомпозиции Эпика или Капабилити или из локального контекста Релизного Поезда (Agile Release Train, ART).
• Реализуется одним ART в рамках одного Интервала Планирования (Planning Interval, PI).
• Управляется в Беклоге Релизного Поезда (ART). Менеджмент Продукта отвечает за (Бизнес) Фичи в Беклоге Релизного Поезда. Архитекторы Систем отвечают за Фичи-Энейблеры.
• Содержит обязательные компоненты: название, гипотеза выгоды, критерии приемки
• Декомпозируется на Истории и Истории-Энейблеры.

Истории

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

Характеристики Истории:

• Появляется в результате декомпозиции (Бизнес) Фичи или Фичи-Энейблера или из локального контекста команды.
• Реализуется одной командой в течение нескольких дней или быстрее.
• Управляется в Беклоге Команды. Владелец Продукта отвечает за Истории в Беклоге Команды.
• Содержит обязательные компоненты: критерии приемки и рекомендуемый формат написания – голос пользователя.

Энейблеры

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

К Энейблерам относятся исследования, разработка архитектуры, создание инфраструктуры и обеспечение соответствия регуляторным требования.

Энейблеры существуют на разных уровнях фреймворка и фиксируются в соответствующих беклогах:

• Эпик-Энейблер (Беклог Портфеля)
• Капабилити-Энейблеры (Беклог Поезда Решения). Используются в конфигурации «Крупное Решение»
• Фичи-Энейблеры (Беклог Релизного Поезда)
• Истории-Энейблеры (Беклог Agile Команды)