Напишите нам
Фреймворки масштабирования 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)
    Если продукт общий, решения об уровне качества должны быть едиными. Обычно это требует внедрения стандартов, зачастую неудобных для отдельных команд. Также централизующая сила нужна и в отношении процесса выпуска продукта в промышленную эксплуатацию.
  • Целеполагание и бюджетировние
    Без общего подхода к целеполаганию всей продуктовой группы и каждой отдельной команды затруднено управление PnL продукта.

Возможно будет интересно