Блог
Release on Demand — управление релизами в SAFe

Release on Demand - управление релизами в SAFe

19 ноября 2025

«Разрабатываем в каденции. Выпускаем по требованию.» – мантра SAFe

Определение: Выпуск по требованию (Release on Demand) – это элемент Конвейера Непрерывной Доставки, обеспечивающий выпуск новой функциональности немедленно или инкрементально в зависимости от потребностей бизнеса и клиентов.

Рисунок 1. Выпуск по требованию – четвёртый аспект Конвейера Непрерывной Доставки

Что такое Выпуск по требованию?

Деятельность в рамках аспекта «Выпуск по Требованию» Конвейера Непрерывной Доставки позволяет Agile командам выпускать новые фичи, продукты или решения в тот момент, когда они наиболее востребованы пользователями или клиентами. Это ускоряет доставку обновлений и гарантирует, что релизы приносят пользу сразу после выпуска – фактор, напрямую влияющий на показатели бизнеса и удовлетворённость клиентов. Решения о том, что и когда выпускать, являются важным экономическим драйвером. В идеале фичи выпускаются по готовности, однако на практике релизы часто опираются на конкретные потребности пользователей или рыночные условия.

Это формирует ключевые вопросы для Менеджмента Продукта и Владельцев Бизнеса:

Когда следует выпустить релиз?
Какой функционал включить в релиз?
Каким сегментам пользователей адресовать выпуск?

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

Критически важно, чтобы выпуск был отделён от процесса развёртывания функциональности. Такое разделение позволяет отделу продуктового маркетинга готовить и запускать целевые промо-кампании для различных аудиторий, а отделу продаж – планировать свои активности с большей уверенностью в сроках и содержании функциональности решения.

Дополнительная информация о Конвейре Непрерывной Доставки (Continuous Delivery Pipeline, CDP)

Какие 4 активности включает «Выпуск по требованию»?

На рисунке 2 выделены четыре ключевые активности аспекта «Выпуск по требованию»:

Выпуск / Релиз — практики, обеспечивающие доставку новой функциональности конечным пользователям единоразово или инкрементально.
Стабилизация и Эксплуатация — подтверждение корректной работы релиза с учётом функциональных и нефункциональных требований (НФТ, NFR).
Измерение — количественная оценка того, приносит ли новая функциональность ожидаемую бизнес-ценность.
(Само)Обучение — сбор обратной связи и интеграция полученных знаний в процесс Непрерывного Исследования Конвейера Непрерывной Доставки.

Рисунок 2. Четыре активности «Выпуска по требованию»

Далее в статье каждая из этих активностей рассматривается подробнее.

Выпуск

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

Практики, повышающие способность к своевременному и контролируемому выпуску:

Скрытые релизы (Dark launches) — развёртывание в продуктовой среде без активации новой функциональности для конечных пользователей.
Переключатели фич/функций (Feature toggles) — механизм включения/отключения функциональности без повторного развёртывания.
Канареечные релизы (Canary releases) — выпуск новой функциональности для ограниченного сегмента пользователей с последующей оценкой результатов до масштабирования на более широкую аудиторию клиентов.
Раздельные элементы выпуска (Decoupled release elements) — выделение компонентов, которые можно выпускать независимо. Даже у простых продуктов таких элементов может быть несколько, и у каждого может быть собственная стратегия релиза (см. рисунок 3).

Рисунок 3. Отделение элементов выпуска от решения

Пример: сайт SAFe, где изначально размещена эта статья, имеет несколько относительно независимых циклов релиза. Это позволяет Scaled Agile:

Быстро устранять уязвимости в инфраструктуре хостинга при необходимости (ускоренный класс обслуживания);
Обновлять отдельные статьи и оперативно уведомлять читателей через размещение поста в блоге (высокая частота);
Добавлять новый контент в расширенное руководство SAFe по мере готовности (средняя частота);
Выпускать значительные обновления фреймворка, включая новую Большую Картину (Big Picture), с частотой, соответствующей возможностям клиентов усваивать новые версии, и учитывая возможности ресурсов, необходимых для разработки (низкая частота).

Эти отдельные потоки, или «ручьи потока ценности» (streamlets), по-прежнему обеспечивают сквозное движение ценности внутри общего потока ценности. Каждый поток управляется с учётом своих целей и темпа доставки ценности. Идентификация таких «ручьёв ценности» критична для реализации аспекта «Выпуск по требованию»: они позволяют выпускать различные элементы решения независимо, в собственной каденции, и служат основой для организации команд и поездов (ART), способных проводить автономные релизы по требованию.

Стабилизация и эксплуатация

После открытия новой функциональности для пользователей могут возникать непредвиденные проблемы – например, рост объёмов использования выше прогнозов или нестандартные сценарии поведения. Команды должны оперативно устранять инциденты и реагировать на угрозы безопасности в рамках соглашений об уровне сервиса (SLA). Для этого применяются следующие практики:

