Please enable JavaScript.
Coggle requires JavaScript to display documents.
Scrum Scaling Frameworks Review (Spotify (Release Trains + Feature Toggles…
Scrum Scaling Frameworks Review
Spotify
Источники
https://medium.com/productmanagement101/spotify-squad-framework-part-i-8f74bcfcd761
http://agilerussia.ru/practices/spotifyscaling/
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
Оргструктура
Squads -> Tribe
Картинка оргструктуры
Chapter - группа по интересам (дизайнеры, тестеры) - чтобы общались и делились опытом решения проблем и не делали одно и тоже несколько раз - внутри клана
Guild - сообщество по интересам на уровне компании, в которое может вступить каждый и выйти в любой момент - между кланами тоже(трайбами) - вебгильдия, например
Feature Squad, Infrastructure Squad(налаживание и ускорение релизов), AppSquad(под платформу)
Release Trains + Feature Toggles
Даже если фича полностью не доделана, ее все равно выкладывают, просто скрывают до момента полной реализации(Toggle features)
Value Delivery > Plan Fulfillment
Experiment friendly area(try both from A or B)
Routine releases
Internal Opensource
Hack Week
Definition of Awesome(direction)
Innovation > Predictability
Skip: TT, Estimation, Separate testers
Squad
Squad сидит вместе, полноценная скрам-команда(от проектирования до тестирования). У каждого отряда есть долгосрочная миссия(фича, часть продукта)
10% - хакатоны для инжереного творчества, проверки хайповых инструментов, гипотез
Есть продуктовнер, который отвечает за беклог своего отряда. В конкретную реализацию не лезет
Есть agile-coach
Tribe
Несколько squad, работающих над одним продуктом, но не более 100 человек(
Числа Данбара
)
Зависимости между трайбами - плохо, между сквадами - ок. Команды реорганизуют если есть такие зависимости
Отслеживание зависимостей, доска с зависимостями, ежемесячные совещания
Архитектура
Микросервисы
Все могут редактировать все (internal opensource)
Есть один(или пара) system-owner, чтобы не превратить все в хаос - он координирует всех, кто точит эту систему, и чаще всего выполняет другую роль, а этой занимается в определенное время
Есть главный архитектор, его ревью носит рекомендательный характер, конечное решение принимает сквад
Релиз - рутина, а не драма
Large Scaled Scrum(LeSS)
Источники
https://less.works/ru/less/framework/introduction.html
Роли
1 владелец продукта
1 скрам-мастер на 3 команды
Фичекоманды
Артефакты
1 беклог продукта
1 инкремент продукта
Отдельный беклог спринта для каждой команды
Community(по тестированию - для обмена опытом между командами на уровне интересов - дизайнеры, тестеры и тп)
События
Один спринт для всего продукта( а не отдельный спринт для каждой команды)
Планирование спринта из 2 частей (1 общая для продукта, вторая - командная внутри)
На первой части присутствует владелец продукта и команды(либо их представители)
Product Backlog Refinement - внутрикомандные встречи по уточнению беклога - проводятся заранее перед планированием
Команды выбирают карточки исходя из своих сильных сторон и прошлого опыта. карточки предоставляет владелец продукта
После выбора карточек задают список вопросов владельцу
Если какие-то команды сильно пересекуются, то второй этап планирования можно тоже провести вместе
На втором этапе формируется беклог спринта(на каждую команду)
Если часть общая
Ставится таймер на 30 минут и идет обсуждание. После окончания таймера все расходятся по своим командам. Нужна глубокая сессия (Design Workshop)
Continious Integration
Нет отдельных команд, отвечающих за интеграцию или тестирование - они создают задержки
цель совершенствования - отгружать продукт каждый спринт
Продукт постоянно находится в состоянии, готовом к поставке
Ретроспектива
Общая макисмум 1.5 часа
Только после того, как провела каждая команда свою
Daily Scrum
Направляются разведчики(scout) в соседние команды
Сессия по уточнению беклога продукта
Предоставляется видение команды
Задаются вопросы по задачам
Оцениваются задачи
Командные сессии по уточнению беклога
Обзор спринта
Учатсвуют все - Владелец продукта. команда, саппорт, клиенты
Демонстрация результатов, обсуждение
Ретроспектива
Mob-программирование для быстрого обучения технологии или распространения идеи
Scaled Agile Framework(SAFe)
Glossary
Источники
https://scrumtrek.ru/blog/safe-dlya-proektnyh-menedzherov-chast-1/
https://www.youtube.com/watch?v=_3fU1AZp_B0
Кратко
Все вокруг Release Train. Оценка по финальному результату - отгрузка ценности клиенту
Все метрики либо в деньгах, либо в том, что можно к ним свести
ART Canvas
Integration RoadMap
Value Stream Canvas
link to www.scaledagileframework.com
4 уровня
Программный
Все кооперируются вокруг продукта(поток создания ценности, value stream)
Синхронизация через:
Совместные сессии планирования(раз в квартал) - Program Increment Planning - собираются все команды, чтобы увидеть список фич на PI. Затем каждая команда планирует, какие цели будут достигнуты ей в каждом PI, выделяя зависимости и риски. Далее презентует результаты планирование перед бизнесом
Еженедельные совещания скрам-мастеров и RTE для синхронизации
Системные демонстрации(раз в 2 недели) System Demo
Инспекция и адаптация(раз в квартал) - Inspect & Adapt
Architectural Runway - архитектор бежит перед паровозом
Роли
Release Train Engineer (Машинист поезда)
Не начальник, а лидер
Скрам-мастер уровня нескольких команд
Business Owner
Отвечает за финансовые показатели
Product Management Team
Бизнес ставит цели - они достигают
Входят: владельцы продукта отдельных команд, продуктовые менеджеры
Выявляют потребности клиента, приоритезируют, составляют дорожную карту, Беклог продукта
System Architect
Определяет архитектуру будущего решения
Направляет команды с технической стороны
Выставляет нефункциональные требования к системе
Все ориентировано на поставку ценностных элементов функциональности через Agile Release Train (ART)
Так же, как и на предыдущем, только команда команд (50-150 человек)
PI(program increment) = 5 итераций (4 + 1 на улучшения)
5я итерация - IP итерация(инновации и планирование) - тут проводятся как хакатоны, техдолг, так и планирование, общие ретроспективы, демонстрации всего PI, планирование нового PI
Портфельный
Стратегии компании, распределение бюджетов по программам, показатели эффективности
Роль: Корпоративный(Enterprise) архитектор
Портфель программ
Уровень крупных комплексных продуктов
Командный
Agile: Scrum, Demo, Retro, Sprint (2weeks)
Implements User stories from Backlog
Roles: ProductOwner, Scrum master, development team member