Масштабирование

Фреймворки масштабирования agile решают проблему: Scrum/Kanban одной команды не работают на размерах от ~50-100 человек: координация растёт квадратично, общие зависимости блокируют, согласование с продуктовой стратегией ослабевает. SAFe, LeSS, Spotify model и Nexus — четыре наиболее обсуждаемых подхода. Ни один не универсален — компромисс между структурой (SAFe) и эмерджентностью (LeSS).

Как это работает

Все scaling-фреймворки пытаются решить одни и те же три проблемы: (1) Межкомандные зависимости — когда работа команды A блокирует команду B; решается общим упорядочиванием backlog (LeSS), Program Increment Planning (SAFe) или политиками автономных команд (Spotify). (2) Согласование с единой продуктовой стратегией — когда у 6 команд разные представления о приоритетах; решается одним Product Owner с общим backlog (LeSS), ролью product manager над командами (SAFe) или Triad уровня tribe (Spotify). (3) Интеграция работы в один отгружаемый продукт — решается Nexus Integration Team, SAFe Release Train Engineer или дисциплиной непрерывной интеграции.

Когда применять

Берите scaling-фреймворк когда (а) у вас реально 50+ инженеров на одном продукте, (б) координация видимо страдает — долгие ожидания зависимостей, боль интеграции, неясные межкомандные приоритеты. Не берите scaling-фреймворки на 15 инженерах — overhead сильно хуже, чем неструктурированное состояние. Оставайтесь на нескольких маленьких Scrum-командах + лёгком ежемесячном межкомандном синке, пока боль не вынудит структурный ответ.

Типичные ошибки

(1) Cargo-cult scaling — внедрение SAFe целиком 'потому что мы растём', когда у команды ещё не работает одно-командный Scrum. (2) Войны фреймворков — выбор фреймворка по цене сертификации или лояльности к вендору вместо организационного fit. (3) Преждевременное масштабирование — формализация структур до проявления проблем; задавайте 'хуже ли текущая дисфункция, чем overhead фреймворка?'

Связанные понятия

• SAFe
• LeSS
• Spotify Model
• Nexus