Инжиниринг надёжности сайта (SRE): Современные цифровые решения представляют собой сложные экосистемы взаимосвязанных систем, обслуживающих пользователей по всему миру. SRE повышает надёжность и масштабируемость таких систем за счёт автоматизации операций и применения программных инструментов управления.
Резервирование и авто-восстановление после аварий: Сбои неизбежны, поэтому необходимо проектировать механизмы оперативного переключения на резервные ресурсы и иметь планы быстрого восстановления. Архитектура отказоустойчивости должна быть спланирована заранее и регулярно отрабатываться на практике.
Непрерывный мониторинг безопасности: Подходы «безопасность как код» и регулярное тестирование на проникновение позволяют предотвращать известные уязвимости до их попадания в продуктовую среду. Одновременно требуется постоянное наблюдение за новыми угрозами и средства обнаружения вторжений в сервисы и инфраструктуру.
Разработка архитектуры с учётом эксплуатации: При создании решений необходимо учитывать операционные требования: пиковые нагрузки, угрозы безопасности и требования к времени реакции. В зависимости от ситуации это может потребовать либо сокращения объёма оказываемых сервисов, либо увеличения ёмкости инфраструктуры. Инструменты мониторинга производительности и централизованного логирования помогают выявлять узкие места, понимать поведение систем и своевременно вносить необходимые корректировки, адаптируясь к изменяющимся сценариям использования.
Мониторинг нефункциональных требований (НФТ, NFR): Команды должны отслеживать надёжность, производительность, масштабируемость и другие нефункциональные параметры, чтобы предотвращать нарушения доступности и деградацию сервиса.

Измерение

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

Для проверки новых гипотез командам потребуются иные метрики, отличные от тех, которые применяются для зрелых продуктов. Учёт инноваций (innovation accounting) – подход, ориентированный на анализ ранних результатов при разработке и тестировании минимально жизнеспособного продукта (MVP). Он помогает интерпретировать начальные данные, оценить вероятные результаты и принять обоснованные решения о дальнейших действиях.

(Само)Обучение

Информация, собранная после релиза, возвращается в Конвейер Непрерывной Доставки. Менеджмент Продукта использует эту обратную связь для принятия решений об инвестициях в будущие фичи и эпики. Менеджмент Продукта и Владельцы Продукта оценивают гипотезы для минимально жизнеспособных продуктов (MVP) и минимально реализуемых рыночных функций/фич (MMF). По результатам оценки принимается одно из решений: продолжить разработку (persevere), остановить её или сменить направление / сделать поворот (pivot) и протестировать альтернативные подходы.

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

Дополнительно почитать о MVP и SAFe Lean Startup Cycle в статье Эпик

Что такое управление релизами?

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

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

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

Поезд может запланировать релизы в ходе PI Планирования – это относительно простая часть процесса. Основная сложность заключается в координации реализации фич на протяжении нескольких итераций внутри Интервала Планировани (PI), особенно при появлении новых проблем, блокировок, зависимостей и рассогласований в видении и беклогах. В связи с этими вызовами объём каждого релиза требует постоянного управления, повторной валидации и прозрачной коммуникации. Такая работа должна включать в себя:

Обеспечение понимания и соблюдения организационных правил управления выпусками;
Информирование внутренних и внешних заинтересованных лиц о состоянии релиза;
Обеспечение наличия соответствующего плана развёртывания;
Координация коммуникаций с отделом маркетинга, Менеджментом Продукта и Менеджментом Решения;
Валидация соответствия решения установленным критериям качества и требованиям комплаенса;
Участие в мероприятии «Инспект-Адапт» (Inspect and Adapt, I&A) для повышения эффективности процесса релиза, роста производительности потока ценности и качества решения;
Принятие окончательного решения о выпуске (финальная авторизация);
Взаимодействие с командой Бережливого Управления Портфелем (LPM) по мере необходимости;
Участие в финальных мероприятиях по выпуску и контроль их исполнения.

Многие организации специально проводят регулярные встречи по управлению релизами, чтобы рассматривать на них следующие вопросы:

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

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

В средах с более непрерывной доставкой участники внимательно отслеживают стадии релизного потока в Канбан системе Поезда (ART): подтверждают выпуск элементов для целевых клиентских сегментов, управляют канареечными и «скрытыми» (dark) релизами, проверяют гипотезы и подтверждают рефакторинг-удаление переключателей фич (feature toggles) после верификации в продуктовой среде.

Оригинал: Scaled Agile, Inc. (вендор), статья «Release on Demand». Материал не является официальным переводом.

Перевод и адаптация: Алексей Ионов, Lean-Agile коуч организаций, Advanced SPC, Ионов и Партнеры.

Основано на версии статьи вендора от 25.02.2025.

Почитать дополнительно по теме:

Конвейер Непрерывной Доставки