Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
LeSS
OKR
PMI
Project management
SAFe
Scrum
Scrum-мастер
Архитектура
Бюджетирование
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Фасилитация
Применить

Как правильно нарезать Фичи для Инкрементов Программы SAFe®

Как подготовить Фичи к планированию Инкремента Программы?

Перевод статьи Ian Spence и Keith de Mendonca Right-sizing Features for SAFe® Program Increments выполнен с разрешения авторов.

Одной из ключевых активностей, необходимой для успеха вашей реализации SAFe®, является аккуратная подготовка Фич (Features) перед планированием Инкремента Программы (PI). И существенной частью этой подготовки является нарезка тех целевых Фич, реализация которых требует более чем одного PI.

В этой статье мы хотим поделиться нашим опытом нарезки Фич. А также, вслед за Ричардом Лоуренсом с его популярным постером о Нарезке Историй, дать вам бесплатный постер с правилами Нарезки Фич, который вы сможете использовать в своей SAFe программе. Вот такие мы добрые.

Фичи — это ведь просто большие истории, разве не так?

Для Владельцев Продуктов (Product Owners) и Менеджеров Продуктов (Product Managers) очень соблазнительно рассматривать Фичи как гигантские Пользовательские Истории (User Stories) и работать с ними в бэклоге программы, используя те же подходы, что и для Пользовательских Историй в бэклогах команд.

Но мы обнаружили, что описание Фичи в формате Историй может приводить к проблемам (подробности вы найдете в статье Features and Capabilities на сайте Scaled Agile Framework), и также не стоит применять к Фичам те же правила нарезки, что и к Пользовательским Историям.

В Scaled Agile Framework Фичи и Истории (включая как Пользовательские Истории, так и Enabler-истории) четко различаются с точки зрения целей, структуры и содержания:

  • Фичи — это видимые блоки бизнес-результата, которые понимает клиент, и именно на уровне гранулярности Фич клиент может приоритизировать потребности.
  • Фичи могут охватывать несколько пользовательских ролей, пользовательских историй и сценариев использования (use cases).
  • Над одной Фичей могут одновременно работать несколько команд — команды могут объединяться для поставки Фич.
  • Разработка Фичи может длиться несколько Спринтов. Реализация Фич происходит посредством реализации всех необходимых Историй.
  • Разработка Фичи должна легко помещаться в Инкремент Программы. Запомните: Фича должна помещаться в длительный Инкремент Программы так же, как Истории должны помещаться в Спринт.
  • Истории — это блоки работы, на которые команды делят Фичи с целью их инкрементальной разработки и поставки. Их задача — помочь команде (и заинтересованным лицам) проверять, обсуждать, договариваться и совместно выстраивать процесс поставки Фичи.
  • Разработка Истории должна быть завершена в течение одного 2-недельного Спринта.
    Истории могут существовать и без Фич, что позволяет командам проводить изменения без необходимости создания дополнительных Фич.

Существует целый ряд источников, описывающих правила нарезки Историй, наши самые любимые из них — опубликованные Ричардом Лоуренсом (включая его знаменитый постер о Нарезке Историй) и Дином Леффингвеллом (детали вы можете найти в статье Story на сайте Scaled Agile Framework). Эти правила актуальны и при использовании Фич: они реально помогают командам выявлять, разделять и упорядочивать Истории, которые требуются для разработки Фичи. Но эти правила перестают быть такими действенными в нарезке Фич.

Например, мы никогда не будем рекомендовать выносить требования по производительности в отдельную Фичу, которая будет сделана позже, даже несмотря на то, что реализация этих “Историй производительности” будет производиться в конце разработки Фичи. Это также касается обработки ошибок, CRUD и изменениям данных — мы можем отложить разработку Историй, связанных с этими важными атрибутами программного обеспечения, и сделать их ближе к концу разработки Фичи, но мы не будем группировать их в отдельную Фичу.

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

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

Нарезка фич

Итак, давайте представим, что команда только что оценила Фичу (обычно в Story Points) и обнаружила, что она слишком большая и не может быть поставлена целиком в следующем Инкременте Программы. Далее, чтобы разделить Фичу на части, им нужно выбрать такой способ нарезки, который позволит снизить приоритет или отложить разработку части функционала на потом. После они выберут только те кусочки бизнес-ценности, которые максимально быстро принесут выгоду клиенту.

