Enablers (Энейблеры)
Обновлено: 7 октября 2024
Назначение энейблеров
В качестве энейблеров можно использовать любые вспомогательные задачи, направленные на улучшение потока создания ценности. Согласно 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 и системными инженерами.
Описанные энейблеры не приносят непосредственной пользы пользователям, но создают надежную технологическую основу для дальнейшего развития приложения.