Беклог Портфеля (Portfolio Backlog)

Что такое Беклог Портфеля?

Беклог Портфеля представляет собой Канбан систему, которая используется для управления Бизнес-Эпиками и Эпиками-Энейблерами. Эпики направлены на создание и развитие продуктов, услуг и решений Портфеля.

Бережливое управление Портфелем (Lean Portfolio Management, LPM) отвечает за разработку Беклога Портфеля, поддержание его в актуальном состоянии и расстановку приоритетов в нем. Задача Lean Portfolio Management – выявить Эпики, которые необходимы для развития решений Портфеля. Для этого LPM активно сотрудничают с заинтересованными лицами, в том числе с Владельцами Бизнеса (многие из которых являются частью LPM), Менеджментом Продукта и Менеджментом Решения, Владельцами Эпика, Архитекторами Предприятия и другими.

Эпики Портфеля — это крупные (и, как правило, сквозные) инициативы, управляемые через Канбан Портфеля. По мере того, как Эпик перемещается слева направо по Канбан системе Портфеля, на его реализацию требуется все больше усилий и ёмкости. И перед LPM встает важная задача – определить, какие из Эпиков перейдут на следующий шаг Канбан системы, а какие будут из нее удалены.

Разработка и уточнение беклога

Для создания и уточнения беклога Lean Portfolio Management применяет подход, основанный на потоке. Управление потоком обеспечивает, что Эпики Портфеля должным образом подготовлены к реализации: по ним в достаточном объеме проведены исследования и определен приемлемый уровень риска.

Чтобы гарантировать готовность Эпика к реализации, уточнение беклога часто включает в себя следующие действия:

• Обзор новых Эпиков и определение их соответствия Стратегическим Темам и Видению Портфеля
• Оценка Заявления Гипотезы Эпика (Epic Hypothesis Statement) для принятия решения о том, необходимо ли для этого Эпика определить Владельца Эпика
• Расстановка приоритетов в беклоге Портфеля на основе WSJF и других факторов в сотрудничестве с Владельцами Бизнеса, Архитекторами Предприятия, Менеджментом Продукта и другими заинтересованными лицами

Уточнение беклога часто происходит во время таких мероприятий, как «Синхронизация Портфеля» (Portfolio Sync) и «Стратегический Обзор Портфеля» (Strategic Portfolio Review). LPM и его заинтересованные лица добавляют новые элементы в воронку беклога, обновляют приоритеты и удаляют менее перспективные эпики. Поддержание беклога в актуальном состоянии является обязательным условием для успешного управления портфелем.

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

Канбан система Портфеля (Portfolio Kanban) визуализирует Эпики Портфеля и организует поток Бизнес-Эпиков и Эпиков-Энейблеров. Таким образом, Эпики Портфеля становятся видимыми, разрабатываются и управляются с помощью Канбан системы Портфеля, где они проходят через разные состояния процесса до тех пор, пока не будут утверждены или отклонены. До взятия в реализацию Эпики требуют анализа и утверждения. Владельцы Эпика несут ответственность за организацию необходимого взаимодействия в рамках всех шагов жизненного цикла соответствующих Бизнес-Эпиков. Архитекторы Предприятия, как правило, отвечают за Эпики-Энейблеры, которые поддерживают технические аспекты Бизнес-Эпиков.

Многие компании испытывают трудности с разработкой инноваций, потому что они не управляют своим портфелем с достаточной строгостью и дисциплиной. Менее важная работа выполняется, в то время как та деятельность, которая имеет больший потенциал, откладывается или ей не уделяется достаточно времени. Если выбирать для реализации одну из «лучших больших» идей на основе ощущений лидеров организации, это не приблизит переход портфеля из его текущего состояния к экономически обоснованному стратегическому состоянию бизнеса в будущем. Для этого требуется целенаправленная работа, в ходе которой LPM и заинтересованные лица определяют конкретные Эпики, которые позволят реализовать Видение Портфеля.

Канбан Портфеля обеспечивает со-направленность стратегии и реализации. Он помогает определить, коммуницировать и управлять выбором крупных стратегических инициатив (Эпиков) для портфеля SAFe. LPM отвечает за Канбан Портфеля, который часто используется во время Стратегического Обзора Портфеля и Синхронизации Портфеля для управления потоком Эпиков.

В то время как отдельные «визионерские» Эпики приветствуются, LPM несет коллективную ответственность за обеспечение потока Эпиков, максимально соответствующих Стратегическим Темам, Видению и экономическим рамкам портфеля. Для достижения лучшего будущего состояния необходимо, чтобы Разработческие Потоки Создания Ценности приняли мышление «одного портфеля». В этом случае они взаимодействуют для достижения высокоуровневых целей портфеля и более масштабных целей предприятия.