Какие стратегии нарезки вы можете использовать? Мы выбрали 10 наиболее полезных моделей для нарезки:

  1. KISS (Keep it simple stupid) – цель заключается в максимально простой реализации, которая может быть проведена без влияния на производительность системы и т.д. Часто это основной удачный кейс с базовой обработкой ошибок. Отложите все “рюшечки” на более поздние фичи, когда базовая часть уже будет стабильно работать с достаточно высоким уровнем качества.
  2. Отложите Необязательные Сценарии — подразумевает ли Фича множество необязательных сценариев? Определите их в отдельные Фичи и отложите до момента, когда будет реализована основная функциональность.
  3. Разделите по Областям Бизнеса – можно ли разрабатывать Фичу инкрементально для разных типов бизнеса? Начните с наиболее простого бизнеса, чтобы получить быструю обратную связь. Например, можем ли мы сделать простое решение для розничного банкинга перед тем, как расширять его и предлагать подразделениям, занимающимися инвестиционными, торговыми и прочими банковскими операциями? Также обратите внимание на региональные особенности: во многих областях бизнеса существуют разные правила для США, Европы и Азии. Возможно, мы сможем запустить Фичу для одной географической зоны, прежде чем добавлять ее для других зон посредством дополнительных Фич.
  4. Проводите Разделение по Каналам — можем ли мы организовать релизы Фичи таким образом, чтобы инкрементально поддерживать разные каналы / пути выхода на рынок / одну функциональность на разных носителях? Например, для предоставления клиентам доступа к мобильному банкингу, банковскому приложению или услугам банка в отделении используются разные операционные системы или разные каналы. Логично иметь одинаковую функциональность для всех этих случаев, но поставка Фичи для каждого канала может быть организована отдельными Фичами (а в некоторых случаях она может оказаться вообще ненужной).
  5. Разделите Поддержку Групп Пользователей – требуются ли разным пользователем разные наборы историй? Понимание потребностей разных групп пользователей может помочь вам разделить Фичу и лучше понять выгоды, которые в результате получит каждая из групп. Например, наша новая Фича может обращаться к разным демографическим группам, но каждая группа захочет использовать ее по-разному. В таком случае нарезка Фичи позволит нам сфокусироваться только на тех историях, которые актуальны для конкретной демографической группы и раньше понять интересы наиболее приоритетных для нас групп пользователей.
  6. Подключайте Исходные Данные Инкрементально — требуются ли для поставки ценности все исходные данные? Возможно, мы можем организовать работу с Данными инкрементально или провести разделение в зависимости от источников их получения?
  7. Изолируйте Специфические Сценарии — сконцентрируйтесь сперва на наиболее популярных / частых сценариях, а затем добавляйте более специфические как отдельные Фичи. Не исключено, что вы обнаружите, что их ценность невелика и они вообще не нужны.
  8. Находите Общие Enablers – бизнес-фичи зачастую опираются на одно и то же базовое поведение системы, вследствие чего внедрение первых фич кажется очень сложным и громоздким. Выявление таких общих сценариев способно снизить риски, уменьшить оценку реализации и в целом упростить внедрение многих бизнес-фич.
  9. Выявите Группу Историй – помните, что 80% результатов для бизнеса скорее всего придут от 20% историй. Определите эти истории и работайте с ними как с отдельной Фичей. Подробности вы найдете в Story Mapping.
  10. Определите Spike – иногда вам не хватает знаний даже для того, чтобы что-либо запланировать. В таком случае — выявляйте spike.

Примеры плохой нарезки

Мы выявили несколько опасных ловушек, которые могут подстерегать вас в ходе нарезки:

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

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

  • Слишком ранняя нарезка – проводите нарезку только такой Фичи, которая 1) нужна в самом ближайшем будущем или 2) слишком большая (на текущий момент), чтобы эффективно встроиться в систему. Помните, что оценки реализации Фич постоянно меняются: то, что сегодня кажется слишком большим, в будущем может получить куда меньшую оценку.
  • Слишком глубокая нарезка – нет необходимости нарезать Фичу на множество меньших фич за один присест. Обычно достаточно определить первые один-два кусочка, а к остальному вернуться после завершения их реализации.
  • Нарезка по компонентам – мы заметили, что техническим специалистам бывает сложно сопротивляться соблазну нарезать фичи по архитектурным компонентам, подсистемам или слоям. Это тактическое решение, которое нередко применяется на уровне Историй, особенно в случае компонентно-специфических команд или с командами, которые всячески пытаются уместить свои истории в двухнедельный спринт. Это плохая привычка, и с ней нужно всерьез бороться, особенно когда вы имеете дело с более крупными компонентами, такими, как Фичи.
  • Откладывание Тестирования Фичи — фичи нередко требуют дополнительного тестирования, сверх того, что необходимо для тестирования набора входящих в них Историй. Одна из ловушек, возникающих в ходе нарезки — откладывание тестирования на более поздний этап вместо того, чтобы включать необходимый объем тестирования как часть каждой из небольших Фич.
  • Нарезка по операциям или шагам процесса — когда речь идет о реализации процесса, зачастую возникает соблазн разделить Фичу по шагам или по операциям, требующимся на каждом шаге. Например, можно определить входящий поток, обработку и выходные данные процесса в разные Фичи или еще проще — разделить процесс на создание, доступ, изменение и удаление элементов. При нарезке Фич это происходит довольно часто и является ошибкой, поскольку реализация только одного шага процесса практически не приносит бизнес-ценности. Сфокусируйтесь на каком-нибудь корневом поведении, присущем Фиче, и создайте максимально простое сквозное решение. Последующие дополнительные Фичи могут включать разные вариации поведения и прочие “рюшечки”, но добавлять их следует только после того, как базовая функциональность от начала до конца процесса успешно прошла релиз и уже находится в руках пользователей. Такая необдуманная нарезка зачастую приводит к ситуации, когда 90% Фичи уже готово, но решение не может удовлетворить ни одну из реальных потребностей пользователей. Они могут внести какие-то данные, найти какие-то данные, что-то поменять, но не могут физически завершить процесс, которому пытаются следовать.

Постер о нарезке фич

IJ_HOW-TO-SLICE_rus-a4[1]

Нужна картинка лучшего качества для печати? Скачайте постер в формате А3 в высоком разрешении, который вы сможете повесить на стену и быстро к нему обращаться.

11 май 2018, Сергей Рогачев
Другие статьи
4 ноя 2018, Сергей Рогачев
OKR для начинающих #3

Перевод книги «OKR для начинающих» Фелипе Кастро, часть 3

scaled-agile-framework
14 окт 2018, Сергей Рогачев
Что нового в SAFe 4.6?

На прошлой неделе вышло обновление Scaled Agile Framework (SAFe) 4.6. В этой заметке мы расскажем, что там интересного.

scaled-agile-framework
3 окт 2018, Артемий Анцупов
SAFe для проектных менеджеров #2

Во второй части нашей серии мы кратко разберёмся, какие же проблемы помогает решать SAFe.