Что такое бэклог простыми словами?

В этой статье поговорим о том, что такое Бэклог продукта и Бэклог спринта, кто управляет Бэклогом и главное — чем планирование в Agile отличается от классического предиктивного подхода.

Существует миф, что в Agile нет планирования, а вместо плана проекта какой-то «бэклог задач». Ноги этого мифа растут из неверной интерпретации одной из ценностей Agile Manifesto – «Готовность к изменениям важнее следования первоначальному плану». Сам по себе термин Agile действительно отражает способность изменять направление движения без потери скорости.

Но для того чтобы изменять планы осознанно и при этом не терять скорость необходимо:

а) сделать планирование регулярным и частым,

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

И тут на сцену выходит Бэклог.

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

Для чего нужен Бэклог:

1. Определение приоритетов: Бэклог помогает команде определить, какие задачи или проекты имеют наивысший приоритет и взять их в работу в первую очередь. Это особенно важно в условиях ограниченных ресурсов или при наличии конкурирующих требований.

2. Управление ожиданиями: Наличие бэклога помогает клиентам и заинтересованным сторонам понять, что команда разработчиков планирует реализовать в ближайшем будущем, и какие функции или возможности будут добавлены в продукт.

3. Оценка трудозатрат: Бэклог позволяет команде оценить, сколько времени потребуется на выполнение каждой задачи или проекта, а также спланировать работу с учетом этих оценок.

4. Гибкость и адаптивность: благодаря независимости элементов (об этом ниже), Бэклог может адаптироваться к изменяющимся требованиям или новым идеям, позволяя команде быстро реагировать на изменения и оптимизировать рабочий процесс.

Элементы бэклога должны вести нас к текущей Цели продукта.

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

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

Типы элементов Бэклога:

1) Новые функции (фичи, истории пользователя и т.п.) важно оценивать на соответствие 6-ти INVEST-критериям. Эти критерии помогают определить, какие задачи следует включить в Бэклог и как их лучше разрабатывать и приоритезировать:

2) Дефекты. Некоторые критические ошибки работающего продукта быстро исправляются, потому что сильно мешают ему. Другие, менее критические, зачастую сохраняются в продукте.

3) Невидимые функции ещё иногда называют Техническими историями – это какие-либо технические улучшения, которые не видны пользователю, но упрощают разработку, повышают надежность или качество, например, логирование.

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

В продуктовой разработке Бэклог продукта — это некий аналог интерфейса взаимодействия с командой продукта. Конкретную фичу в Бэклог может поместить любой член команды или стейкхолдер, но назначить приоритет или убрать элемент из Бэклога может только Владелец продукта (Product Owner, PO).

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

Путем изменения приоритетов Владелец продукта управляет созданием продукта. Поскольку Agile как подход создан для работы в условиях неопределенности, а цель Владельца продукта – максимизация ценности итогового продукта, приоритеты в Бэклоге меняются в зависимости от происходящего в продукте и вокруг него.

Независимые (согласно INVEST) элементы достаточно легко менять местами без необходимости сложного перепланирования, как в случае с планом проекта. Следуя принципу Парето, Владелец продукта стремится найти те 20% функционала, что несут 80% ценности конечному пользователю. И Бэклог – это его основной инструмент для структурирования работы.

Бэклог / Backlog продукта

Под словом Бэклог чаще всего подразумевается именно Бэклог продукта, его содержание мы подробно разобрали выше.

Бэклог / Backlog проекта

В таком случае, что такое Бэклог проекта? Если применяются гибкие подходы, то у проекта тоже может быть Бэклог. Бэклог проекта – это список, который в отличие от плана проекта задаёт только текущую последовательность выполнения элементов согласно приоритету.

Бэклог / Backlog релиза

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

По сути, отличия между вышеописанными терминами только в единице управления: продукт, проект или релиз. В остальном состав и взаимодействие с ними идентичны.

В самом начале статьи я уже упоминал, что в Agile много планирования, просто речь не о предварительном планировании в начале проекта, как в классическом предиктивном подходе. В начале каждого спринта Владелец продукта с командой определяют цель на 1-4 недели (в зависимости от продолжительности спринта). После чего на Планировании спринта команда детально планирует свою работу на спринт. Большие элементы Бэклога декомпозируются на более мелкие, иногда до атомарных конкретных задач для разработчика, тестировщика или дизайнера. Такой список называется Бэклог Спринта (Sprint Backlog).

Также на Планировании спринта команда планирует свою работу по достижению Цели спринта. Важно, что Scrum не требует какого-то конкретного артефакта, например Диаграммы Ганта, для фиксации результатов этого планирования. Но как минимум порядок и композиция задач в спринте задают порядок планирования, а как максимум некоторые команды могут составлять довольно подробные планы на спринт.

При этом Бэклог Спринта не обязан занимать 100% ёмкости (скорости (Velocity)) команды, т.к. неопределенность некоторых контекстов требует большей адаптивности. Для старта достаточно иметь Цель спринта и понимание работы на первый день спринта. И это нормально, потому что на Планировании спринта непосредственно процесс планирования не заканчивается. Каждый день разработчики принимают участие в Ежедневном стендапе. В рамках этого мероприятия Разработчики, которые владеют и управляют Бэклогом Спринта, синхронизируются вокруг прогресса по достижению Цели Спринта и планируют свою работу на день. А параллельно с этим Владелец продукта занимается уточнением Бэклога продукта (Product Backlog Refinment), привлекая к этому команду.

Давайте подытожим. Планирование в Agile происходит постоянно и непрерывно в течение всего времени жизни проекта или продукта, а основными артефактами для него являются:

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

Автор: Артемий Анцупов, Agile-коуч и эксперт ScrumTrek