Блог
Беклог Команды

Беклог Команды

1 августа 2024

Что такое Беклог Команды?

Беклог команды (Team Backlog) — это совокупность столбцов Канбан системы, которая используется для сбора и управления Пользовательскими Историями и Энейблерами, предназначенными для улучшения Решения.

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

Беклог команды содержит всю возможную работу, которую команда может выполнить для улучшения решения. Например, беклог может состоять из Пользовательских Историй, Энейблеров, а также Историй для корректировки выполнения работы (улучшений). Истории улучшений обычно появляются в результате проведения таких мероприятий как Ретроспектива Команды или Инспект-Адапт Поезда (Inspect & Adapt).

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

Беклог содержит всю работу, которую Agile команда планирует выполнить для создания решения и его дальнейшего развития. Беклог также выравнивает (со-направляет) всех членов команды относительно общей цели.
Беклог — это список желаний и потребностей, а не обязательств. Элементы в нем могут быть оценены (предпочтительно) или нет. Простыми словами, беклог — это просто упорядоченный список элементов работы без каких-либо конкретных временных обязательств по их выполнению. Другими словами, беклог не зависит от времени, что дает команде гибкость в отношении того, что и когда будет реализовано.
Все участники команды могут вносить Истории в беклог.
У беклога есть владелец — Владелец Продукта (Product Owner, PO). Он/она помогает команде управлять запросами от нескольких заинтересованных лиц, у которых могут быть разные взгляды на то, что важно.

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

Источники данных для заполнения беклога команды

Существует три основных источника данных для беклога команды, как показано на рисунке 1.

Рисунок 1. Источники данных для беклога команды

Беклог Релизного Поезда (Agile Release Train, ART) – Беклог Релизного Поезда содержит Фичи, которые Поезд планирует доставить в ближайшее время. Во время подготовки к PI Планированию и во время этого мероприятия команды разбивают Фичи-кандидаты на Истории и предварительно распределяют их по предстоящим итерациям. Эти новые Истории фиксируются в беклоге команды.
Локальный контекст команды – Локальные задачи команды (другая новая функциональность, дефекты, рефакторинг, технический долг и обслуживание) также находятся в беклоге. Поскольку «PI-Планирование» — это высокоуровневое мероприятие, команды, скорее всего, будут вносить корректировки в Истории уже во время Интервала Планирования. Команды, использующие Scrum, обычно делают модификации во время мероприятия «Планирование Итерации», а команды, применяющие Kanban, обычно вносят изменения во время собрания по пополнению.
Другие стейкхолдеры – Agile команды внутри Релизного Поезда (ART) — это не отдельные государства. Их беклоги могут содержать какие-то Истории, которые поддерживают зависимости и обязательства других команд, включая Цели на Интервал Планирования (PI Objectives) на уровне Поезда (ART). Эти Истории могут содержать спайки для исследований, которые необходимы для оценки Фич, Капабилити (Возможностей) и даже Эпиков.

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

При гибкой разработке важную роль играют Нефункциональные Требования (Nonfunctional Requirements, NFR). Нефункциональные Требования (НФТ)— это устойчивые качества, которые могут повлиять на дизайн, производительность или качество решения.

НФТ служат ограничениями (или определенными условиями) для всех элементов, над которыми работает команда, поэтому на Большой Картине (Big Picture) они отражены внизу беклога (рисунок 1). Из-за их важности команды часто автоматизируют тесты приемки для NFR и включают их в свое Определение Выполненности (Definition of Done, DoD).

Создание и уточнение беклога

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

Уточнение беклога команды включает следующие действия:

Уточнение Историй и установление критериев приемки.
Регулярная расстановка приоритетов в беклоге команды со стороны Владельца Продукта. Для обеспечения корректной приоритизации Владелец Продукта должен взаимодействовать с самой командой и заинтересованными лицами.
Формулирование новых Историй, включая Энейблеры, а также изменение или удаление из беклога существующих Историй.
Определение критериев приёмки и размера для Историй, которые с высокой вероятностью скоро будут включены в итерацию. Эта работа включает в себя контроль того, чтобы каждая История по возможности была небольшой по сложности и обязательно умещалась в итерацию.
Удаление Историй, которые находились в беклоге слишком долго и потеряли свою актуальность.

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

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

Не существует какого-то единого шаблона для проведения мероприятия по уточнению беклога (Backlog Refinement). Некоторые команды предпочитают регулярно выделять немного времени на уточнение беклога сразу после проведения Синхронизации Команды (Team Sync). Другие проводят еженедельные сессии по уточнению беклога или мастерские по уточнению требований, применяя методы разработки на основе поведения (Behavior-Dtiven Development, BDD) для прояснения историй.

Поскольку над одной Фичей часто работают несколько команд, то при взаимодействии возникают новые вопросы, зависимости и истории. Уточнение беклога также помогает выявить проблемы с текущим планом, которые могут потребовать дополнительного обсуждения внутри команды, а также на Синхронизации Владельцев Продукта (PO Sync) или Синхронизации Коучей (Coach Sync).

Управление беклогом с помощью Kanban

В SAFe Agile команды управляют своим беклогом с помощью Kanban системы, которая обеспечивает со-направленность и наглядность, а также помогает управлять зависимостями. На рисунке 2 показан пример Канбан системы одной команды.

Рисунок 2. Канбан доска Agile команды

Канбан система визуализирует всю начатую и незавершенную работу, состояния рабочего процесса и ограничения на количество незавершенной работы (НЗР, WIP).

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

Для получения дополнительной информации о создании Канбан системы на уровне команды переходите на статьи: «Применение Kanban в SAFe» и «Kanban Команда в SAFe».

Как уравновесить доставку ценности и «здоровье» системы с помощью аллокации ёмкости?

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

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

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

Для решения этой проблемы Владелец Продукта вместе с командой применяет аллокацию ёмкости (рис. 3). Во время планирования Владелец Продукта, команда и Архитектор Систем выбирают элементы беклога с наивысшим приоритетом, заполняя доступный аллоцированный объем для каждого из типов Историй.

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

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