Фичи и Капабилити (Features & Capabilities)

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

Linus Torvalds, creator of Linux

Что такое Фичи и Капабилити?

Фича (Feature) — это функциональность решения, которая обеспечивает бизнес-ценность, удовлетворяет потребности заинтересованных лиц и может быть реализована с помощью одного Agile Release Train (ART) в рамках одного Интервала Планирования (Planning Interval*, PI). *Интервал Планирования — это новый термин, который используется в SAFe 6.0 и заменяет термин Инкремент Программы (Program Increment). 

Каждая Фича включает в себя гипотезу выгоды и критерии приемки, а также имеет размер (или при необходимости декомпозируется), чтобы быть разработанной одним ART за один PI.

Капабилити (Возможность, Capability) — это функциональность крупного решения, которая обычно охватывает несколько ART и реализуется в рамках одного Интервала Планирования (PI).

Фичи также создаются, используя модель процесса Lean UX, которая включает в себя определение Минимальной Рыночной Фичи (Minimum Marketable Feature, MMF), гипотезу выгоды и критерии приемки. MMF помогает ограничить объем работ и инвестиции, повышает гибкость и обеспечивает быструю обратную связь. Капабилити (Возможности) ведут себя так же, как и фичи. Однако они находятся на более высоком уровне абстракции (имеют бОльший масштаб) и поддерживают определение и развитие крупных Решений.

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

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

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Фичи и Капабилити занимают центральное место в модели требований SAFe. Они имеют решающее значение для определения, планирования и реализации ценности Решения. На рисунке 1 представлен более широкий контекст для этих рабочих элементов:

Рисунок 1. Фичи в контексте SAFe

На рисунке 1 показано, что решения разрабатываются с использованием Фич. Каждая Фича отражает сервис, предоставляемый системой. Система в свою очередь удовлетворяет важные требования заинтересованных лиц. Фичи находятся в Беклоге Релизного Поезда (ART Backlog) и имеют размер, позволяющий завершить их разработку за Интервал Планирования (PI). Таким образом, каждая Фича доставляет новую ценность за определенный период. Фичи могут возникать либо из локального контекста Agile Release Train (ART), либо в результате разделения Эпиков или Капабилити.

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

Менеджмент Продукта и Архитекторы Систем владеют фичами и энейблерами соответственно. Нефункциональные требования (НФТ/NFR) определяют атрибуты системы, такие как безопасность, надежность, производительность, удобство обслуживания, масштабируемость и удобство использования. NFR выполняют роль требований или ограничений для проектирования системы во всех беклогах, к которым они относятся.

Фичи расставляются по приоритетам с помощью WSJF. Они планируются и рассматриваются на границах Интервала Планирования. Фичи разделены на истории и разрабатываются, интегрируются, тестируются и демонстрируются по мере появления соответствующей функциональности.

Поиск, выявление и описание Фич

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

Фичи определяются с помощью формата «Фичи и Преимущества (Гипотеза Выгоды)»:

• Фича – Короткая фраза, дающая имя и контекст (краткое описание и краткое обозначение области применения)
• Гипотеза Выгоды – Предполагаемая измеримая выгода для конечного пользователя или бизнеса предприятия

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

Ключевые вопросы, ответ на которые нужно держать в уме при формулировании Гипотезы Выгоды: «кто именно является клиентом для данной Фичи?» и «какая выгода делает данную Фичу востребованной со стороны этого клиента?»

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Не определяйте фичи с помощью формата «голос пользовательской истории» (Голос Клиента / Голос Пользователя), который предназначен для поддержки одной роли пользователя. Обычно Фичи предоставляют функциональные возможности для нескольких ролей пользователей. Кроме того, использование одного и того же метода для описания пользовательских историй и фич может запутать большинство представителей бизнеса, тем более что они обычно не знакомы с Историями.

На рисунке 2 показан пример Фич с гипотезами выгоды:

Рисунок 2. Фичи и гипотезы выгоды

