---

Что такое бэклог продукта Scrum? Ответ может вас удивить!

Бэклог продукта (бэклог Scrum), или бэклог продукта Scrum — центральный элемент управления всеми известными требованиями продукта Scrum.

Он состоит из возникающей и упорядоченной работы для улучшения продукта и достижения его целей. Требования включают функциональные, нефункциональные и другие возможности пользовательского опыта и проектирования интерфейса.

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

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

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

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

Работа с бэклогом продукта не запрещает другие артефакты управления. Например, сводку ролей пользователей, описание потоков работы, рекомендации интерфейса, раскадровки или прототипы. Они не заменяют бэклог продукта, а дополняют и детализируют его.

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

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

Владелец продукта расставляет приоритеты требований в бэклоге. Чем выше приоритет элемента, тем подробнее он должен быть. Тогда команда легко понимает важные требования и создаёт задачи для реализации.

Разработчики по мере необходимости оценивают размер элементов; стори-пойнты — один необязательный метод. Оценки высокоприоритетных историй следует уточнять, подготавливая их к Планированию Спринта.

Бэклог продукта отличается от простого списка дел определёнными свойствами:

• История всегда добавляет бизнес-ценность или техническую ценность клиенту, Владельцу бизнеса и конечным пользователям,
• Все истории приоритизированы и упорядочены от высшего приоритета к низшему,
• Подробность истории зависит от её положения в бэклоге,
• Размер историй оценивают по необходимости подходящим методом,
• Бэклог продукта Scrum — живой документ,
• Бэклог продукта описывает работу над продуктом; подробный план выполнения Разработчиков находится в бэклоге Спринта.

Истории добавляют ценность клиенту, бизнесу и системам

Каждая история бэклога продукта должна давать определённую ценность клиенту. Истории без ценности клиенту — чистая трата ресурсов, и их нужно устранять. В бэклоге могут быть истории для:

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

Пример бэклога продукта Scrum

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

Бэклог продукта — живой документ

Бэклог продукта меняется и развивается на всём протяжении проекта. При необходимости добавляются истории, существующие меняются, детализируются или удаляются. Требования больше не замораживаются заранее, как при каскадной методологии.

Вместо этого итоговый набор требований бэклога развивается итеративно вместе с появляющимися Инкрементами программного обеспечения.

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

Разные уровни подробности

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

Не имеет смысла тратить время и ресурсы на подробное описание таких требований: к моменту реализации некоторые изменятся или исчезнут. Работа с требованиями «точно вовремя» — одно из главных преимуществ Scrum для неизвестных неизвестных проекта.

Без низкоуровневых задач в бэклоге продукта

Бэклог продукта обычно описывает работу над продуктом, а не подробное разбиение на исполнительские задачи. Владелец определяет требования совместно с бизнес-клиентами и заинтересованными сторонами до встреч уточнения или Планирования Спринта. Разработчики отвечают за подробное разбиение и организацию собственной работы.

Бэклог продукта Scrum упорядочен по приоритетам

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

Оценка размера элементов бэклога продукта

Разработчики могут оценивать размер согласованным методом, например стори-пойнтами по Фибоначчи или относительными размерами S/M/L/XL/XXL. Scrum не требует одной шкалы или оценки каждого далёкого элемента. Подробнее об этом — позже. Оценки влияют на планирование возможностей Спринтов, содержимое их бэклогов и планы выпусков.

Работа с бэклогом

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

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

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

После первоначального создания бэклог нужно постоянно поддерживать. Это означает:

• Описывать и добавлять новые выявленные требования; существующие при необходимости изменять или удалять,
• Упорядочивать (приоритизировать) бэклог, перемещая важнейшие истории с высшим приоритетом наверх,
• Готовить высокоприоритетные истории к следующему Планированию Спринта (обычно на встречах уточнения бэклога),
• Оценивать и переоценивать истории бэклога продукта (обычно на встречах уточнения бэклога).

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

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