Эффективный шаблон описания Фичей в SAFe®

Перевод статьи Mark Richards Effective Feature Templates for SAFe выполнен с разрешения автора.

Введение

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

Очевидно, что необходимо иметь больше информации по Фиче и поэтому, кажется, уже бесчисленное количество раз я участвовал в разработке шаблона Фичи с Продуктовым Менеджментом. Студенты моих тренингов просили меня дать им шаблон Фичи, но примеры, которые у меня есть, принадлежат моим клиентам, я не могу ими поделиться.

Новый акцент на Lean UX в SAFe 4.5 вдохновил меня потратить некоторое время на создание собственного шаблона Фичи, которым я мог бы поделиться. Результатом этого является синтез повторяющихся паттернов, которые я наблюдал во время своего коучинга, в котором основное внимание уделяется необходимым компонентам с рекомендациями по дополнительной информации, которая может потребоваться.

Как много деталей необходимо и когда?

Я разделил цикл уточнения Фичи на 2 этапа:

• До оценки WSJF.
• До PI-планирования.

На этом этапе необходим такой уровень детализации, который позволяет оценить стоимость задержки (Cost of Delay) и определить размер Фичи. Информация — это инвентарь, и нам нужна простая схема хранения, пока приоритет Фичи не укажет, что ее необходимо подготовить для PI-планирования.

С этой целью в моем шаблоне ключевое внимание уделяется использованию канваса оценки WSJF (прим. ред. — Более Ценная и Короткая Работа Сначала — Weighted Shortest Job First, WSJF), и я даю несколько рекомендаций по возможному расширению деталей для подготовки к PI-планированию.

Канвас Фичи (Feature Canvas)

(прим. ред. — исходник Канваса Фичи)

Описание проблемы (Problem Statement)

Используя работу Джеффа Готельфа в Lean UX, мы основываем Фичу на определении проблемы, для решения которой она предназначена. Готельф предоставляет здесь два отличных шаблонна:

Новый продукт:

“Текущее состояние [домен] сосредоточено в первую очередь на [сегмент пользователей, болевые точки и т.д.].
Существующие продукты/услуги не могут решить [этот пробел].
Наш продукт/услуга восполнит этот пробел при помощи [видение/стратегия].
В первую очередь мы сфокусируемся на [сегменте пользователей]”.

Существующий продукт:

“Наш [продукт/услуга] предназначена для достижения [целей].
Мы видим, что наш [продукт/услуга] не достигает [целей], что оказывает [негативное воздействие] на наш бизнес.
Как мы можем улучшить [услугу/продукт], чтобы наши клиенты были более успешными на основе [измеримых критериев]?”

Гипотеза Фичи (Feature Hypothesis)

Аналогично на основе работы Готельфа мы формулируем гипотезу о том, какое влияние может оказать наша Фича. Шаблон гипотезы имеет вид:

“Мы верим, что достигнем [бизнес-результат], если [сегмент пользователей] успешно достигнет [пользовательский результат] посредством [Фичи]”.

Цели и Ключевые Результаты (Objectives and Key Results, OKRs)

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

Как уже было описано в этой статье, я стал большим поклонником OKR, опробованной в Intel и популяризированной Google. Я считаю, это полезный инструмент для определения влияния Фичи.

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

Компоненты стоимости задержки (Cost of Delay Components)

Эффективность / объективность воркшопов по оценке стоимости задержки во многом определяется данными в таблице. Три раздела: «Ценность для пользователя / бизнеса (User/Business Value)», «Критичность сроков (Timing Criticality)» и «Снижение рисков / открытие возможностей (Risk Reduction/Opportunity Enablement)» предоставляют возможность выделить вспомогательные данные для оценки трех компонентов стоимости задержки.

Ключевые эксперты (Key Subject Matter experts)

Я редко, если вообще когда-либо такое было, работал с ART, в котором Продуктовый Менеджмент самодостаточны в экспертных знаниях предметной области. Важное значение имеет выявление и взаимодействие на ранних этапах жизненного цикла Фичи с экспертами в данной предметной области.

Внешние зависимости (External Dependencies)

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

Нефункциональные требования (Non Functional Requirements)

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

Пример заполненного канваса Фичи

Придумать шаблон Фичи было невероятно сложно, потому что я все время думал о реальных Фичах, но в конце концов я остановился на придуманной Фиче для бронирования столиков в ресторане.

Так вы могли бы визуализировать свой следующий семинар по оценке WSJF:

Детали за пределами канваса

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

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

• Пути пользователей (User Journey): UX-исследования часто очень полезны при подготовке Фичи и сильно помогают командам на PI-планировании.
• Оценка влияния на архитектуру (Architectural Impact Assessment): некоторая форма архитектурного исследования воздействия Фичи имеет решающее значение в большинстве сложных сред. Исследование редко должно быть больше страницы — я считаю, что в общем случае — это один-два абзаца текста, сопровождаемых диаграммой последовательности высокого уровня, определяющей ожидаемые взаимодействия между архитектурными слоями.
• Влияние на управление изменениями (Change Management Impacts): как перейти от развернутого программного обеспечения к получению ценности? Кому понадобится обучение? Требуются ли рабочие инструкции?

Настройка шаблона

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

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

Затем снова подведите итоги после Инкремента Программы. Посмотрите, как доставлялись Фичи и какие моменты вы хотели бы избежать в будущем.

Кто заполняет канвас Фичи?

Продуктовый Менеджмент является ответственным за уровень Бэклога Программы, следовательно, они являются основными владельцами. Однако, одним из приятных моментов, которые Lean UX привнес в SAFe 4.5, является реальный акцент на «совместном проектировании». Чтобы избежать ненужной передачи знаний, лучше всего проработать большую часть деталей (включая подготовку основы канваса) Владельцам Продуктов и командам, которые, вероятно, будут внедрять эту Фичу.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.