Essential SAFe

28 июля 2022

Простота – искусство максимизации объема невыполняемой работы – крайне необходима.

Манифест Гибкой Разработки (Agile Manifesto)
Манифест Гибкой Разработки (Agile Manifesto)

В своей работе я регулярно сталкиваюсь с точкой зрения, что Scaled Agile Framework (SAFe) достаточно сложен для понимания, поскольку там «очень много всего». Это справедливо только отчасти, поскольку SAFe это фреймворк масштабирования для любого объёма разработки, в том числе, когда речь идет об участии в Разработческих потоках ценности тысяч и тысяч человек, работающих над разными продуктами, что само по себе может быть очень непростой управленческой задачей.

Но, с другой стороны, SAFe не требует, как некоторые другие Agile подходы, строгого соблюдения всех 100% своих техник и практик, так как они не всегда и не всем нужны на практике. В результате можно говорить о том, что сам SAFe фреймворк масштабный, и минимальный масштаб, который называется «Essential SAFe (Базовый SAFe)», содержит достаточно простой набор элементов.

Используется Базовый SAFe (Essential SAFe), когда стоит задача организовать (во фреймворке используется глагол «to align» или «выравнять», «со-направить») относительно небольшое количество команд вокруг разработки одного или группы связанных продуктов для существующей организации со своим ИТ-ландшафтом.

Базовый SAFe (Essential SAFe) содержит готовую модель управления для создания одного или нескольких не связанных между собой объединений команд, «команды команд», которые фреймворк именует «Релизный Поезд Agile (Agile Release Train, ART)». Ниже представлен неофициальный перевод статьи SAFe, описывающий все элементы этой минимальной конфигурации.

По нашему опыту, конфигурация Базовый SAFe (Essential SAFe) становится работоспособной без излишних накладных расходов от 3 Agile команд и выходит на максимальную эффективность, когда в Поезде совместно работают от 5 до 12 Agile команд (размер команды при этом ограничивается рекомендацией Скрама – до 11 человек включительно, считая Владельца Продукта и Скрам Мастера). — Алексей Ионов, Executive LeanAgile коуч.

Что такое Essential SAFe (Базовый SAFe)?

Базовый SAFe (Essential SAFe)
Рисунок 1. Базовый SAFe (Essential SAFe)

 

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

Релизный Поезд Agile (Agile Release Train, ART) является «сердцем» Базового SAFe. Релизные Поезда — это виртуальные организации, созданные для того, чтобы преодолеть функциональные границы, исключить ненужные действия и возникающие при передаче информации сложности, а также чтобы ускорить доставку ценности путем использования принципов и практик SAFe на основе Lean-Agile мышления.

Конфигурация Базового SAFe (рисунок 1) включает в себя следующие группы концепций:

Группа 1: Три основные компетенции.

Компетенция описывает критически важные навыки, а также Lean-Agile принципы и практики, которые высокопроизводительные Agile-команды и команды Agile-команд используют для создания высококачественных Решений для своих клиентов.

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

Компетенция описывает, как Lean-Agile лидеры стимулируют и поддерживают организационные изменения и операционное совершенство, предоставляя сотрудникам и командам возможность реализовать свой самый высокий потенциал.

Группа 2: Набор ролей, артефактов и событий основной конфигурации фреймворка, необходимых для Базового SAFe.

Группа 3: Минимальная перекрывающая палитра практик и техник, которые многократно применимы на всех масштабах этой конфигурации (человек, команда, поезд), включающая в себя Видение, Дорожные Карты и Команду Системы.

 

Essential SAFe является отправной точкой для запуска Scaled Agile Framework® (SAFe).  Кроме этого, существует десять критически важных факторов успеха SAFe трансформации. Их соблюдение в организации необходимо для того, чтобы Релизный Поезд Agile (Agile Release Train, ART) смог реализовать большинство преимуществ фреймворка (см. последний раздел этой статьи).

Essential SAFe состоит из соответствующих ролей, артефактов, событий и мышления, которые позволяют Релизным Поездам Agile доставлять одно или несколько желаемых (востребованных), осуществимых, жизнеспособных и устойчивых Решений или частей Решения.

Долговременная, основанная на потоке, самоорганизующаяся сущность Поезда (Agile Release Train, ART) — это то, что «питает» SAFe и в итоге обеспечивает гибкость бизнеса (business agility). Многие поезда являются виртуальными конструкциями, охватывающими организационные и географические границы. Другие встраиваются в структуру управления по направлениям бизнеса или продуктовую линейку.

