System Demo - демонстрация системы в SAFe

31 октября 2025

Поезд проводит System Demo: показ интегрированной функциональности на панели управления перед заинтересованными сторонами и другими членами Поезда

Определение: Демонстрация Системы предоставляет заинтересованным лицам единый обзор нового интегрированного функционала (фич), реализованного всеми командами Поезда (Agile Release Train, ART) за последнюю завершённую итерацию. Каждая такая демонстрация позволяет объективно оценить прогресс в достижении целей и получить обратную связь.

«Чтобы избежать двусмысленности, стоит сразу добавить, что в SAFe присутствует особый вид этого мероприятия, которое является частью события Инспект-Адапт и называется Демонстрация Системы Интервала Планирования (PI System Demo). В этом случае оно позволяет провести обзор всего функционала, реализованного за весь Интервал Планирования. Оба мероприятия являются обязательными и одно не заменяет другое.

Также хотелось бы прокомментировать название мероприятия. В SAFe как минимум присутствует две демонстрации – демонстрация команды в рамках мероприятия «Обзор Итерации» для Scrum команд и собственно Демонстрация Системы на уровне Поезда. Вполне логичным было бы назвать последнее мероприятие «Демонстрация Поезда» или «Обзор Итерации для всего Поезда», однако авторы фреймворка приняли иное решение.

Если рассматривать конфигурацию SAFe «Крупное Решение», в ней также присутствуют демонстрации и они называются «Демонстрация Решения». Проводятся Демонстрации Решения на уровне «Поезда Поездов», который в SAFe называется «Поезд Решения».

Исходя из логики фреймворка, если Решение представляет собой что-то крупное, то его можно разделить на отдельные Системы. Таким образом, на уровне отдельного поезда мероприятие и получило название «Демонстрация Системы», как часть чего-то крупного, что может совместно разрабатываться многими поездами (даже если это по факту не так).

На практике термины Демо Команды (вместо Обзор Итерации/Спринта) и Демо Поезда (вместо Демонстрация Системы) также могут применяться, хотя и не являются полностью корректными с точки зрения Scrum и SAFe соответственно.»

Алексей Ионов, Lean-Agile коуч организаций, Ионов и Партнеры
Алексей Ионов, Lean-Agile коуч организаций, Ионов и Партнеры

Что такое Демонстрация Системы (System Demo)?

Демонстрация Системы предоставляет заинтересованным сторонам единый обзор новых интегрированных функций (фич), которые были доставлены командами Поезда (Agile Release Train, ART) в последней итерации. Каждая System Demo служит объективным индикатором прогресса в достижении целей Интервала Планирования и даёт возможность предоставить конструктивную обратную связь.

Демонстрация Cистемы имеет ключевое значение для работы Поезда (ART) и проводится с участием всех его членов. В отличие от System Demo, мероприятие «Обзор Итерации» сосредоточено на результатах, достигнутых конкретной Agile командой за одну итерацию. Как правило, в таких обзорах участвует только сама команда и заинтересованные лица, непосредственно заинтересованные в результатах этой команды или вовлечённые в её работу.

Во время Демонстрации Системы команды ART представляют реализованные ими фичи в среде, максимально приближенной к продуктовой. Это позволяет объективно оценить прогресс команды — не через формальное закрытие задач или отчёты о статусе, а посредством показа работающего продукта. Регулярные демонстрации работающей системы способствуют своевременному выявлению дефектов и недостатков в архитектуре и дизайне, что уменьшает затраты и упрощает их устранение. Кроме того, такие мероприятия стимулируют генерацию идей и поддерживают цикл непрерывного улучшения продукта.

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

Демонстрации Системы приносят заметную пользу и командам Поезда (ART). Показ интегрированной системы позволяет увидеть влияние работы каждой команды на продукт в целом, и оптимизировать их вклад. Команды получают прозрачное представление о задачах и результатах других команд, что укрепляет сотрудничество и ускоряет обмен знаниями. В ходе System Demo команды получают оперативную обратную связь от заинтересованных лиц, что позволяет быстро вносить необходимые корректировки и сосредоточиться на приоритетных задачах. В результате снижаются неэффективные затраты времени и усилий.

Рисунок 1. Демонстрации Системы проводятся по установленной каденции в конце каждой итерации.

Для крупных решений, в разработке которых задействовано несколько Поездов (ART), Демонстрация Системы становится частью более масштабной Демонстрации Решения (Solution Demo). В Демонстрациях Решения участвуют все задействованные Поезда (ART).

Как часто проводится Демонстрация Системы?

Демонстрация Системы проводится в конце каждой итерации и должна проходить после дня её завершения — оптимально на следующий рабочий день. Задержка с интеграцией препятствует обучению и создаёт ложное ощущение прогресса. Чтобы этого избежать, командам ART рекомендуется прилагать все необходимые усилия для систематического проведения демонстраций. Любые отклонения от регулярного ритма могут сигнализировать о системных проблемах — например, о необходимости улучшить практики интеграции или выделить дополнительные ресурсы для Команды Системы (System Team). Быстрое устранение таких проблем повышает эффективность рабочего процесса и качество результатов.

