[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"general-list":3,"methodology-agile-scaling":4,"footer-feature-tags":266},true,{"slug":5,"title":6,"short":7,"group":8,"art":9,"cover":10,"lead":11,"fit":12,"inGrid":3,"h1":13,"intro":14,"tldr":15,"readTime":20,"level":21,"published":22,"updated":23,"about":24,"fitYes":33,"fitNo":38,"artefacts":43,"rollout":83,"metrics":109,"mistakes":132,"shtab":153,"topicGroups":178,"faq":188,"terms":204,"related":238,"seo":253,"topicIndex":256},"agile-scaling","Масштабирование Agile (SAFe, LeSS, Nexus)","масштабирование","agile","load","https:\u002F\u002Fcdn.shtab.app\u002Fmedia\u002Fmethodology\u002Fcovers\u002Fagile-scaling\u002Fcover.png","Одна команда по Scrum работает сама. Пять команд на одном продукте начинают спотыкаться о зависимости, общий бэклог и разные представления о готовности.","Продукт, над которым работают от трёх до нескольких десятков команд, с общими сроками и общей архитектурой.","Масштабирование Agile: несколько команд на одном продукте","Проблемы масштабирования редко связаны с самим Scrum. Они появляются на стыках: одна команда ждёт другую, приоритеты расходятся, интеграция всплывает в конце квартала. Фреймворки масштабирования отвечают на один вопрос — как согласовать работу нескольких команд, не превратив её обратно в проектное управление сверху.",[16,17,18,19],"Главная беда масштабирования — зависимости между командами; их лучше устранять структурой, чем координировать","Общий бэклог с одним владельцем приоритетов важнее выбора фреймворка","Синхронный ритм нужен зависимым командам; независимым его навязывают зря","Единое определение готовности — минимум, без которого интеграция всплывает в конце","11 мин чтения","продвинутый","2026-08-30","2026-08-31",{"paras":25,"title":32},[26,27,28,29,30,31],"Одна продуктовая команда до десяти человек справляется сама: у неё общий бэклог, одна цель на цикл и короткий путь до решения. Проблемы начинаются, когда команд становится несколько, а продукт остаётся общим.","Симптомы узнаваемые. Команда неделю ждёт правку от соседей. Приоритеты у двух команд противоречат друг другу, и каждая уверена в своей правоте. Интеграция всплывает в конце квартала и съедает две недели. Никто не может ответить, когда будет готова функция, потому что она собирается из четырёх кусков.","Готовых наборов правил несколько. SAFe даёт самую подробную конструкцию с общим планированием на восемь-двенадцать недель и выделенными ролями координации. LeSS идёт от обратного и снимает лишнее: один владелец продукта, один бэклог, одно определение готовности на все команды. Nexus добавляет к Scrum минимум механики интеграции для трёх-девяти команд.","Отдельно стоит сказать о широко известной модели Spotify. Её авторы неоднократно повторяли, что описывали снимок своей компании в конкретный момент. Копирование её структуры без понимания причин обычно даёт переименованные отделы.","Выбор фреймворка занимает людей больше, чем стоило бы. Практика показывает, что решают две вещи: у продукта один владелец приоритетов и команды устроены так, чтобы каждая могла довести функцию до конца самостоятельно.","Стоит держать в голове закон Конвея: система получается такой, каковы каналы общения в организации. Разрезав команды по техническим слоям, вы получите продукт, собранный из слоёв, и зависимость на каждую заметную функцию.","Что такое масштабирование Agile",[34,35,36,37],"Над одним продуктом работают три и более команды с общей архитектурой","Есть общий срок, к которому нужен собранный результат","Зависимости между командами возникают регулярно и заметно тормозят","Руководство готово менять состав команд, а не только процессы",[39,40,41,42],"Команды работают над независимыми продуктами: общий ритм им только мешает","Команд две, и они договариваются напрямую за пять минут","Настоящая проблема — слишком много работ в параллели; масштабирование её закрепит","Организационную структуру менять нельзя ни при каких условиях",{"lead":44,"items":45,"title":61,"events":62},"На уровне нескольких команд добавляются ровно те артефакты, которые отвечают за общее: единый список приоритетов, общее определение готовности и видимая карта зависимостей.",[46,50,54,58],{"d":47,"t":48,"owner":49},"Один упорядоченный список на все команды с одним владельцем приоритетов. Отдельные бэклоги команд наполняются из него.","Общий бэклог продукта","Владелец продукта",{"d":51,"t":52,"owner":53},"Одинаковые критерии завершённости для всех команд, включая интеграцию и тесты. Разные критерии дают куски, которые не собираются.","Единое определение готовности","Команды совместно",{"d":55,"t":56,"owner":57},"Что и от кого ждёт каждая команда в ближайшем горизонте. Пересматривается на общей синхронизации.","Карта зависимостей","Координатор ритма",{"d":59,"t":60,"owner":49},"Что команды должны получить вместе за ближайшие недели. Формулируется результатом для пользователя.","Общая цель периода","Что появляется в работе",[63,68,73,78],{"t":64,"dur":65,"out":66,"who":67},"Общее планирование периода","1–2 дня раз в 8–12 недель","согласованный план и явно названные зависимости","все команды и заинтересованные стороны",{"t":69,"dur":70,"out":71,"who":72},"Сверка представителей команд","15–30 мин 2–3 раза в неделю","снятые препятствия и обновлённые зависимости","по одному человеку от команды",{"t":74,"dur":75,"out":76,"who":77},"Общий обзор результата","1–2 ч в конце цикла","собранный инкремент и обратная связь","команды и заказчики",{"t":79,"dur":80,"out":81,"who":82},"Общая ретроспектива","1–1,5 ч в конце цикла","улучшения на стыках, а не внутри команд","представители команд",{"lead":84,"steps":85,"title":108},"Первый шаг делают не в процессах, а в составе команд: большинство проблем масштабирования растёт из того, как команды нарезаны.",[86,90,94,97,101,104],{"d":87,"t":88,"when":89},"Если команды работают над разными продуктами, общий ритм им помешает. Масштабирование нужно там, где результат собирается из работы нескольких команд.","Проверьте, нужна ли вам эта задача","до старта",{"d":91,"t":92,"when":93},"Команда должна доводить функцию до пользователя своими силами. Нарезка по техническим слоям порождает зависимость на каждую заметную функцию.","Соберите команды вокруг функций","первый месяц",{"d":95,"t":96,"when":93},"Один владелец приоритетов на продукт. Пока каждая команда получает задачи от своего заказчика, договориться о порядке работ невозможно.","Сведите приоритеты в один список",{"d":98,"t":99,"when":100},"Одинаковые критерии завершённости, включая интеграцию. Это дешёвый шаг, который снимает большую часть сюрпризов в конце периода.","Договоритесь о единой готовности","второй месяц",{"d":102,"t":103,"when":100},"Одинаковая длина и даты начала у тех, кто зависит друг от друга. Независимым командам общий ритм навязывать не нужно.","Синхронизируйте циклы у зависимых команд",{"d":105,"t":106,"when":107},"Раз в два-три месяца команды планируют вместе и вслух называют зависимости. Один такой день экономит недели переписки.","Заведите общее планирование периода","третий месяц","С чего начать",{"items":110,"title":131},[111,115,119,123,127],{"d":112,"t":113,"how":114},"Сколько раз команда ждёт другую. Показатель успеха масштабирования — снижение этого числа.","Число зависимостей на период","Подсчёт на общем планировании и по факту за период.",{"d":116,"t":117,"how":118},"Сколько работа стоит в ожидании соседней команды.","Время ожидания на стыке","Время в статусе «ждёт другую команду», медиана за период.",{"d":120,"t":121,"how":122},"Какая часть запланированного на период доведена до состояния, пригодного к поставке.","Доля собранного инкремента","Готовые элементы к запланированным на период.",{"d":124,"t":125,"how":126},"Сколько занимает интеграция результатов команд. Рост означает расхождение критериев готовности.","Срок сборки","Время от готовности последнего куска до собранного результата.",{"d":128,"t":129,"how":130},"Как часто людей перебрасывают между командами. Перетасовка обнуляет сработанность.","Стабильность состава команд","Доля людей, сменивших команду за квартал.","Что считать",{"items":133,"title":152},[134,137,140,143,146,149],{"t":135,"fix":136},"Фреймворк выбирают раньше, чем находят проблему","Начните с описания того, что именно ломается на стыках. Набор правил, внедрённый до этого разговора, добавит событий и оставит зависимости на месте.",{"t":138,"fix":139},"Команды нарезаны по техническим слоям","Пересоберите их вокруг функций, чтобы каждая доводила результат до пользователя. Это тяжелее любой процессной правки и даёт больше, чем все остальные шаги вместе.",{"t":141,"fix":142},"У каждой команды свой заказчик","Введите одного владельца приоритетов на продукт. Пока приоритеты приходят из разных мест, любое общее планирование превращается в торг.",{"t":144,"fix":145},"Масштабируют вместо того, чтобы уменьшить параллель","Посчитайте, сколько инициатив идёт одновременно. Часто честный ответ — сократить их вдвое, и тогда координация нескольких команд просто не понадобится.",{"t":147,"fix":148},"Общий ритм навязывают независимым командам","Синхронизируйте циклы только у тех, кто зависит друг от друга. Остальным общий календарь добавляет встреч без всякой пользы.",{"t":150,"fix":151},"Координация становится отдельным этажом управления","Держите роли координации минимальными и временными. Как только появляется постоянный слой руководителей над командами, решения снова начинают спускаться сверху.","Где обычно ломается",{"lead":154,"links":155,"title":170,"points":171},"Заведите портфель проектов: у каждой команды свой проект со своей доской, а над ними — общий срез, где видно продукт целиком и зависимости между командами.",[156,161,165],{"to":157,"tag":158,"text":159,"title":160},"\u002Ffeatures\u002Fportfel-proektov\u002F","ВОЗМОЖНОСТЬ","Несколько команд и общие сроки в одном срезе.","Портфель проектов",{"to":162,"tag":158,"text":163,"title":164},"\u002Ffeatures\u002Fsviazi-tselei\u002F","Цели команд, связанные с общим результатом.","Связи целей",{"to":166,"tag":167,"text":168,"title":169},"\u002Fsolutions\u002Fdlya-pmo\u002F","РЕШЕНИЕ","Как управлять портфелем и зависимостями между командами.","Проектный офис","Как собрать несколько команд в Shtab",[172,173,174,175,176,177],"Портфель проектов показывает работу нескольких команд в одном месте, включая общие сроки.","Связи между задачами делают зависимость видимой: понятно, кто кого ждёт и с какого дня.","Общий бэклог удобно держать отдельным списком, из которого элементы уходят в проекты команд.","Диаграмма Ганта показывает, как сдвиг у одной команды двигает общий срок.","Единое определение готовности заводится чек-листом в шаблоне задачи — одинаковым для всех команд.","Сквозные цели связывают работу команд с общим результатом периода.",[179,184],{"items":180,"title":183},[181,182],"vnedrenie","sinhronizatsiya","ПРОЦЕСС",{"items":185,"title":187},[186],"zavisimosti","СТЫКИ",[189,192,195,198,201],{"a":190,"q":191},"Начните с числа команд и с того, насколько жёсткая координация вам действительно нужна. Nexus — минимальное дополнение к Scrum для трёх-девяти команд. LeSS снимает лишнее и требует одного бэклога с одним владельцем; он строже к организационным изменениям. SAFe даёт подробную конструкцию и чаще выбирается крупными компаниями с регуляторными требованиями. Разница в объёме правил, и ни один из них не решит проблему нарезки команд по слоям.","Какой фреймворк выбрать: SAFe, LeSS или Nexus?",{"a":193,"q":194},"Её авторы говорили, что описывали состояние своей компании в конкретный момент, и предупреждали против копирования. На практике попытка обычно заканчивается переименованием отделов в трайбы и сквады при сохранении прежних согласований. Полезнее взять из модели идею автономии команды и проверить, есть ли у ваших команд возможность довести работу до пользователя без внешних согласований.","Можно ли просто скопировать модель Spotify?",{"a":196,"q":197},"На практике до восьми-десяти команд общее планирование ещё работает как разговор. Дальше оно превращается в череду докладов, и его приходится делить на группы по продуктовым областям. Сама по себе численность — плохой повод переходить к более тяжёлому фреймворку: сначала проверьте, все ли эти команды действительно зависят друг от друга.","Сколько команд можно синхронизировать одним планированием?",{"a":199,"q":200},"Минимально и по возможности временно. Роль, отвечающая за ритм общих событий и видимость зависимостей, полезна. Опасность в том, что вокруг неё быстро вырастает постоянный слой управления над командами, и решения снова начинают спускаться сверху — ровно то, от чего уходили.","Нужны ли отдельные роли координаторов?",{"a":202,"q":203},"Смотреть на состав команд. Устойчивые зависимости почти всегда означают, что команды нарезаны по техническим слоям или по компонентам, и каждая функция требует троих. Процессные правила такое не лечат: они делают ожидание видимым и предсказуемым, но не убирают его.","Что делать, если зависимости не уходят?",[205,208,211,214,217,220,223,226,229,232,235],{"slug":206,"title":207},"safe","SAFe",{"slug":209,"title":210},"less","LeSS",{"slug":212,"title":213},"nexus","Nexus",{"slug":215,"title":216},"spotify-model","Модель Spotify",{"slug":218,"title":219},"scrum-of-scrums","Сверка Scrum-команд",{"slug":221,"title":222},"agile-release-train","Поезд поставки",{"slug":224,"title":225},"program-increment","Программный инкремент",{"slug":227,"title":228},"pi-planning","Планирование инкремента",{"slug":230,"title":231},"feature-team","Продуктовая команда",{"slug":233,"title":234},"component-team","Компонентная команда",{"slug":236,"title":237},"tribe","Трайб",[239,244,248],{"to":240,"tag":241,"text":242,"title":243},"\u002Fmethodology\u002Fscrum\u002F","МЕТОДОЛОГИЯ","Каркас одной команды, с которого начинается масштабирование.","Scrum",{"to":245,"tag":241,"text":246,"title":247},"\u002Fmethodology\u002Fproject-management\u002F","Как устроена координация там, где содержание зафиксировано договором.","Классическое управление проектами",{"to":249,"tag":250,"text":251,"title":252},"\u002Fmethodology\u002Fscrum\u002Fsobytiya\u002F","ТЕМА","Ритм одной команды, поверх которого строится общий.","События Scrum",{"title":254,"description":255},"Масштабирование Agile: SAFe, LeSS и Nexus на практике","Как согласовать работу нескольких команд на одном продукте: общий бэклог, единое определение готовности, синхронный ритм и работа с зависимостями. Сравнение SAFe, LeSS и Nexus.",[257,260,263],{"slug":181,"title":258,"hint":259},"Как масштабировать Agile","состав команд, общий бэклог, ритм",{"slug":182,"title":261,"hint":262},"Как синхронизировать команды","планирование периода, сверки, общий обзор",{"slug":186,"title":264,"hint":265},"Как управлять зависимостями","убрать структурой, а не координировать",[267,276,282,291,296,302,308,314,318,324],{"id":268,"name":269,"hex":270,"translations":271,"count_pages":275},8,"Компания","#f40925",{"ru":272,"en":273},{"name":269},{"name":274},"Company",9,{"id":277,"name":278,"hex":279,"translations":280,"count_pages":268},26,"Главная страница",null,{"ru":281},{"name":278},{"id":283,"name":284,"hex":285,"translations":286,"count_pages":290},2,"Проекты","#3027ff",{"ru":287,"en":288},{"name":284},{"name":289},"Project",15,{"id":292,"name":293,"hex":279,"translations":294,"count_pages":283},33,"ИИ",{"ru":295},{"name":293},{"id":297,"name":298,"hex":279,"translations":299,"count_pages":301},34,"Комментарии",{"ru":300},{"name":298},4,{"id":303,"name":304,"hex":279,"translations":305,"count_pages":307},25,"Задачи",{"ru":306},{"name":304},24,{"id":309,"name":310,"hex":279,"translations":311,"count_pages":313},27,"Рабочие пространства",{"ru":312},{"name":310},3,{"id":307,"name":315,"hex":279,"translations":316,"count_pages":268},"Kanban-доска",{"ru":317},{"name":315},{"id":319,"name":320,"hex":279,"translations":321,"count_pages":323},23,"Диаграмма Ганта",{"ru":322},{"name":320},1,{"id":290,"name":325,"hex":279,"translations":326,"count_pages":323},"Календарь",{"ru":327},{"name":325}]