Product Backlog

Как-то в статье о Sprint мы писали, что это основа методологии Scrum, и всё вокруг него крутится. Сегодня самое время сказать:

«А сам-то Sprint то крутится вокруг Product Backlog и производной – Sprint Backlog!».

На самом деле Product Backlog должен быть понятен абсолютно всем (за что и отвечает Product Owner). Прозрачность Product Backlog помогает разобраться в нём как команде, так и заказчику. Сделать его таким – сродни искусству. Порой заказчики и специалисты говорят совершенно на разных языках, и данный «языковой барьер» главным образом мешает работе, а ещё, более того, таит в себе опасности. Если где-то какое-то недопонимание было изначально, и интерпретация желаний заказчика была не совсем верная, то по прошествии спринта будет готовый продукт, который, представьте себе, сильно ушел в сторону. Малейшее отклонение в ядре продукта может привести к его неисправимой эволюции в другую сторону, так как весь остальной код может базироваться на ошибочном изначальном.

Сам Product Backlog состоит из элементов бэклога или, как модно называть, User Story. По сути, это список желаний, или, на сленге разработчиков – «хотелок». Сами эти «хотелки» должны быть упорядочены по степени важности.

Но довольно слов, давайте посмотрим, как это выглядит:

Расшифровка полей Product Backlog:

ID – всем разработчикам тут всё понятно. Уникальный номер задачи, который идет по порядку.

Название – ёмкое название задачи, которое, по сути, должно быть однозначным и понятным всем.

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

Изначальная оценка – пока это просто примерное значение, которое накидал Product Owner, но, по сути, оно может, конечно же, меняться. Просто когда команды работают над похожими продуктами вместе достаточно долго, то Product Owner понимает, сколько требуется трудовых ресурсов на выполнение той или иной задачи. Потом, конечно, это переоценивается при помощи Planning (Scrum) Poker.

Демонстрация – чтобы доказать законченность работы, надо продемонстрировать результат. Что хочет видеть Product Owner и заказчик? Это и необходимо описать в данном поле.

Релиз – по сути, это наглядная демонстрация того, что хотелось бы видеть после первого спринта. По мере роста очков важности бывает тяжело определить, на чем остановиться, если есть какие-то пограничные состояния. Например, Product Owner по Velocity знает, на что способна команда и как идет её работа. Он рассчитывает по Story Points и по «Важности», сколько примерно команда сможет выполнить за одну итерацию. Бывает так, что вроде следующий пункт уже выходит за рамки возможностей команды, согласно Velocity, или, наоборот, можно еще что-то впихнуть, но стоит ли? Product Owner может оценить, что для логичной законченности продукта на эту итерацию, скажем, не надо делать пункт, который ещё можно включить, и ставит на нём «Релиз 2».

Примечания – всегда полезно иметь эту графу. Она может быть пустая, а может расширять понимание задачи.

На самом деле в Product Backlog могут быть и другие поля, расширяющие понимание задач и всего проекта:

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

Компоненты. Разработка чего-либо так или иначе связана с какими-то компонентами производства. В программировании это, например, могут быть база данных, файловый сервер, API и так далее. В других направлениях свои компоненты. Такое разделение очень полезно, если используются несколько команд. Таким образом команды могут поделить между собой направления в разработке, что, в свою очередь, улучшит производительность. В книге Джеффа Сазерленда приводился пример, который отражает одну из основ методологии Scrum. Данный пример заключается в написании последовательно цифр и букв.

Сначала необходимо попытаться написать это всё по строчкам: 1 I A, 2 II B, 3 III C, 4 IV D, 5 V E – и засечь, сколько времени это займет. Можно представить, что арабские цифры – работа с базой данных, римские – с файловым сервером, буквы – это API. То есть вам нужно сначала сделать что-то по базе, потом по файлам, потом по API. Теперь, по тесту, нужно написать всё тоже самое, только по столбикам: 1 2 3 4 5, I II III IV V, A B C D E. Так, конечно, получится намного быстрее, так как мозгу нет необходимости переключаться с одной системы на другую, и он на автомате работает гораздо лучше в одной системе координат.

Привязываясь к данному примеру с компонентами, представьте, что у команды есть возможность работы не с такими данными: 3 III C, 5 V E, а скажем, с такими: 1 2 3 4, A B C. Такая работа будет намного продуктивней.

Инициатор задачи. Как известно, ответственный за Product Backlog – Product Owner, однако его правкой могут заниматься многие. Очень удобно отслеживать, кто поставил задачу, чтобы знать, с кем по этому поводу общаться.

ID-взаимосвязь – связь с чем угодно. Бывает, что нужно завязать задачи бэклога с какими-то сторонними или внутренними сервисами, например, отдельный баг-трекер.

Возвращаясь к разделению на категории, всегда возникает вопрос: а как поступать, если имеются несколько команд разработки? Сделать для каждой своего Product Owner и свой Product Backlog? Может лучше иметь один Product Backlog и одного Product Owner?

На само деле существуют разные подходы, используемые компаниями.

Подход №1 – один Product Owner и один Product Backlog

Подход №2 – один Product Owner и несколько Product Backlog

Подход №3 – несколько Product Owner и несколько Product Backlog