Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>23 дек 2025</li>

3 <li>0</li>

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

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

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

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

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

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

10 Содержание

11 <ul><li><a>Что такое SAFe и когда его используют</a></li>

12 <li><a>Из чего состоит фреймворк</a></li>

13 <li><a>Как в SAFe устроено управление задачами</a></li>

14 <li><a>Как договориться о приоритетах в SAFe</a></li>

15 <li><a>Как синхронизировать планы в фреймворке</a></li>

16 <li><a>Проблемы при внедрении SAFe</a></li>

17 <li><a>Какую пользу можно ожидать от внедрения SAFe</a></li>

18 </ul>Эксперт

19 Agile-коуч и CEO ScrumTrek

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

21 <ul><li>большое количество команд, задействованных в работе;</li>

22 <li>сложное программное обеспечение, состоящее из тесно связанных элементов, которые разрабатываются параллельно;</li>

23 <li>высокая степень неопределённости.</li>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

40 <ul><li>Team - это базовый уровень для любого Agile-подхода. На нём происходит планирование и реализация спринтов отдельными командами.</li>

41 <li>На уровне ART координируется работа отдельных команд, обеспечивая единый план релизов.</li>

42 <li>Solution Train будет необходим, когда к продукту подключатся внешние интеграторы, например поставщики карт, и потребуется выстроить общую с ними архитектуру решения.</li>

43 <li>На уровне Portfolio принимаются стратегические решения: расширять ли географию сервиса, менять ли модель монетизации, или запускать новые виды перевозок.</li>

44 </ul>Четыре уровня SAFeИзображение:<a>Kaiten</a>Как и в других Agile-подходах, в SAFe работу рассматривают какпоток - последовательное движение от идеи до поставки ценности. При этом каждая задача проходит свой жизненный цикл.

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

46 <ul><li>Upstream - анализ ценности, формулирование гипотезы и проведение первичной оценки. Здесь задача проходит фильтр на полезность и адекватность.</li>

47 <li>Downstream - прошедшие отбор задачи попадают в реализацию. Команды берут их в план, оценивают и двигают по спринтам.</li>

48 </ul>"Разделение на upstream и downstream помогает поддерживать порядок в потоке задач: в реализацию попадают только те инициативы, которые достаточно проработаны и имеют понятную ценность".

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

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

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

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

53 <ul><li>Feature (функциональный компонент) - это конкретная часть продукта, которая несёт для пользователя ценность и обычно реализуется в одном или нескольких спринтах. Например, это может быть экран авторизации в приложении, который позволяет пользователю ввести номер телефона и получить SMS-код для авторизации.</li>

54 <li>Enabler (технический компонент)обеспечивает реализацию фич, то есть включает в себя архитектуру, инфраструктуру и интеграции продукта. Например, интеграция с сервисом отправки SMS для реализации функции авторизации по номеру телефона.</li>

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

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

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

58 Уровни рабочих элементов в SAFeСкриншот:<a>Kaiten</a>/ Skillbox MediaЧтобы понять, какие именно задачи брать в работу, в SAFe используется метод Weighted Shortest Job First (WSJF). Он помогает решить, что делать в первую очередь, когда идей больше, чем ресурсов. Благодаря ему команды выстраивают приоритеты в бэклоге и понимают, какие задачи дадут наибольший эффект для продукта.

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

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

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

62 <ul><li>Стоимость промедления - это показатель, который отражает, сколько ценности теряется, если отложить выполнение задачи. Он учитывает не только потенциальную пользу, но и то, насколько критично выполнить задачу именно сейчас.Сначала определяют ожидаемую ценность: вклад в выручку или экономию затрат, снижение рисков или улучшение пользовательского опыта. Затем - фактор времени: насколько задержка выполнения задачи снижает эффект от неё и влияет ли она на доступность вариантов развития продукта в будущем.

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

64 </li>

65 </ul><ul><li>Размер работы команда оценивает в часах, стори-поинтах или других условных единицах трудозатрат.</li>

66 <li>После этого стоимость промедления делят на размер работы. Задачи с наибольшим значением оказываются выше в приоритете.</li>

67 </ul>"Формулу WSJF не стоит воспринимать как нечто раз и навсегда заданное. Её можно и нужно подстраивать под реальность компании. Например, добавить критерий "актуальность сейчас“ - чтобы не упустить задачу, которая важна именно в этот момент, или "вклад в стратегию“ - если речь о фичах, которые помогут бизнесу через полгода. Формула - это инструмент для обсуждения, а не строгая математика.

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

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

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

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

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

73 <ul><li>договариваются, кто что делает в ближайшие недели;</li>

74 <li>обсуждают между собой зависимости и риски;</li>

75 <li>оценивают, хватает ли ресурсов и где возможны перегрузки;</li>

76 <li>формулируют PI Objectives - цели отдельных команд и всего "поезда" на итерацию.</li>

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

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

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

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

81 Процесс планирования фич и энейблеров по итерациям в командеСкриншот:<a>Kaiten</a>/ Skillbox MediaSAFe не всегда работает так, как задумано. Возникающие проблемы часто повторяются между разными компаниями, и их можно объединить в четыре большие группы: отсутствие общего инкремента, сбор обратной связи не от пользователей продукта, технический долг, мешающий релизам, и низкая эффективность подхода в небольших командах. Рассмотрим каждый из этих пунктов подробно.

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

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

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

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

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

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

88 <ul><li>рост продуктивности на 20-50%;</li>

89 <li>повышение качества на 25-75%;</li>

90 <li>сокращение времени вывода продуктов на рынок на 30-75%;</li>

91 <li>рост вовлечённости сотрудников на 10-50%.</li>

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

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

94 <a>Курс с трудоустройством: "Профессия Разработчик + ИИ" Узнать о курсе</a>