Основные концепции

Key concepts of Essential SAFe

Основные концепции Базового SAFe (Essential SAFe) включают в себя:

  • Релизный Поезд Agile (Agile Release Train, ART) – это долгосрочная команда Agile-команд, которая вместе с другими заинтересованными лицами инкрементально разрабатывает, доставляет и, где это применимо, эксплуатирует и поддерживает одно или несколько Решений, относящихся к данному потоку создания ценности.
  • Конвейер Непрерывной Доставки (Continuous Delivery Pipeline)описывает рабочие процессы, действия и автоматизацию, необходимые для обеспечения постоянного выпуска ценности для конечного пользователя.
  • Клиентоцентричность (Customer Centricity) это мышление и способ ведения бизнеса, который фокусируется на создании положительного опыта для клиента. Пример — путь клиента, который ведет покупателей через полный спектр продуктов и услуг, предлагаемых предприятием.
  • Дизайн-Мышление (Design Thinking)это клиентоцентричный процесс разработки. Он позволяет создавать желаемые продукты, которые являются прибыльными и устойчивыми на протяжении всего их жизненного цикла.
  • Инкремент Программы (Program Increment, PI)это временной интервал, в котором Релизный Поезд Agile инкрементально доставляет ценность. Инкремент Программы (PI) обычно длится от 8 до 12 недель. Наиболее распространенной моделью для PI является Инкремент Программы в 5 Итераций: четыре итерации разработки, за которыми следует одна Итерация Инноваций и Планирования (IP Итерация).
  • Итерации (Iterations)это фиксированный интервал времени, который обеспечивает каденцию (ритм) разработки для Agile команд, создающих фичи и компоненты. Каждая итерация доставляет инкремент ценности новой функциональности. («Итерация» — термин Экстремального Программирования, XP, Скрам в свою очередь использует термин «Спринт»; оба термина можно использовать как смысловые синонимы.)
  • Итерация Инноваций и Планирования (Innovation and Planning «IP» Iteration) – предоставляет командам возможность для исследований и инноваций, выделенное время для планирования и обучения, которое может обеспечиваться как формальными, так и неформальными мероприятиями.
  • ScrumXP это легковесный процесс для Agile команд, позволяющий непрерывно доставлять ценность. ScrumXP использует фреймворк Скрам (Scrum) для управления командой и их работой, а также практики обеспечения качества, основанные на XP.
  • Канбан Команды (Team Kanban)это бережливый метод, который помогает командам повысить эффективность внутреннего потока ценности путем визуализации рабочего процесса, установления ограничений для незавершенной работы (Work in Process, WIP), измерения пропускной способности и постоянного улучшения своего процесса.
  • Встроенное Качество (BuiltIn Quality) – обеспечивает, что каждый инкремент решения сразу является высококачественным и может легко адаптироваться к изменениям.
  • DevOpsэто мышление, культура и набор технических практик. DevOps обеспечивает коммуникацию, интеграцию, автоматизацию и тесное сотрудничество между всеми людьми, которые необходимы для планирования, разработки, тестирования, развертывания, выпуска и обслуживания системы.

Роли

Essential SAFe roles

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

Роли Agile Release Train (ART)

  • Продуктовый Менеджмент (Product Management) – является внутренним голосом клиента и работает с клиентами и Владельцами Продукта (Product Owner). Основные задачи: понять потребности клиентов, сообщить о них Владельцам Продукта, определить необходимые функции системы и участвовать в валидации результатов. Они несут ответственность за Беклог Программы.
  • Архитекторы / Инженеры Систем (System Architect/Engineering)это отдельная или небольшая междисциплинарная команда, которая действительно применяет Принцип No 2 — «Применять системное мышление». Архитекторы/Инженеры определяют общую архитектуру систем, помогают выявить нефункциональные требования (NFR), установить важные элементы и подсистемы, а также помогают проектировать интерфейсы и взаимодействия между ними.
  • Инженер Релизного Поезда (Release Train Engineer, RTE) – является лидером-слугой и главным Скрам-мастером поезда. RTE фасилитирует оптимизацию потока ценности, обеспечивая правильное проведение мероприятий Поезда (например, Инспект-Адапт/Inspect & Adapt (I&A), Синхронизация Поезда, PI Планирование) и эффективное применение артефактов поезда (например, Канбан Программы).
  • Владельцы Бизнеса (Business Owners)представляют собой небольшую группу заинтересованных лиц, которые несут бизнес и техническую ответственность за решение, которое разрабатывается Поездом. В частности, они отвечают за пригодность Решения для использования, управление и окупаемость инвестиций (ROI). Владельцы Бизнеса являются основными стейкхолдерами Agile Release Train и активно участвуют в мероприятиях Поезда.

