Бэклог Продукта

При переходе продуктовой группы на Скрам перед стартом первого Спринта им необходим Бэклог Продукта (Product Backlog), приоритизированный (упорядоченный 1, 2, 3, …) список задач, ориентированных на клиента.
Бэклог Продукта существует (и развивается) на протяжении всего жизненного цикла продукта; это дорожная карта (roadmap) продукта (Иллюстрации 2 и 3). В любой момент Бэклог Продукта является единственным, исчерпывающим представлением “всего, что могло бы быть сделано Командой, в порядке приоритета”. Для продукта существует только единственный Бэклог Продукта; это означает, что Владелец Продукта необходим, чтобы принимать решения о приоритетах на всём спектре, предоставляя интересы заинтересованных лиц (включая Команду).

Приоритет Элемент Детали (ссылка на Wiki) Первоначальная оценка Обновлённая Оценка в Спринте
1 2 3 4 5 6
1 Как покупатель, Я хочу положить книгу в корзину (см. наброски UI в wiki) 5
2 Как покупатель, Я хочу удалять книги из корзины 2
3 Улучшить производительность обработки транзакции (см. целевые метрики производительности в wiki) 13
4 Исследовать решение для ускорения проверки кредитной карты (см. целевые метрики производительности в wiki) 20
5 Обновить версию Apache до 2.2.3 на всех серверах 13
6 Диагностировать и исправить ошибки в порядке исполнения скриптов (bugzilla ID 14823) 3
7 Как покупатель, Я хочу создавать и сохранять список желаний 40
8 Как покупатель, Я хочу добавлять и удалять элементы в мой список желаний 20

Иллюстрация 2. Бэклог Продукта

Иллюстрация 3. Визуальное Управление: Элементы Бэклога Продукта на стене
Иллюстрация 3. Визуальное Управление: Элементы Бэклога Продукта на стене

Бэклог Продукта включает множество видов элементов, в первую очередь новую функциональность для пользователей (“разрешить всем пользователем класть книги в корзину”), но также и основные цели по инженерному улучшению (напр., “переписать код системы с C++ на Java”), улучшения (напр. “ускорить наши тесты”), исследовательскую работу (“исследовать решения для ускорения проверки кредитной карты”) и, возможно, известные дефекты (“диагностировать и исправить ошибки порядка исполнения скриптов”), если только их немного (системы с большим количеством дефектов обычно имеют отдельную систему управления дефектами).

Элементы Бэклога Продукта могут быть сформулированы в любом понятном и поддерживаемом виде. Вразрез с популярным недопониманием Бэклог Продукта не содержит “пользовательские истории” (user stories); он просто состоит из элементов. Эти элементы могут быть выражены в формате пользовательских историй, сценариев использования или любом другом формате описания требований, который группа сочтёт полезным. Но какой бы ни был выбран подход, большинство элементы должны сконцентрироваться на поставке ценности клиентом.

Хороший Бэклог Продукта является ИСЧЕРПЫВАЮЩИМ…

Подробно детализирован. Самые приоритетные элементы наиболее хорошо нормализованы по размеру, прояснены и детализированы, чем остальные с более низким приоритетом, так как они попадут в работу раньше. Например, 10% верхушки Бэклога может состоять из очень небольших, хорошо проанализированных элементов, а остальные 90% из более крупных.

Оценён. Элементы для текущего релиза должны иметь оценку, и, кроме того, следует рассматривать возможность переоценки в каждом Спринте, поскольку все учатся и появляется новая информация. Команда предоставляет Владельцу Продукта оценку своих усилий для каждого элемента Бэклога Продукта, также, возможно, оценивая технические риски. Владелец Продукта и другие заинтересованные лица предоставляют информацию о ценности продуктовых запросов, которые могут включать получение дохода, снижение издержек, бизнес риски, важность для ряда заинтересованных лиц и т.д.

Актуален. В ответ на обучение и вариативность, Бэклог Продукта постоянно проясняется. Каждый Спринт элементы могут быть добавлены, удалены, изменены, разделены, или у них может измениться приоритет. Поэтому Бэклог Продукта постоянно обновляется Владельцем Продукта, чтобы отразить изменения в потребностях клиентов, новые идеи или сведения, действия конкурентов, возникающие технические препятствия и т. д.

