SAFe (Scaled Agile Framework)

В 2014 году подразделение LEGO Digital Solutions, отвечавшее за цифровые продукты компании, упёрлось в типичную проблему роста: двадцать команд в Дании и Индии работали над связанными продуктами, но каждая планировала сама, зависимости всплывали в последний момент, а приоритеты руководства до команд доходили с искажениями. Компания выбрала SAFe (Scaled Agile Framework) и начала не с команд, а с руководителей: двадцать менеджеров прошли двухдневный курс Leading SAFe. Центром перехода стало совместное планирование всего поезда на квартал вперёд — PI Planning, которое в LEGO назвали «центром тяжести» трансформации. Консультант Хенрик Книберг, сопровождавший LEGO, в докладе 2015 года описал одно такое планирование: два дня, 19 команд, около 150 человек в одном пространстве, общая доска зависимостей «кто, что, от кого и к какому сроку ждёт» и правило «обязательство действительно, только если команда взяла его добровольно и оставила запас ёмкости на неопределённость». Наблюдаемые результаты — прозрачность, более ясные приоритеты, команды сами распределяют нагрузку. Главная названная трудность — поезд разрастается слишком сильно. Позже вице-президент корпоративного ИТ Хенрик Амсинк распространил подход на подразделения численностью более 500 человек.

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

Фреймворк не ускоряет одну команду — он устраняет потери между командами: несогласованные приоритеты, поздно обнаруженные зависимости и обещания, которые поезд не в состоянии выполнить.

Происхождение и исследовательская база SAFe (Scaled Agile Framework)

Леффингуэлл: от «большой картины» к фреймворку

Автор фреймворка — американский инженер и предприниматель Дин Леффингуэлл. В середине 2000-х он консультировал крупные компании, которые пытались перенести Scrum и XP с одной команды на сотни разработчиков, и рисовал для них «большую картину» — схему того, как работа течёт от управления продуктом через уровни программ и команд к клиенту. Впервые эти наблюдения изложены в книге «Scaling Software Agility: Best Practices for Large Enterprises» (2007). В 2011 году вышла книга «Agile Software Requirements», где «большая картина» обрела вид требований на трёх уровнях — портфель, программа, команда. В том же году Леффингуэлл вместе с Дрю Джемило опубликовал первую версию SAFe и основал компанию Scaled Agile, Inc., которая с тех пор развивает фреймворк, обучает и сертифицирует специалистов. После первого выпуска вышло шесть крупных версий; версия 6.0 опубликована в марте 2023 года.

Lean-линия: экономика потока Рейнертсена

Фреймворк не изобретает приоритизацию заново. Его формула WSJF и требование «принимать решения в экономических единицах» восходят к книге Дональда Рейнертсена «The Principles of Product Development Flow: Second Generation Lean Product Development» (2009). Рейнертсен ввёл в разработку продуктов понятие стоимости задержки (Cost of Delay) — сколько денег теряет компания за каждую неделю, на которую функция приходит позже, — и показал, что при ограниченной ёмкости оптимальная очередь строится по отношению стоимости задержки к длительности работы. Отсюда же взяты и другие принципы потока: ограничение незавершённой работы, малые партии, управление очередями, ритм и синхронизацию.

Agile-линия и системное мышление

Вторая опора — Agile-манифест и практики Scrum, XP и Kanban на уровне команды. Третья — системное мышление в традиции Деминга: результат определяется системой, а не усилиями отдельных людей, поэтому оптимизировать нужно поток целиком. Четвёртая — подходы к знаниевому труду: внутренняя мотивация, децентрализация решений. Из этих источников и наблюдений за внедрениями авторы вывели десять принципов фреймворка.

Что говорит академическая наука

Научных исследований метода меньше, чем внедрений: фреймворк создан практиками, а не исследователями. Систематический обзор Абхишты Путты, Марии Паасиваары и Каспера Лассениуса (2018) собрал 48 описанных случаев внедрения в 46 организациях из рецензируемых и нерецензируемых источников и отметил, что при господстве SAFe на рынке независимых данных о его эффективности мало. Паасиваара (2017) изучила внедрение в финской компании Comptel по одиннадцати интервью: SAFe выбрали, чтобы улучшить связь бизнеса и ИТ, быстрее реагировать на изменения и не терять время на разнесение функций по командам; бизнес-направление, начавшее переход на полгода позже, прошло его заметно успешнее, потому что училось на опыте первого. Кирон Конбой и Ноэл Кэрролл (2019) на 13 трансформациях за 15 лет выделили девять сквозных трудностей внедрения крупных Agile-фреймворков — от определения роли менеджеров до измерения результата. Оуктай Тюреткен с соавторами (2016) предложили модель зрелости внедрения SAFe, а Михал Ковальчик с коллегами (2022) методом исследования действием описали, как банк Nordea адаптировал «сложный и жёсткий» фреймворк к своей программе базовой банковской платформы: из 34 предложенных решений часть оказалась тупиковой.

