В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.
Почему PBR важен
PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.
Разработчики общаются с клиентами напрямую
Очень часто замечаю дисфункциональные имплементации Скрама, когда между разработчиками и рынком стоят промежуточные лица, препятствующие прямой коммуникации и являющиеся источником потерь. Примеры потерь:
- промежуточные артефакты (BRD, спецификации и т.д.);
- многочисленные передачи, как результат, искажение и потеря информации;
- низкая скорость принятия решений;
- отсутствие эмпатии у разработчиков по отношению к клиентам/пользователям продукта;
- непонимание разработчиками бизнес-домена.
Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки.
Такой подход лежит в основе масштабируемого Скрама. Когда продукт разрабатывают много команд, то у Владельца Продукта не хватает времени на прояснение элементов Бэклога Продукта. Он делегирует эту активность командам и оставляет за собой упорядочивание Бэклога Продукта.
В масштабируемом Скраме команды выясняют детали требований напрямую со стейкхолдерами. Владелец Продукта оставляет за собой упорядочивание Бэклога Продукта.
Команда в полном составе присутствует на PBR
Некоторые команды высылают на PBR представителей. Несмотря на то, что такой подход работает в некоторых контекстах, у него есть побочные эффекты. Создаются вынужденные передачи и потери. Знания об элементах Бэклога Продукта находятся в головах лишь у нескольких лиц. Этого можно избежать, если на PBR присутствуют все участники команды.
Анализом занимается вся команда, не бизнес-аналитики
Еще один анти-паттерн, который я часто наблюдаю — выделенные бизнес-аналитики, занимающиеся только бизнес анализом. Они служат прокси между стейкхолдерами и командой. Часто в такой структуре в Спринте N-1 проводится бизнес-анализ, а в Спринте N непосредственно сама разработка (код, тестирование и т.д.).
Бизнес-анализ является одной из функций в команде и за нее отвечают все, а не выделенный бизнес-аналитик. Более того, возвращаясь к оригинальной концепции Скрама, Команда Разработки выполняет все активности, начиная от интервью с пользователями до поставки на рынок ценности и поддержки продукта. Работы максимально распараллеливаются. Для этого команда самоорганизуется и использует различные техники. Например, парное программирование, Swarming, моб-программирование.
Пример эффективного PBR
Ниже я детально опишу, как мы проводили один из PBR-ов. Контекст — продуктовая группа (≅30 человек), разрабатывающая один продукт. Соответственно, имеем один Бэклог Продукта и одного Владельца Продукта. На встречу приглашены две команды разработчиков (14 человек), стейкхолдеры из смежных подразделений, которые выступали главными заказчиками функциональности. Мы хотели, чтобы разработчики напрямую уточнили требования со стейкхолдерами.
Цель, желаемые результаты, рабочие договоренности. (5 мин)
Любая эффективная встреча начинается с определения ее цели и желаемых результатов. В нашем случае цель звучала так: “декомпозировать огромную фичу, приоритезировать полученные элементы, определить минимальный необходимый набор функциональности (MVP) для реализации”. Мы договорились о том, что встреча займет не более 2х часов и через час сделаем перерыв.
Верхнеуровневое выравнивание (10 мин)
В открытой дискуссии мы потратили не более 10 мин на обсуждение фичи в формате: Кто, Что и Зачем.
- Кто: на какой сегмент клиентов ориентирована фича
- Что: верхнеуровневый скоуп работ и что туда входит
- Зачем: какая потребность закрывается функциональностью и какая бизнес-ценность создается.
Формируем смешанные группы (5 мин)
Общение в малых группах проходит эффективно, когда в них есть как минимум один стейкхолдер и представители разных команд. Нам удалось сформировать 3 такие смешанные группы. Каждая группа сформировала станцию в общем помещение и продолжила работу.
Первый раунд: разбиение (20 мин)
Мы попросили команды на выходе получить дерево с вариантами разбиения. Сверху помещается изначальное требование. Затем подбираем подходящий паттерн разбиения, получаем следующий уровень. И так далее.
Второй раунд: переход на соседнюю станцию (5 мин)
Так как в предыдущем раунде все группы работали над одним и тем же заданием, то мы попросили команды оставить одного представителя на месте, а остальных перейти по часовой стрелке к следующей станции. Это нужно для того, чтобы узнать, что делали другие команды, а также для получения обратной связи.
Перерыв (10 мин)
Вовлеченно работать более 50-60 минут тяжело. Даже если участники говорят нам о том, что они не устали и готовы работать дальше, мы настаиваем на небольшом перерыве. Чай, кофе и глюкоза (конфеты, печенье) очень полезны. Тем ни менее, хороший знак, если кто-то остается на станциях и продолжает работать. Это сигнал высокой вовлеченности. Значит PBR эффективен.
Третий раунд: завершение разбиения (20 мин)
После перерыва мы дали еще 20 минут на то, чтобы завершить разбиение. Цель в том, чтобы получить небольшие элементы Бэклога Продукта, которые могут быть завершены в Спринте (“ready”). Ниже один из вариантов разбиения, который получился у одной из групп:
Четвертый раунд: представление результатов (20 мин)
Группы по очереди представляют свои варианты разбиения в открытой дискуссии. Интересно, что они пришли к аналогичным результатам. Минимальный набор фич (MVP) оказался на удивление мал. Главным инсайтом PBR оказалось то, что основную бизнес-ценность можно достичь относительно небольшими усилиями. Все согласились с тем, что формат проведения PBR оказался очень эффективным. Когда разработчики напрямую общаются с представителями бизнеса, работая со стикерами и маркерами, фиксируя результаты на листах бумаги, результаты оказываются просто удивительными.
Основные мысли
- Стейкхолдеры, пользователи и разработчики общаются напрямую.
- Полезно, когда на PBR присутствует Команда(ы) Разработки в полном составе.
- За бизнес-анализ, как и другие функции, отвечает целиком Команда Разработки, нет выделенных бизнес-аналитиков.
- В больших продуктах уточнением Бэклога Продукта занимаются разработчики, а Владелец Продукта оставляет за собой определение порядка элементов Бэклога Продукта (PBI).
- PBR эффективно проводить, используя форматы малых групп, мирового кафе, циклы “схождения-расхождения”.
