Scrum-time.com

Product Backlog

Product Backlog


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

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

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

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

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

ID

Название

Важность

Начальная оценка

Демонстрация

Релиз

Примечание

1Создание корзины покупок5013Зайти на страницу товара, добавить товар в корзину. Зайти в корзину, показать, что товар добавлен. Перейти на другой товар, добавить его, вернуться в корзину и продемонстрировать, что добавлены два товара, есть отображение цен продуктов, общая сумма. Показать, как оформить заказ, дойдя до

1
2Подключить электронную кассу для оплаты товара (название подключаемой кассы)

4521Проделав демонстрацию работы корзины – оплатить товар.1

Расшифровка полей 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. Данный пример заключается в написании последовательно цифр и букв.

1IA
2IIB
3IIIC
4IVD
5VE

Сначала необходимо попытаться написать это всё по строчкам: 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

Product Owner и один Product Backlog

Такой подход похож на ситуацию, когда капитаны команд в какой-либо игре отбирают себе игроков. Сначала один капитан выбирает себе самого сильного игрока, потом второй самого сильного из оставшихся и так далее. Здесь происходит похожая ситуация. Product Owner располагает задачи из Product Backlog в порядке важности, и команды начинают разбирать себе задачи также в порядке важности. Деление обычно происходит по тематике (для этого удобно использовать соответствующую графу в Product Backlog).

Команды могут поторговаться за какие-то задачи, сгруппировать их у себя, поменять приоритеты.

Когда распределение закончено, каждая команда занимается только своей стеной задач, то есть своим Sprint Backlog.

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

Product Owner и несколько Product Backlog

Всё, собственно, тоже самое, только задачи на команды раздает Product Owner. Тут, конечно, сразу возникают резонные замечания, одно из которых: «Зачем владельцу продукта распределять задачи по командам? Команды сами лучше решат, кто что сделает, ведь Product Owner может не знать тонкостей реализации» – и это вполне резонно. Однако в некоторых случаях рабочего процесса это может вполне работать. Благодаря такому подходу сама подготовка и формирование Sprint Backlog происходит значительно быстрее. Если на каком-то производстве заранее известно, какой команде какой набор лучше дать – этот способ подойдет как нельзя лучше.

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

несколько Product Owner и несколько Product Backlog

Существует даже такой подход, и некоторые его используют. Если быть честным, то он, по большей степени, пригоден для каких-либо узких направлений, когда точно известно, как распределяется разработка, или она состоит из глобальных модулей, которые между собой стыкуются в самый последний момент.

Scrum Sprint

Scrum Sprint

Пожалуй основной процесс в методологии Scrum, остановка которого и может произойти. Во время Sprint происходит вся работа Development Team, Scrum Master и Product Owner.

Sprint Backlog

Sprint Backlog

Product Owner

Product Owner

Владельцу продукта надо знать как работает команда и что её предлагать в первую очередь на реализацию. Правильные действия Product Owner способствуют не возникновению остановки спринта.

Sprint Planning Meeting

Sprint Planning Meeting

Story Points

Story Points

Чтобы отчетливо понимать как формируется Velocity в Scrum, нужно понимать как грамотно оценивать Story Points. Данное понимание приводит к развитию максимально продуктивной команды.

Project Manegement
Project Manegement
close
Управление проектами по Scrum
Система управления проектами по методологии Scrum

Начните - Это бесплатно

Время Scrum Time

keyboard_arrow_up