На рисунке 1 показан процесс, как Эпик проходит различные состояния от воронки до завершения. При этом Владелец Эпика координирует его перемещение по Канбан системе Портфеля. Только состояния «Рассмотрение», «Анализ» и «Выполнено» имеют явные ограничения на количество незавершенной работы (НЗР, WIP). Подсостояние MVP имеет неявный лимит НЗР, доступную ёмкость поездов и бюджет потоков создания ценности.

Рисунок 1. Пример Канбан системы Портфеля

Дизайн Канбан системы должен развиваться в соответствии с потребностями конкретного портфеля и отражать непрерывное совершенствование процесса. Эти улучшения могут включать в себя настройку WIP-лимитов , разделение или объединение состояний Kanban системы или добавление классов обслуживания для оптимизации потока и последовательности реализации эпиков.

Каждый пример состояния портфеля будет описан далее в статье.

Воронка (Funnel)

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

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

Эпики изначально описываются в формате «Заявление Гипотезы Выгоды» (Epic Hypothesis Statement). Воронка не имеет ограничений на количество НЗР (WIP), поскольку содержит просто идеи, которые требуют дополнительного рассмотрения. Если при первоначальном рассмотрении какая-то идея Эпика не соответствует определению в Направляющих и не является Эпиком Портфеля, то она переносится в Канбан систему одного из Релизных Поездов (Agile Release Train, ART) или Поездов Решения (Solution Train).

Эпики могут возникать из любого источника, обычно Эпики попадают в Воронку в результате двух активностей, как показано на рисунке 2:

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

Рисунок 2. Наполнение воронки портфеля

Рассмотрение (Reviewing)

Каждый Эпик является существенной инвестицией, поэтому для него определяется Владелец Эпика. Владелец Эпика идентифицирует Эпик и выступает его спонсором.

Когда Владелец Эпика определен, он переводит Эпик из стадии «Воронка» на следующий шаг Канбан системы Портфеля — «Рассмотрение», работая с соответствующими заинтересованными лицами над уточнением Эпика и созданием Заявления Гипотезы Эпика.

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

Эпики на шаге «Рассмотрение» непрерывно оцениваются друг относительно друга с помощью WSJF. Таким образом Эпики всегда выстроены относительно экономической ценности на основе предварительных оценок бизнес-выгоды и затрат.

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

Анализ (Analyzing)

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

Для проведения анализа, как правило, необходимо активное сотрудничество между следующими ролями:

• Владельцы Бизнеса (Business Owners)
• Архитекторы Предприятия, Архитекторы Решения, Архитекторы Систем
• Менеджмент Продукта и Менеджмент Решения
• Agile Команды

Во время состояния «Анализ» обычно выполняются следующие действия:

• Идентификация и анализ альтернативных решений
• Определение MVP
• Уточнение объема затрат на MVP и полного предполагаемого объема затрат на Эпик
• Создание Бережливого Бизнес Кейса (Lean Business Case)
• Проведение небольших исследовательских спайков для демонстрации потенциальной технической- и бизнес-жизнеспособности
• Первичная валидация со стороны клиента
• Обновление WSJF относительно других эпиков, находящихся на этом же шаге
• Принятие решения «Делаем/Не делаем» со стороны LPM на основе Lean Business Case

Как правило, на этом шаге Канбана Портфеля находится небольшое количество Эпиков, и они регулярно рассматриваются командой LPM. Поскольку анализ Эпика и его последующая реализация требуют больших ресурсов, требуется формальное утверждение его перехода в следующее состояние «Готово к разработке».

Принятие решений «Делаем/Не делаем» производится коллегиально командой LPM на основе Lean Business Case во время мероприятия «Синхронизация Портфеля». «Делаем» означает, что Эпик одобрен для реализации и включен в Беклоги Поездов. «Не Делаем» переводит Эпик в состояние «Выполнено».

Готово к разработке (Ready)

Эпики, по которым команда LPM приняла решение «Делаем», включаются в беклоги реализации поездов и переносятся на шаг «Готово к Разработке».

Перенос Эпиков из шага «Анализ» производится на основе WSJF с учетом WIP-лимита шага «Готово к разработке». В этом состоянии Эпики находятся в ожидании начала реальной разработки со стороны поездов. Все Эпики на этом шаге также непрерывно приоритизируются друг относительно друга с помощью WSJF и других соответствующих факторов.

Нахождение Эпика в состоянии «Готово к разработке» означает, что Эпик одобрен к реализации, но ни один из Поездов еще не приступил к работе над ним (никакие Фичи/Капабилити еще не прошли PI Планирование).

Разработка (Implementing)

Что включает в себя состояние «Разработка»:

