Бэклог продукта — совершенный список задач

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

Dan Radigan Dan Radigan
Просмотр тем

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

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

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

Подсказка

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

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

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

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

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

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

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

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

От чего может зависеть то, как владелец продукта расставляет приоритеты?

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

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

Правильное ведение бэклога

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

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

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

Подсказка

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

Примеры, которых нужно избегать

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

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

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

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

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

Подсказка

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