Product backlog — это основа Scrum'a. С него все начинается. По существу, product backlog является списком требований, историй, функциональности, которые упорядочены по степени важности. При этом все требования описаны на понятном для заказчика языке.

Элементы этого списка мы будем называть «историями», user story, а иногда элементами backlog'a.

Описание каждой нашей истории включает в себя следующие поля:

• ID — уникальный идентификатор — просто порядковый номер. Применяется для идентификации историй в случае их переименования.

• Название — краткое описание истории. Например, «Просмотр журнала своих транзакций». Оно должно быть однозначным, чтобы разработчики и product owner (владелец продукта) могли примерно понять, о чем идет речь, и отличить одну историю от другой. Обычно от 2 до 10 слов.

• Важность (Importance) — степень важности данной задачи, по мнению product owner'a. Например, 10. Или 150. Чем больше значение, тем выше важность.

a) Я предпочитаю не использовать термин «приоритет», поскольку обычно в этом случае 1 обозначает наивысший приоритет. Это очень неудобно: если впоследствии вы решите, что какая-то история еще более важна, то какой «приоритет» вы тогда ей поставите? Приоритет 0? Приоритет-1?

• Предварительная оценка (initial estimate) — начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point'ax. Приблизительно соответствует числу «идеальных человеко-дней».

a) Спросите вашу команду: «Если собрать команду из оптимального количества людей, то есть не слишком большую и не слишком маленькую (чаще всего из двух человек), закрыться в комнате с достаточным запасом еды и работать ни на что не отвлекаясь, то, сколько дней тогда понадобится на разработку завершённого, протестированного продукта, готового к демонстрации и релизу?». Если ответ будет «Для трёх человек, закрытых в комнате, на это потребуется 4 дня», это значит, что изначальная оценка составляет 12 story point'oв.

b) В этом случае важно получить не максимально точные оценки (например, для истории в 2 story point'a потребуется 2 дня), а сделать так, чтобы оценки верно отражали относительную трудоёмкость историй (например, на историю, оцененную в 2 story point'a потребует примерно в два раза меньше работы по сравнению с историей в 4 story point'a).

• Как продемонстрировать (how to demo) — краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. По сути, это простой тестовый сценарий типа «Сделайте это, сделайте то — должно получиться то-то».

a) Если у вас практикуется Test Driven Development (разработка через тестирование или кратко TDD), то это описание может послужить псевдокодом [3] для приемочного теста.

• Примечания — любая другая информация: пояснения, ссылки на дополнительные источники информации, и т. д. Обычно она представлена в форме кратких тезисов

Мы экспериментировали и с другими полями, но в итоге именно эти 6 оказались для нас самыми применимыми.

Обычно product backlog хранится в Excel таблице с возможностью совместного доступа (несколько пользователей могут редактировать файл одновременно). Хотя официально документ принадлежит product owner’у, мы не запрещаем другим пользователям редактировать его. Ведь разработчикам довольно часто приходится заглядывать в product backlog, чтобы что-то уточнить или изменить оценку предполагаемых трудозатрат.

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

Однако почти все остальные артефакты хранятся у нас в системе контроля версий.

Иногда мы используем дополнительные поля в product backlog’е. В основном для того, чтобы помочь product owner’у определиться с его приоритетами.

Категория (track) — Например, «панель управления» или «оптимизация». При помощи этого поля product owner может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.

Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений. Поле «компоненты» окажется особенно полезным, если у вас несколько Scrum команд, например, одна, которая работает над панелью управления и другая, которая отвечает за клиентскую часть. В данном случае это поле существенно упростит для каждой из команд процедуру выбора истории, за которую она могла бы взяться.

Инициатор запроса (requestor). product owner может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.

ID в системе учёта дефектов (bug tracking id) — если вы используете отдельную систему для учёта дефектов (например. Jira), тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.

Если product owner — технарь, то он вполне может добавить историю вроде «Добавить индексы в таблицу Events». Зачем ему это нужно? Да потому, что реальной целью этой истории, скорее всего, будет «ускорение поиска событий в панели управления».

И вообще, может оказаться, что не индексы были узким местом, приводящим к медленной работе поисковой формы. Причиной могло быть что-то абсолютно другое. Обычно команде виднее, каким образом лучше решить подобную проблему, поэтому product owner должен ставить цели с точки зрения бизнеса (т. е. что надо).

Когда я вижу технические истории подобные этой, я обычно задаю product owner’у вопросы вроде «Да, но зачем?». Я делаю это до тех пор, пока не проявится истинная причина появления истории (в приведенном примере — повысить скорость поиска событий в панели управления). Первоначальное техническое описание проблемы можно поместить в колонку с примечаниями: «Индексирование таблицы Events может решить проблему».

Примечания:

3

в программировании специальный способ записи любого алгоритма (прим. переводчика)