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 продукта.
Зарегистрироваться на консультацию
Если вы хотите узнать больше или записаться на консультацию - отправьте заявку!
Возможно будет интересно
