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

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

Dan Radigan Автор: Dan Radigan
Просмотр тем

Agile-бэклог с правильно расставленными приоритетами не только упрощает планирование релизов и итераций. Из него команда узнает, над чем она будет работать. Вся внутренняя кухня скрыта от глаз клиента. Работа становится для заинтересованных лиц и других команд более предсказуемой, что особенно полезно, когда они ставят перед вами дополнительные задачи. Время на разработку становится фиксированным ресурсом.

Что такое бэклог продукта?

Бэклог продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале бэклога продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь. Скорость, с которой команда выполняет задачи бэклога, не зависит от желаний владельца продукта, а он, в свою очередь, не оказывает давления на команду. Напротив, команда разработки самостоятельно выбирает задачи из бэклога продукта, когда у нее есть необходимые ресурсы, выполняя их непрерывно (Kanban) или итерациями (Scrum).

Подсказка

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

Два столпа бэклога продукта

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

Дорожная карта в agile | Atlassian — тренер по agile

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

Инициативы и эпики в agile | Atlassian — тренер по agile

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

Эпики и истории в agile | Atlassian — тренер по agile

Что может повлиять на то, как владелец продукта расставляет приоритеты?

  • Важность для клиента
  • Необходимость в обратной связи
  • Относительная сложность реализации
  • Тесная взаимосвязь между рабочими задачами (например, сделать «Б» будет проще, если сначала сделать «А»)

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

Как эффективно управлять бэклогом продукта

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

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

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

Подсказка

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

Плохие примеры, которые лучше не повторять

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

Бэклог продукта продвигает принципы Agile в команде

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

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

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

Подсказка

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

Стрелка Agile

Расставьте приоритеты для важных задач с помощью шаблона Scrum для Jira

Получите полное представление обо всей предстоящей работе, чтобы сосредоточиться на самом важном.

продолжение темы
Обзоры итогов спринтов