Enablers (Энейблеры)
Обновлено: 28 ноября 2024
Enablers — это термин из методологии SAFe, который может переводиться на русский язык как «вспомогательные элементы». Под энейблерами понимаются задачи продуктового бэклога, которые расширяют возможности процесса разработки. Такие задачи могут быть представлены в бэклоге как эпики, фичи, или пользовательские истории. Энейблеры обеспечивают видимость работы, необходимой для эффективной разработки и реализации будущих бизнес-требований. Они используются для изучения идей, улучшения архитектуры и инфраструктуры решения, а также для обеспечения соответствия требованиям. Энейблеры незаметны для конечных пользователей, но при этом они важны для поддержания работоспособности системы. Хотя их тип уникален, они управляются аналогично элементам бэклога, ориентированным на клиента. К энейблерам относятся так же, как и ко всем остальным элементам бэклога — они подлежат видимости, приоритезации, постепенной реализации, измерению и обратной связи.
Назначение энейблеров
В качестве энейблеров можно использовать любые вспомогательные задачи, направленные на улучшение потока создания ценности. Согласно Scaled Agile, Inc., выделяются четыре категории Enablers по назначению:
- Исследовательские — поддерживают проведение исследований, разработку прототипов и других задач, необходимых для изучения потребностей клиентов, анализа альтернатив и поиска оптимальных решений;
- Архитектурные — обеспечивают плавное и быстрое развитие системы в рамках конвейера непрерывной доставки (CDP). Такие энейблеры направлены на поддержание системы, например, за счет повышения производительности;
- Инфраструктурные — улучшают и оптимизируют системы, используемые для разработки, тестирования, развертывания и эксплуатации решений;
- Комплаенс — обеспечивают автоматизацию аудитов и соответствие различным нормативно-правовым актам, системным требованиям.
- Enabler Epics (эпики) — создаются в формате утвержденной гипотезы. Эпики могут охватывать несколько Agile Release Trains (ARTs) и PI (Program Increments) и управляются через продуктовый бэклог;
- Enabler Features & Capabilities (фичи и возможности) — определяются в рамках ART и включают краткое описание, гипотезу о ценности и критерии приемки. Размер должен соответствовать одному PI;
- Enabler Stories (истории) — формулировка намерения пользователя и того, что продукт должен сделать для него. Задачи на уровне команды, которые должны вписываться в одну итерацию.
Ответственные лица
В работе с энейблерами в рамках методологии SAFe задействованы различные специалисты:
- Архитекторы — играют ключевую роль в определении и направлении Enabler Epics, Enabler Features и Enabler Capabilities;
- Agile-команды — также используют энейблеры. Enabler Stories возникают на локальном уровне из потребностей и попадают в бэклог команд;
- Владельцы продукта — участвуют в планировании ART и демонстрациях системы, подтверждая соответствие энейблеров бизнес-целям;
- Клиенты и конечные пользователи — вовлекаются в процесс валидации энейблеров, чтобы подтвердить, что создаваемое решение соответствует их потребностям.
Отличия от других элементов
Хотя энейблеры управляются по тем же принципам, что и другие элементы бэклога (видимость, приоритезация, итеративная реализация, измерение и обратная связь), есть ряд отличий:
- Ориентация на потенциал решения, а не на непосредственное предоставление ценности клиенту. В то время как обычные элементы бэклога нацелены на создание функциональности, видимой для конечного пользователя, Enablers фокусируются на улучшении архитектуры, инфраструктуры и прочих возможностей, необходимых для поддержки будущих бизнес-требований;
- Большее влияние на долгосрочную эффективность. Ценность Enablers может быть менее очевидной для конечных пользователей, но их эффект на производительность, масштабируемость и адаптивность системы в долгосрочной перспективе может быть существенным;
- Более тесная связь с архитектурными решениями. Энейблеры тесно связаны с архитектурными решениями и требуют совместной работы архитекторов и Agile-команд.
Приоритизация энейблеров
Энейблеры требуют особого внимания при приоритизации и формировании бэклога, так как обеспечивают критически важные, основополагающие технологии и понимание потока создания ценности, однако важно соблюдать баланс.
Энейблеры должны внедряться быстро и итеративно, чтобы не задерживать предоставление ценности для пользователей. При этом крупные архитектурные и инфраструктурные энейблеры часто нуждаются в долгой тщательной проработке и могут потребовать временной остановки системы.
Поэтому при приоритизации энейблеров важно учитывать:
- Критичность для поддержки будущих бизнес-требований;
- Возможность поэтапного внедрения без остановки системы;
- Соотношение ожидаемой ценности и затрат на реализацию.
Гибкий подход к внедрению Enablers, разбивка их на более мелкие итерации, а также тесная совместная работа архитекторов и Agile-команд помогают найти оптимальный баланс между скоростью доставки ценности и необходимыми инвестициями в технологическую основу.
Простой пример использования Enablers в ИТ-проекте
Команда разрабатывает мобильное приложение для управления личными финансами, одна из функций которого — синхронизация данных между устройствами пользователя.
В ходе работы команда понимает, что для реализации надежной и эффективной синхронизации им требуется новая серверная архитектура. Текущая архитектура не справляется с нагрузкой и не обеспечивает должного уровня безопасности. Для решения этой задачи команда определяет следующий список энейблеров:
Enabler Epic
«Создать масштабируемую и безопасную серверную архитектуру для синхронизации данных»
- определяет общие цели и гипотезы для этого архитектурного улучшения;
- управляется архитекторами, которые обеспечивают видимость и приоритизацию в портфеле.
Enabler Features
- Высокопроизводительная система кэширования;
- Шифрование и аутентификация данных;
- Распределенное хранилище данных.
- определяют конкретные архитектурные компоненты, необходимые для реализации эпика;
- управляются архитекторами совместно с командами разработки.
Enabler Stories
«Как системный инженер, я хочу настроить горизонтальное масштабирование Redis-кластера, чтобы обеспечить высокую производительность кэширования»
«Как инженер по безопасности, я хочу интегрировать AWS KMS для шифрования данных пользователей в полете и хранении»
«Как DevOps-инженер, я хочу автоматизировать разворачивание и мониторинг распределенного хранилища данных на базе Cassandra»
- определяют конкретные требования специалистов по реализации архитектурных возможностей;
- управляются командами разработки, DevOps и системными инженерами.
Описанные энейблеры не приносят непосредственной пользы пользователям, но создают надежную технологическую основу для дальнейшего развития приложения.