SAFe в Agile: что это такое и как его использовать

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

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

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

Содержание

• Что такое SAFe и когда его используют
• Из чего состоит фреймворк
• Как в SAFe устроено управление задачами
• Как договориться о приоритетах в SAFe
• Как синхронизировать планы в фреймворке
• Проблемы при внедрении SAFe
• Какую пользу можно ожидать от внедрения SAFe

Эксперт

Иван Дубровин

Agile-коуч и CEO ScrumTrek

Эксперт

Егор Ткачёв

CAO Kaiten

Что такое SAFe и когда его используют

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

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

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

Большой масштаб

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

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

Продукт состоит из взаимосвязанных частей

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

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

Работа в среде с высокой неопределённостью

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

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

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

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

Читайте также:

Agile: что это такое и как работает гибкое управление проектами

Из чего состоит SAFe

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

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

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

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

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

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

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

• На уровне ART координируется работа отдельных команд, обеспечивая единый план релизов.
• Solution Train будет необходим, когда к продукту подключатся внешние интеграторы, например поставщики карт, и потребуется выстроить общую с ними архитектуру решения.
• На уровне Portfolio принимаются стратегические решения: расширять ли географию сервиса, менять ли модель монетизации, или запускать новые виды перевозок.

Как в SAFe устроено управление задачами

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

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

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

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

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

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

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

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

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

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

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

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

Как договориться о приоритетах в SAFe

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

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

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

• Стоимость промедления — это показатель, который отражает, сколько ценности теряется, если отложить выполнение задачи. Он учитывает не только потенциальную пользу, но и то, насколько критично выполнить задачу именно сейчас.
  
  Сначала определяют ожидаемую ценность: вклад в выручку или экономию затрат, снижение рисков или улучшение пользовательского опыта. Затем — фактор времени: насколько задержка выполнения задачи снижает эффект от неё и влияет ли она на доступность вариантов развития продукта в будущем.
  
  Все параметры оценивают по одной шкале (например, от 1 до 20) и суммируют — так получается «стоимость промедления».

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

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

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

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

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

Как синхронизировать планы в SAFe

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

Проблемы при внедрении SAFe

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

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

Читайте также:

Что такое SDLC и как устроен жизненный цикл разработки ПО

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

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

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

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

Какую пользу можно ожидать от внедрения SAFe

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

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

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

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