Отдельный вопрос — что фреймворк делает с автономией команд. Томас Густавссон, Марте Норденген Бернтсен и Виктория Стрей (2022) провели 28 интервью и 17 выездных наблюдений в трёх организациях. Автономия выросла в четырёх отношениях: команды лучше видят общую картину, принимают более дальновидные решения, им проще помогать друг другу и сигнализировать о пределах своей ёмкости — именно на PI Planning становится видно, какая команда набрала слишком много. Снизилась она в двух: команда больше не выбирает функции сама и обязана проходить навязанное уточнение бэклога. Это честная цена координации, и о ней стоит знать до внедрения.

Ключевые идеи и принципы SAFe

1. Принцип: десять принципов как основа всех практик

   Все практики выведены из десяти принципов: 1) экономический взгляд на решения; 2) системное мышление; 3) допускать изменчивость и сохранять варианты; 4) строить инкрементно, с быстрыми интегрированными циклами обучения; 5) ставить контрольные точки по объективной оценке работающей системы, а не по документам; 6) обеспечивать непрерывный поток ценности; 7) работать в ритме и синхронизировать планирование между областями; 8) раскрывать внутреннюю мотивацию работников знаний; 9) децентрализовать принятие решений; 10) организовываться вокруг ценности. Если практика противоречит принципу, принцип важнее — так авторы предлагают адаптировать фреймворк, не теряя его смысла.

2. Принцип: четыре ценности

   В версии 6.0 базовые ценности — согласованность (alignment), прозрачность (transparency), уважение к людям (respect for people) и непрерывное совершенствование (relentless improvement). Согласованность означает, что все команды понимают общие цели и работают на них; прозрачность — что планы, риски и проблемы видны всем, включая руководство; уважение к людям унаследовано от бережливого производства Toyota; непрерывное совершенствование выражается в регулярных событиях «Анализ и адаптация».

3. Принцип: Agile Release Train — команда команд вокруг потока ценности

   Базовая единица — Agile Release Train (ART, «поезд»): долгоживущая команда из Agile-команд численностью примерно 50–125 человек. Поезд кросс-функционален: в нём есть все, кто нужен, чтобы определить, построить, проверить и выпустить решение без передачи работы наружу. Поезд строится вокруг потока ценности, а не вокруг подразделений: сначала определяют, какую ценность получает клиент, потом — кто нужен для её создания. Каждая Agile-команда внутри поезда — небольшая, примерно до десяти человек, и работает по Scrum, Kanban или их сочетанию.

4. Принцип: роли поезда

   На уровне поезда появляются роли, которых нет в командном Scrum. Release Train Engineer (RTE) — фасилитатор и «Scrum-мастер поезда»: организует события, снимает препятствия, следит за потоком. Product Management отвечает за бэклог поезда, видение и приоритеты функций — именно эта роль считает WSJF. System Architect держит техническое видение и архитектурную взлётную полосу (architectural runway) — задел инфраструктуры, без которого функции не построить. Business Owners — небольшая группа руководителей, отвечающих за бизнес-результат поезда: они присваивают бизнес-ценность целям PI и участвуют в планировании.

5. Принцип: Planning Interval — ритм поезда

   Поезд живёт в фиксированном ритме планирования — PI. В SAFe 6.0 аббревиатура расшифровывается как Planning Interval, в предыдущих версиях — Program Increment. Практические руководства описывают PI длиной обычно 8–12 недель: несколько итераций разработки и одна итерация инноваций и планирования (IP), где команды доделывают интеграцию, исследуют, учатся и готовятся к следующему планированию. Принцип «планируй в ритме, выпускай по требованию» разделяет два решения: когда синхронизироваться и когда отдавать ценность клиенту.

