Все статьи
Фичи и возможности в SAFe®
Дата: 27.05.2024
Понятия фича (Feature) и возможность (Capability) в SAFe® (Scaled Agile Framework®) используются для масштабирования продуктового подхода на уровни Agile-поставки продуктов (бэклог Agile Release Train) и поставки корпоративных решений (бэклог Solution Train).
Содержание
Понятие фич и возможностей
Фича представляет собой функциональность решения, которая несет бизнес-ценность, удовлетворяет потребности заинтересованных лиц и реализуется одним ART (Agile Release Train) за один Интервал Планирования (Planning Interval, PI).
Каждая фича содержит гипотезу о выгоде и критерии приемки. Фичи создают такого размера, чтобы один ART мог реализовать их за один PI. При необходимости фичи разделяют на меньшие, чтобы соблюдать это условие.
Возможность представляет функциональность крупного решения, в реализацию которого часто участвуют несколько ART. Возможности имеют размер, позволяющий реализовать их за один PI.
Фичи имеют отсылку к модели Lean UX, которая содержит понятие фичи, минимально пригодной для продажи (Minimum Marketable Feature, MMF), гипотезу о выгоде и критерии приемки. MMF помогает ограничить объем работ и инвестиций (вложений, затрат), поддерживает гибкость и обеспечивает получение быстрой обратной связи. Возможности аналогичны фичам, но они относятся к более высокому уровню структуры и поддерживают определение и разработку крупного решения.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Agile Release Train (ART)
Agile Release Train (ART) — это долгосрочная команда Agile-команд, которая инкрементально разрабатывает, внедряет и часто эксплуатирует одно или несколько решений в рамках потока разработки ценности.
Решение
Решение — это продукт, система или сервис, который предоставляет ценность внутренним или внешним клиентам.
Интервал Планирования (Planning Interval, PI)
Интервал Планирования (Planning Interval, PI) — это регулярный повторяющийся временной интервал, за который Agile Release Train (ART) непрерывно поставляет ценность клиентам в соответствии с Целями Интервала Планирования (PI-целями).
Фича, Минимально Пригодная для Продажи (Minimum Marketable Feature, MMF)
Фича, Минимально Пригодная для Продажи (Minimum Marketable Feature, MMF) — это минимальная функциональность, необходимая для подтверждения гипотезы о пользе Фичи.
Фичи и возможности имеют критическую роль в определении, планировании и реализации ценности решения. На рисунке 1 — больше деталей о фичах и возможностях.
Рисунок 1 показывает, что решения разрабатываются с использованием фич. Каждая фича отображает сервис, который предоставляет система для удовлетворения тех или иных запросов (нужд) заинтересованного лица. Они прорабатываются в бэклоге ART и приводятся к размеру, соответствующему PI. Таким образом, каждая фича поставляет новую ценность. Фичи могут появляться непосредственно из контекста конкретного Agile Release Train (ART) или как результат разбиения эпиков или возможностей.
Канбан ART и Solution Train поддерживают поток фич и возможностей. Они проходят через стадии воронки, анализа, бэклога, реализации, валидации, развертывания и релиза. Этот процесс обеспечивает необходимый экономический анализ, техническое влияние и стратегию для инкрементальной поставки.
Продуктовый менеджмент определяет фичи, а системный архитектор определяет энейблеры (инструментальные фичи). Нефункциональные требования (Non-Functional Requirements, NFRs) определяются аттрибутами системы, такими как безопасность, надежность, эксплуатационные характеристики, масштабируемость и удобство использования.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Бэклог ART
Бэклог ART — это Канбан-система, используемая для сбора и управления Фичами и Энейблерами, предназначенными для функционального улучшения Решения и расширения Архитектурной Полосы.
Эпик
Эпик — существенная инициатива по разработке Решения.
Бэклог Solution Train
Бэклог Solution Train — это Канбан-система, используемая для хранения и управления Возможностями и Энейблерами, которые развивают крупное Решение и Архитектурную Полосу.
Продуктовый менеджмент
Продуктовый менеджмент отвечает за определение и поддержку разработки востребованных, осуществимых, жизнеспособных и устойчивых продуктов, удовлетворяющих потребностям клиентов на всем жизненном цикле продукта.
Системный архитектор
Системный архитектор отвечает за определение и донесение общей технической и архитектурной концепции Решений, разрабатываемых несколькими ART.
Энейблер
Энейблер — это элементы бэклога, которые расширяют Архитектурную Полосу разрабатываемого решения или улучшают производительность потока разработки ценности.
Нефункциональные требования
Нефункциональные требования — это свойства системы, которые определяют дизайн решения и часто служат ограничениями для соответствующих бэклогов.
Дизайн-мышление берет принцип клиентоориентированности для создания устойчивых продуктов, которые ждут пользователи. Инструменты дизайн-мышления, включая персоны (Persona Canvas), карты эмпатии (Empathy Maps) и карты пути клиента (Customer Journey Maps) дают возможности к более глубокому пониманию клиентов и пользователей. Все это дает глубокий контекст для лучшего понимания фич и и их потенциальной ценности.
Фичи определяют используя формат фич и выгоды:
- Фича – короткая фраза, дающая название и контекст.
- Гипотеза выгоды – предлагаемая измеримая выгода для конечного пользователя или бизнеса.
Избегайте определения фич в формате пользовательских историй исходя из одной пользовательской роли – фичи обычно несут функциональность для совокупности пользовательских ролей. Более того, использование одного и того же метода для описания пользовательских историй и фич может вызывать путаницу.
Рисунок 2 показывает примеры фич и гипотез выгоды.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Дизайн-мышление
Дизайн-мышление — это клиентоориентированный процесс разработки востребованных продуктов, которые прибыльны и устойчивы на протяжении своего жизненного цикла.
Персоны
Персоны — это описания людей, которые пользуются или могут воспользоваться продуктом.
Карта эмпатии
Карта эмпатии — это инструмент дизайн-мышления, который используется для разработки глубокого и единого понимания потребностей клиентов.
Карта пути клиента
Карта пути клиента запечатлевает пользовательский опыт взаимодействия с потоками поставки ценности, продуктами и сервисами компании.
Истории
Истории — это короткие описания небольшого компонента желаемой функциональности на понятном пользователю языке.
Создание и управление фичами
Менеджеры продукта в сотрудничестве с владельцами продукта и другими заинтересованными лицами определяют фичи в контексте конкретного ART. Некоторые фичи появляются как результат разбиения эпиков.
Системный архитектор обычно определяет энейблер-фичи (инструментальные фичи). И фичи, и энейблер-фичи располагаются вместе в бэклоге ART. Энейблеры составляют архитектурную полосу и поддерживают исследования или предоставляют инфраструктуру, необходимую для разработки, тестирования и внедрения решения.
Также как и бизнес-фичи, энейблер-фичи могут возникать из эпиков или появляться локально на уровне ART. Энейблеры, проводимые через Канбан будут использоваться для распределения ресурсов в бэклоге ART, чтобы сбалансировать акценты на реализации решения и расширения архитектурной полосы. В рамках каждого PI соотношение процента ресурсов, отведенных на новые фичи (или возможности) и отведенных на энейблеры рассчитывается так, чтобы обеспечивать деятельность ART.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Владелец продукта
Владелец продукта — член Agile-команды, основная ответственность которого в максимизации ценности, поставляемой командой, которую он обеспечивает соответствием Бэклога Команды потребностям клиентов и заинтересованных лиц.
Архитектурная полоса
Архитектурная полоса состоит из текущего программного кода, компонентов и технической инфраструктуры, которые в каждый момент времени позволяют реализовывать высокоприоритетные Фичи без чрезмерных задержек и перепроектирования.
Приоритизация фич
Модель приоритизации WSJF (Weighted Shortest Job First, Более Ценная и Короткая Работа Сначала) используется, чтобы упорядочить последовательность работ (фич, возможностей) на основании экономики потока разработки продукта. Трудно переоценить важность этого процесса, так как выполнение нужной работы в нужное время дает максимальную экономическую выгоду.
Продуктовый менеджмент и менеджмент решения используют WSJF, чтобы приоритизировать фичи. Аналогично системные архитекторы и архитекторы решений также используют WSJF для приоритизации энейблеров. Поскольку и бизнес-фичи и энейблеры располагаются в общем бэклоге, продуктовый менеджмент и менеджмент решения должны сотрудничать с системными архитекторами и архитекторами решений, чтобы разрешить противоречия в приоритетах. Существуют два подхода для выравнивания бэклога и достижения баланса: ориентация на стратегические темы и распределение ресурсов.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Weighted Shortest Job First (WSJF)
Weighted Shortest Job First (WSJF) — модель приоритизации «Более Ценная и Короткая Работа Сначала» для упорядочивания работ с достижением максимальной экономической выгоды. В SAFe WSJF оценивается делением стоимости задержки на относительную длительность реализации.
Менеджмент решения
Менеджмент решения — это функция, отвечающая за определение востребованных, реализуемых, жизнеспособных и устойчивых крупных Решений, удовлетворяющих потребности клиента и поддерживающих разработку на всех этапах жизненного цикла Решений.
Архитектор решения
Архитектор решения — отвечает за определение и донесение общей технической и архитектурной концепции Solution Train, обеспечивая гарантию соответствия разрабатываемого Решения своему целевому назначению.
Стратегические темы
Стратегические темы — это бизнес-цели портфельного уровня, описывающие конкурентные особенности и стратегические преимущества. Они обеспечивают бизнес-контекст для стратегии и принятия решений на уровне портфеля, представляя определенные аспекты стратегического плана предприятия.
Оценка фич
Оценка фич поддерживает прогноз доставки ценности, применение WSJF-приоритизации и регулировку размера эпиков через разбиение их на фичи и суммирование их оценок. Оценки фич обычно производятся на стадии анализа Канбан ART. Она опирается на техники стандартизированной оценки, аналогично методу, используемому Agile-командами. Для анализа необходимо привлекать специалистов ART из необходимых областей, которые участвуют в исследованиях и предварительной оценке.
Agile-команда — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.
Приемка фич
Критерии приемки фич помогают определить правильно ли реализована фича и приносит ли она бизнес-ценность.
Критерии приемки обеспечивают выравнивание в понимании между менеджерами продукта, заинтересованными лицами и разработчиками и, в результате, снижают риск неверной реализации, а также обеспечивают базис для ранней проверки гипотезы ценности.
Менеджеры продукта ответственны за приемку фич. Они используют критерии приемки, чтобы определить правильна ли реализована фича, а также обеспечено ли соблюдение нефункциональных требований.
Возможности
Большая часть статьи посвящена описанию фич и их реализации, так как они обычно описывают поведение системы. Возможности проявляют те же свойства и к ним применимы те же практики, что и для фич. Например:
- Описание включает заголовок и гипотезу о выгоде.
- Их размер соответствует PI, однако, для их реализации часто требуются усилия нескольких ART.
- Обсуждаются и одобряются в Канбан Solution Train. Бэклог Solution Train содержит одобренные возможности.
- Имеют соответствующие энейблеры, чтобы описать и сделать видимой всю техническую работу, необходимую для обеспечения эффективной разработки и доставки бизнес-возможностей.
- Принимаются менеджером решения, который использует критерии приемки, чтобы определить соответствует ли функциональность заявленной цели.
Возможности могут возникать из контекста конкретного решения или быть результатом разбиения эпиков портфеля, которые могут затрагивать более одного потока ценности. Другой возможный источник возможностей – это контекст решения, где некоторые аспекты инфраструктуры могут потребовать дополнительную функциональность решения.
Портфель — это набор потоков ценности, который обеспечивает непрерывный поток ценных решений для клиентов в рамках общей модели финансирования и управления.
Разделение фич и возможностей
Чтобы реализовать возможности, их необходимо разбить на фичи. Фичи в свою очередь разбиваются на истории, с которыми работают команды в итерациях. SAFe дает 10 паттернов для разбиения работы:
- По шагам бизнес-процесса.
- По вариантам бизнес-правил.
- По существенным усилиям.
- Простые/сложные.
- Вариации в данных.
- Методы обработки данных.
- Качество системы.
- Операции.
- Сценарии использования.
- Разделение исследования (spike) и реализации.
Рисунок 4 иллюстрирует разбиение возможности на фичи.
