Частичное устранение зависимостей, благодаря реорганизации оргструктуры компании в продукт-ориентированные структуры 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).

Регулярная работа для минимизации системных зависимостей между командами с целью обеспечения независимости поставки каждой командой

N/A