Приоритизирован. Элементы верхушки Бэклога Продукта приоритизированы или упорядочены в порядке 1-N. Обычно, самые высокоприоритетные элементы должны принести наибольшую отдачу от ваших вложений [в ориг. идиома “bang for your buck”, прим. переводчика]: больше бизнес-ценности за меньшую стоимость. Другая мотивация увеличить приоритет элемента в том, чтобы разобраться с высоким риском раньше, чем он разберётся с вами. [в ориг. игра слов “tackle high risks early, before the risks attack you”, прим. переводчика]

Традиционная разработка обычно не выделяет важность поставки элементов с самой высокой отдачей от ваших вложений, но Скрам это делает, поэтому Владельцу Продукта необходимо научиться, как определять “бизнес ценность”. Это такое обучение, в котором Скрам-мастер может помочь Владельцу Продукта. Что значит “бизнес ценность”? Некоторые продуктовые группы используют относительные очки ценности для каждого Элемента Бэклога, которые представляют собой синтез “предположительных” факторов, включая рост доходов, сокращение расходов, предпочтения заинтересованных лиц, рыночные дифференциацию и т.д. Некоторые делают вложения в конкретный элемент для одного или нескольких клиентов, платящих за его разработку, и поэтому определяют ценность на базе точного (краткосрочного) дохода от этого элемента. В других продуктовых группах такая оценка конкретных элементов слишком расфокусирована или гранулярна; они применяют более широкий поход, основанный на бизнес выгоде (“увеличить количество подписок на 10% к 1-му сентября”), в котором ценность создаётся только тогда, когда несколько элементов, способствующих результату, поставляются вместе. В этом случае Владелец Продукта должен определить следующий инкремент Минимально Жизнеспособного Продукта (Minimum Viable Product, MVP).

Оценка затрат обычно производится в относительном виде (отражающем объём работы, сложность и неопределённость) и использует в качестве единицы измерения “очки историй” (story points) или просто “очки” (points).

Это только предложение; Скрам не определяет технику для выражения или приоритизации элементов Бэклога Продукта, а также технику оценки затрат или её единицы измерения.

Обычно в Скраме применяется техника отслеживания того, сколько работы было закончено в каждом Спринте; например: в среднем выполнено работы на 26 очков за Спринт. Зная эту информацию можно прогнозировать дату релиза, к которой будут закончены все задачи, или сколько задач будет закончен к установленной дате, если в среднем это значение остаётся неизменным. Это среднее называют “скоростью” (velocity). Скорость выражается в тех же единицах, что и оценка элементов Бэклога Продукта.

Элементы в Бэклоге Продукта могут значительным образом отличаться по размеру или затратам. Большие разбиваются на более мелкие во время Уточнения Бэклога Продукта или Планирования Спринта, а маленькие, наоборот, могут быть объединены. Элементы Бэклога Продукта для нескольких следующих Спринтов должны быть небольшими и прояснены достаточно, чтобы быть понятными Команде, тем самым давая возможность прогнозу на Планировании Спринта стать реалистичным; такой размер называется “выполнимый” (actionable).

Важные инженерные улучшения, которые требуют много времени и денег, также должны быть в Бэклогое Продукта, раз уж они могут оказаться одним из вариантов инвестиций бизнеса, и в конечном итоге решения насчёт их должны быть сделаны бизнес-ориентированным Владельцем Продукта. Обратите внимание, что в Скраме команда имеет независимые полномочия в отношении того, сколько элементов из Бэклога Продукта они решают взять в Спринт, поэтому они могут самостоятельно выполнять незначительные инженерные улучшения, поскольку их можно рассматривать, как часть обычных затрат на выполнения бизнес задач, и как то, что требуется разработчику для правильного выполнения своей работы. При этом в каждом Спринте бóльшая часть времени Команды обычно должна отводиться целям Владельца Продукта, а не на внутренние инженерные задачи.

Один из мифов о Скраме, что он предостерегает вас от написания исчерпывающей документации; в реальности это решение лежит на Владельце Продукта и Команде, какой уровень детализации требуется, и он может меняться от одного элемента Бэклога Продукта к другому, в зависимости от осведомлённости Команды или других факторов. Укажите, что важно, в минимально необходимом виде - другими словами, не описывайте все возможные детали элемента, просто чётко укажите, что необходимо для его понимания, и дополните это постоянным диалогом между Командой, Владельцем Продукта и заинтересованными сторонами. Элементы Бэклога Продукта с низким приоритетом, над которыми не будут работать в течение ближайшего времени, обычно являются “крупнодроблёными” (большие, с менее ясными требованиями). Высокоприоритетные и детализированные Элементы Бэклога Продукта, которые скоро будут реализованы, обычно содержат больше деталей.

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.