Роли Agile Команды

  • Agile Команды (Agile Teams) – это кросс-функциональные группы из 5-11 человек, которые могут определять, разрабатывать, тестировать и развертывать инкремент ценности за короткий промежуток времени. Каждый Agile Release Train состоит из 5–12 Agile команд и включает в себя роли и инфраструктуру, необходимые для доставки полностью работающих и протестированных бизнес-решений.
  • Владелец Продукта (Product Owner, PO) – отвечает за содержание беклога команды, а также за определение историй и расстановку приоритетов в беклоге.
  • Скрам Мастер (Scrum Master) – является лидером-слугой и коучем agile-команды. Скрам Мастер помогает команде устранять препятствия, фасилитирует командные мероприятия и способствует созданию среды для высокоэффективных команд.

Мероприятия

Essential SAFe events

В Essential SAFe включены разные мероприятия, которые помогают координировать поезда и команды.

Мероприятия Agile Release Train (ART)

  •  Планирование Инкремента Программы (PI Планирование, PI Planning) – это мероприятие по планированию, основанное на каденции и личном общении. PI Planningявляется сердцебиением Agile Release Train и выравнивает все команды в поезде в соответствии с общей миссией.
  • Демонстрация Системы (System Demo) – обеспечивает интегрированное представление новых фич, которые были доставлены всеми командами поезда за самую последнюю итерацию. Каждая демонстрация предоставляет заинтересованным лицам Agile Release Train объективную оценку прогресса во время Инкремента Программы (PI).
  • Инспект-Адапт (Inspect & Adapt) – является важным мероприятием, на котором демонстрируется и оценивается текущее состояние решения. Затем команды анализируют результаты и проводят мастерскую по решению проблем (ProblemSolvingWorkshop). В рамках мастерской они определяют элементы улучшения и вносят их в свой беклог.
  • Синхронизация Скрам Мастеров (Скрам Скрамов, Scrum of Scrums) –мероприятие помогает координировать зависимости внутри Поезда и обеспечивает видимость прогресса и препятствий.
  • Синхронизация Владельцев Продукта (Product Owner (PO) Sync) – Мероприятие обеспечивает видимость того, насколько хорошо Agile Release Train продвигается к достижению целей Инкремента Программы на уровне Поезда. Po Sync также помогаетобсудить проблемы или возможности, связанные с разработкой фич, а также оценить любые корректировки в области объема работ.
  • Синхронизация Поезда (ART Sync)объединяет 2 мероприятия поезда — Scrum of Scrums и PO Sync — в одно событие.

Мероприятия Agile Команды

  • Планирование Итерации (Iteration Planning) – это мероприятие, на котором Agileкоманда определяет цели итерации и те элементы беклога, за выполнение которых она берет на себя обязательства на предстоящую итерацию. Емкость команды определяет количество историй и энейблеров, которые берутся в Итерацию.
  • Выполнение Итерации (Iteration Execution) – это то, как Agile команда разрабатывает инкремент высококачественной, работающей, протестированной системы в рамках установленного временного периода (Итерации).
  • Обзор Итерации (Iteration Review)мероприятие на основе каденции проходит в конце каждой итерации. На нем команда просматривает результаты предыдущего инкремента и корректирует беклог команды на основе обратной связи.
  • Ретроспектива Итерации (Iteration Retrospective)это мероприятие проводится в конце итерации для Agile команды. Цель — проанализировать свои практики и определить способы улучшения. Ретроспектива основана на качественной и количественной информации, которая была представлена на мероприятии «Обзор Итерации».
  • Уточнение Беклога (Backlog refinement) – это мероприятие проводится один или два раза за время итерации для уточнения, рассмотрения и оценки будущих историй и энейблеров в беклоге команды.

Артефакты

 

SAFe basic configuration - artefacts

Следующие элементы Базового SAFe (Essential SAFe) помогают координировать Релизный Поезд (Agile Release Train) и его команды.

Артефакты Agile Release Train (ART)

  • Фичи (Features) — это сервисы, которые удовлетворяют потребности заинтересованных лиц. Каждая из них имеет название, гипотезу выгоды и критерии приемки. Их разработка должна умещаться в Инкремент Программы (PI).
  • Фичи Энейблеры (Enabler Features)поддерживают действия, необходимые для расширения Архитектурного Русла. Основная цель Фич Энейблеров — обеспечить разработку будущих бизнес-фич. Фичи Энейблеры бывают 4-х типов: исследования, архитектура, инфраструктура и соответствие регуляторным требованиям.
  • Эпики Программы (Program Epics) — это эпики, которые может доставить один поезд (Agile Release Train, ART) и которые не управляются на уровне Портфеля (LPM).
  • PI Цели Программы (Program PI Objectives)описывают конкретные бизнес и технические цели, которые Agile Release Train намерен достичь в предстоящей Инкремент Программы (PI).
  • Беклог Программы (Program Backlog) – это место хранения будущих Фич, которые предназначены для удовлетворения потребностей пользователей и доставки бизнес-преимуществ для одного Релизного Поезда Agile (Agile Release Train). Беклог Программы также содержит Фичи Энейблеры, необходимые для создания Архитектурного Русла.
  • Канбан Программы (Program Kanban)управляет потоком фич и энейблеров через Конвейер Непрерывной Доставки.
  • Видение (Vision) это описание будущего состояния разрабатываемых решений. Видение отражает потребности клиентов и заинтересованных лиц, а также фичи, предлагаемые для их удовлетворения.
  • Дорожная Карта (Roadmap)это расписание событий и вех (ключевых дат развития Решения), которое дает необходимую информацию о запланированных результатах Решения относительно шкалы времени в масштабе соответствующей карты. Дорожные карты SAFe существуют во многих масштабах и могут представлять собой каскадную модель с точки зрения вложенности.
  • Архитектурное Русло (Architectural Runway)состоит из существующего кода, компонентов и технической инфраструктуры, которые необходимы для поддержки ближайшей реализации приоритетных фич в самые короткие сроки, без чрезмерного редизайна и задержек.
  • Решение (Solution) это продукт, услуга или система, которые Релизные Поезда Agileдоставляют клиентам, как внутренним, так и внешним по отношению к предприятию.
  • Контекст Решения (Solution Context)описывает, как система будет взаимодействовать, упаковываться и развертываться в своей операционной (окружающей, внешней) среде.
  • Команда Системы (System Team) – это специализированная Agile-команда, которая помогает в создании и поддержке среды (платформы) гибкой разработки. Как правило, это включает в себя разработку и обслуживание комплекса инструментов, которые поддерживают конвейер непрерывной доставки в работоспособном состоянии.

Артефакты Agile команды

  • Истории (Stories) – являются средством, которое доводит требования клиентов до реализации через поток создания ценности. Команды используют истории для создания ценности в рамках итерации. Владелец продукта имеет всю полноту полномочий по содержанию Историй и отвечает за создание и приёмку результатов разработки историй Agile Командой.
  • Истории Энейблеры (Enabler stories) – обеспечивают необходимую работу в части исследований, создания инфраструктуры, архитектурных элементов или обеспечения соответствия регуляторным требованиям (4 типа Энейблеров SAFe), которая необходима для другой Истории или Фичи в целом.
  • PI Цели Команды (Team PI objectives) – это краткое описание конкретных бизнес- и технических целей, которые конкретная Agile команда намерена достичь в предстоящий Инкремент Программы (PI).
  • Цели Итерации (Iteration goals)являются результом мероприятия «Планирование Итерации». Цели Итерации представляют собой высокоуровневую сводку бизнес- и технических целей, за выполнение которых команда отвечает в рамках предстоящей Итерации. Они помогают обеспечить согласованность с PI Целями Команды и их достижение в конечном итоге.
  • Беклог команды (Team backlog)состоит из пользовательских (бизнес) Историй и Историй Энейблеров. Большинство историй определяются в ходе двух мероприятий: PIПланирование и Уточнение Беклога. Многие истории в своем предварительном виде прорабатываются командами при подготовке к будущему PI Планированию.

Десять важнейших факторов успеха Agile Release Train

Scaled Agile Framework доказал свою способность к масштабированию в любых ситуациях, от разработки сложного (комплексного) программного обеспечения и систем до торговли облигациями, от производства медицинских устройств до разработки чипов памяти и создания истребителей. Но с таким хорошо проработанным фреймворком возникает вопрос: в каком объёме и насколько строго организация должна следовать практикам Базового SAFe (Essential SAFe), чтобы получить желаемый результат?

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

Чтобы избежать проблем и получить ответ на вопрос о соответствии или не соответствии необходимому минимальному набору требований, Базовый SAFe (Essential SAFe) включает в себя десять критически важных факторов успеха Релизного Поезда Agile (рисунок 2). Вы можете оценить, на сколько ваше использование Базового SAFe соответствует каждому из этих 10 факторам, сделать соответствующие выводы и принять необходимые решения по улучшению ситуации.

10 факторов успеха Agile Release Train
Рисунок 2. Десять важнейших факторов успеха Agile Release Train

#1 – LeanAgile Принципы

Практики SAFe основаны на фундаментальных Lean-Agile Принципах. По мере того, как организации переходят на SAFe, они непрерывно стремятся к улучшениям. И это позволяет им находить всё более эффективные способы работы.  Знание принципов направляет усилия по улучшению и гарантирует, что корректировки движутся к достижению «кратчайших устойчивых сроков выполнения (shortest sustainable lead time), с наилучшим качеством и максимальной ценностью для людей и общества».

#2 – Настоящие Agile Команды и Поезда

Настоящие Agile команды и Релизные Поезда Аgile (Agile Release Train) полностью кросс-функциональны. У них есть все и всё для создания работающего, протестированного инкремента решения. Они являются самоорганизующимися и самоуправляемыми, что позволяет ценности проходить по потоку быстрее, с минимальными накладными расходами. Agile команды, которые не могут определять, разрабатывать и тестировать свою работу сами, не являются настоящими Agileкомандами. Релизные Поезда, которые не могут доставить решения или полнофункциональную их часть, не являются истинными Agile Release Train.

#3 – Каденция и Синхронизация

Каденция задает ритм, который обеспечивает стабильное (устойчивое, ровное) сердцебиение для процесса разработки. Это позволяет обеспечить гарантированную регулярность выполнения для рутинных операций. Синхронизация позволяет одновременно понимать и принимать различные подходы и решения для большого количества разных участников потока. Например, синхронизация используется для объединения различных активов системы для оценки её жизнеспособности на уровне решения.

#4 – PI Планирование

Ни одно событие не является более значимым в SAFe, чем Планирование Инкремента программы (PI Planning). Оно обеспечивает ритм для Agile Release Train и связывает стратегию с выполнением, обеспечивая согласованность бизнеса и технологий. Выравнивание всего Релизного Поезда в соответствии с одинаково понятными всем целями и видением дает важную энергию, осмысленность и единое понимание задачи.

#5 – Клиентоцентричность, DevOps и Выпуск по Требованию

Предприятия SAFe создают положительный опыт для клиентов в рамках всего своего портфеля продуктов и услуг.  Они принимают мышление и культуру DevOps, применяют технические практики, чтобы обеспечить более частые и более качественные выпуски (релизы) в соответствии с требованиями рынка.  Эти методы обеспечивают более быструю проверку гипотез и приносят большую прибыль, обеспечивают повышенную вовлеченность сотрудников и создают более удовлетворенных клиентов.

#6 – Демонстрация Системы (System Demo)

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

#7 – ИнспектАдапт (Inspect and Adapt, I&A)

Инспект-Адапт (I&A) является важным событием, которое проводится каждый Инкремент Программы (PI). Это время для размышлений, сбора данных и решения проблем. Мероприятие собирает команды и заинтересованных лиц, чтобы оценить решение и определить, что нужно и можно улучшить. В течение I&A определяются конкретные действия, которые необходимы для повышения скорости, качества и надежности следующего Инкремента Программы (PI).

#8 – Итерация Инноваций и Планирования (IP Iteration)

Итерация инноваций и планирования (IP Итерация) происходит в рамках каждого Инкремента Программы (PI) и служит нескольким целям. Она действует как своего рода буфер для повышения уровня достижения Целей Инкремента Программы (PI Objectives) и предоставляет выделенное время для инноваций, непрерывного обучения, проведения таких мероприятий как PIПланирование (PI Planning) и Инспект-Адапт. (Inspect & Adapt).  Деятельность в рамках IP Итерациипозволяет реализовать многие принципы Lean-Agile, которые обеспечивают гибкость бизнеса.

#9 – Архитектурное Русло (Architectural Runway)

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

#10 – Lean-Agile Лидерство (Lean-Agile Leadership)

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

Статья подготовлена по материалам Scaled Agile, Inc.