СМА — модель разработки программного обеспечения¶

СМА (англ. Scaled Agile Framework, SAFe) — масштабируемый гибкий фреймворк, описывающий набор организационных и процессных практик для гибкой разработки программного обеспечения на уровне крупных предприятий. Фреймворк объединяет принципы гибкой разработки (Agile) с элементами бережливого производства (Lean) и описывает, как координировать работу нескольких десятков и сотен команд разработки с общими целями и сроками. СМА применяется преимущественно в IT-компаниях, банках, телекоммуникациях и промышленных предприятиях, где требуется одновременная координация множества продуктовых команд.

¶История создания

СМА был создан Дином Леффингуэллом (Dean Leffingwell), консультантом в области методологий разработки ПО и автором ряда книг по масштабированию Agile. Первые версии фреймворка появились в начале 2010-х годов как попытка систематизировать практики, которые крупные организации применяли при попытке масштабировать Scrum и XP на уровне всего портфеля продуктов. В 2011 году была опубликована первая версия Scaled Agile Framework, доступная в открытом виде на официальном сайте. Далее фреймворк развивался итеративно: выпускались новые релизы (2.5, 3.0, 4.0, 5.0, 6.0), добавлялись новые конфигурации и практики. Права на бренд и содержимое принадлежат компании Scaled Agile, Inc. (США), которая также проводит сертификационные программы для тренеров, консультантов и руководителей.

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

СМА описывает организацию работы на нескольких уровнях — от команды до портфеля продуктов:

• Командный уровень (Team Level). Работа ведётся небольшими кросс-функциональными командами, как правило, по методологии Scrum или Kanban. Команды планируют работу короткими итерациями (спринтами) длительностью 1–2 недели.
• Программный уровень (Program Level). Несколько команд объединяются в «агильную программу» (Agile Release Train, ART) — устойчивую виртуальную команду из 50–125 человек, которая поставляет ценность синхронными циклами «инкрементов программы» (Program Increment, PI) длительностью 8–12 недель. В начале каждого PI проводится общее планирование PI Planning.
• Портфельный уровень (Portfolio Level). Координация нескольких ART и стратегическое управление потоками ценности (Value Streams), бюджетирование и приоритизация инициатив.
• Уровень крупного бизнеса (Large Solution Level). Для решений, требующих координации нескольких портфелей и внешних поставщиков (например, в оборонной промышленности).

¶Ключевые роли

СМА вводит ряд специфических ролей, дополняющих привычные Agile-роли (Scrum Master, Product Owner, разработчик):

• Release Train Engineer (RTE) — «поездной инженер», координатор ART, отвечающий за PI Planning и устранение блокеров.
• Product Management — определяет содержание и приоритеты работ на уровне программы, управляет бэклогом ART.
• System Architect/Engineering — архитектор системы, отвечает за техническое видение и архитектурные решения.
• Business Owner — представители бизнеса, участвующие в планировании и оценке результатов.
• Lean Portfolio Management — руководство портфелем, стратегическое инвестирование и управление потоками ценности.

¶Основные практики и артефакты

Среди центральных практик СМА:

• PI Planning — крупное событие, на котором все команды ART совместно планируют работу на ближайший инкремент программы, формируют общую дорожную карту (Program Board) и фиксируют зависимости между командами.
• Innovation and Planning (IP) Iteration — итерация внутри PI, выделенная на инновации, обучение и подготовку к следующему планированию.
• System Demo — демонстрация интегрированного результата работы всех команд ART в конце каждого PI.
• Inspect and Adapt (I&A) — ретроспектива программы с анализом результатов и улучшением процессов.
• DevOps и Continuous Delivery Pipeline — практики непрерывной интеграции, тестирования и поставки.
• Lean UX — проектирование пользовательского опыта на основе быстрых экспериментов и обратной связи.
• Канбан потоков ценности — визуализация и управление потоком работ на уровне программы и портфеля.

¶Критика

СМА подвергается критике со стороны части Agile-сообщества за избыточную формализацию, бюрократизацию гибких практик и «тяжеловесность» процессов. Критики указывают, что в попытке описать координацию сотен людей фреймворк добавляет множество ролей, событий и артефактов, что может замедлять разработку и снижать гибкость. Сторонники СМА отмечают, что фреймворк допускает конфигурирование: он предлагает несколько профилей (Essential, Large Solution, Portfolio, Full), и организации могут применять только необходимый минимум практик.

¶Распространение

СМА широко применяется в крупных международных и российских компаниях. В России практики СМА внедряются в банках, телекоммуникациях и IT-подразделениях промышленных холдингов. Существует сертификационная экосистема Scaled Agile, Inc.: сертификаты SAFe Agilist (SA), SAFe Scrum Master (SSM), SAFe Program Consultant (SPC) и другие подтверждают знание фреймворка и дают право проводить трансформации по СМА. По данным опросов индустрии, СМА остаётся одним из наиболее распространённых масштабируемых Agile-фреймворков наряду с LeSS, Nexus и Spotify-моделью.

¶Источники

• Leffingwell D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. — Addison-Wesley, 2011.
• Leffingwell D., Wideman R. Agile Software Requirements: Lean Rules for Scaling Development. — Scaled Agile, Inc.
• Официальный сайт Scaled Agile Framework: scaledagileframework.com
• Knaster R., Leffingwell D. SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework. — Addison-Wesley, 2020.