Все статьи
Координация потоков ценности в SAFe®
Дата: 03.02.2026
Когда в портфеле несколько потоков ценности, настоящая сложность заключается не столько в их развитии, сколько в их согласовании. Координация потоков ценности в SAFe® (Scaled Agile Framework®) показывает, как управлять зависимостями между потоками, выстроить общий ритм работы и превратить пересечения и интеграцию в источник дополнительной, уникальной ценности для бизнеса.
Содержание
Подробности
Потоки ценности являются долгоживущими и, как правило, независимыми друг от друга. Например, компания, разрабатывающая системы или программное обеспечение, может продавать множество продуктов и услуг, в основном технологически не связанных между собой. Однако, чаще всего между потоками ценности существуют зависимости. Хотя обычно зависимости воспринимаются негативно, SAFe-принцип №2 «Системное мышление» показывает, что ценность проходит именно через эти зависимости. Да, здесь есть вызовы, которые необходимо учитывать, но также существуют ценные возможности, которые можно использовать.
Что наиболее важно, эта дополнительная ценность зачастую является уникальной и дифференцирующей, позволяя предприятию предлагать решения за счёт зависимостей, которые конкуренты не способны воспроизвести. Либо конкурент не развил мастерство в выявлении возникающих возможностей, которые могут предоставить эти скоординированные потоки ценности.
Использование возможностей, возникающих во взаимосвязях между потоками ценности, требует способности координировать потоки ценности в рамках портфеля, как показано на рисунке 1 и описано в следующих разделах.
Роли координации
SAFe опирается на людей, выполняющих три ключевые роли (или триады), которые представляют собой повторяющийся шаблон уровнем ниже.
- Что создаётся: Владелец продукта → Продуктовый Менеджмент → Менеджмент Решения.
- Как это создаётся: Agile-команда → Системный архитектор → Архитектор решения.
- Служащее лидерство: Скрам-мастер / Коуч Команды → Release Train Engineer (RTE) → Solution Train Engineer (STE).
Поэтому неудивительно, что в крупных портфелях при необходимости значительного уровня координации появляются схожие роли и зоны ответственности, как показано на рисунке 2 и описано ниже.
- Корпоративный Архитектор обеспечивает техническое руководство долгосрочной эволюцией технологий и платформ, а также наиболее значимыми нефункциональными требованиями (например, безопасность, соответствие требованиям, производительность) для решений портфеля.
- Руководство Портфеля — это функция, отвечающая за руководство набором интегрированных решений в рамках портфеля. Эту функцию выполняет один или несколько высших руководителей, несущих ответственность за данный набор решений.
- Value Management Office (VMO), а также RTE и STE, как правило, отвечают за поддержку децентрализованного и эффективного выполнения PI (Planning Interval).
Применение ритма и синхронизации
Рисунок 3 иллюстрирует SAFe-принцип №7 — применение ритма и синхронизации на уровне портфеля для реализации бизнес-эпиков и Энейблеров в рамках Потоков Создания Ценности.
Применение ритма и синхронизации позволяет нескольким потокам ценности совместно работать над поставкой инициатив уровня портфеля через эпики. Такая совместная работа, как правило, требует следования общему расписанию PI-планирования, интегрированных демонстраций и мероприятий Inspect & Adapt. Каждая демонстрация обеспечивает объективную оценку разрабатываемого решения и поддерживает непрерывную интеграцию на большом масштабе с внутренними и внешними поставщиками.
В идеале все потоки ценности в портфеле выровнены по общему ритму, что делает выполнение рутинных действий предсказуемым. Поскольку такой ритм снижает транзакционные издержки, связанные с изменениями, внутренние и внешние поставщики также должны быть частью этого общего ритма.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, вступайте в сообщество SAFe® Russia.
Введение новой работы уровня портфеля
Рисунок 4 иллюстрирует ещё одну важную концепцию. Ритм портфеля определяет темп и моменты добавления новой работы уровня портфеля. Этот ритм обеспечивает надёжную основу для введения новой портфельной работы на границах PI, поскольку команды зачастую не могут одновременно выполнять существующие обязательства и включать значительный объём незапланированной работы. Это помогает ART удовлетворять потребности предприятия в предсказуемости.
Этот ритм также задаёт способы, с помощью которых Владельцы Эпиков, Корпоративные Архитекторы и другие участники управляют эпиками через Канбан Портфеля. Любой эпик, не готовый к PI-планированию, должен ждать следующего PI, даже если доступная ёмкость могла существовать. Ограничение ритма по времени также ограничивает Незавершенную Работу (Work in Process, WIP) для новой и существенной работы, которая будет вводиться.
ART и Solution Trains в каждом PI фокусируются на зафиксированных PI-целях. Любая новая работа, добавляемая в систему в промежутке, вызывает существенные прерывания, переключение задач, повторное выравнивание и перераспределение людей на новые цели.
Обеспеченные точки интеграции
Интеграция решений между потоками ценности является сложной задачей. Полная интеграция может быть невозможна в каждой итерации (рисунок 5). Поэтому крайне важно выполнять частичную интеграцию на протяжении всего PI, когда полная интеграция ещё невозможна. Эти точки интеграции, основанные на ритме, являются единственной объективной мерой скорости портфеля: чем чаще выполняется интеграция, тем быстрее происходит обучение.
При определении ритма интеграции и развертывания необходимо учитывать следующие экономические компромиссы:
- преимущества более быстрого обучения, которое часто выражается в более высоком качестве и лучших продуктах;
- стоимость отложенного обучения и возможных доработок;
- затраты и выгоды от автоматизации DevOps;
- требуемая глубина интеграции;
- необходимая точность обратной связи;
- требуемый уровень удовлетворённости клиентов.
Развертывания часто сопровождаются непредсказуемыми сюрпризами. Наша естественная человеческая склонность — откладывать задачи, которые считаются рискованными. К сожалению, откладывание развертываний и формирование крупных пакетов изменений не просто откладывает риск — оно его увеличивает. Если каждая отдельная функциональность имеет вероятность 1% содержать дефект, требующий исправления в продуктивной среде, то ожидание выпуска пакета из 10 изменений означает почти 10% вероятность необходимости исправления или отката.
Более того, простои небольших изменений увеличивают «стоимость хранения» пакета. Избыточные запасы являются формой потерь. Вместо этого следует находить способы интегрировать такие небольшие изменения с другими. Более эффективным решением является снижение транзакционных издержек развертывания за счёт улучшения практик DevOps, включая, например, автоматизацию тестирования и развертывания, автоматизацию безопасности и соответствия требованиям, а также использование моделей для поддержки сквозной интеграции — с демонстрацией полной или частичной функциональности системы на уровне решения.
Дорожная карта портфеля
Рисунок 6 иллюстрирует, что дорожная карта портфеля формируется на основе дорожных карт решений и, в свою очередь, вносит вклад в них. Такое представление более высокого уровня позволяет интегрировать релевантные аспекты дорожных карт решений и связанные с ними вехи в более целостную картину. Этот агрегированный вид доносит общее представление до заинтересованных сторон предприятия и портфеля.
Релиз по требованию
Развертывание и выпуск интегрированной ценности зависят от эффективных возможностей DevOps и конвейера непрерывной поставки, что обусловлено природой потоков ценности и существующими зависимостями. В некоторых случаях ART предоставляют все необходимые возможности DevOps. В других — возникают дополнительные соображения (рисунок 7). В отдельных ситуациях это может требовать выделенных или общих сервисов и системных команд для отдельных ART и на уровне потоков ценности, которые помогают интегрировать решение в релиз уровня портфеля.
