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

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

Linus Torvalds, creator of Linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фичи изначально определяются с помощью Матрицы Фич и Преимуществ (Features and Benefits, FAB Matrix):

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

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

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

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

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

На рисунке 2 показан пример FAB с четырьмя разными фичами:

Рисунок 2. Матрица фич и преимуществ

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

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

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

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

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

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

Оценка Фич

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

Приемка Фич

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

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

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

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

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

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

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

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

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

Капабилити должны быть декомпозированы на фичи для последующей разработки. Фичи в свою очередь разбиваются на Истории, которые команды берут в работу в рамках Итерации. 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»