Смотримвбудущее(Grooming)
Недавно получил письмо от одного из участников моих тренингов следующего содержания:
Привет, Сергей! У меня короткий вопрос о Grooming-ах… В последнее время наши grooming встречи все больше и больше фокусируются на получении оценок к историям из беклога, однако, некоторые члены команды начинают сетовать по поводу того, что они хотели бы лучше понимать истории до того, как они начнут голосовать по поводу их оценок…
И несмотря на то, что наши оценки всегда примерно в одном спектре (например, все показывают 3 стори поинта), члены команды говорят, что они не всегда полностью понимают, за что же они голосовали… На сегодняшний день мы голосуем и начинаем обсуждение только в случае, если будут обнаружены расхождения оценок. Итак, мой вопрос: стоит ли тратить время на grooming встрече на “понимание историй” до того как приступать к голосованию? И если да, то сколько? С одной стороны, я чувствую, что хорошо понимать истории – это важно, а с другой стороны, их изучение – не самое эффективное времяпровождение.
Я ответил в следующем ключе:
Понимание элементов бэклога (историй) требует больше времени, чем отведено на это на планировании спринта. Это факт, и большинство высоко эффективных команд на сегодняшний день делают так называемое “скользящее планирование” (rolling-planning) [кстати, у кого есть лучший русский вариант термина, пишите в комменты].
На сегодняшний день мы учим такие команды посвящать 15-20 минут каждый день сразу после Дэйли скрама (таким образом, мы не отвлекаем команду еще одной встречей, поскольку они уже отвлечены Дейли) обсудить одну историю более детально. У всех появляется возможность заняться разведкой и до следующего стендапа посмотреть на историю, покопаться в ней индивидуально, и, тем самым, подготовиться к планированию, чтобы чувствовать себя более комфортно.
Таким образом, планирование превращается в простой выбор, что же конкретно мы будем делать… это занимает около 10 минут и позволяет сразу перейти к распилу историй на задачи, и вовлечь всех в работу незамедлительно. Потом команда инспектирует и подстраивается соответсвующим образом каждый день. При двухнедельной продолжительности спринтов у вас получится 2 часа (15 минут * 8 дней), которые вы сэкономили от планирования спринта.
Когда все голосуют одинаково, не имея общего понимания, за что же они голосуют, это наводит меня на мысль, что команда не понимает до конца, в чем ценность получения оценок, что является отдельной темой [пожалуй, я опубликую новый пост на эту тему в ближайшее время].
Таким образом, цель grooming-а – это достижение общего понимания какую проблему мы будем решать, а также обсудить некое общее решение, которое является лучшим компромиссом между качеством (сервиса, а не нашей работы), ценой, и бизнес ценностью, которое должно отражаться на упорядочивании бэклога, которое становится функцией “ценности”, “рисков”, “удобства”, “технических” и “функциональных зависимостей”.
А что бы вы ответили на данное письмо?
Шаг 1. Определить связь PBI с бизнес-целью
Мы обсудили, что связывает PBI с ближайшей бизнес-целью: с увеличением конверсии заявок с сайта (CR). Если ранее вы не определили бизнес-цель, то техника Impact Mapping и её вариация Extended Impact Mapping точно помогут на этом шаге.Шаг 2. Описать PBI в формате «кто, что и зачем»
Я часто использую такой формат описания элементов Бэклога Продукта:- кто — пользовательский сегмент или персона;
- что — краткое описание задачи;
- зачем — бизнес-ценность или ценность для пользователя.
Шаг 3. Разбить PBI в малых группах
Мы сформировали четыре группы по 3–5 человек и отправили их на рабочии станции в опенспейсе, где они в течение 20 минут декомпозировали PBI. Ребята использовали паттерны разбиения и другие техники, в частности, User Story Mapping. Если команды ещё не владеют навыками декомпозиции, нужно провести обучающий воркшоп.
Шаг 4. Представить варианты разбиения
У нас получились четыре варианта декомпозиции. Теперь я хотел, чтобы мы нашли самое ценное в каждом из них. Для этого мы прошлись по каждой рабочей станции, где нам презентовали каждый из вариантов разбиения. На каждой станции мы пробыли не более пяти минут.
Шаг 5. Провести финальную «склейку»
Я попросил Владельца Продукта и нескольких представителей команд сделать финальную «склейку» различных вариантов декомпозиции. Для этого мы принесли все флипчарты и повесили их на стену. Владелец Продукта выбирал наиболее удачные части и размещал их на финальной версии.
Шаг 6. Оценить и приоритезировали полученные фичи
К этому моменту гигантская фича была разбита на более мелкие элементы. Я попросил представителей из каждой команды провести экспресс-оценку при помощи «рубашечных размеров». Затем Владелец Продукта упорядочил все полученные фичи. В итоге мы получили 11 фич, самые приоритетные из которых должны были комфортно поместиться в двухнедельном Спринте.
Шаг 7. Прояснить приоритетные PBI
Каждая группа, взяв одну фичу из верхушки Бэклога Продукта, прояснила её на рабочей станции. Через 20 минут на каждой станции появились:- описание фичи,
- обновлённая оценка,
- приемочные критерии,
- бизнес- и пользовательская ценности.
Шаг 8. Обсудить полученную ценность
Перед закрытием встречи я попросил озвучить полученные ценности и зафиксировать результат на флипчарте. Это были оценки, цель на квартал, полная картина происходящего.Выводы
- Предпочитайте использовать Multi-Team PBR, когда Бэклог Продукта актуализируют сразу несколько команд.
- Всегда начинайте обсуждение PBI со связи с бизнес-целью.
- Декомпозируйте элементы Бэклога Продукта с помощью паттернов разбиения и техники User Story Mapping.
- Работайте в малых группах и форматах мирового кафе, трейдшоу или коктейльной вечеринки.
- Для лучшего взаимодействия используйте бумагу, флипчарты, ножницы или стикеры.
Условия задачи
Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.Что происходит
Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
- возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
- стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
- рабочий процесс перестаёт быть прозрачным.
Решение
Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:- объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
- помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
- научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
- помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
- визуализировать поток работы. Прозрачность — залог успеха;
- устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
- объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Итоги
Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:- декомпозиция работы на небольшие PBI;
- визуализация потока работы в Спринте и поиск основных узких мест;
- устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
- планомерная ликвидация технического долга.
Спасибо за вопросы, Константин.
Цель скользящего планирования, в первую очередь, во втором, это и хотелось сказать в статье:
По первому вопросу, большинство команд работает на обычном grooming-e, который проводится регулярно и еженедельньно, плюс нерегулярно по требованию PO (помним, что команды типично резервируют 10-15% времени на подобные нужды), как раз для того, чтобы удовлетворить его любопытство по поводу оценок (высокого уровня).
У меня вопрос: какая истинная цель в проведении "скользящего планирования"? 1. проставить оценки (более точно)? или 2. дать команде разобраться с тем что ее ждез в следующем спринте?
По статье создается впечатление, что для первого ("..понимать перед тем как голосовать...") но тогда не решается более важная (для овнера) задача - получить список оцененных командой задач как можно быстрее (асап - овнеры они такие ;) )
коментарии?
--Константин
Спасибо за хорошие дополнения.
Rolling-planning - процесс “скользящего(непрерывного) планирования”.
Главное преимущество такого планирования в том, что видно и понятно, что делать дальше.
Оно позволяет повысить чувствительность к изменениям, сделать свои реакции на эти изменения более адекватными и своевременными.
Непрерывный процесс ведения скользящего планирования повышает его качество, позволяет обеспечить постоянную вовлеченность команды в процесс, оперативность реагирования (т.к. используется в качестве повседневного инструмента) и принятие общего решения.