Создание Фич и управление ими

Менеджеры Продукта в сотрудничестве с Владельцами Продукта и другими ключевыми заинтересованными лицами определяют фичи в локальном контексте Agile Release Train. Некоторые фичи возникают в результате декомпозиции эпиков.

Архитекторы Систем обычно создают фичи-энейблеры. Беклог Релизного Поезда (ART Backlog) используется для хранения энейблеров наряду с бизнес-фичами. Энейблеры «прокладывают путь» для реализации Архитектурного Русла, поддерживают исследования или могут обеспечить инфраструктуру, необходимую для разработки, тестирования и интеграции результатов.

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

Приоритизация Фич

Модель приоритизации WSJF используется для определения последовательности выполнения работ (например, фич, капабилити) на основе экономики потока разработки продукта. Поскольку реализация необходимых работ в правильной последовательности дает максимальную экономическую выгоду, трудно переоценить важность этого процесса.

Менеджент Продукта и Решения отвечает за приоритизацию фич, в то время как Архитекторы Систем и Решения — за приоритизацию энейблеров.Поскольку бизнес-фичи и энейблер-фичи находятся в одном и том же беклоге, Менеджмент Продукта и Решения должен взаимодействовать с Архитекторами Систем и Решения для урегулирования различий в приоритетах. Существует 2 подхода к обеспечению со-направленности и сбалансированности в беклоге – это выравнивание приоритетов в соответствии со Стратегическими Темами и аллокацией ёмкости.

Оценка Фич

Оценка фич позволяет спрогнозировать доставку ценности с помощью модели приоритизации WSJF и определить размер эпиков, разделяя их на фичи и суммируя оценки каждой из них. Оценка фич обычно происходит на стадии анализа Канбана Поезда (ART Kanban) и опирается на нормализованные методы оценки. В ходе анализа профильные эксперты из Agile Release Train принимают участие в исследованиях и предварительной оценке размера. На стадии анализа определение размера фич не требует проведения декомпозиции их на истории или подключения всех команд, которые могут их разработать.

Приемка Фич

Критерии приемки Фич используются для определения того, является ли реализация правильной и обеспечивает ли она преимущества для бизнеса. На рисунке 3 приведен пример:

Рисунок 3. Фича с критериями приемки

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

Менеджмент Продукта несет ответственность за приемку фич. С помощью критериев приемки продуктовый менеджмент определяет, правильно ли реализована функциональность и выполнены ли нефункциональные требования.

Капабилити (Возможности)

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

• Описываются с помощью фразы (краткие имя и контекст) и гипотезы выгоды
• Имеют размер, позволяющий разработать их за один Интервал Планирования (PI). При этом обычно требуется вовлечение нескольких Agile Release Train.
• Обоснованы и одобрены с использованием Канбана Поезда Решения (Solution Train Kanban). Беклог Поезда Решения содержит утвержденные возможности (капабилити).
• Имеют связанные с ними энейблеры. Это позволяет описать и показать всю техническую работу, необходимую для поддержки эффективной разработки и доставки бизнес-капабилити.
• Принимаются Менеджерами Решения, которые используют критерии приемки для определения того, соответствует ли функциональность назначению.

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

Декомпозиция фич и капабилити

Капабилити должны быть декомпозированы на фичи для последующей разработки. Фичи в свою очередь разбиваются на Истории, которые команды берут в работу в рамках Итерации. SAFe предоставляет десять шаблонов для разделения работы, как описано в книге Leffingwell [1], глава 6.

• Шаги рабочего процесса
• Варианты бизнес-правил
• Значительные усилия
• Простой/сложный
• Различия в данных
• Различия в методах данных
• Выделение отдельных качеств системы
• Особенности эксплуатации
• Сценарии использования
• Выделение спайка (исследования, эксперимента)

На рисунке 4 показано разделение капабилити на фичи:

Рисунок 4. Декомпозиция капабилити на фичи

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

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

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Cтатья «WSJF, Weighted Shortest Job First»