собрали и осмыслили Алексей Воронин и Василий Савунов
Сравнение механик
разных подходов
к масштабированию Agile
В чем различие популярных подходов к масштабированию Agile:
SAFe, LeSS и моделью Spotify (которой на самом деле нет :))?
Данная таблица является частью контента тренинга
Certified Enterprise Agile Coaching

Дисклеймер: мы глубоко убеждены, что нет плохих или хороших подходов к масштабированию Agile - они все разные, и применяют разные механики, эффективное применение которых зависит от контекста
Проблема или фокус внимания

Оптимизационная цель подхода (субъективное мнение составителей таблицы)
SAFe



Легкий старт, минимизация сопротивления

LeSS



Адаптивность и ценность для клиента


Модель Spotify



Сохранение культуры стартапа на масштабе


Концепция разрешения зависимостей
Частичное устранение зависимостей, благодаря реорганизации оргструктуры компании в продукт-ориентированные структуры Value Streams and Agile Release Trains.


Ручное управление зависимостями через ряд встреч по синхронизации
Устранение зависимостей за счет реорганизации функциональных подразделения в универсальные, кросс-функциональные и кросс-компонентные команды (feature team)
- Устранение зависимостей за счет реорганизации функциональных подразделения в универсальные, кросс-функциональные и кросс-компонентные команды (feature squad)

- Команды полностью автономны с точки зрения поставки
Практики для разрешения зависимостей
Синхронизирующие встречи:
- PI Planning
- PO Sync
- Scrum of Scrum
- System Demo

Частая интеграция и обзор сделанного через System Demo
- Feature teams - кросс-компонентные и кросс-функциональные продуктовые команды
- Внутренний open source
- Continuous integration на уровне продукта
- Feature squads - кросс-функциональные, кросс-компонентные команды- Устранение системных зависимостей между командами трайба. Cбор системных зависимостей в единый dependencies backlog, для последующего их разрешения
- Внутренний open source
- Обеспечение независимости поставки каждой команды
- Client App Squad – отдельная команда, которая фокусируется на обеспечении возможности независимой поставки каждой командой
Обеспечения фокусировки на общих бизнес-целях
Pi Planning - регулярная встреча для планирования на 2.5 месяца, с привлечением всех команд и стейкхолдеров

PO Sync – регулярная встреча Владельцев Продуктов команд для синхронизации планов на спринт
Один продуктовый бэклог на все команды, и один Владелец Продукта для этого бэклога.

Межкомандые мероприятия:
- Sprint Review
- Sprint Planning One
- Overall Product Backlog Refinement.
Spotify Rhythm.
Среднесрочное планирование
PI Planning
- Overall Product Backlog Refinement.
- Multi-team Product Backlog Refinement
Spotify Rhythm
Управление требованиями
- Иерархия требований
- Командный бэклог
- Синхронизация требований на регулярных встречах (PO Sync, Scrum of Scrums, PI Planning, etc.)
Multi-team Product Backlog Refinement

Для уровня 2-8 команд:
- Один продукт
- Один продуктовый бэклог
- Один Владелец Продукта

Для уровня больше 8 команды добавляется:
- Выделенные Области Требований (Requirement Areas)
- Владелец Области Продукта (Area Product Owners)
- Бэклог области продукта (Area Product Backlogs)
- Владелец продукта для команды (Team Product Owner)
- Командный бэклог (Team Backlog)
- Команда организована вокруг клиентского опыта
Обеспечение единства архитектуры
- Architect Runway
- Enterprise Architect
- Solution Architect
- System Architect
- Architect Sync
- Сообщества
(Communities)

- Менторы компонентов
(Component Mentors)

- Межкомандный воркшоп по дизайну архитектуры
(Multi-Team Design workshops (architectural))
- Главный Архитектор (Chief Architect)
- Владелец Системы (System Owner)
Требования к зрелости инженерных практик и инфраструктуры *
Минимальные требования к инженерным практикам:

Среда для интеграционного тестирования, ежедневно доступная для разработчиков, на которой каждый 2 недели можно демонстрировать результат в интеграци (System Demo)

