Scrum в масштабе

Фреймворки масштабирования Scrum

LeSS

“С 2005 года мы работаем с клиентами применяя Фреймворк масштабирования Scrum, Lean и Agile разработки для больших групп - LeSS (Large-Scale Scrum, Scrum в большом масштабе). Мы готовы поделиться с вами этим опытом и знаниями, чтобы вы также могли преуспевать в масштабировании, используя LeSS”.

—Craig Larman & Bas Vodde

Nexus

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

—scrum.org

Scrum@Scale

Scrum@Scale был создан, чтобы эффективно координировать экосистему команд, совместно работающих над созданием больших продуктов, процессов, сервисов и систем. Эта координация достигается с помощью обеспечения “минимально жизнеспособной бюрократии” и архитектуры, не требующей масштабирования.

—The Definitive Guide to Scrum at Scale

Модель Spotify

Инженерная модель Spotify, основанная на принципах и ценностях Scrum, была успешно применена в ING Bank и с тех пор используется в разных отраслях.

Решаемые фреймворками масштабирования вызовы

Зависимости и приоритизация

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

Если продукт общий, решения об уровне качества должны быть едиными. Обычно это требует внедрения стандартов, зачастую неудобных для отдельных команд. Также централизующая сила нужна и в отношении процесса выпуска продукта в промышленную эксплуатацию.
Синхронизация (как команд между собой, так и бизнеса с IT)

С ростом числа команд растет количество межкомандных синхронизаций. Накладные расходы при этом могут быть избыточны, либо эффективность коммуникаций недостаточной. Выбор оптимальных условий (частота, состав, повестка и т.д.) становится затруднителен и требует опыта в масштабировании Scrum.
Целеполагание и бюджетировние

Без общего подхода к целеполаганию всей продуктовой группы и каждой отдельной команды затруднено управление PnL продукта.