SAFe в Agile: что это такое и как его использовать
2026-02-21 00:51 Diff
https://skillbox.ru/media/code/safe/

#статьи

  • 23 дек 2025
  • 0

Используем гибкие методологии в больших командах.

Иллюстрация: Катя Павловская для Skillbox Media

Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

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

В таких ситуациях помогает Scaled Agile Framework (SAFe) — это фреймворк для масштабирования Agile на уровне большой компании. Он подробно описывает роли, процессы и практики, которые позволяют десяткам команд работать согласованно и успешно завершать каждый спринт.

В этой статье мы разберёмся в том, в каких случаях SAFe действительно нужен, как он устроен и каких результатов можно добиться при его внедрении. А помогут нам в этом Agile-коуч и CEO ScrumTrek Иван Дубровин и CAO Kaiten Егор Ткачёв.

Содержание

Эксперт

Agile-коуч и CEO ScrumTrek

SAFe — не универсальный фреймворк для управления разработкой ПО, который подойдёт любой компании. Эксперты выделяют несколько условий, при которых он может быть полезен:

  • большое количество команд, задействованных в работе;
  • сложное программное обеспечение, состоящее из тесно связанных элементов, которые разрабатываются параллельно;
  • высокая степень неопределённости.

Разберём каждый из этих пунктов подробно.

Если над продуктом одновременно работает сотня и более человек, стандартные гибкие методологии, например Scrum или Kanban, начинают давать сбои. Команды эффективно закрывают свои спринты, но общий фокус размывается: стратегия не доходит до исполнения, релизы сдвигаются и растёт число конфликтов по приоритетам.

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

Если продукт или сервис состоит из множества частей, которые тесно связаны между собой, классическая Agile не подойдёт: команды будут опираться на собственные приоритеты, которые могут конфликтовать между собой. Как итог, выпускаются фичи, которые сейчас не нужны, а часть задач не может быть выполнена из-за того, что предварительные условия отсутствуют. Например, одна из команд не подготовила необходимую инфраструктуру.

Чтобы решить эту проблему, в SAFe предусмотрены «поезда» (ART — Agile Release Train), объединяющие отдельные команды в общую структуру с единым ритмом планирования и поставки.

SAFe помогает выстроить работу в условиях высокой неопределённости, когда требуется быстро проверять гипотезы и получать обратную связь от пользователей. В менеджменте это называют «запутанным доменом» (complex domain) — ситуацией, при которой невозможно заранее всё просчитать, и приходится корректировать решения по мере появления новых данных.

«Когда над одним продуктом работает больше сотни человек, у них общие цели, и условия быстро меняются — стоит рассмотреть SAFe».

Иван Дубровин, Agile-коуч и CEO ScrumTrek

Фактически SAFe подходит в тех ситуациях, когда компания упирается в потолок масштабирования: растёт количество зависимостей в продукте, стратегия теряется на уровне исполнения, а релизы срываются из-за разрозненности команд. Если этих проблем нет — вероятно, нет и потребности в SAFe.

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

Команда (Team) — уровень ежедневной деятельности. Команды планируют спринты, берут в работу задачи и совершают конкретные шаги, которые продвигают продукт вперёд и помогают выполнить цели «поезда». Горизонт планирования — одна итерация. Как правило, это 1-2 недели. Команда — базовая структура для классических фреймворков Agile.

Поезд (ART, Agile Release Train) — основной уровень координации в SAFe. Он объединяет несколько команд, которые двигаются по общему плану: у них есть понятная цель, синхронизированные итерации и согласованный график релизов. Горизонт планирования — несколько месяцев. Многие компании начинают внедрение SAFe именно с уровня ART и подключают следующие только по мере роста сложности продукта.

Решения (Solution Train) — уровень, который отвечает за координацию разработки и развития крупных продуктов, в создании которых участвуют несколько «поездов» (ART) и возможны внешние подрядчики (Supplier).

Основная задача уровня — построить единую архитектуру решения и синхронизировать планы отдельных «поездов», чтобы весь продукт функционировал как цельная система. Горизонт планирования — около 3–6 месяцев.

Портфель (Portfolio) — стратегический уровень. Здесь определяются приоритеты бизнеса, формируются крупные инициативы (эпики) и решается, какие направления приносят наибольшую ценность бизнесу. На уровне портфеля работают топ-менеджмент и владельцы компании. Горизонт планирования — месяцы и годы.