6. Принцип: PI Planning — два дня совместного планирования

   PI Planning — главное событие фреймворка. Весь поезд, по возможности очно, два дня планирует следующий интервал. Сначала руководство рассказывает о бизнес-контексте, Product Management — о видении и топе бэклога, архитектор — о технических приоритетах. Затем команды в отдельных сессиях оценивают ёмкость, вытягивают функции и формулируют цели PI. Зависимости фиксируются на общей доске программы. Риски разбираются по модели ROAM: устранён (Resolved), принят в работу ответственным (Owned), принят как есть (Accepted), снижен (Mitigated). В конце команды голосуют уверенностью в плане; если уверенность низкая, план пересматривают. Ключевое слово — ёмкость: план, превышающий ёмкость поезда, — не план, а список пожеланий.

7. Принцип: WSJF — приоритет по стоимости задержки

   Бэклог поезда упорядочивается по WSJF (Weighted Shortest Job First — «сначала взвешенно-короткие работы»): WSJF = стоимость задержки / размер работы. Стоимость задержки здесь складывается из трёх относительных оценок: ценности для пользователя и бизнеса, критичности по времени (теряется ли ценность при опоздании, есть ли жёсткий срок) и снижения риска или открытия новых возможностей. Размер работы служит приближением длительности. Все оценки — относительные, по модифицированной шкале Фибоначчи (1, 2, 3, 5, 8, 13, 20): в каждом столбце самая «маленькая» функция получает 1, остальные оцениваются относительно неё. Оценивать нужно по столбцу за раз, сравнивая все функции между собой, а не функцию за функцией. Смысл формулы: при прочих равных выигрывает маленькая работа с большой стоимостью задержки — её быстрее доставить, и деньги перестают теряться раньше.

8. Принцип: четыре конфигурации

   Фреймворк масштабируется конфигурациями. Essential SAFe — минимальный набор: команды, поезд, PI Planning, базовые роли. Large Solution SAFe добавляет координацию нескольких поездов над одним большим решением (космос, оборона, медицинские системы) — уровень решения с собственными ролями и событиями. Portfolio SAFe добавляет бережливое управление портфелем: потоки ценности, бюджеты потоков вместо бюджетов проектов, канбан эпиков и стратегические темы. Full SAFe объединяет всё. Организация выбирает минимально достаточную конфигурацию, а не самую полную.

9. Принцип: семь компетенций бизнес-гибкости

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

10. Принцип: SAFe среди других фреймворков масштабирования

    Это самый детально регламентированный из фреймворков масштабирования. LeSS (Large-Scale Scrum) Крейга Лармана и Баса Водде, наоборот, минималистичен: один владелец продукта и один бэклог на несколько команд, без новых ролей. Nexus от Кена Швабера и Scrum.org добавляет к Scrum интеграционную команду для 3–9 команд. Scrum@Scale Джеффа Сазерленда масштабирует Scrum фрактально, через Scrum of Scrums. Disciplined Agile Скотта Эмблера и Марка Лайнса — набор вариантов выбора, а не единый процесс. Так называемая модель Spotify — описание практик одной компании (племена, отряды, гильдии), которое сами авторы не предлагали как фреймворк. В отчётах State of Agile SAFe много лет называют самым распространённым подходом к масштабированию: в 13-м отчёте его выбрали 30 % респондентов, в 16-м — 53 %.

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

Ограничения, слепые зоны и критика SAFe

Типовые ошибки при внедрении SAFe

1. Ошибка 1: «SAFe сверху» без понимания руководством.

   Руководители отправляют на обучение команды, а сами продолжают управлять проектами по-старому: утверждают сроки до планирования, вмешиваются в бэклог в обход Product Management, требуют отчётов о загрузке. Команды видят разрыв между словами и практикой, PI Planning превращается в ритуал.

   Как избежать

   начинать, как LEGO, с обучения руководителей и бизнес-владельцев; до первого PI договориться, какие решения теперь принимаются на планировании, а не в кабинетах.

2. Ошибка 2: план PI больше ёмкости поезда.

   Под давлением бизнеса команды берут в PI всё, что «надо», — спрос превышает ёмкость, запаса на неопределённость нет. Через месяц половина целей сорвана, доверие к планированию падает, и руководство возвращается к ручному управлению.

   Как избежать

   считать ёмкость каждой команды до планирования, закладывать запас, проводить черту отсечения по WSJF и открыто говорить бизнесу, что за чертой в этот PI не войдёт. Обязательство действительно, только если команда взяла его добровольно.

