Предлагаю перевод небольшой статьи Андерса Абеля на волнующую меня в данный момент тему — качественный и формализованный процесс подготовки задач к передаче в разработку при условии, что разработка ведется по скраму. Если у кого-то есть опыт использования описанного данным автором подхода, итересно было бы, если бы вы поделились нюансами. Оригинал статьи: «Using Kanban for Scrum Backlog Grooming».
картинка по запросу grooming:
***
Поддержка бэклога в скрам-проектах – это важная задача. Он очень быстро разрастается до сотен задач, находящихся на разных стадиях готовности для включения в спринт. В моём текущем проекте мы подключили Канбан-доску для помощи в поддержке бэклога и повышения эффективности груминга.
Мне кажется, что во многом бэклог продукта и роль владельца продукта – это узкие места скрама. Скрам упорядочивает процесс разработки и требует предоставления чётких требований для его старта. Это помогает увидеть то, что мы, разработчики, и так знаем: если проект провалился, то это не всегда наша вина, ибо мы не можем сделать нашу работу хорошо при плохих требованиях. Так что теперь, когда проблема с требованиями заметна и понятна, пора взяться за процесс обработки требований.
В моём текущем проекте есть несколько различных этапов, через которые проходит каждый элемент продуктового бэклога:
1. Новая задача попадает в продуктовый бэклог.
2. Владелец продукта определяет, полезна ли эта задача, и в зависимости от этого либо удаляет её сразу, либо инициирует более подробный анализ.
3. Владелец продукта (или помогающий ему аналитик) выполняет анализ.
4. Полученные в итоге элементы продуктового бэклога презентуются команде разработки в ходе встречи по грумингу бэклога.
Для сопровождения вышеописанного процесса мы используем Канбан-доску.
Канбан-доска
Наша Канбан-доска содержит четыре колонки, которые визуализируют описанную выше этапность:
1. Новые задачи
2. Аналитика
3. Требования готовы
4. Бэклог (или Требования согласованы)
При добавлении в бэклог впервые элемент помещается в колонку новых задач. Владелец продукта определяет, имеет ли смысл тратить ресурсы на исследование этой задачи. Если да, то она перемещается в колонку аналитики. Это своего рода статус In Progress для владельца продукта и аналитика. Когда они считают, что закончили с анализом, они перемещают элемент в колонку «Требования готовы». Когда эта колонка накапливает 10-20 элементов (у нас нет жёсткого лимита), наступает время встречи для груминга бэклога, во время которой разработчики разбирают элементы из последней колонки. Если они считают, что задачи достаточно понятны для продолжения работы с ними, они перемещают их в статус «Бэклог», одновременно предоставляя оценку сроков (мы оцениваемся в часах, а не в стори-поинтах).
Если же разработчики считают, что в описании элемента бэклога чего-то не хватает, они отправляют элемент обратно в статус аналитики, прикладывая к нему список вопросов, требующих ответа.
Планирование спринта
Когда наступает время для встречи по планированию нового спринта, рассматриваются только те элементы, которые находятся в статусе «Бэклог». Мы работаем в Jira и отфильтровываем скрам-доску таким образом, что задачи со статусом, отличным от статуса «Бэклог», не отображаются вообще.
В итоге на планировании спринта на обсуждение сути элементов бэклога тратится минимум времени, так как это уже обсуждалось на груминге. Фокус на планировании смещается на утверждение владельцем продукта списка приоретизированных элементов и перемещение этих элементов в спринт. К этому времени владелец продукта уже имеет оценку сроков реализации, так что, обладая информацией о стоимости реализации и о бизнес-ценности данных задач (а владелец продукта должен понимать бизнес-ценность), становится возможным принять обоснованное решение о том, должна ли задача быть решенной уже сейчас, отложена на более поздний спринт или, возможно, её не стоит реализовывать вообще.
Контроль процесса обработки бэклога
Для эффективной благодаря скрам-практикам команды разработки важнее чем когда бы то ни было быть уверенной в том, что бэклог наполняется данными, необходимыми команде для того, чтобы оставаться эффективной. Достаточно сложно управлять бэклогом без надлежащей инструментальной поддержки или без понимания того, каким образом приводить его элементы в надлежащим образом детализированное состояние. Можно сказать, что это невозможно для большинства проектов, за исключением самых маленьких.
Если уж мы проводим так много времени, улучшая процесс разработки, мне кажется, что было бы естественно улучшить и процесс, предваряющий разработку. Также я думаю, что наличие четко поставленного процесса подготовки элементов к помещению в продуктовый бэклог — это, к сожалению, достаточно редкий случай. По моему опыту, эта работа обычно выполняется нерегулярно и без всякого плана, что мне кажется неправильным подходом.
Я собираюсь продолжать работать с моей Канбан-доской, чтобы быть уверенным, что управление продуктовым бэклогом не скатывается к случайному процессу. Уже после нескольких месяцев использования очевидно, что налаженный процесс управления продуктовым бэклогом с хорошей инструментальной поддержкой действительно помогает.
картинка по запросу grooming:
***
Поддержка бэклога в скрам-проектах – это важная задача. Он очень быстро разрастается до сотен задач, находящихся на разных стадиях готовности для включения в спринт. В моём текущем проекте мы подключили Канбан-доску для помощи в поддержке бэклога и повышения эффективности груминга.
Мне кажется, что во многом бэклог продукта и роль владельца продукта – это узкие места скрама. Скрам упорядочивает процесс разработки и требует предоставления чётких требований для его старта. Это помогает увидеть то, что мы, разработчики, и так знаем: если проект провалился, то это не всегда наша вина, ибо мы не можем сделать нашу работу хорошо при плохих требованиях. Так что теперь, когда проблема с требованиями заметна и понятна, пора взяться за процесс обработки требований.
В моём текущем проекте есть несколько различных этапов, через которые проходит каждый элемент продуктового бэклога:
1. Новая задача попадает в продуктовый бэклог.
2. Владелец продукта определяет, полезна ли эта задача, и в зависимости от этого либо удаляет её сразу, либо инициирует более подробный анализ.
3. Владелец продукта (или помогающий ему аналитик) выполняет анализ.
4. Полученные в итоге элементы продуктового бэклога презентуются команде разработки в ходе встречи по грумингу бэклога.
- У разработчиков появляются вопросы и они заворачивают элемент обратно для дополнительной детализации.
- Разработчики согласуют элемент и оценивают его.
Для сопровождения вышеописанного процесса мы используем Канбан-доску.
Канбан-доска
Наша Канбан-доска содержит четыре колонки, которые визуализируют описанную выше этапность:
1. Новые задачи
2. Аналитика
3. Требования готовы
4. Бэклог (или Требования согласованы)
При добавлении в бэклог впервые элемент помещается в колонку новых задач. Владелец продукта определяет, имеет ли смысл тратить ресурсы на исследование этой задачи. Если да, то она перемещается в колонку аналитики. Это своего рода статус In Progress для владельца продукта и аналитика. Когда они считают, что закончили с анализом, они перемещают элемент в колонку «Требования готовы». Когда эта колонка накапливает 10-20 элементов (у нас нет жёсткого лимита), наступает время встречи для груминга бэклога, во время которой разработчики разбирают элементы из последней колонки. Если они считают, что задачи достаточно понятны для продолжения работы с ними, они перемещают их в статус «Бэклог», одновременно предоставляя оценку сроков (мы оцениваемся в часах, а не в стори-поинтах).
Если же разработчики считают, что в описании элемента бэклога чего-то не хватает, они отправляют элемент обратно в статус аналитики, прикладывая к нему список вопросов, требующих ответа.
Планирование спринта
Когда наступает время для встречи по планированию нового спринта, рассматриваются только те элементы, которые находятся в статусе «Бэклог». Мы работаем в Jira и отфильтровываем скрам-доску таким образом, что задачи со статусом, отличным от статуса «Бэклог», не отображаются вообще.
В итоге на планировании спринта на обсуждение сути элементов бэклога тратится минимум времени, так как это уже обсуждалось на груминге. Фокус на планировании смещается на утверждение владельцем продукта списка приоретизированных элементов и перемещение этих элементов в спринт. К этому времени владелец продукта уже имеет оценку сроков реализации, так что, обладая информацией о стоимости реализации и о бизнес-ценности данных задач (а владелец продукта должен понимать бизнес-ценность), становится возможным принять обоснованное решение о том, должна ли задача быть решенной уже сейчас, отложена на более поздний спринт или, возможно, её не стоит реализовывать вообще.
Контроль процесса обработки бэклога
Для эффективной благодаря скрам-практикам команды разработки важнее чем когда бы то ни было быть уверенной в том, что бэклог наполняется данными, необходимыми команде для того, чтобы оставаться эффективной. Достаточно сложно управлять бэклогом без надлежащей инструментальной поддержки или без понимания того, каким образом приводить его элементы в надлежащим образом детализированное состояние. Можно сказать, что это невозможно для большинства проектов, за исключением самых маленьких.
Если уж мы проводим так много времени, улучшая процесс разработки, мне кажется, что было бы естественно улучшить и процесс, предваряющий разработку. Также я думаю, что наличие четко поставленного процесса подготовки элементов к помещению в продуктовый бэклог — это, к сожалению, достаточно редкий случай. По моему опыту, эта работа обычно выполняется нерегулярно и без всякого плана, что мне кажется неправильным подходом.
Я собираюсь продолжать работать с моей Канбан-доской, чтобы быть уверенным, что управление продуктовым бэклогом не скатывается к случайному процессу. Уже после нескольких месяцев использования очевидно, что налаженный процесс управления продуктовым бэклогом с хорошей инструментальной поддержкой действительно помогает.