Давайте посмотрим на практическую реализацию уровней SAFe. Представим, что компания занимается разработкой транспортной цифровой платформы. Команды в ней создают и развивают отдельные модули — от мобильного приложения до веб-интерфейса и навигационных сервисов. Как реализован SAFe:

  • Team — это базовый уровень для любого Agile-подхода. На нём происходит планирование и реализация спринтов отдельными командами.
  • На уровне ART координируется работа отдельных команд, обеспечивая единый план релизов.
  • Solution Train будет необходим, когда к продукту подключатся внешние интеграторы, например поставщики карт, и потребуется выстроить общую с ними архитектуру решения.
  • На уровне Portfolio принимаются стратегические решения: расширять ли географию сервиса, менять ли модель монетизации, или запускать новые виды перевозок.
Четыре уровня SAFe
Изображение: Kaiten

Как и в других Agile-подходах, в SAFe работу рассматривают как поток — последовательное движение от идеи до поставки ценности. При этом каждая задача проходит свой жизненный цикл.

Чтобы поток не забивался элементами с низким приоритетом, в SAFe предусмотрена их проработка на двух уровнях:

  • Upstream — анализ ценности, формулирование гипотезы и проведение первичной оценки. Здесь задача проходит фильтр на полезность и адекватность.
  • Downstream — прошедшие отбор задачи попадают в реализацию. Команды берут их в план, оценивают и двигают по спринтам.

«Разделение на upstream и downstream помогает поддерживать порядок в потоке задач: в реализацию попадают только те инициативы, которые достаточно проработаны и имеют понятную ценность».

Егор Ткачёв, CAO Kaiten

Чтобы управлять большим объёмом работы, внутри Upstream и Downstream SAFe делит задачи по уровням рабочих элементов — от стратегических инициатив до конкретных задач команд. Это помогает видеть всю логику работы: как большая идея шаг за шагом превращается в конкретный результат.

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

Эпик разбивается на функциональные (Feature) и технические (Enabler) компоненты.

  • Feature (функциональный компонент) — это конкретная часть продукта, которая несёт для пользователя ценность и обычно реализуется в одном или нескольких спринтах. Например, это может быть экран авторизации в приложении, который позволяет пользователю ввести номер телефона и получить SMS-код для авторизации.
  • Enabler (технический компонент) обеспечивает реализацию фич, то есть включает в себя архитектуру, инфраструктуру и интеграции продукта. Например, интеграция с сервисом отправки SMS для реализации функции авторизации по номеру телефона.

Каждый компонент в итоге превращается в конкретную задачу, которая может быть взята в очередной спринт.

«Такое разграничение делает работу прозрачной: понятно, какая часть команды создаёт бизнес-ценность, а какая — поддерживает продукт и готовит его к будущим изменениям».

Егор Ткачёв, CAO Kaiten

Уровни рабочих элементов в SAFe
Скриншот: Kaiten / Skillbox Media

Чтобы понять, какие именно задачи брать в работу, в SAFe используется метод Weighted Shortest Job First (WSJF). Он помогает решить, что делать в первую очередь, когда идей больше, чем ресурсов. Благодаря ему команды выстраивают приоритеты в бэклоге и понимают, какие задачи дадут наибольший эффект для продукта.

Принцип WSJF простой: сравниваем ценность задачи и затраты на её решение. Формула выглядит так:

приоритет = стоимость промедления ÷ размер работы

Чем больше частное, тем раньше нужно брать задачу в работу. При этом все оценки переводят в числа:

  • Стоимость промедления — это показатель, который отражает, сколько ценности теряется, если отложить выполнение задачи. Он учитывает не только потенциальную пользу, но и то, насколько критично выполнить задачу именно сейчас.

    Сначала определяют ожидаемую ценность: вклад в выручку или экономию затрат, снижение рисков или улучшение пользовательского опыта. Затем — фактор времени: насколько задержка выполнения задачи снижает эффект от неё и влияет ли она на доступность вариантов развития продукта в будущем.

    Все параметры оценивают по одной шкале (например, от 1 до 20) и суммируют — так получается «стоимость промедления».

  • Размер работы команда оценивает в часах, стори-поинтах или других условных единицах трудозатрат.
  • После этого стоимость промедления делят на размер работы. Задачи с наибольшим значением оказываются выше в приоритете.

«Формулу WSJF не стоит воспринимать как нечто раз и навсегда заданное. Её можно и нужно подстраивать под реальность компании. Например, добавить критерий „актуальность сейчас“ — чтобы не упустить задачу, которая важна именно в этот момент, или „вклад в стратегию“ — если речь о фичах, которые помогут бизнесу через полгода. Формула — это инструмент для обсуждения, а не строгая математика.

Чтобы оценки были честными, хорошо работает система «арбитров»: за бизнес-ценность отвечает продуктовая команда, а за критичность времени — владельцы направлений. Тогда обсуждение превращается не в спор, а в диалог, где каждый отвечает за свою часть картины.

