Scrum – это простая, но вполне достаточная методика создания новых продуктов если вы заранее понимаете, что именно нужно создать. Но даже после успешной стадии разработки продукта, вы можете столкнуться с трудностями при попытке сделать правильно правильную вещь, если ваш бэклог продукта не работает; как говориться, мусор на входе – мусор на выходе. В этой статье рассматриваются идеи по улучшению методов управления бэклогом продукта, включая процесс его уточнения.

Бэклог продукта в соответствии со Scrum Guide

Прежде всего, посмотрим, что говорит о бэклоге актуальная версия Scrum Guide:

“Уточнение бэклога продукта – это процесс добавления деталей, оценок и порядка к элементам продуктового бэклога. Это непрерывный процесс, в котором владелец продукта (Product Owner) и команда разработки (Development Team) совместно работают над деталями элементов бэклога продукта. Во время процесса уточнения бэклога продукта, его элементы рассматриваются и пересматриваются. Scrum-команда решает, как и когда будет выполнена доработка. Обычно доработка составляет не более 10% мощности команды разработчиков. Однако элементы бэклога продукта могут быть обновлены в любое время владельцем продукта или по его решению.

Элементы бэклога продукта с более высоким приоритетом обычно более понятны и детализированы, чем те, что находятся дальше по порядку. Более точные оценки основаны на большей ясности и детализации, чем ниже порядок, тем меньше деталей. Элементы бэклога, над которыми команда разработчиков будет работать в предстоящем спринте, уточняются до такой степени, чтобы их можно было «сделать» во время спринта. Элементы бэклога продукта, которые могут быть «сделаны» командой разработчиков в течение одного спринта, считаются «готовыми» для выбора при планировании спринта. Элементы бэклога продукта обычно приобретают такую степень прозрачности в процессе работы по уточнению.

Команда разработчиков несет ответственность за все оценки. Владелец продукта может влиять на команду, помогая ей понять и найти компромиссы, но люди, которые будут выполнять работу, делают окончательную оценку.»

Источник: 2016 Scrum.Org и Scrum Inc.

Обобщенные анти-шаблоны (Anti–Patterns) бэклога продукта

Несмотря на относительную простоту, процесс создания и уточнения бэклога продукта зачастую страдает от различных анти-шаблонов. Я выделил пять категорий методой работы с бэклогом продукта:

Ключевые приемы работы с бэклогом продукта:

1. Приоритезация по доверенности: одна заинтересованная сторона или комитет, состоящий заинтересованных сторон, определяют приоритеты при работе с бэклогом продукта. (В основе Scrum – сильная позиция владельца продукта. Он (Product Owner) – единственный человек, кто решает, какие задачи становятся элементами бэклога продукта. Следовательно, владелец также принимает решение о приоритетах. Уберите эти полномочия и Scrum превратится во вполне надежный процесс водопада, waterfall.)
2. 100% вперёд: Scrum-команда создаёт Product Backlog, охватывающий проект или продукт целиком, поскольку ограничены в выпуске релизов. (Вопрос: как вы можете быть уверены сегодня в том, что будет через шесть месяцев?)
3. Чрезмерный объём: бэклог продукта включает слишком много элементов. (В этом случае, владелец продукта, по всей видимости, накапливает мусор, спасаясь от проблем, которые могут никогда не случиться. В зависимости от конкретной ситуации, многие продукты могут выиграть от ограничения продуктового бэклога до трёх, возможно, четырёх, спринтов, особенно на высококонкуретных рынках)
4. Устаревшие задачи: бэклог продукта включает элементы, которые не были актуальны в течение шести-восьми недель и более. (Обычно это длина от двух до четырех спринтов. Если владелец продукта накапливает элементы бэклога, возникает риск того, что давние элементы бэклога устареют окончательно, сделав ненужной ранее оговоренную работу Scrum-команды)
5. Всё оценено: все элементы бэклога продукта детализированы и оценены. (Это очень большая предварительная работы и риск неправильного распределения времени Scrum-команды)
6. Элементы на основе компонентов: элементы бэклога продукта делятся по горизонтали на уровне компонентов, а не по вертикали – на основе сквозных характеристик. (Это может быть следствием вашей организационной структуры. Нужно переходить к кросс-функциональным командам, чтобы улучшить работу команды. В противном случае команде, как и владельцу продукта, нужен семинар по созданию элементов)
7. Отсутствующие критерии приемки: в бэклоге продукта есть элементы без критериев приёмки. (Нет необходимости в критериях приёмки в начале цикла уточнения, хотя они сделали бы задачу гораздо более управляемой)
8. Ничего, кроме заголовка: Product Backlog включает элементы, в которых нет ничего, кроме заголовка (смотреть выше)
9. Задачи слишком детализированы: есть элементы с обширным перечнем притериев приёмки. (Это другая крайность. Как правило, трёх-пяти критериев более, чем достаточно)
10. Ни темы, ни описания: отсутствие темы и описания не помогают создавать структуру бэклога продукта. (Это затрудняет понимание роли отдельных элементов на фоне общей картины. Бэклог продукта не должен быть ассорти из изолированных задач или объемным списком задач. Обратите внимание, что темы и описания не являются элементами руководства Scrum)
11. Нет исследований: Product Backlog не содержит или вовсе не включает совсем Cпайки (Spike). (Зачастую эта проблема связана с командой, которая тратит слишком много времени на обсуждение проблем в перспективе, вместо того, чтобы исследовать их с помощью Спайка, как часть итеративного процесса создания элемента)

Скачать бесплатно Scrum Anti-Patterns Guide

Техники на стадии портфеля и дорожной карты продукта