3. Ошибка 3: WSJF как формальность.

   Оценки ставят по одной функции целиком, у каждой «ценность 13», размер подбирают так, чтобы любимый проект оказался наверху. Формула есть, сравнения нет.

   Как избежать

   оценивать по столбцу за раз, у самой маленькой функции в столбце ставить 1, обсуждать расхождения оценок с бизнес-владельцами и пересчитывать WSJF перед каждым PI, потому что критичность по времени меняется.

4. Ошибка 4: поезд вокруг оргструктуры, а не потока ценности.

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

   Как избежать

   начинать с картирования потока ценности — например, через Value Stream Mapping — и собирать поезд так, чтобы он мог доставить ценность от идеи до клиента сам.

5. Ошибка 5: полная конфигурация с первого дня.

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

   Как избежать

   начинать с Essential SAFe и одного поезда, добавлять уровни, только когда появилась реальная потребность — несколько поездов на одно решение или портфель с конкурирующими инвестициями.

6. Ошибка 6: итерация IP превращается в обычный спринт.

   Итерацию инноваций и планирования заполняют недоделанными функциями. Нет времени на интеграцию, обучение и подготовку к планированию, технический долг копится, а следующий PI начинается без подготовки.

   Как избежать

   не планировать функции в IP-итерацию, использовать её как буфер на неопределённость и время для анализа и адаптации.

План внедрения SAFe (Scaled Agile Framework)

1. Месяц 1: решение и подготовка. Оценить, нужен ли фреймворк: сколько команд работают над одним решением, сколько зависимостей между ними, где теряется время. Если команд меньше пяти-шести, рассмотреть Agile/Scrum с Scrum of Scrums или LeSS. Обучить руководителей и будущих бизнес-владельцев, назначить агентов изменений.

2. Месяц 2: проектирование поезда. Картировать поток ценности, определить состав поезда, назначить RTE, Product Management, системного архитектора и бизнес-владельцев. Сформировать бэклог поезда: функции с критериями приёмки. Провести первую оценку WSJF с бизнес-владельцами.

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

4. Месяцы 4–5: исполнение первого PI. Синхронизация поезда раз в неделю, демонстрации системы по итерациям, отслеживание целей PI и рисков. IP-итерация в конце — без функций.

5. Месяц 6: анализ и адаптация. Провести Inspect & Adapt: демонстрация результата PI, количественные метрики (доля выполненных целей, предсказуемость), разбор проблем, бэклог улучшений. Решить, что из практик оставить, что адаптировать, — по принципу LEGO «оставлять то, что даёт энергию».

   Далее: поддержание и обновление. Каждый PI — пересчёт WSJF и ёмкости, новое планирование, анализ и адаптация. Второй поезд или портфельный уровень добавлять, только когда первый стабилизировался. Связывать стратегические темы портфеля с целями — например, через OKR.

Как реализовать этот план с помощью фрейма «SAFe» в OrgDevTools

Фрейм «SAFe» — тренажёр двух решений, которые принимаются на шаге «Месяц 2» и перед каждым PI Planning: в каком порядке брать функции бэклога поезда и что из них поместится в интервал. У фрейма три вкладки. Фрейм бесплатный; в Инструменте «Проекты и задачи» SAFe подключён как тот же фрейм, привязанный к проекту, отдельной реальной функциональности для этой методики там нет.

Книги по теме SAFe (Scaled Agile Framework)

• Дин Леффингуэлл — «Scaling Software Agility: Best Practices for Large Enterprises» (2007). Первое описание «большой картины», из которой вырос SAFe.

• Дин Леффингуэлл — «Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise» (2011). Трёхуровневая модель требований и поезд — основа первой версии фреймворка.

• Ричард Кнастер, Дин Леффингуэлл — «SAFe Distilled: Applying the Scaled Agile Framework for Lean Software and Systems Engineering» (2017; обновлённое издание «SAFe 5.0 Distilled» — 2020). Краткое изложение принципов, конфигураций и событий от авторов.

• Дональд Рейнертсен — «The Principles of Product Development Flow: Second Generation Lean Product Development» (2009). Стоимость задержки, WSJF и экономика потока, на которые опирается SAFe.

• Алекс Якима — «The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe» (2016). Внедрение SAFe в форме бизнес-романа: роли, первое PI Planning, сопротивление.