'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Что такое масштабирование Agile
Одна продуктовая команда до десяти человек справляется сама: у неё общий бэклог, одна цель на цикл и короткий путь до решения. Проблемы начинаются, когда команд становится несколько, а продукт остаётся общим.
Симптомы узнаваемые. Команда неделю ждёт правку от соседей. Приоритеты у двух команд противоречат друг другу, и каждая уверена в своей правоте. Интеграция всплывает в конце квартала и съедает две недели. Никто не может ответить, когда будет готова функция, потому что она собирается из четырёх кусков.
Готовых наборов правил несколько. SAFe даёт самую подробную конструкцию с общим планированием на восемь-двенадцать недель и выделенными ролями координации. LeSS идёт от обратного и снимает лишнее: один владелец продукта, один бэклог, одно определение готовности на все команды. Nexus добавляет к Scrum минимум механики интеграции для трёх-девяти команд.
Отдельно стоит сказать о широко известной модели Spotify. Её авторы неоднократно повторяли, что описывали снимок своей компании в конкретный момент. Копирование её структуры без понимания причин обычно даёт переименованные отделы.
Выбор фреймворка занимает людей больше, чем стоило бы. Практика показывает, что решают две вещи: у продукта один владелец приоритетов и команды устроены так, чтобы каждая могла довести функцию до конца самостоятельно.
Стоит держать в голове закон Конвея: система получается такой, каковы каналы общения в организации. Разрезав команды по техническим слоям, вы получите продукт, собранный из слоёв, и зависимость на каждую заметную функцию.
- Над одним продуктом работают три и более команды с общей архитектурой
- Есть общий срок, к которому нужен собранный результат
- Зависимости между командами возникают регулярно и заметно тормозят
- Руководство готово менять состав команд, а не только процессы
- Команды работают над независимыми продуктами: общий ритм им только мешает
- Команд две, и они договариваются напрямую за пять минут
- Настоящая проблема — слишком много работ в параллели; масштабирование её закрепит
- Организационную структуру менять нельзя ни при каких условиях
Что появляется в работе
На уровне нескольких команд добавляются ровно те артефакты, которые отвечают за общее: единый список приоритетов, общее определение готовности и видимая карта зависимостей.
Общий бэклог продукта
Один упорядоченный список на все команды с одним владельцем приоритетов. Отдельные бэклоги команд наполняются из него.
Единое определение готовности
Одинаковые критерии завершённости для всех команд, включая интеграцию и тесты. Разные критерии дают куски, которые не собираются.
Карта зависимостей
Что и от кого ждёт каждая команда в ближайшем горизонте. Пересматривается на общей синхронизации.
Общая цель периода
Что команды должны получить вместе за ближайшие недели. Формулируется результатом для пользователя.
| СОБЫТИЕ | ЧАСТОТА И ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | ЧЕМ ЗАКАНЧИВАЕТСЯ |
|---|---|---|---|
| Общее планирование периода | 1–2 дня раз в 8–12 недель | все команды и заинтересованные стороны | согласованный план и явно названные зависимости |
| Сверка представителей команд | 15–30 мин 2–3 раза в неделю | по одному человеку от команды | снятые препятствия и обновлённые зависимости |
| Общий обзор результата | 1–2 ч в конце цикла | команды и заказчики | собранный инкремент и обратная связь |
| Общая ретроспектива | 1–1,5 ч в конце цикла | представители команд | улучшения на стыках, а не внутри команд |
С чего начать
Первый шаг делают не в процессах, а в составе команд: большинство проблем масштабирования растёт из того, как команды нарезаны.
- 1Проверьте, нужна ли вам эта задачаЕсли команды работают над разными продуктами, общий ритм им помешает. Масштабирование нужно там, где результат собирается из работы нескольких команд.до старта
- 2Соберите команды вокруг функцийКоманда должна доводить функцию до пользователя своими силами. Нарезка по техническим слоям порождает зависимость на каждую заметную функцию.первый месяц
- 3Сведите приоритеты в один списокОдин владелец приоритетов на продукт. Пока каждая команда получает задачи от своего заказчика, договориться о порядке работ невозможно.первый месяц
- 4Договоритесь о единой готовностиОдинаковые критерии завершённости, включая интеграцию. Это дешёвый шаг, который снимает большую часть сюрпризов в конце периода.второй месяц
- 5Синхронизируйте циклы у зависимых командОдинаковая длина и даты начала у тех, кто зависит друг от друга. Независимым командам общий ритм навязывать не нужно.второй месяц
- 6Заведите общее планирование периодаРаз в два-три месяца команды планируют вместе и вслух называют зависимости. Один такой день экономит недели переписки.третий месяц
Что считать
Где обычно ломается
Фреймворк выбирают раньше, чем находят проблему
Команды нарезаны по техническим слоям
У каждой команды свой заказчик
Масштабируют вместо того, чтобы уменьшить параллель
Общий ритм навязывают независимым командам
Координация становится отдельным этажом управления
Темы про масштабирование
Как собрать несколько команд в Shtab
Заведите портфель проектов: у каждой команды свой проект со своей доской, а над ними — общий срез, где видно продукт целиком и зависимости между командами.
- 01Портфель проектов показывает работу нескольких команд в одном месте, включая общие сроки.
- 02Связи между задачами делают зависимость видимой: понятно, кто кого ждёт и с какого дня.
- 03Общий бэклог удобно держать отдельным списком, из которого элементы уходят в проекты команд.
- 04Диаграмма Ганта показывает, как сдвиг у одной команды двигает общий срок.
- 05Единое определение готовности заводится чек-листом в шаблоне задачи — одинаковым для всех команд.
- 06Сквозные цели связывают работу команд с общим результатом периода.
Частые вопросы
Начните с числа команд и с того, насколько жёсткая координация вам действительно нужна. Nexus — минимальное дополнение к Scrum для трёх-девяти команд. LeSS снимает лишнее и требует одного бэклога с одним владельцем; он строже к организационным изменениям. SAFe даёт подробную конструкцию и чаще выбирается крупными компаниями с регуляторными требованиями. Разница в объёме правил, и ни один из них не решит проблему нарезки команд по слоям.