Если оценки разошлись слишком сильно, например один ставит 3, другой 20, и долго не получается сойтись во мнениях, — это сигнал, что чего-то не хватает. В таких случаях лучше просто отложить элемент, собрать нужных людей и вернуться к оценке позже».

Иван Дубровин, Agile-коуч и CEO ScrumTrek

Program Increment (PI) — это общий цикл работы для всех команд в SAFe, который длится 8–12 недель. Обычно это 4-5 спринтов. Смысл PI в том, чтобы команды двигались в одном ритме, понимали общие цели и видели, как их задачи связаны между собой.

PI-планирование — стартовая точка этого цикла работы. Обычно оно занимает два дня и требует участия всех членов одного ART («поезда»). За это время команды:

  • договариваются, кто что делает в ближайшие недели;
  • обсуждают между собой зависимости и риски;
  • оценивают, хватает ли ресурсов и где возможны перегрузки;
  • формулируют PI Objectives — цели отдельных команд и всего «поезда» на итерацию.

На выходе получается наглядная «доска программы» (program board): на ней видно, какие фичи делает каждая команда и как они связаны между собой. Такая визуализация помогает заранее снять конфликты по срокам и приоритетам, чтобы не «тушить пожары» в середине цикла.

После PI-планирования все команды двигаются по своим спринтам и регулярно показывают общий результат на демо. В конце цикла проходит встреча Inspect & Adapt — по сути, это большое ретро для всего «поезда»: команды вместе разбирают итоги цикла, находят проблемы и решают, что улучшить в следующем PI.

«Запустить первый „поезд“ (ART) в составе 70–150 человек можно примерно за полгода. Сначала идёт подготовка и обучение, потом первое PI-планирование, подведение итогов и настройка общего ритма. Дальше уже можно масштабировать: добавлять новые „поезда“ или переходить на уровень Large Solution».

Иван Дубровин, Agile-коуч и CEO ScrumTrek

Процесс планирования фич и энейблеров по итерациям в команде
Скриншот: Kaiten / Skillbox Media

SAFe не всегда работает так, как задумано. Возникающие проблемы часто повторяются между разными компаниями, и их можно объединить в четыре большие группы: отсутствие общего инкремента, сбор обратной связи не от пользователей продукта, технический долг, мешающий релизам, и низкая эффективность подхода в небольших командах. Рассмотрим каждый из этих пунктов подробно.

Нет общего инкремента, то есть работающей версии продукта, которую можно показать и протестировать. Возникает это из-за того, что команды работают параллельно, но не сводят результаты в единое целое. В этих случаях демо превращается в формальность, с показом отдельных элементов, а проблемы становятся заметны только на поздних этапах жизненного цикла ПО. Чтобы этого избежать, важно регулярно собирать общий результат команд и заранее договариваться о критериях готовности.

Обратная связь не от пользователей. Команды собирают метрики, которые описывают только процесс создания продукта: сколько задач выполнено, сколько спринтов закрыто и насколько соблюдены сроки. При этом нет показателей, отражающих реальную ценность создаваемого ПО для клиентов.

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

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

Небольшой масштаб компании. Когда команд мало и они заняты разными проектами, не связанными друг с другом, фреймворк приносит мало пользы и только усложняет процессы разработки. Например, если в компании работает 30–40 человек, обычно хватает базовой Agile.

Если компания опирается на SAFe, то есть команды работают согласованно, ориентируются на обратную связь от пользователей и развивают инженерные процессы, то фреймворк приносит ощутимый результат. По данным Scaled Agile, Inc., компании, развивающей эту методологию, можно ожидать следующие эффекты:

  • рост продуктивности на 20–50%;
  • повышение качества на 25–75%;
  • сокращение времени вывода продуктов на рынок на 30–75%;
  • рост вовлечённости сотрудников на 10–50%.

Посмотрим на один из кейсов — финансовую компанию из Дании. До внедрения SAFe путь от идеи до реализации мог занимать около 18 месяцев, а после перехода на фреймворк часть изменений удавалось завершить в пределах одного PI, то есть примерно за 10 недель. Компания также отмечает, что увеличилась точность и предсказуемость работы: около 70% из запланированного успешно реализовывалось.

Важно отметить, что SAFe не способен справиться со всеми сложностями в создании или развитии программного обеспечения. Но это инструмент, который помогает выстроить порядок работы там, где обычная Agile уже не справляется с масштабом.

Курс с трудоустройством: «Профессия Разработчик + ИИ» Узнать о курсе