* Это явно фреймворком не требуется, но без этого условия фреймворк будет очень трудно использовать эффективно
Обширные и строгие требования к инженерным практикам:

- Среда для интеграционного тестирования, ежедневно доступная для разработчиков
- Continuous Integration (CI)
- Continuous Delivery (CD) – автоматизированное end-to-end тестирование
- Внутренний open source

* Это явно фреймворком не требуется, но без этого уровня инженерных практик фреймворк будет очень трудно использовать эффективно
Обширные и строгие требования к инженерным практикам:

- Среда для интеграционного тестирования, ежедневно доступная для разработчиков
- Continuous Integration (CI)
- Continuous Delivery (CD) – автоматизированное end-to-end тестирование
- Команды могут поставлять результат независимо друг от друга
- Внутренний open source
Обеспечение прозрачности статуса разработки
-В конце каждого спринта команды организуют и проводят System Demo, на которых показывают сделанное в максимально возможной степени интеграции с результатами других команд

-Inspect & Adapt Workshop – общее мероприятие для всех команд и заинтересованных сторон в конце PI.


В конце каждого спринта проводится Sprint Review, общий для всех команд
Частые релизы

Бюджетирование
Бюджетируется Value Stream или Epic

Практики:
- Lean Budgeting
Бюджетируется группа разработки продукта
Бюджетируется - Трайб (продуктовый юнит)

Практики:
- Spotify Rhythm
Оргструктура и схема подчиненности
Иерархическая
Плоская оргструктура: Владелец Продукта и команды находятся на одном уровне иерархии. Они подчиняются руководителю продуктовой группы
Плоская оргструктура. Всего два уровня иерархия в группе продуктовой разработки: Лидер Трайба (Tribe Leader) и команды
Мероприятия для дизайна команд
- Встреча по самодизайну команд по составу и компетенциям
- Встреча по самоопределению сотрудников в команды
Рекомендуется встреча по самодизайну команд по составу и компетенциям
N/A
Состав команд
Компонентные или кросс-функциональные фича-команды (feature teams)
Большинство команд представляют собой клиенто-ориентированные фича-команды (feature teams)
Большинство команд представляют собой клиенто-ориентированные фича-команды (feature squads)

Каждый трайб содержит две специальные команды:
- Client App Squad
- Infrastructure Squad
Синхронизация в процессе разработки продукта
Синхронизирующие встречи:
- Scrum of Scrums
- PO Sync- System Demo
- Inspect & Adapt
Сообщества

Общие встречи:
- Overall Sprint Planning
- Overall Product Backlog Refinement.

Рекомендуемые практики:
- Скауты (Scouts)
- Путешественники (Travellers)

Не рекомендуемые практики:
- Scrum of Scrum
- Чаптеры(Chapters) - формульные объединения по профессиональным компетенциям

- Гильдии (Guilds) - неформальные ситуативные сообщества для решения какой-то проблемы или распространения какой-то практики

Триумвират или Альянс (Trio or Alliance) в составе:
- Лидер Трайба (Tribe Lead)
- Design Lead
- Лидер Продуктовой Области (Product Area Lead)
Кросс-обучение
- Центры компетенции (Centers Of Excellence)

- Сообщества практиков (Communities of Practices)
- Менторы компонентов (Component mentors)

- Сообщества
(Communities)
- Чаптеры(Chapters) - формульные объединения по профессиональным компетенциям

- Гильдии (Guilds) - неформальные ситуативные сообщества для решения какой-то проблемы или распространения какой-то практики
Механизмы постоянного улучшения
Inspect & Adapt (в конце каждого PI)
Overall Sprint Retrospective (в конце каждого спринта)
Бэклог системных зависимостей на уровне Трайба (Tribe-level Dependency Backlog).

Регулярная работа для минимизации системных зависимостей между командами с целью обеспечения независимости поставки каждой командой
Оффициальный web-сайт
N/A
Эта таблица является частью контента тренинга
Certified Enterprise Agile Coaching.