Карта фич в Scaled Agile Framework®

Перевод статьи Feature Mapping with Scaled Agile Framework, выполнен с разрешения Ivar Jacobson International. Copyright © 2021 Ivar Jacobson International SA. Все права защищены. 

Техника визуализации для создания и формирования общего понимания Бэклога Программы

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

В основном в комнате присутствовали люди уровня Программы SAFe: Release Train Engineer (RTE), Product Management, Product Owner, Архитекторы и несколько экспертов в предметной области. Существовал черновой вариант дорожной карты, который был тщательно продуман и имел, по меньшей мере, условные приоритеты. Эпики Программы и Фичи были объединены в четыре группы в порядке убывания приоритета. 

Как RTE или Agile Coach, запускающему новый ART, вам нужно задать самому себе один из самых важных вопросов на установочной встрече новой Программы:

1. Что должно произойти прежде, чем мы сможем спланировать наш первый Инкремент Программы?
2. Есть ли команда?
3. Готов ли Бэклог Программы к планированию?

В этом ART Agile-команды только комплектовались, но если есть хотя бы укомплектованный состав Программы, как в этом случае, то все равно можно подготовить Бэклог. Итак, как определить, хорош ли Бэклог Программы для PI-планирования, и если нет, то какие техники вы могли бы использовать для фасилитации его подготовки?

Подготовка Бэклога Программы

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

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

Понимает ли Команда Программы Фичи?

Если вы хотите выяснить, вся ли группа одинаково понимает эту Фичу то, как правило, неэффективно просто спросить об этом.

Я обнаружил, что один из наиболее эффективных способов быстро выяснить, есть ли общее понимание – это начать расставлять приоритеты в работе.

SAFe рекомендует метод определения приоритетов, называемый Weighted Shortest Job First (WSJF). В этом методе используются четыре метрики для взвешивания элементов в бэклоге:

1. Ценность для бизнеса.
2. Критичность по времени.
3. Расширение Возможностей/Снижение Рисков.
4. Длительность (размер).

Я не буду здесь вдаваться в подробности относительно WSJF. Суть перечисления критериев, используемых этим методом скоринга заключается в том, что обращаясь к команде за согласованием этих метрик, вы можете установить, есть ли общее понимание Фич в Бэклоге.

Вначале я попросил команду определить самую маленькую Фичу. Я ожидал, что они договорятся об относительной оценке каждой из Фич, относящихся к первой приоритетной группе. Для этого я задавал вопрос: “Эта Фича больше или меньше других?” – и довольно быстро стало понятно, что команда обладает не глубоким, а только поверхностным пониманием. 

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

Именно поэтому мне нравится полный набор метрик, используемых для WSJF: если дискуссии о размере Фичи не вскроют пробелов, то, возможно, дискуссии о Ценности для бизнеса или Срочности помогут их обнаружить.

Этот подход хорошо подходит для того, чтобы сформировать у команды общее понимание при обсуждении относительных оценок. Можно довольно быстро прийти к общему мнению, если обсуждение складывается. Однако, если вы видите, что команда тонет в длительных дискуссиях, разногласия нарастают и в глазах членов команды читается слово «отчаяние», значит вы делаете что-то не так. Такая ситуация может произойти, если вы имеете дело с большим количеством невыполненных, сложных и запутанных задач. Не затягивайте такую встречу. Когда становится очевидным, что относительные оценки вызывают только стресс, вероятно, причина кроется в недостаточно хорошо проработанном бэклоге. Прекратите то, что вы делаете, и начните прояснять ситуацию!

Создание карты ваших фич

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

После попытки расставить приоритеты по каждой Фиче, довольно быстро стало очевидно, что у команды не было единого мнения относительно Бэклога, поэтому мы уточнили цель установочной встречи: проверить и достичь единого понимания целей и приоритетов Программы, которое позволит команде провести первую встречу по PI-планированию (PI Planning).

Вдохновленные такими техниками, как Story Mapping, как описал Джефф Паттон в книге «User Story Mapping», и другими видами моделирования, мы приступили к визуализации бэклога, составляя карту того, как должна выглядеть каждая Фича с точки зрения использования всей системы. Главное – это было сформировать общее понимание поведения работы всей системы, фокусируясь на потоке Фич и избегая дискуссий на тему её технического устройства.

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

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

Метод составления карты фич

Так что же мы сделали на самом деле?

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

Вот как это было:

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

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

Главная задача Продуктового Менеджера была в том, чтобы отслеживать, правильно ли команда двигается в достижении бизнес-целей. Архитекторы заботились о том, как это повлияет на Техническое Решение. 

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

Четыре приоритетные группы в исходной дорожной карте представляли собой Вехи Бизнеса. После некоторого обсуждения было решено, что на самом деле требуются только две Вехи, которые мы отделили вертикальной линией на стене от других точек. Таким образом, чтобы закончить первый этап проверки дорожной карты мы должны задать вопрос: какие Фичи должны находиться в левой части от каждой Вехи?

Увы, я не смог сфотографировать то, что у нас получилось, потому что съёмка была запрещена. На рисунке показано примерно то, как это выглядело на стене.

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

В конечном итоге такой подход привёл к обновлению Бэклога. Новые Фичи возникли из обсуждения имеющихся деталей, а некоторые другие Фичи даже были исключены. На это потребовалось время, но команда в течение нескольких часов придерживалась постоянного темпа, и на самом деле было довольно сложно остановиться. Согласитесь, что это очень хороший знак продуктивной сессии!

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

По мере готовности вашего бэклога и вовлечения в Поток, команды позаботятся о своей работе и подготовят планы точно в срок. Обсуждая и формулируя общее мнение самой первой Фичи, используя WSJF и Feature Mapping, команда Программы получит намного больше уверенности и достигнет согласия по приоритетам бэклога и скоупа Фич.

В заключении

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

Целью установочной встречи Программы было Проверить и получить единое понимание целей и приоритетов для команды Программы перед первым PI Planning. Невозможно переоценить ценность техники Feature Mapping, которая помогает направлять и облегчать дискуссии, которые привели к такому результату.

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