1. Дорожная карта? Бэклог продукта не отражает дорожную карту. (Бэклог должен быть достаточно детализированным только для первых двух или трёх спринтов. После этого бэклог продукта должен фокусироваться на темах и описаниях – см. выше – из дорожной карты продукта. Если они недоступны, бэклог продукта, по всей вероятности, будет granular)
2. Ежегодные дорожные карты: план портфеля организации, равно как и план выпуска или дорожная карта продукта создаются раз в год. (Соответствие бэклога этим планам исподволь запускает планирование по принципу водопада. Гибкое планирование всегда непрерывное. На уровне портфеля план нужно пересматривать, как минимум, каждые три месяца)
3. Дорожные карты – это секрет: планирование портфеля и план выпуска или дорожная карта проекта доступны не всем. (Если вы не знаете, куда идёте, любая дорога приведёт вас не туда. Эта информация имеет решающее значение для любой Scrum-команды и должна быть доступна всем в любое время)
4. Синица в руках: планирование портфеля и план выпуска или дорожная карта продукта не выглядят достижимыми и правдоподобными. 

Техники работы с бэклогом для владельца продукта

1. Хранилище идей: владелец продукта использует бэклог, как хранилище идей и требований. (Эта практика засоряет бэклог продукта, может привести к перегрузке и делает очень сложным процесс соотнесения с общей картиной организации на уровне управления портфелем и планирования дорожной карты)
2. Занятый или работающий по совместительству владелец продукта: владелец продукта не работает на бэклогом ежедневно. (Бэклог должен в любой момент времени отражать наилучшее использование ресурсов команды разработчиков. Для выполнения этого недостаточно обновлять его раз в неделю перед сессией уточнения)
3. Copy & paste Product Owner: владелец продукта создаёт элементы путём разбивания на мелкие части требований, полученных от заинтересованных сторон. (Этот сценарий способен наградить владельца продукта титулом “ticket monkey”. Помните, в создании элементов беклога должна участвовать команда.)
4. Доминирующий владелец продукта: Product Owner создаёт элементы, описывая не только «почему», но и «как», и «что». (На вопрос «как» -техническая реализация – отвечает команда, а команда и владелец продукта вместе работают над вопросом «что»: что необходимо для достижения желаемой цели)
5. Инвестиции? Владелец продукта не применяет принципы инвестиций Билла Вейка (Bill Wake) к элементам.
6. Проблемы слишком детализированы: владелец продукта заранее тратит слишком много времени и описывает их слишком подробно. (Если элемент выглядит завершенным, другие члены команды не видят необходимости участвовать в дальнейшей его доработке. Таким образом, «толстый» элемент снижает уровень вовлеченности команды, ставя под угрозу создание общего понимания.)
7. Какая команда? Владелец продукта не вовлекает всю Scrum-команду в процесс уточнения, вместо этого полагается только на «ведущего инженера» (или любого другого члена команды, не зависимо от остальных)
8. «Я знаю всё» Product Owner: владелец продукта не привлекает заинтересованные стороны или предметных экспертов в процессе уточнения. (Владелец продукта, который считает себя всеведущим или коммуникационным шлюзом – риск для успеха Scrum-команды)

Техники для команды разработчиков

1. Покорная команда: команда разработчиков покорно следует требованиям владельца продукта. (Дискуссии с владельцем команды на тему, является ли его выбор элементов наилучшим – благородная обязанность каждого члена команды.)
2. Какой технический долг? Команда разработчиков не требует достаточных ресурсов для устранения технического долга и ошибок. (Эмпирическое правило гласит, что 25% ресурсов выделяется каждый спринт для исправления ошибок и рефакторинга базы кода)
3. Отсутствие резерва (slack): команда разработки не требует 20% резервного времени от владельца продукта. (Это накладывается на планирование спринта и прогноз команды. Если потенциал команды используется на 100%, её производительность будет снижаться с течением времени. Каждый сосредоточится на выполнении своих задач. Будет меньше времени, чтобы поддержать товарищей по команде и в паре. Мелкие проблемы больше не будут решаться немедленно. В конечном счете, это «я занят» приведёт к отсутствию общего понимания у всех членов команды, зачем они делают то, что они делают.)

Техники для Scrum-команды

1. Нет времени на доработку: команде не хватает сессий доработки, что приводит к бэклогу низкого качества. (Руководство Scrum рекомендует тратить до 10% времени Scrum-команды на доработку бэклога продукта. Это разумное бизнес-решение: нет ничего дороже, чем деталь, которая не несёт никакой ценности)
2. Слишком много уточнений: у команды слишком много сеансов уточнений, что ведёт к слишком подробному бэклогу. (Излишние уточнения тоже вредны для здоровья)
3. Нет определения выполненной работы : Scrum-команда не дала «определение готовности» (definition of ready, definition of done), которому должны соответствовать элементы бэклога продукта, чтобы их могли отобрать в спринт. (Определение готовности, может значительно улучшить работу Scrum-команды. Это повысит качество как готового продукта, так и общего подхода к работе в команде. Обратите внимание, что руководство Scrum упоминает «готовность» только в следующем ключе: «элементы бэклога продукта, которые могут быть «сделаны» командой разработчиков в течение одного спринта, считаются «готовыми» для выбора при планировании спринта»)

Вывод

Даже если вы успешно определились с тем, что делать дальше, ваш продуктовый бэклог, как и процесс его уточнения, скорее всего, обеспечат пространство для улучшений. Просто дайте его команде и покажите возможные техники работы с бэклогом продукта.

Оригинал Ideas on How to Improve Your Product Backlog Management Techniques, автор Стефан Вольперс (Stefan Wolpers).

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы