Все статьи
Энейблеры в SAFe®
Дата: 27.08.2025
Энейблеры в SAFe® (Scaled Agile Framework®) используются для описания работы, необходимой для поддержки исследований, развития архитектуры и инфраструктуры, уточнения кода и ключевой инфраструктуры, а также обеспечения соответствия нормативным требованиям. Они управляются в соответствующем бэклоге в виде эпиков, возможностей, фич или историй. Несмотря на особенное назначение энейблеры обрабатываются и управляются так же, как и другие элементы бэклога, ориентированные непосредственно на клиентов.
Удача – это сочетание подготовки и возможности.
Энейблеры — это элементы бэклога, которые расширяют Архитектурную Полосу разрабатываемого решения или улучшают производительность потока разработки ценности.
Энейблеры используются для описания работы, необходимой для поддержки исследований, развития архитектуры и инфраструктуры, уточнения кода и ключевой инфраструктуры, а также обеспечения соответствия нормативным требованиям. Они управляются в соответствующем бэклоге в виде эпиков, возможностей, фич или историй. Несмотря на особенное назначение энейблеры обрабатываются и управляются так же, как и другие элементы бэклога, ориентированные непосредственно на клиентов.
Содержание
Что такое энейблеры?
Энейблеры — это работа, необходимая для разработки и поставки будущих бизнес-требований. Команды используют их для исследования идей, улучшения архитектуры, укрепления инфраструктуры и управления соответствием нормативным требованиям. Поскольку Enabler создают конкретные результаты, они должны быть видимыми и управляться так же, как другие элементы бэклога. Как правило, они подразделяются на одну из четырех категорий:
- Exploration (Исследование) – исследования, прототипирование и другие действия, необходимые для понимания потребностей клиентов, включая анализ возможных решений и оценку альтернатив.
- Architecture (Архитектура) – расширение архитектурной полосы (Architectural Runway), обеспечивающее более плавную и быструю разработку через конвейер непрерывной поставки (Continuous Delivery Pipeline, CDP).
- Infrastructure (Инфраструктура) – создание и улучшение среды разработки и эксплуатации в части систем, используемых для сборки, тестирования, развертывания и управления решениями.
- Compliance (Нормативные требования) — управление активностями, связанными с нормативными требованиями, включая Verification and Validation (V&V), аудиты, утверждения и автоматизацию политик.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, вступайте в сообщество SAFe® Russia.
Как определяются и описываются энейблеры?
Энейблеры — распространенный элемент в SAFe. Они формулируются и приоритизируются по тем же правилам, что Epics, Features, Capabilities и Stories:
- Энейблер-эпики (Enabler Epics) похожи на бизнес-эпики и оформляются с помощью декларации гипотезы эпика (Epic Hypothesis Statement). Они могут охватывать несколько Agile Release Trains (ARTs) и PI (Planning Interval), управляясь через Бэклог Портфля (Portfolio Backlog) и связанную Kanban-систему.
- Энейбер-фичи (Enabler Features) и энейблер-возможности (Enabler Capabilities) определяются несколькими ART и Solution Trains, включая краткое описание, гипотезу выгоды (Benefit Hypothesis) и критерии приемки (Acceptance Criteria). Они должны умещаться в один PI.
- Энейблер-истории (Enabler Stories) должны вписываться в итерацию, как и любые другие истории. Хотя они могут не требовать формата «пользовательской истории», их критерии приемки четко определяют требования и поддерживают тестирование.
Архитекторы (Enterprise Architects, System Architects, Solution Architects) часто определяют и направляют работу с Enabler, проводя их через соответствующие Kanban-системы и бэклоги.
Исследовательские энейблеры
Исследовательские энейблеры используются для изучения требований и анализа вариантов проектирования. В процессе разработки продуктов и решений многие требования изначально имеют изменчивую природу. На ранних этапах команды часто не до конца понимают, что именно нужно клиенту и как это реализовать. При этом сами клиенты не всегда могут четко сформулировать свои потребности.
Благодаря непрерывному исследованию (Continuous Exploration) команды постепенно определяют, какие аспекты продукта или Solution Intent должны перейти из изменчивого (вариативного) состояния в фиксированное.
Обычно существует несколько технических вариантов реализации бизнес-потребности, и важно проанализировать их все. Распространенные методы оценки включают:
- моделирование;
- прототипирование;
- Set-Based Design (вариативное проектирование);
- применение цикла Lean Startup.
Исследовательские энейблеры помогают организовать и структурировать эти активности. Они визуализируют работу и обеспечивают соответствие результатов исследования потребностям клиентов и заинтересованных лиц.
Архитектурные энейблеры
Архитектурная полоса (Architectural Runway) включает существующий код, компоненты и инфраструктуру, необходимые для реализации ближайших фич (Features) с минимальными переделками и задержками. Она обеспечивает Agile-командам и ART возможность быстро поставлять продукты и решения без лишних простоев.
Однако, новые эпики, фичи, возможности и истории постоянно «нагружают» эту полосу. Архитектурные энейблеры помогают расширять её, подготавливая основу для будущей функциональности.
Кроме того, они решают проблемы устойчивости (resiliency) уже развернутых решений. После реализации такие энейблеры часто трансформируются в нефункциональные требования (Non-Functional Requrements, NFRs), которые становятся ограничениями для будущих элементов бэклога.
NFRs нередко начинаются как архитектурные энейблеры, а со временем развиваются в полноценные требования.
Инфраструктурные энейблеры
Agile-разработка требует частой интеграции. Agile-команды регулярно интегрируют свою работу и демонстрируют рабочий инкремент на системной демонстрации (System Demo). Аналогично, несколько ART в рамках Solution Train интегрируют свои решения как можно чаще в течение PI, готовясь к демонстрации решения (Solution Demo).
Инфраструктурные энейблеры обеспечивают технологии для непрерывной интеграции и поставки (Continuous Integration/Deployment, CI/CD), поддерживая эти регулярные точки интеграции. Системная команда (System Team) играет ключевую роль в определении и создании таких энейблеров, которые улучшают среду разработки и оптимизируют конвейер непрерывной поставки.
Общие сервисы (Shared Services), операционные команды и специалисты по обеспечению бесперебойной работы сервисов (Site Reliability Engineering, SRE) используют инфраструктурные инструменты для предоставления облачных сервисов. Это ускоряет разработку и упрощает масштабирование решений.
Энейблеры нормативных требований
В SAFe процесс непрерывной верификации и валидации (V&V) обеспечивается за счет создания необходимых артефактов Solution Intent на протяжении нескольких PI. Эти активности являются частью рабочего процесса разработки и часто закрепляются в критериях готовности (Definition of Done, DoD). Соответствующие артефакты создаются на протяжении всего жизненного цикла разработки, гарантируя соответствие требованиям к доказательной базе к моменту завершения процесса.
Валидация происходит при участии владельцев продуктов (Product Owners), заказчиков и конечных пользователей на PI-планировании и системных демонстрациях, где подтверждается соответствие решения целевому назначению. Энейблеры поддерживают эти процессы.
Например, рассмотрим нормативное требование о проведении дизайн-ревью с обязательной фиксацией принимаемых решений. Элемент бэклога «design review enabler» будет предоставлять доказательства проведения такого ревью. Его критерии готовности гарантируют, что все решения сохранены и реализованы в соответствии с Lean Quality Management System (Lean QMS). При необходимости эти активности могут отслеживаться как энейблер-стори.
Как реализуются энейблеры инкрементально?
Энейблеры формируют критически важную основу для эффективной разработки продуктов и решений. Следовательно, они требуют особого внимания на уровне портфеля в вопросах бюджетирования и распределения ресурсов. Однако, поскольку их ценность связана с перспективными бизнес-целями, крайне важно реализовывать их быстро и итеративно. В противном случае поставка ценности для клиентов может задерживаться, что подрывает саму цель энейблера.
Энейблеры улучшают экономику разработки, создавая технологические платформы для оптимальной бизнес-функциональности. Однако, инновационная разработка продуктов невозможна без принятия рисков. Поэтому первоначальные технологические решения не всегда оказываются верными. Именно поэтому организации Lean-Agile должны быть готовы периодически корректировать курс. В таких случаях особенно полезен принцип невозвратных затрат: не учитывайте уже потраченные средства. Инкрементная реализация позволяет вносить корректировки до того, как инвестиции станут слишком большими.
Все типы энейблеров следует реализовывать инкрементально. Однако, поскольку архитектурные и инфраструктурные энейблеры могут влиять на поставку и работу критически важных решений, они требуют дополнительного руководства.
Масштаб и сложность работ по архитектурным и инфраструктурным энейблерам часто оказываются значительными. Ключевой подход заключается в их декомпозиции на фичи и истории для поэтапной реализации. Однако, эта задача сопряжена с определёнными трудностями:
- Проблема совместимости: изменения в архитектуре и инфраструктуре могут временно нарушать работу существующей системы.
- Требование к планированию: необходима тщательная последовательность внедрения изменений.
- Обеспечение непрерывности: важно сохранять работоспособность текущей системы в процессе реализации.
Критически важные аспекты:
- Поддержка непрерывной работы команд.
- Возможность регулярной интеграции изменений.
- Проведение демонстраций функциональности.
- Сохранение способности выпускать новый функционал.
Такой подход позволяет минимизировать риски при внедрении масштабных архитектурных изменений, сохраняя при этом возможность непрерывной поставки ценности.
Существует три подхода к реализации:
- Сценарий А — энейблер масштабный, но реализуется инкрементально. Система остается работоспособной на всех этапах.
- Сценарий B — энейблер масштабный и не поддается инкрементной реализации. Системе потребуются временные остановки.
- Сценарий C — энейблер очень крупный и не может быть реализован по частям. Система функционирует только в запланированные периоды.
Пример инкрементальных подходов: устаревшие системы постепенно выводятся из эксплуатации с использованием методов захвата активов (asset capture) и перехвата событий (event interception).
Эпики и энейблер-возможности могут охватывать несколько потоков создания ценности (value streams) или Agile Release Trains (ARTs). На этапе анализа в соответствующей системе Канбан важно определить: реализовывать энейблер во всех ART одновременно или поэтапно.
- Сценарий А: если уровень неопределенности, воздействия на существующие системы и общий риск высоки, то разумным выбором будет поэтапная реализация.
- Сценарий B: если затраты на задержку неприемлемо высоки, то энейблеры могут реализовываться одновременно во всех ART (пример: новое нормативное требование).
В сценарии А энейблер сначала внедряется в ART 1, а затем в других ART в последующих PI. Это может снизить влияние изменений на портфель, но задерживает получение всех преимуществ полностью реализованного энейблера. В отличие от этого, сценарий B предполагает одновременное внедрение энейблера во всех ART. Если задержка реализации неприемлема по стоимости, этот подход предпочтительнее.
