Готовим бэклог для PI-планирования

Гленн Смит и Даррен Уилмшерст из Radtac, партнера Scaled Agile, написали эту статью в соавторстве.

По завершении PI-планирования мы обычно запоминаем что-то сказанное одним из наших коллег. Есть много поводов для гордости, ведь мы смогли создать набор конкретных планов. Но сначала необходимо провести ретроспективу PI-планирования (слышатся вздохи) и “уже завтра мы должны начинать готовиться к следующему планированию” (еще больше вздохов).

Важнейшим пререквизитом для PI-планирования является создание уточненного и приоритезированного бэклога. Без него планирование невозможно. Но как выполнение этой задачи выглядит на практике?

Эта статья будет полезна коучам, которым нужно заниматься процессом подготовки бэклога к следующему планированию. Это могут быть SAFe® Program Consultants (SPCs), поддерживающие Agile Release Train (ART) и Release Train Engineers (RTEs). Но еще больше статья поможет, Менеджерам продукта (PMs) и Системным архитекторам (SAs), которые непосредственно должны наполнять, совершенствовать, приоритезировать и адаптировать бэклог совместно с Владельцами продукта (POs) и Представителями бизнеса (BOs). Мы рассмотрим каждую из этих ролей в этой статье.

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

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

Модель интенсивности работ по подготовке бэклога по конкретным ролям в течение PI.

На графике очевиден значительный всплеск интенсивности, он происходит во время IP-итерации (Итерации Инноваций и Планирования) у PMs, BOs, POs и Команд. Именно этот момент и происходит PI-планирование.

Менеджеры продукта и Системный архитектор

PMs и SAs должны действовать по схеме аналогичной друг для друга, поскольку их роли — это две стороны одной монеты: одна ориентирована на внешний рынок, другая — ориентирована на техническую составляющую. Им необходимо работать совместно, чтобы убедиться, что важные для них вещи обязательно спланированы.

Создание бэклога для поезда, будь то бизнес-фичи или Enablers, должно происходить по определенным шагам: Создание, Уточнение, Приоритезация и Социализация элемента. Если говорить упрощенно — каждый из этих шагов применим ко всем первым четырем итерациям планирования. В первой половине PI PMs и SAs должны анализировать новые эпики, декомпозировать существующие, а также работать над дорожной картой поезда и связанной с ней архитектурной тропинкой.

Обычно на входе мы получаем плохо определенные Фичи со слабыми гипотезами о выгодах и критериями приемки. Не следует упускать из виду, сколько усилий потребуется, чтобы привести их в надлежащий вид. Это связано с тем, что работа заключается не только в том, чтобы внести задачи в Agile Lifecycle Management (система управления Agile-проектами, например, Jira — прим. редактора), но и совместно проработать их с владельцами бизнеса, в общении с другими заинтересованными лицами, включая клиентов, и в анализе тенденций рынка. Улучшение описания фич позволит людям в командах легче поставлять ценность. Во время планирования, трудозатраты существенно снижаются благодаря работе по наполнению бэклога для планирования.

Представители бизнеса

Представители бизнеса являются ключевыми заинтересованными сторонами ART. Таким образом, они постепенно сталкиваются с растущим спросом на свое время для поддержки и создания бэклога в течение всего PI, причем наибольшее их участие требуется во время самого планирования. BO должны быть доступны всегда, когда это необходимо для PMs, а также активно участвовать в системных демонстрациях на каждой итерации. Здесь они не только видят ход выполнения работ, но и дают обратную связь, чтобы помочь менеджеру продукта и владельцам продукта уточнять и адаптировать бэклог.

Мы рекомендуем приоритизировать задачи по принципу «часто и понемногу». А поскольку мы говорим про совместную работу, то ожидается, что Владельцы бизнеса должны присутствовать и на сессиях приоритезации бэклога (это маленькие пики на линии ВО в модели).

Владельцы продукта

На масштабе организации POs работают как на команду, так и на весь поезд. В начале PI, POs сосредоточены на помощи команде и на поддержке PM в работе над бэклогом. По мере того, как бэклог начинает приобретать форму, участие PO увеличивается, но уже в части декомпозиции фич на пользовательские истории для последующего объяснения команде сути работ.

Команда

На протяжении большей части PI команда должна быть сосредоточена на непосредственном выполнении работы, а также на необходимом и достаточном взаимодействии с PM, SA и PO. Повышенное вовлечение команд должно быть запланировано — в конце концов, работа есть работа! Это должно быть сделано за счет планирования в итерации PI исследовательских enabler-историй, а также активностей по поиску новых решений, которые происходят во время IP-итерации. Результатом таких работ является получение необходимых знаний, которые существенно уменьшают неопределенность будущих задач.

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

Release Train Engineer и Scrum Master

Эй, подождите, вы же не забыли об RTE и Scrum Master (SM)? Обычно, они выступают в роли фасилитаторов, так какое же отношение они имеют к элементам бэклога? Давайте порассуждаем об этом. Как фасилитаторы на уровне поезда или команды, они являются ключевыми ответственными за процессы улучшений и доставки ценности. Поэтому вполне разумно ожидать, что они предложат улучшения процессов, которые потребуют вовлечения команд. И конечно же, все то, что требует усилий от команд, должно планироваться и оцениваться соответственно.

Элементы бэклога, которые RTE и SM предложат для включения, скорее всего, будут взяты из командных ретроспектив, мероприятий «Инспекции и адаптации» или из идей, полученных в ходе обучения на курсах по SAFe.

Наполнение бэклога во время PI-планирования

Во время каждого PI-планирования PM представляет определенный объем работы, в котором подсвечиваются предлагаемые решения, а также соответствующие предстоящие вехи. Хотя кому-то может показаться, что на этом этапе процесс создания бэклога для PM закончен — это не так, и ему еще есть над чем работать. Во время планирования, вероятно, могут возникнуть споры по видению проблем и их решению, поскольку команды будут глубже погружаться в контекст и планировать работу в малых группах.

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

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

Тем не менее, предложенной модели не обязательно следовать неукоснительно, а лучше использовать ее для определения того, кто, когда и сколько внимания и усилий должен уделять, чтобы планирование прошло успешно. Упор на качество элементов бэклога во многом поможет поезду, но не решит имеющиеся проблемы с поставкой, однако определенно будет ключевым Enabler-ом на пути к этому.

Следует оговориться: на процесс всегда огромное влияние имеют конкретные особенности вашего продукта! Мы лишь высказали свое мнение о подготовительных мероприятиях, но конкретика всегда будет зависеть в первую очередь от вашего продукта и контекста. При написании этой статьи у нас был немного разный подход к расстановке приоритетов, основанный на нашем предыдущем опыте. Единственно правильного ответа здесь нет, скорее это наш общий взгляд на кейсы клиентов, с которыми мы работали. Поэтому, пожалуйста, относитесь к модели, которую мы создали, как к «ментальной модели», которую вы можете использовать со своими поездами для обсуждения.

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

Последняя мысль и мы вернемся к нашему коллеге, который сказал, что «подготовка к PI-планированию начинается завтра». Запомните — нет никакого смысла заставлять команду следовать планам, которые вы создали, а затем не выполнять их. В противном случае, зачем тогда вообще было проводить PI-планирование?

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