Уточнение Бэклога Продукта (PBR) в однокомандном Скраме не является официальным событием. В масштабированной разработке (LeSS, Nexus) комплексность продукта резко возрастает, и PBR становится обязательным каждый Спринт. В этой статье я объясню, как с помощью PBR повысить организационную гибкость (Agility) продуктовой группы.
Вопрос молодому Скрам-мастеру
Недавно я разговаривал с начинающим Скрам-мастером: она запускала со мной продуктовую группу. За неделю до первого Спринта мы вместе готовили план активностей. Продуктовая группа состояла из нескольких Скрам-команд, работающих над одним продуктом. С одним Владельцем Продукта, естесственно.
Я спросил: «Какое событие Скрама ты бы хотела “отладить” в первую очередь: Планирование Спринта, Ежедневный Скрам или что-то еще?» Подумав, она ответила: «Планирование Спринта». Ответ логичный, ведь Планирование Спринта — первое событие в любом Спринте. Так ли очевиден ответ?
Двойственная природа Скрама
Скрам обладает двойственной природой и состоит из двух сущностей. Первая — продуктовая организация, которая описывает людей, команды, роли и взаимосвязи между ними. Вторая сущность — поток создания ценности, который начинается с формирования предположений (требований), а завершается “готовым” к поставке инкрементом и циклом обратной связи. В эффективном Скраме необходимо уделять внимание каждой сущности. Они наглядно представлены в двух языках паттернов. Если вы еще не знакомы с паттернами Скрама, то погрузиться в них вам помогут статьи:
Берем фокус на PBR
Уточнение Бэклога Продукта (PBR) снижает вариабельность Элементов Бэклога Продукта (PBI) до взятия в работу в Спринт. Согласно Закону размещения изменчивых элементов [HS08], самое негативное влияние на Cycle Time оказывают элементы очереди, стоящие перед многоступенчатой системой. Спринт—именно такая многоступенчатая система. Когда Элементы Бэклога Продукта (PBI) приобретают статус готовности(“ready”), Команда Разработки сталкивается с меньшим количеством «неожиданностей» в Спринте, и вероятность достижения Цели Спринта значительно возрастает.
Считаю, что Скрам-мастеру нужно обращать самое пристальное внимание именно на Уточнение Бэклога Продукта (PBR) вначале. Первый PBR должен пройти еще до первого Спринта. Мы формируем Бэклог Продукта и готовим его к инспекции на первом Планировании Спринта.
Часто использую такую последовательность Скрам-паттернов для запуска потока требований: Видение -> Дорожная карта Продукта -> Бэклог Продукта -> (Уточненный Бэклог Продукта | Информационный радиатор) -> Маленькие элементы -> (Критерии Готовности для взятия в Спринт | Поинты оценки).
![](https://static.tildacdn.com/tild6463-6330-4361-b036-303035336330/image.png)
Но PBR еще и инструмент повышения гибкости (Agility) продуктовой группы. Давайте разберемся почему.
Однокомандный и мульти-командный PBR-ы
В независимости от количества команд, разрабатывающих продукт, используется только один Бэклог Продукта:
“Если над одним продуктом работает несколько Скрам-команд, для описания предстоящей работы используется один Бэклог Продукта” (Scrum Guide).
В масштабируемой среде существуют два основных формата PBR: однокомандный и мульти-командный. При мульти-командном варианте две Команды Разработки или более уточняют детали Бэклога Продукта совместно со стейкхолдерами и конечными пользователями напрямую (тем самым, разгружая Владельца Продукта). Некоторые из плюсов применения мульти-командного PBR в продуктовой группе:
- улучшенная координация между командами;
- повышенная тактическая и стратегическая гибкость.
Как фасилитировать мульти-командные события читайте в статьях:
![](https://static.tildacdn.com/tild3263-3761-4665-b939-373938326665/image.png)
Координация, основанная на самоорганизации
Совместное уточнение несколькими командами элементов Бэклога Продукта (PBI) создает условия, когда каждая команда в курсе, чем занимаются другие команды в Спринте. Это значительно упрощает координацию. А зависимости теперь обнаруживаются сами собой. Не нужны специальные координаторы и лишние встречи. Команды координируют свою работу и зависимости благодаря возникающей самоорганизации (Рис. 1).
![](https://static.tildacdn.com/tild3834-6364-4161-b766-303331346136/image.png)
Временный стресс
Замечаю одну причину, по которой команды противятся мульти-командному PBR —наличие значительных пробелов в доменной области продукта. Продолжительная работа с узким определенным продуктом формирует специалистов узкого профиля. Разработчикам не нравится выходить из зоны комфорта. Кроме того, непосредственное взаимодействие с конечными пользователями и клиентами также вызывает дополнительный стресс. Используйте мульти-командный PBR с осторожностью. Не стоит с самого начала приглашать 6–8 команд в одно помещение. Начинайте с 2-3 команд (Рис. 2):
![](https://static.tildacdn.com/tild3136-3132-4733-b635-613962613630/image.png)
Тактическая и стратегическая гибкость
Мульти-командный PBR влияет на тактическую и стратегическую гибкость. Под «тактической гибкостью» имеется в виду возможность отложить решение, какая из команд берет конкретный элемент Бэклога Продукта (PBI) в Спринт, до самого Планирования Спринта. Под «стратегической гибкостью» понимается способность продуктовой группы поддержать радикальное изменение разработки продукта. Оно может быть вызвано появлением революционных технологий или другими событиями на рынке (Рис. 3)
![](https://static.tildacdn.com/tild6237-6534-4235-b063-316662356533/image.png)
Выберите свою комбинацию однокомандного и мульти-командного PBR
![](https://static.tildacdn.com/tild3665-3237-4132-a661-316533323735/image.png)
Я успешно фасилитировал PBR для шести команд одновременно. Такое событие занимает 2–3 часа. Но ваша продуктовая группа нуждается в собственной комбинации однокомандного и мульти-командного PBR. Вам нужно найти свою точку на диапазоне от ограниченной (использование исключительно одно-командных PBR) до радикальной гибкости (использование только мульти-командных PBR).
Приведу несколько примеров.
Пример “МТС Касса”
Поделюсь отрывком из кейса МТС. В продуктовую группу входило семь фиче-команд, работающих над одним продуктом. Вот как выглядел начальный процесс PBR:
![](https://static.tildacdn.com/tild3138-3038-4562-a435-656330313237/image.png)
Продуктовая группа использовала в работе двухнедельные Спринты. Уточнение начиналось с предварительной встречи представителей команд. На ней планировалось, какие Элементы Бэклога Продукта (PBI) должны обсуждаться и уточняться далее. Команда из Украины, как правило, проводила собственный однокомандный PBR. Причина—удаленность команды. Остальные шесть команд разделялись на две группы по три и проводили параллельные мульти-командные PBR. Почему не сразу шесть команд одновременно? Причина очень прозаична. Не нашлось помещения, которое бы вместило всех.
Пример “ОК, Альфа”
В продуктовую группу вошло пять кросс-функциональных команд, работающих над одним продуктом. К сожалению, не все команды были полноценными фиче-командами. Некоторые разработчики, обладающие уникальной экспертизой, переходили из команды в команду. Участники команд также часто жаловались на дублирование функциональности, отсутствие фокуса на всем продукте и зависимости. Команды строго использовали только однокомандный тип PBR. Ситуация усложнялась еще наличием пяти фейковых Бэклогов Продуктов, которые со временем создали локальные идентификации у команд. Разработчики привыкли работать со своими “Владельцами Продуктов” и знали только узкую доменную область.
Что я предложил сделать? Решено было, во первых, перейти к сквозным приоритетам и одному Бэклогу Продукта. Во вторых, проводить полезные и ценные мульти-командные PBR для всей продуктовой группы одновременно. Ниже вы видите фотографию с первого (самого памятного) проведенного нами мульти-командного PBR. Обратите внимание на сквозной Бэклог Продукта в левой части.
![](https://static.tildacdn.com/ffb6456b-781b-40e8-9517-ffb5225e8bcd/imgfish.jpg)
Прекрасно помню тот день во всех деталях. Это было потрясающе: люди активно участвовали в проведении PBR и были довольны результатами. Неудивительно, ведь мульти-командный PBR собирать всех в одном помещении, невероятно вовлекает в процесс уточнения требований. Никаких асинхронных зависимостей: все вопросы решаются одновременно и быстро.
Выберите собственную комбинацию PBR
В этой статье мы узнали, как при помощи PBR можно повысить тактическую и стратегическую гибкость в масштабированном Скраме. Все, что нужно — подобрать оптимальное сочетание одно-командных и мульти-командных событий на пользу продуктовой вашей группы. Надеюсь, статья полезна для вас.
Ключевые мысли
- У Скрама двойственная природа. Он состоит из двух сущностей: продуктовой организации и потока создания ценности
- PBR снижает вариабельность Элементов Бэклога Продукта (PBI) до их попадания в Спринт
- В масштабируемом Скраме существует два основных формата PBR: однокомандный и мульти-командный
- Выгоды применения мульти-командного PBR для продуктовой группы: улучшение координации, повышение тактической и стратегической гибкости
- Мульти-командный PBR вызывает временный стресс у команды из-за пробела в доменных знаниях
- PBR—это не игра с нулевой суммой. Найдите правильную комбинацию однокомандного и мульти-командного PBR.