Рассказываем, что такое бэклог в Scrum, какие разновидности существуют, кто за что отвечает и как с ним работают.
Бэклог — это список всех требований к проекту: и желания пользователя, и строго необходимые вещи. Сразу нужно сказать, что бэклог — это не список спецификаций на листочках. Понятие шире.
Бэклог в Scrum может быть бэклогом продукта, релиза или спринта.
Бэклог продукта
Бэклог продукта, или главный бэклог, — это ядро проекта. Это функции, которые нужно реализовать, и ошибки, которые требуется устранить.
Элементы бэклога в Scrum называются PBI — Product Backlog Items.
Обычно в их основу берутся "user story" они же пользовательские истории. Это позволяет использовать человеческий язык и не ограничивать команду в выбранном решении. Еще помогают лучше представлять использование продукта.
Несколько пользовательских историй объединяются в Epic'и. С эпиками — группами историй — удобнее составлять бэклог.
Так определяется, что нужно реализовать и какими функциями наделить продукт, чтобы его было удобно использовать:
Я, как пользователь приложения, хочу получить аккаунт с последними методами защиты.
Я, как посетитель сайта, хочу удобный поиск на сайте, чтобы быстро находить нужный товар.
Я, как оператор техподдержки, хочу легко находить заявки пользователей.
Бэклог продукта — единственный источник работ для команды разработки. Все, что находится в бэклоге, достаточно для запуска проекта. Он создается до начала первого спринта, на стадии планирования работы, но не раз и навсегда:
- если добавленный элемент не способствует достижению цели, его нужно удалить;
- если появляется новая функция, которая сделает проект лучше/конкурентнее/безопаснее и т. д., ее нужно добавить;
- элементы внутри бэклога могут переставляться местами: менять приоритет и прочее.
В активном проекте бэклог постоянно пополняется. Это происходит по ходу выпуска ПО, когда выясняются новые условия и требования.
Ответственность за заполнение бэклога несет владелец продукта, но с возможными идеями может помогать команда, бизнес, сторонние аналитики, конечные пользователи.
Что попадает в бэклог продукта
Может показаться, что это список дел. Но в Scrum это не так. В бэклог попадают такие задачи, функции, что отвечают требованиям:
- Ценность для пользователя
Каждая запись в бэклоге должна иметь какую-то ценность для клиента. Обязательно будут записи, которые влияют на это опосредованно. Они не добавят конкретные функции, но помогают в долгосрочной перспективе (решение проблем безопасности, устранение багов, описание требований и т. д.)
На самом деле, определить ценности и составить исчерпывающий список PBI сложно: практически для каждой программы предполагается несколько групп пользователей. У них свои представления, что нужно получить от ПО.
Банально, интернет-магазин. Это могут быть частные покупатели, оптовые клиенты, менеджеры по продажам и операторы, аналитики, владельцы бизнеса... И у каждого свой самый важный аспект: для покупателя хорошо бы увидеть подробное описание товара и много способов оплаты без аккаунта, а для аналитика ценность в статистике.
- Высокоуровневые задачи
В общий бэклог не попадает излишняя информация по каждому требованию. Элементы детализируются позже, уже в рамках спринта появляются задачи низкого уровня и рутина.
- Возможность оценить и проверить
Несмотря на некоторую абстрактность, нужно понимать, сколько усилий от разработчиков потребуется для ее реализации. После создания функционала его нужно проверить: это также должно отражаться в истории.
Я, как пользователь сайта, хочу загружать аватарку пользователя в аккаунт. Требуется место для хранения фото, интерфейс загрузки и т. д. На проверке — можно добавить изображение, и оно отобразится в аккаунте.
- Независимость
Удобнее для разработки, когда PBI автономны, минимально зависят друг от друга. От взаимосвязи не избавиться, но она должна быть горизонтальной: предыдущая история может служить отправной точкой для следующей. Когда зависимостей не избежать, их нужно представлять и строить работу с этим пониманием, чтобы не было задержек всего процесса.
Расстановка приоритетов и оценка пользовательских историй
В зависимости от стадии развития проекта по-разному детализируются задачи.
Все требования к проекту отбираются и фиксируются, но детально продумываются те, что быстрее отправятся в работу. Если каждый эпик или историю разобрать далеко наперед, это быстро потеряет актуальность.
Чтобы присвоить приоритет истории, нужно соотношение минимум двух показателей: насколько она важна для бизнеса и сколько усилий стоит ее разработка.
Первый показатель определяет владелец продукта, а оценку работы дает команда уже на этапе планирования спринта. Например, для бизнеса задача важна на 8 очков, а по сложности работы это 5 story point (это очки сложности работы, которые вычисляют в сравнении с другими задачами). На самом деле, система оценок намного сложнее и часто остается спорным местом, этой теме мы посветим отдельную статью.
Так в спринт отбираются самые приоритетные задачи и учитывается общая нагрузка. В Scrum это происходит на груминге, или разборе бэклога, — мероприятии, которое специально выделено на оценку задач и их отбор на следующий цикл.
Бэклог спринта
Из бэклога продукта в бэклог спринта попадают несколько требований. Их число зависит от опытности команды и сложности задач, а содержательная часть определяется целью спринта.
Бэклог спринта — это обещание команды, что будет добавлено в обновлении продукта по окончании спринта.
Требования в бэклоге продукта более абстрактные, поэтому эпик разделяется на пользовательские истории, они, в свою очередь, на отдельные задачи. Все, чтобы четко представлять работу и оценить объем.
К началу спринта есть список: что нужно сделать.
Только команда может изменять бэклог спринта, если он уже принят. Владелец продукта или клиент может увидеть, над чем в данный момент трудятся разработчики.
Бэклог релиза
Иногда несколько спринтов объединяются в релиз. У него одна цель и бэклог для ее выполнения. Он также делится на части: разбирается в отдельные спринты.
В каждом обновлении продукта отражены верхние истории бэклога. На базе этого и заказчик, и пользователи могут дать обратную связь, как дополнить основной бэклог. И чем дальше развивается проект, тем это ценнее: в вакууме разрабатывать годный продукт не получится.
В каком формате ведут бэклог
Утвержденного формата нет. Это может быть электронная таблица, доска в кабинете или специализированная программа.
Распространена физическая доска: она визуализирует задачу и имеет только одну версию. Она же хорошо подходит как место для стендапа, а ограниченное пространство заставляет писать элементы бэклога лаконично и для всех.
Конечно, бэклог может вестись одновременно в двух форматах с выкладками на доске и детализироваться в документе.