• Выбор конкретных Эпиков для реализации.
  Для определения Эпиков для разработки команда LPM и представители разных потоков ценности проводят «Самобюджетирование» (Инициативное Бюджетирование, Participatory Budgeting) или похожее мероприятие. Полученные результаты и обратная связь помогают LPM решить, как скорректировать бюджеты потоков ценности для поддержки реализации наиболее выгодных Эпиков для организации.
• Установление последовательности выполнения работ, определение размера и ранжирование Эпиков относительно друг друга с помощью WSJF.
  Для того, чтобы оставаться в рамках Бережливых Бюджетных Направляющих, таких как аллокация ёмкости, инвестиционные горизонты и другие, может потребоваться корректировка приоритетов Эпиков на основе WSJF. LPM должен хорошо понимать доступные ёмкости ART, поскольку продолжительность работы, используемая для вычисления WSJF, может зависеть от ёмкости, доступной для реализации.
• Декомпозиция Эпиков на Фичи и Капабилити
  Владелец Эпика взаимодействует с различными заинтересованными лицами, чтобы разделить Эпики на Фичи и Капабилити. Ответственные за реализацию Релизные Поезда (Agile Release Train) и Поезда Решения (Solution Train) далее распределяют работу по соответствующим беклогам, как показано на рисунке 3.
• Презентация Фич и Капабилити на PI-Планировании
  Когда все готово к реализации, Фичи и Капабилити презентуются на соответствующих мероприятиях по PI Планированию, чтобы начать разработку MVP Эпиков.
• Оценка прогресса в разработке MVP
  LPM оценивает прогресс MVP на основе опережающих индикаторов, ключевых показателей эффективности потока создания ценности (KPI) и демонстраций работающего MVP или его компонентов.
• Состояние «Разработка» имеет два подсостояния: MVP и Persevere (Продолжение).
  Эти два подсостояния описаны в следующих разделах.

Рисунок 3. Релизные Поезда (ART) и Поезда Решения (Solution Train) распределяют работу по своим беклогам

Подсостояние разработки: MVP

При наличии достаточной ёмкости у одного или нескольких Релизных Поездов Эпики с наибольшим WSJF переходят из «Готово к Разработке» в состояние «MVP». Здесь Владелец Эпика работает с Agile командами, чтобы обеспечить начало разработки MVP. Работа над MVP продолжается до тех пор, пока не будут потрачены деньги, выделенные на MVP, или гипотеза не будет оценена. Владелец Эпика готовит оценку бизнес-результатов гипотезы.

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

Если гипотеза не подтверждена, то возможны следующие дальнейшие действия:

• Поворот (Pivot) – корректировка курса, формулирование и проверка новой гипотезы
• Остановка (Stop) – остановка разработки по данному Эпику

Подсостояние разработки: Продолжение (Persevere)

Если гипотеза подтверждена, Эпик переходит в подсостояние «Persevere» (Продолжение), и команды продолжают разрабатывать новые Фичи и Капабилити для этого Эпика. На уровне Поездов Капабилити/Фичи данного Эпика непрерывно конкурируют с Капабилити/Фичами других Эпиков на основе WSJF.
Наступает момент, когда Капабилити/Фичи данного Эпика уже не могут конкурировать с помощью WSJF относительно Капабилити/Фич других Эпиков. В таком случае Эпик считается «выполненным в экономически достаточном объеме». В любом случае Владельцы Эпика по-прежнему остаются доступными для работы с ART и Поездами Решений.

Выполнено / Завершено (Done)

Эпик считается завершенным, когда получено достаточное количество знаний или ценности, или когда он больше не является задачей уровня Портфеля. Бережливое Управление Портфелем не требует обязательного выполнения всего объема работ Lean Business Case.

Эпик считается «Выполненным», если:

• Команда LPM отказывается от Эпика на любом из шагов Канбан системы Портфеля
• Гипотеза доказана, и команда LPM определила, что дополнительное управление на уровне Портфеля больше не требуется
• Команда LPM наблюдает, что Капабилити/Фичи данного Эпика проигрывают в экономической конкуренции другим Эпикам, и завершает работу по данному Эпику

Если гипотеза доказана, Релизные Поезда, ответственные за ее реализацию, продолжают работу над Эпиком. В процессе разработки от Владельца Эпика может потребоваться получение обратной связи и отслеживание результатов. Когда Эпик более не является Эпиком Портфеля, для информирования LPM о прогрессе используются опережающие индикаторы, KPI потока создания ценности и Направляющие.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Portfolio Kanban».

Дополнительно почитать:

статья «Бережливое Управление Портфелем»

статья «Каскадная модель требований в SAFe»

статья «Мероприятия Scaled Agile Framework»

статья «WSJF»