Бэклог разработки

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

Бэклог разработки

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

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

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

Работа с бэклогом включает несколько ключевых аспектов:

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

Что входит в бэклог?

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

Давайте разберем каждый элемент бэклога подробнее:

  • Функции: Это желаемые характеристики и возможности ПО, которые делают продукт полезным для пользователей. Например, в приложении для заказа еды функцией может быть возможность отслеживания статуса заказа в реальном времени.
    • Пример: В приложении по доставке еды функцией может быть система лояльности с накоплением бонусных баллов за каждый заказ. Такие дополнительные функции повышают удовлетворенность клиентов и стимулируют повторные заказы.
  • Дефекты (баги): Это ошибки в ПО, которые мешают его нормальной работе.
    • Пример: Ошибка в приложении по доставке еды, из-за которой не отображается текущее местоположение курьера. Устранение таких дефектов критично для поддержания доверия пользователей.
  • Технический долг: Это задачи, не видимые пользователям напрямую, но необходимые для поддержания и улучшения качества ПО.
    • Пример: Миграция базы данных с локального сервера на облачную платформу для улучшения масштабируемости и надежности приложения. Такая работа не всегда заметна пользователям напрямую, но имеет решающее значение для долгосрочной стабильности продукта.
  • Исследование: Задачи, направленные на изучение новых технологий или подходов для решения сложных задач.
    • Пример: Разработка прототипа для интеграции расширенной реальности в приложение по доставке еды, чтобы пользователи могли виртуально «примерить» блюда перед заказом. Это помогает команде оценить потенциал новых функций перед их полноценной реализацией.

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

Как управлять бэклогом продукта?

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

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

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

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

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

Почему управление бэклогом полезно?

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

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

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

Совет

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

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

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

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

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

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

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

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

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

такой подход может оказаться не по душе.

Резюме

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