Иногда своевременная интеграция и демонстрации системы затруднительны для организаций, переходящих на Lean-Agile, а также для команд, работающих над сложными кибер-физическими решениями. Это естественно и не должно служить поводом для сокращения объёма или глубины интеграции. По мере «взросления» ART большинство препятствий, как правило, исчезает. Если полная интеграция на каждой итерации пока невозможна, Agile командам рекомендуется рассмотреть следующие меры:

  • Интегрировать отдельные части функциональности, компоненты или подсистемы с целью демонстрации конкретной фичи или нефункционального требования (НФТ, NFR).
  • Проводить частичную интеграцию с использованием физических или цифровых прототипов вместо дефицитных или дорогостоящих компонентов.
  • Использовать тестовых двойников (дублёры, заглушки, test doubles) для ускорения интеграции и тестирования.
  • Выполнять интеграцию реже (например, через итерацию), пока не станет возможным перейти к более частым интеграциям.
  • Выделить Команду Системы для ART для создания инфраструктуры и необходимых возможностей для частой и надёжной интеграции.

Кроме Демонстрации Системы по итогам каждой итерации, Поезд (ART) проводит итоговую Демонстрацию Системы за весь Интервал Планирования (PI System Demo), на которой показываются все фичи, разработанные в течение Интервала Планирования (Planning Interval, PI). PI System Demo является ключевым элементом мероприятия «Инспект-Адапт» (Inspect and Adapt, I&A).

Узнать больше о PI System Demo в рамках мероприятия Инспект-Адапт можно в статье «Инспект-Адапт».

Кто участвует в System Demo?

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

Обычно в System Demo участвуют:

Участники не только наблюдают, но и активно дают конструктивную обратную связь.

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

Как проводить System Demo?

Release Train Engineer (RTE), как правило, фасилитирует проведение Демонстрации Системы при активном участии других представителей ART. Любой член Поезда может представлять результаты работы своей команды. Интегрированные фичи нередко демонстрируются совместно несколькими командами.

Формат Демонстрации Системы может со временем эволюционировать, однако следующая структура служит хорошей отправной точкой:

Начало мероприятия: кратко представьте мероприятие, его цель и контекст проведения Демонстрации Системы.

Живая демонстрация фич: покажите, как представленные фичи связь с целями Интервала Планирования и ожидаемую пользу для бизнеса и клиентов.

Вопросы и обратная связь: подготовьте пространство для обсуждения.

Определение рисков и препятствий: договоритесь о дальнейших шагах по устранению выявленных рисков и препятствий.

Завершение: резюмируйте проделанную работу в ходе Демонстрации Системы. Кратко изложите план на оставшуюся часть Интервала Планирования.

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

Демонстрация реальной, протестированной функциональности непосредственно из среды, близкой к продуктовой, а не с помощью слайдов презентации, делает показ более живым и содержательным. Важно также показывать, какое влияние система оказывает, какие задачи решает и какую пользу приносит. Это подчеркнёт её ценность и эффективность для участников мероприятия.

Ниже — несколько дополнительных рекомендаций для успешного проведения Демонстрации Системы:

  • Показывайте реальные, работающие фичи, а не слайды.
  • Демонстрируйте развитие архитектуры системы и то, как учтены нефункциональные требования.
  • Подготовьте и заранее, до мероприятия, представьте поезду (ART) и заинтересованным лицам перечень элементов, которые будут продемонстрированы.

Как применить на практике полученные на Демонстрации Системы знания?

Цель демонстрации системы — чтобы все участники ART получили новые знания по результатам завершённого этапа разработки и при необходимости скорректировали дальнейшие действия. System Demo даёт оперативную обратную связь, которую затем следует правильно обработать и превратить в конкретные шаги.

При получении конкретной обратной связи на Демонстрации Системы команда(ы) могут воспользоваться несколькими мероприятиями SAFe для её отработки:

  • Ретроспективы команды позволяют оценить производительность, обсудить улучшения на основе полученной обратной связи на Демонстрации Системы, и сформировать план действий.
  • На Планировании Итерации обратная связь с предыдущей Демонстрации помогает определить приоритеты для следующей итерации и может потребовать создания новых пользовательских Историй.
  • Синхронизация Поезда (ART Sync) — отличная возможность для RTE, Скрам Мастеров/Коучей Команд, Менеджеров Продукта и Владельцев Продукта обсудить обратную связь, полученную на Демонстрации Системы и скоординировать необходимые действия.
  • Уточнение беклога ART/Подготовка к новому Интервалу и само PI Планирование дают возможность создать новые Фичи в результате полученной обратной связи, затрагивающей несколько команд.

Обратная связь с Демонстрации Системы и реализованные на её основе действия — важные шаги в процессе непрерывного улучшения ART.

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

Перевод: Ионов и Партнеры. Перевод подготовлен по последней версии статьи на сайте вендора от 15.10.2024.

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

Инспект-Адапт

PI Планирование

Мероприятия SAFe

Agile команды

Релизный Поезд (Agile Release Train, ART)

Владельцы Бизнеса

Цели Интервала Планирования (PI Objectives)

 

© «Ионов и Партнеры» (ИП Ионов Алексей Константинович), 2017-2025. Все права защищены. Цитирование материалов и размещение ссылок на материалы для формирования сторонних баз знаний, рубрикаторов или агрегаторов допускается только с письменного согласия «Ионов и Партнеры».

SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.

Другие статьи в блоге

База знаний SAFe® на русском языке - статьи, кейсы, глоссарий
База знаний структурирована по ключевым темам — от основ Lean‑Agile и компетенций до уровней Портфеля, Крупного Решения, Поезда (ART) и Agile команды, а также включает универсальные техники для всех уровней, описания ролей, кейсы внедрения SAFe и глоссарий.
Дисциплина «Командная и Техническая Гибкость»
Дисциплина "Командная и Техническая гибкость" в SAFe: основные компетенции для развития дисциплины, что входит в дисциплину и как её измерять.
Итерация Инноваций и Планирования (IP Iteration)
Что такое IP-Итерация? Для чего используется и какие преимущества даёт? Календарь Итерации Инноваций и Планирования.