Функциональные характеристики и Функциональные возможности

Функциональная характеристика (feature) или фича представляет собой функциональность решения (Solution), которая обеспечивает ценность для бизнеса, удовлетворяет потребности заинтересованных лиц и имеет такой размер, чтобы быть реализованной одним Agile Release Train в рамках одного PI.

Каждая фича включает в себя ценностную гипотезу (benefit hypothesis) и критерии приемки (acceptance criteria), а также имеет размер или, при необходимости, разделена на части таким образом, чтобы их можно было реализовать с помощью одного Agile Release Train (ART) в PI.

Функциональные возможности (capabilities) представляют собой функциональность больших решений (Large Solution), реализация которых возможна только силами нескольких ARТов и которые имеют размер, позволяющие реализовать их в рамках PI.

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

Детали

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

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

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

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

Обнаружение и описание фич

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

Фичи определяются с использованием формата функций и ценностной гипотезы:

• Функция — короткая фраза, содержащая название и контекст фичи.
• Ценностная гипотеза — предполагаемая измеримая выгода для конечного пользователя или бизнеса.

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

На рисунке 2 показан примерный набор фич с ценностными гипотезами:

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

В сотрудничестве с Владельцами продукта (PO) и другими ключевыми заинтересованными лицами Менеджеры продукта (Product Managers) определяют фичи в локальном контексте ART. Прочие возникают результатом декомпозиции эпиков.

Системные архитекторы обычно создают вспомогательные фичи. Бэклог ARТа используется для хранения вспомогательных фич также, как и бизнес-фич. Вспомогательные фичи обеспечивают Архитектурную взлетно-посадочную полосу, поддерживают исследования или предоставляют инфраструктуру, необходимую для разработки, тестирования и интеграции решения.

Как и бизнес-фичи, вспомогательные фичи могут порождаться эпиками или появляться локально на уровне ARТов. Для вспомогательных фич, проходящие через Канбан-систему, должна выделяться часть емкости команды (capacity), чтобы обеспечить особое внимание развитию решения и расширению архитектурной взлетно-посадочной полосы. Для более точного управления поездом (ART), на каждой границе между двумя PI оценивается процентное соотношение ресурсов, выделенных для фич (или капабилити), направленных на реализацию новой функциональности, и на вспомогательные фичи.

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

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

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

Оценка фич

Оценка фич обеспечивает прогнозирование доставки ценности, применение WSJF подхода для приоритизации и определение размеров эпиков путем их разделения на фичи и суммирования оценок этих фич. Оценка фич обычно происходит в стадии анализа Канбан-доски ARТа. Метод оценки основан на технике нормализованной оценки, аналогичной методам оценки, используемым Agile-командами (подробнее см. в статье «Планирование итерации»). Во время стадии анализа выберите экспертов в предметной области из ART, которые будут участвовать в исследовании и предварительной оценке.

Приемка фич

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

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

Функциональные возможности (Capabilities)

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

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

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

Декомпозиция функциональных характеристик (features) и функциональных возможностей (capabilities)

Капабилити должны быть декомпозированы на фичи, чтобы их можно было реализовать. Фичи, в свою очередь, декомпозируются на истории, которые команды реализуют в рамках итерации. SAFe предоставляет десять шаблонов для разделения элементов работы, как это описано в (Leffingwell, 2011), глава 6:

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

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

Список литературы

• Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.