Перевод оригинальной статьи Сезарио Рамоса «Multi-team Backlog Refinement»
В этой небольшой статье я поделюсь с вами некоторыми советами по мультикомандному Уточнению Бэклога Продукта.
Что такое Уточнение Бэклога Продукта?
Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта (Product Backlog Items, PBI), которые предстоит взять в работу в следующих Спринтах. В однокомандном Скраме команда обычно проводит одну или несколько подобных встреч за Спринт.
Ниже приведены примеры связанных с этим событием активностей:
- Понимание того, какую проблему надо решить: Владелец Продукта рассказывает несколько последовательных историй и связывает их с текущими бизнес-целями. Команда обсуждает “почему мы это делаем?”, “как понять, что мы решаем нужную проблему?”. Некоторые команды используют карту историй (story mapping), карту влияния (impact mapping), игры «Speedboat», «Я и моя тень» и технику «5 почему».
- Разбивка больших элементов для более простого обсуждения и изучения.
- Оценка элементов.
- Понимание потребностей клиента: команда обсуждает“Почему пользователь хочет этого?”, “Правильно ли мы решаем его проблему?”. Некоторые команды используют доску историй (storyboard) до и после, карты Pain Gain.
- Прояснение элементов: Некоторые команды используют технику спецификации на примерах (Specification By Example) и создают приемочные тесты для пользовательских историй, используют описание историй с помощью спецификаций языка Gherkin, таблицы потоков и/или таблицы решений.
- Определение планов исследовательского тестирования:Выявление рисков при достижении цели, выявление фич, которые требуют ручного тестирования. Некоторые команды используют план исследовательского тестирования (Exploratory Test Charter) для каждой фичи и проводят сессии исследовательского тестирования всей командой.
- Создание первоначального дизайна: Моделирование на магнитной доске, прототипы дизайна…
(больше примеров можно найти в нашей статье в журнале Testing Experience)
Командам, которые совместно работают над одним продуктом, может быть полезно проводить мультикомандное PBR. Но как можно провести PBR для нескольких команд одновременно и зачем это делать?
Для чего нужно мультикомандное PBR?
Мультикомандное PBR — это мероприятие, в ходе которого все члены команд совместно уточняют PBI(s), не принимая решений о том, какая команда будет выполнять тот или иной элемент.
Ниже приведены несколько преимуществ мультикомандного PBR: (на самом деле, преимуществ гораздо больше, но их перечисление может сделать эту статью слишком длинной)
- Адаптивность на уровне продукта. Почему? Потому что каждая команда понимает все PBI в Бэклоге Продукта, а не только «свои» (то есть определенное подмножество Элементов Бэклога Продукта). Если все команды понимают все PBI, тогда Владелец Продукта может разместить PBI, которые считает наиболее значимыми, выше, при этом не создавая конфликтов с теми, которые понимает лишь одна команда.
- Улучшение самокоординации. Почему? Потому что команды обладают широким пониманием продукта в целом и предстоящих PBI, а значит, лучше понимают «зависимости» между PBI.
- Прозрачные метрики прогресса на уровне Продукта. Почему? Потому что все команды участвуют в оценке всех PBI. Следовательно, у них одно общее понимание оценок.
Как проводить мультикомандное PBR?
Активности, выполняемые при однокомандном PBR можно точно также использовать и для нескольких команд. Основное различие в том, что их эффект усиливается благодаря фасилитации больших групп людей.
Я предпочитаю создавать новые группы на основе участвующих в сессии PBR, вместо того чтобы использовать постоянные команды. Например, предположим, что у нас есть четыре команды: A, B, C и D. Во время Уточнения Бэклога Продукта я прошу их перегруппироваться так, чтобы все команды включали в себя по одному человеку из каждой другой команды. Для чего? С группами, включающими в себя участников других команд, все PBI уточняются по крайней мере одним представителем каждой команды. Это позволяет достичь совместного владения и широкого понимания PBI.
Форматы мультикомандного PBR
Работая с командами, я показываю им четыре способа мультикомандного PBR, чтобы они выбрали, какой способ им больше подходит, и применяли его, впоследствии улучшая.
Я работаю со следующими четырьмя форматами:
Полная рулетка (Full Roulette)
Каждая группа выбирает один PBI и начинает его Уточнение на своей станции. После таймбокса (мне нравятся таймбоксы по 15 минут) все группы переходят на следующую станцию и продолжают PBR с того этапа, на котором остановилась другая группа. Это продолжается до тех пор пока все PBI не будут уточнены или таймбокс совещания не истечет. Группы при этом могут использовать любые подходы, которые им нравятся.
Полная рулетка даёт хорошие результаты, так как группы чувствуют необходимость сделать свою работу максимально ясной и понятной для другой группы.
Частичная рулетка (Partial Roulette)
Проводится так же, как и полная рулетка, но вместо перемещения всей группы на другую станцию, один её участник остаётся. Он объясняет новой группе, что именно они обсуждали, перед тем как продолжить PBR.
Сперва я использую именно этот подход, потому что с него проще начинать. Когда у команд появляется достаточный опыт использования частичной рулетки, я предлагаю им попробовать полную рулетку.
Расхождение и слияние
При использовании этого подхода группы совершают расхождение-слияние после каждого таймбокса. На каждой станции остаётся по одному участнику, они становятся учителями. Затем все группы отправляют по одному участнику на каждую из других станций. Например, предположим, у нас есть группы A, B, C и D. Один участник из группы A остается на станции для обучения, один участник переходит в группу B, один — в группу C, и ещё один — в группу D. После обучения эти участники возвращаются в исходную группу и делятся своими знаниями. Любые затруднения и вопросы обсуждаются в группе.
Я применял эту методику к группам примерно до 35 человек.
Обратное обучение
Каждая группа выбирает PBI и уточняет его. После таймбокса каждая группа рассказывает о своей работе остальным командам и проводит обсуждение в форме вопросов и ответов.
Эта методика не очень хорошо подходит для большого количества команд, потому что обратное обучение таких групп может занять слишком много времени. Кроме того, с большим количеством людей сложнее проводить обсуждение в открытой дискуссии.
Роль Владельца Продукта и клиентов
Владелец Продукта и клиенты играют важную роль во время сессий PBR. Владелец Продукта должен быть подготовлен и иметь понимание того, что необходимо сделать с точки зрения бизнеса. Он может обсудить общие вопросы, например, используя карту историй, а также присоединиться к любой из групп, когда потребуется.
Вы также можете захотеть привлечь конечных пользователей или людей, которые близки к ним (например, специалистов по продажам, специалистов службы поддержки и т. д.), к участию в сессиях подробного PBR.
Подход, который нравится мне больше всего — полная рулетка. Он показал себя как наиболее эффективный. Если вы решите попробовать любой из описанных выше подходов, я буду очень рад услышать о результатах.
Цезарио занимается широкомасштабными Аджайл-трансформациями по всему миру. Автор книг «Emergent» и «Scrum Patterns». Он также является сертифицированным тренером LeSS, профессиональным тренером по Скраму (Professional Scrum Trainer™) и сертифицированным коучем.
