Повышайте Agility при помощи PBR

Уточнение Бэклога Продукта (PBR) в однокомандном Скраме не является официальным событием. В масштабированной разработке (LeSS, Nexus) комплексность продукта резко возрастает, и PBR становится обязательным каждый Спринт. В этой статье я объясню, как с помощью PBR повысить организационную гибкость (Agility) продуктовой группы.

Недавно я разговаривал с начинающим Скрам-мастером: она запускала со мной продуктовую группу. За неделю до первого Спринта мы вместе готовили план активностей. Продуктовая группа состояла из нескольких Скрам-команд, работающих над одним продуктом. С одним Владельцем Продукта, естесственно.

Я спросил: «Какое событие Скрама ты бы хотела “отладить” в первую очередь: Планирование Спринта, Ежедневный Скрам или что-то еще?» Подумав, она ответила: «Планирование Спринта». Ответ логичный, ведь Планирование Спринта — первое событие в любом Спринте. Так ли очевиден ответ?

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

Уточнение Бэклога Продукта (PBR) снижает вариабельность Элементов Бэклога Продукта (PBI) до взятия в работу в Спринт. Согласно Закону размещения изменчивых элементов [HS08], самое негативное влияние на Cycle Time оказывают элементы очереди, стоящие перед многоступенчатой системой. Спринт—именно такая многоступенчатая система. Когда Элементы Бэклога Продукта (PBI) приобретают статус готовности(“ready”), Команда Разработки сталкивается с меньшим количеством «неожиданностей» в Спринте, и вероятность достижения Цели Спринта значительно возрастает.

Считаю, что Скрам-мастеру нужно обращать самое пристальное внимание именно на Уточнение Бэклога Продукта (PBR) вначале. Первый PBR должен пройти еще до первого Спринта. Мы формируем Бэклог Продукта и готовим его к инспекции на первом Планировании Спринта.

Часто использую такую последовательность Скрам-паттернов для запуска потока требований: Видение -> Дорожная карта Продукта -> Бэклог Продукта -> (Уточненный Бэклог Продукта | Информационный радиатор) -> Маленькие элементы -> (Критерии Готовности для взятия в Спринт | Поинты оценки).

Но PBR еще и инструмент повышения гибкости (Agility) продуктовой группы. Давайте разберемся почему.

В независимости от количества команд, разрабатывающих продукт, используется только один Бэклог Продукта:

В масштабируемой среде существуют два основных формата PBR: однокомандный и мульти-командный. При мульти-командном варианте две Команды Разработки или более уточняют детали Бэклога Продукта совместно со стейкхолдерами и конечными пользователями напрямую (тем самым, разгружая Владельца Продукта). Некоторые из плюсов применения мульти-командного PBR в продуктовой группе:

Как фасилитировать мульти-командные события читайте в статьях:

Совместное уточнение несколькими командами элементов Бэклога Продукта (PBI) создает условия, когда каждая команда в курсе, чем занимаются другие команды в Спринте. Это значительно упрощает координацию. А зависимости теперь обнаруживаются сами собой. Не нужны специальные координаторы и лишние встречи. Команды координируют свою работу и зависимости благодаря возникающей самоорганизации (Рис. 1).

Замечаю одну причину, по которой команды противятся мульти-командному PBR —наличие значительных пробелов в доменной области продукта. Продолжительная работа с узким определенным продуктом формирует специалистов узкого профиля. Разработчикам не нравится выходить из зоны комфорта. Кроме того, непосредственное взаимодействие с конечными пользователями и клиентами также вызывает дополнительный стресс. Используйте мульти-командный PBR с осторожностью. Не стоит с самого начала приглашать 6–8 команд в одно помещение. Начинайте с 2-3 команд (Рис. 2):

Мульти-командный PBR влияет на тактическую и стратегическую гибкость. Под «тактической гибкостью» имеется в виду возможность отложить решение, какая из команд берет конкретный элемент Бэклога Продукта (PBI) в Спринт, до самого Планирования Спринта. Под «стратегической гибкостью» понимается способность продуктовой группы поддержать радикальное изменение разработки продукта. Оно может быть вызвано появлением революционных технологий или другими событиями на рынке (Рис. 3)

Выберите свою комбинацию однокомандного и мульти-командного PBR

Я успешно фасилитировал PBR для шести команд одновременно. Такое событие занимает 2–3 часа. Но ваша продуктовая группа нуждается в собственной комбинации однокомандного и мульти-командного PBR. Вам нужно найти свою точку на диапазоне от ограниченной (использование исключительно одно-командных PBR) до радикальной гибкости (использование только мульти-командных PBR).

Приведу несколько примеров.

Поделюсь отрывком из кейса МТС. В продуктовую группу входило семь фиче-команд, работающих над одним продуктом. Вот как выглядел начальный процесс PBR:

Продуктовая группа использовала в работе двухнедельные Спринты. Уточнение начиналось с предварительной встречи представителей команд. На ней планировалось, какие Элементы Бэклога Продукта (PBI) должны обсуждаться и уточняться далее. Команда из Украины, как правило, проводила собственный однокомандный PBR. Причина—удаленность команды. Остальные шесть команд разделялись на две группы по три и проводили параллельные мульти-командные PBR. Почему не сразу шесть команд одновременно? Причина очень прозаична. Не нашлось помещения, которое бы вместило всех.

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

Что я предложил сделать? Решено было, во первых, перейти к сквозным приоритетам и одному Бэклогу Продукта. Во вторых, проводить полезные и ценные мульти-командные PBR для всей продуктовой группы одновременно. Ниже вы видите фотографию с первого (самого памятного) проведенного нами мульти-командного PBR. Обратите внимание на сквозной Бэклог Продукта в левой части.

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

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