Автор блога на Scrum.org, Christiaan Verwijs, опубликовал несколько статей. Все они посвящены мифам, которые строятся вокруг Scrum. Мифами он обрастает из-за того, что фреймфорк даёт только границы для разработки, но не инструкции.
Является ли уточнение бэклога продукта постоянным событием в расписании вашего спринта? Для него отведён свой день и время? А как он проходит? Разработчики воспринимают уточнение бэклога как событие, где пара человек говорят, а остальные несколько часов подряд умирают от скуки? Если такое описание близко к ситуации в вашей команде, пост будет особенно полезен.
Начнём с того, что уточнение бэклога — это неотъемлемая часть работы по Scrum. К сожалению, оно часто принимает не ту форму, что предполагается авторами фреймворка. Вместо обсуждения команда пассивно сидит за столом в переговорке, пока несколько человек придумывают новые итемы бэклога во всех деталях. Процесс прерывается на ожидание того, пока кто-то записывает всё в JIRA.
Когда работа над бэклогом ведется таким образом, понятно, «почему команда старается тратить меньше времени на одну из ключевых причин, почему scrum-команды показывают потрясающие результаты».
В этом посте Кристиан рассеивает миф в основе того, почему уточнение бэклога тяжело даётся командам, а также предлагает несколько альтернативных подходов.
Что говорит Scrum Guide?
Scrum Guide описывает уточнение бэклога продукта как событие, на котором добавляются детали, оценки и новые элементы в бэклог. Событие позиционируется как постоянное сотрудничество между владельцем продукта и командой разработки. На уточнении бэклога scrum-команда решает, когда и как выполнять новые истории.
Scrum Guide выделяет пять основных событий процесса: спринт, планирование спринта, ежедневный Scrum, ревью спринта и ретроспектива. Таким образом, в руководстве от создателей фреймворка уточнение бэклога не указано как обязательное событие.
Это может показаться незначительным, но это влияет на то, как процесс строится в реальном применении Scrum.
В руководстве подчеркивается, что уточнение бэклога — это то, что команды делают естественно, как часть разработки. Это не то, что обязательно происходит в определённый момент во время спринта. Уточнение не указано как мероприятие, где должна присутствовать вся команда Scrum. Тем не менее, это тонкое различие иногда теряется. Прежде чем перейти к альтернативам, сначала рассмотрим цель такого события, как уточнение бэклога.
Цель уточнения бэклога продукта в Scrum
Scrum построен на том, что разработка продукта — это сложно. Из-за этой сложности лучшие идеи появляются уже тогда, когда мы выполняем работу. Даже ближайшее будущее трудно предсказать. Scrum предлагает фреймворк для того, чтобы это понимание приходило как можно быстрее и команда не теряла фокус, необходимый для решения сложных задач.
Бэклог фиксирует всю работу, необходимую для создания продукта, о которой мы знаем в момент его составления. Некоторые PBI будут небольшими и достаточно ясными, чтобы сделать их за спринт. Другие истории будут слишком большими, слишком абстрактными или всё вместе. Чтобы максимизировать то, что мы можем узнать (например, из отзывов стейкхолдеров и просто в процессе работы), а также для снижения рисков, мы разбиваем и уточняем итемы бэклога до такой степени, чтобы завершить их за спринт.
Может возникнуть соблазн зайти вперед и сразу разбить всю работу в бэклоге на мелкие истории. Но гораздо лучше постепенно прорабатывать истории, с которыми вскоре начнется работа. Время, затрачиваемое на отдалённые PBI, часто теряется впустую. Лучше подходить к вещам в последний момент, со свежим взглядом и актуальной информацией.
Как событие Scrum, уточнение бэклога имеет следующие цели:
- Разъяснение элементов бэклога, которые ещё неясны, чтобы начать работу над ними. Это лучше делать непосредственно с теми, для кого будут реализованы эти истории (с заинтересованными сторонами).
- Разделение крупных элементов, чтобы взять их в спринт.
- Переоценка бэклога, если это необходимо.
- Добавление или удаление элементов из бэклога, когда появляются новые идеи.
- Оценка усилий, связанных с реализацией PBI. Это не должно быть формальным проставлением очков историй. В основном, это проходит уже на планировании спринта.
Таким образом, уточнение — это продолжающийся процесс общения. Иногда это означает общение с заинтересованными сторонами о какой-то истории, в других случаях это может быть элемент, который является частью текущего спринта.
Вместо этой серии разговоров, для многих команд уточнение приняло форму формализованного собрания один раз во время Спринта.
Модель Схождения-Расхождения
Для многих организаций встречи стали стандартом. Только на них команда собирается вместе: за определённое количество времени нужно обменяться всей информацией, чтобы достичь цели. Кажется, это лучший (или даже единственный) способ использовать мудрость и креативность команд и делиться этими знаниями.
Тем не менее, не все действия, связанные с уточнением бэклога, идеально подходят для всей команды. Например, конкретизация PBI может выполняться по подгруппам, которые затем снова сходятся в одну команду.
Конкретизация крупных историй — это сложная деятельность, которая требует много творческих сил и времени, чтобы все обдумать. Как признаёт большинство разработчиков, уточнение может происходить и во время обеденных переговоров, и во время езды на велосипеде. Часто, формальные встречи не лучший вариант для этого умственного процесса.
Существует естественный рабочий процесс во время спринта. Мы хотим нарушать его как можно реже, и именно поэтому Scrum Guide выделяет только четыре обязательных события во время спринта.
Многие команды могут извлечь выгоду из схемы схождения-расхождения. Сотрудники решат, какие истории нужно уточнить или разделить, и кто хочет или должен в этом участвовать. Затем небольшие группы выполняют эту работу во время спринта или перерывов (расхождение) и делятся своими результатами со всей scrum-командой позже, когда надо выбрать следующие шаги (схождение).
Другие действия, такие как оценка или перераспределение историй в бэклоге, могут проходить совместно. Во время спринта может возникнуть несколько циклов схождения-расхождения: зависит от сложности того, что нужно уточнить.
Каким бы образом вы не проводили уточнение бэклога, убедитесь, что все одинаково вовлечены. Антимодель — когда в уточнении бэклога участвуют только аналитики или ведущие разработчики: так игнорируется «мудрость толпы», то есть мнение всей команды.
Дополнительные советы
Вместо того, чтобы тратить часы за столом, работа над бэклогом — отличная возможность для Scrum-мастера помочь своей команде.
Предложите команде сформировать небольшие группы, которые несут ответственность за уточнение отдельных итемов в предстоящем спринте. Пусть они решат, как и когда это делать, сотрудничая с владельцем продукта и стейкхолдерами. Наметьте время, когда подгруппы обменяются идеями со всей командой и получат фидбек;
Не используйте инструменты (например, JIRA) во время уточнения. Это огромная трата энергии и творческих сил: люди ждут под звук клавиш, когда уточнение обретёт цифровой вид. Вместо этого, работайте со стикерами или рисунками, а остальное оформите позже. Если вам действительно нужно использовать инструменты во время уточнения бэклога, убедитесь, что у каждого есть доступ к ним и вы можете работать совместно.
Во время работы над бэклогом пользуйтесь инструментами фасилитации, например, приемом 1-2-4-ALL или чек-листами.
Предлагайте стейкхолдерам принимать участие в событии, когда это необходимо. Чтобы построить правильный продукт, вам, безусловно, понадобятся их знания.
Попросите членов команды самим решить, хотят ли они участвовать в уточнении бэклога. Попросите их определить, могут ли они внести свой вклад в эту встречу. Если после этого никто не пришел на разбор бэклога, у вас есть серьезная тема для предстоящей ретроспективы.
Поэкспериментируйте с тем, что подходит вашей команде. Для некоторых команд лучший способ — работать вместе. Для других больше подходят подгруппы. Это зависит от размера и зрелости команды и сложности работы.
В статье Кристиан разоблачил миф о том, что уточнение бэклога продукта должно проводиться в форме «совещаний», на которых должны присутствовать все. Автор уточнил цель этого события, предложил альтернативные подходы и поделился советами для повышения эффективности.
А как разбор бэклога проходит в вашей scrum-команде? Какие методы для оптимизации процесса знакомы вам?