Масштабирование Agile
Введение
В центре Agile - небольшая кросс-функциональная команда до 10 человек. Такие команды мотивированы, самоуправляемы и обладают всеми компетенциями для разработки продукта.
Однако Agile-подходы так же нужно использовать и в больших корпорациях, где не один продукт, а несколько и людей для развития и поддержки требуется больше.
Стандартная организация
Обычно большие компании разбиты на отделы/департаменты и так далее. Отделы могут содержать по несколько команд. Либо сам отдел может быть командой. Сами отделы могут делиться по направлениям: отдел разработки, отдел администрирования, аналитики, дизайна и так далее. За каждым отделом закреплён руководитель. Руководитель обладает высокими компетенциями по специализации отдела.
Чтобы все команды и отделы разрабатывали продукт, есть ряд продуктовых и проектных менеджеров, которые раздают в каждый отдел задачи, следят за их исполнением и выставляют приоритеты.
Такая структура имеет ряд тяжёлых проблем, которые не позволят эффективно разрабатывать продукт:
- тяжело оркестрировать такое количество людей
- тяжело поддерживать коммуникацию между определёнными людьми
- растёт количество бюрократии
- недостаток компетенций
- распыление внимания сотрудников
Кросс-функциональная организация команды позволяет закрыть львиную долю коммуникаций прямо внутри команды, потому что каждый человек знает к кому обратиться для быстрого решения проблем.
Само по себе масштабирование Agile происходит за счёт периодической синхронизации команд.
Типы деления команд
| Тип команды | Компонентные команды | Фиче-команды |
|---|---|---|
| Принцип деления | Команды делятся по типу: frontend, backend, iOS, Android | Независимо от платформы реализуют разный функционал: сервис видео, сервис музыки, сервис ленты новостей, сервис оплаты услуг, сервис сообщений |
| Где подходит | Больше подходит для маленьких команд и бизнесов | Больше подходит для крупных бизнесов с большим количеством команд, когда приложение стоит делить на микросервисы |
Преобразование к Agile
Для преобразования больших структур в Agile потребуется:
- Нужно определить будущую структуру компании. То есть нужно определить, какие кросс-функциональные команды нужны для достижения поставленных целей и как они должны друг с другом взаимодействовать.
- Уточнение необходимых компетенций в каждой команде.
- Анализ существующих компетенций. Собрать карту компетенций и далее определиться с тем, что нам нужен добор или переквалификация имеющихся специалистов.
- Собрать общую встречу с описанием реструктуризации компании и описать RoadMap.
- Реорганизация коллектива в соответствии с новой структурой. Тут уже можно попробовать дать сотрудникам самоорганизоваться и предоставить им возможность самим выбрать команду с более интересным проектом.
Командные топологии
Можно перейти на качественно новый уровень конструирования и взаимодействия команд.
Для уточнения топологий можно обратиться к книге Мэтью Скелтона и Мануэля Пайса "Team Topologies"
- Команды, ориентированные на поток - быстро и надёжно создавать ценности для пользователей, работая автономно от других команд
- Команды поддержки - помогают другим потоко-ориентированным командам заполнять пробелы
- Команды сложных подсистем - специализируются на поддержке и разработке специализированных частей системы с требованием углублённых знаний
- Команды платформы - предоставляют ресурсы для потоковых команд, чтобы те работали максимально автономно и эффективно
Kanban в масштабе
Kanban - это эволюционный метод, который применим ко всем этапам развития компании и не требует сильных перестроек.
Переиспользуемость
Kanban нацелен изначально не на одну команду, а на компанию целиком. Все принципы, роли и ценности применимы на любом масштабировании:
-
STATIK
-
модель
-
визуализация процессов
-
ограничение количества работ
-
управление потоком
-
введение правил работы
-
циклы обратной связи
-
непрерывное улучшение
Каденции масштабирования
Каденции, которые стоит применять для синхронизации команд:
- Ревью стратегии - квартальное совещание для синхронизации глобальных целей
- Проводится ежеквартально
- Определение целей и задач
- Оценивается прогресс выполнения задач
- Определяются проблемы и ищутся новые возможности
- Стратегические корректировки
- Планирование следующих шагов на квартал
- Операционное ревью - ежемесячное совещание между менеджерами для улучшения взаимодействия между командами
- проводится ежемесячно
- оцениваются достижения каждой из команд
- собираются данные (зависимости, препятствия)
- генерируются новые идеи для решения проблем
- принимаются решения по решению выведенных проблем
- определяются следующие шаги на месяц
- Ревью рисков - ежемесячное совещание для выявления и планирования действий по узким местам и рискам
- проводится ежемесячно
- устанавливаются правила проведения встречи
- анализируются риски
- все риски приоритизируют (вероятность - тяжесть)
- планируют реакцию на эти риски (работа с рисками)
- определяются следующие шаги на месяц
Концепция уровней полёта (Flight Levels)
Предлагается Клаусом Леопольдом как решение проблемы координации команд через создание надуровней управления.
Техника подразумевает создание менеджерского уровня над командами, которое контролирует выполнение задач и синхронизацию команд между разными уровнями. Необходимо выполнять 5 активностей для обеспечения эффективной работы на разных уровнях координации.
Для синхронизации команд предлагается команда уровнем выше, всего 3 уровня: операционный, координационный и стратегический.
Подробнее на FlightLevels
Nexus
Nexus - это масштабируемый Agile-фреймворк, разработанный сообществом Scrum.org для работы нескольких команд над одним продуктом.
Nexus напрямую связан со Scrum.
Характеристики Nexus
- Вводится команда интеграции, которая синхронизирует постоянно все команды.
- Количество команд: от 3 до 9, включая команду интеграции, которая помогает в координации между командами Scrum. Синхронизировать 2 команды - очень просто, а больше 9 - невероятно сложно.
- Единство продукта: один продукт, единый бэклог продукта и один владелец продукта для всех команд. Цель продукта так же будет являться одной для всех команд.
- Присутствует Nexus Sprint Backlog, который представляет из себя задачи на спринт сразу для всех команд.
- Единый спринт - единый инкремент.
- Все встречи и тайминг взяты из оригинального Scrum как для одной команды (планирование до 4 часов, обзор спринта до 2 часов, ретро до 1,5 часов)
- Общее планирование спринта определяет:
- состояние, которое нужно достичь за итерацию;
- уточняются взаимосвязи между командами;
- добавляются задачи для команды интеграции;
- Локальное планирование внутри команд
- Обзор спринта общий без разделения на локальные обзоры, так как инкремент общий и обратная связь так же общая
- Ретро делится на 3 этапа:
- Встречаются руководители команд, которые решают вопросы по совместному взаимодействию
- Потом встречаются команды на обычное ретро
- Далее снова встречаются представители и вырабатывают договорённости на следующий спринт
- Ежедневные встречи (суммарно должны длиться 15 минут, но можно провести каждый по 15):
- сначала встречаются представители команд
- затем встречаются команды по отдельности
- Кросс-командное уточнение бэклога. Теперь оно является не активностью в течение спринта, а событием, которое должно иногда происходить. Оно не ограничено по времени.
Спринт для трекера задач - это фильтр, в котором выставлен конкретный спринт.
Это очень важно понимать, когда внутри каждой команды будет идти синхронизированный спринт и самих задач станет крайне много. Бэклог продукта это также набор задач, которые не сопоставлены с определённым спринтом.
Команда Интеграции (КИ)
- Представители Scrum-команд - это делегированные на конкретное мероприятие участники Scrum-команд, список которых может меняться
- Состав каждого события ситуативен и может меняться в зависимости от команды и возможностей каждого человека
- Команда интеграции - это Представители Scrum-команд и SM (scrum-master) / PO (product owner)
- Ключевая задача КИ - это способствование появлению общего инкремента
Внедрение
- Ознакомиться с официальным руководством по Nexus - PDF2021
- Собрать команду интеграции в контексте конкретного продукта
LeSS
LeSS (Large Scale Scrum) - это крупномасштабный Scrum.
LeSS делится на:
- Стандартный LeSS: Для до 8 команд, каждая из которых до 8 человек.
- LeSS Huge: Для проектов с тысячами участников.
Основные аспекты LeSS:
- Единство продукта - один продукт, один бэклог, один владелец продукта, единый итоговый инкремент и обзор спринта.
- Планирование и ретроспективы проходят в несколько этапов:
- Планирование в два этапа с участием всех членов команд. Сначала все команды, а потом внутри каждой.
- Ретроспективы в два этапа: командная ретроспектива и менеджерская, на которой встречаются представители команд, сторонние менеджеры и СМ.
- Ежедневные встречи. Схожи с традиционными скрам-встречами, с возможностью участия наблюдателей из других команд для координации.
- Координация: просто говорите (любые члены команды могут общаться с другими членами команды), ревью кода, сообщества практик, многокомандные встречи.
Так же отдельно можно выделить:
- Фокус на фича-команды. Предпочтение отдаётся мультидисциплинарным командам, способным полностью реализовывать функциональность.
- Инженерные практики, бережливое и системное мышление. Важность технического совершенства и комплексного подхода к процессам.
- Внедрение. LeSS решает проблему: большого количества людей, непрерывное улучшение на пути к совершенству.
- Коучинг. Коучинг означает, что опытный тренер будет тесно работать вместе с организацией, чтобы улучшить её продуктовую разработку.
LeSS Huge
LeSS Huge - это несколько вложенных LeSS, где каждая LeSS-группа команд формируется по принципу области требований к продукту.
- бэклог продукта делится на бэклоги области
- для каждой области есть свой владелец области продукта (Area Product Owner)
- сохраняется целиковый владелец продукта и его роль сводится к тому, чтобы распределить задачи по бэклогу продукта по независимым областям требований
- координация команд происходит на общих встречах через координацию обычно с помощью Наблюдателей
Практики LeSS сохраняются для каждой из областей.
Внедрение
Внедрение осуществляется через несколько принципов, которые нужно поддерживать даже в процессе существования LeSS:
- три принципа
- глубоко и узко против широко и поверхностно (хорошее внедрение LeSS в одном продукте, чем плохое внедрение в нескольких)
- поддержка сверху и снизу (успешное внедрение LeSS требует как энергии людей, которые делают Правильные Вещи, так и поддержки людей с организационной властью, чтобы помочь им делать Правильные Вещи)
- привлекайте волонтёров (подключать членов команды для выполнения различных функций)
- коучинг
- карта внедрения
- постоянное улучшение (не существует постоянного состояния, когда продукт готов - продукт должен развиваться постоянно)
Sbergile
Sbergile - это некоторая трансформация Agile, которая ориентируется на модель Spotify. Герман Оскарович Греф сделал огромный вклад в популяризацию Agile в России. Agile-трансформация превратила Сбербанк из бюрократизированной структуры в IT-лидера с высоким уровнем сервиса.
Модель Spotify
- Squad (команда / отряд).
- Chapter (части). Группы по компетенциям в рамках команд. В каждой команде есть, например, QA, DevOps, Backend, Frontend. Для каждой части есть свой руководитель.
- Guild. Объединяют сотрудников по интересам на уровне всей компании. Этот срез нужен для коммуникации людей на уровне интересов, чтобы взаимно задавать вопросы и обучать друг друга
- Tribe (Клан / Племя либо близкое департамент). Содержит до 150 человек и объединяет команды с общей миссией.
- Pollination (Опыление). Команды в Spotify достаточно автономны, но за счёт высокого уровня коммуникации, мы получаем повышение эффективности через обмен знаниями между командами.
Но так же в Spotify важную роль играют:
- Релизные поезда - это процесс синхронизации релизов нескольких команд, которые взаимосвязаны друг с другом
- Feature toggle - переключатель для включения использования фичи в проекте или их отключения, если фича не готова полностью или что-то ломает.
Особенности в Sbergile
В подходе от Сбербанка больше стандартов / предписаний и меньше автономности для команд.
Сбербанк адаптировал Agile под свои нужды, учитывая большие риски и важность дисциплины для государственно-важной финансовой организации.
- Сервисная команда - разработка определённого сервиса - Kanban
- Продуктовая команда - разработка нового продукта - Scrum
- Несколько продуктовых команд - несколько команд для одного продукта - LeSS
Под все команды детально описаны роли, которых около 20 типов, способствующих чёткому распределению ответственности.
Культура и Ценности
Культура ест стратегию на завтрак - Дэйв Логан “Лидер и Племя”
Ценности → Культура → Стратегия
Модель Зрелости Kanban, посвящённая Культуре - “Результаты следуют за Практиками. Практики следуют за Культурой. Культура следует за Ценностями. И поэтому, Развивайте Ценности!”
Сбербанк акцентирует внимание на пропаганде внутренних ценностей и на развитии коммуникации и взаимодействия между сотрудниками.
SAFe
SAFe (Scaled Agile Framework) - это комплексная модель для обеспечения гибкости и масштабирования agile-практик в крупных организациях.
- SAFe интегрирует Scrum и Kanban в рамках большего, более организованного подхода к разработке
- Kanban адаптирован и используется в рамках Agile
- Team Coach = Scrum Master
Сфера применения
- Разработан для больших компаний (от 50 до нескольких тысяч сотрудников) для перехода к agile на масштабном уровне.
- Часто используется в банках и крупных программных компаниях.
Основные компоненты SAFe
- Фундамент: Содержит информацию о мышлении Lean-Agile, принципах и подходах.
- Essential SAFe: Ядро фреймворка, сосредотачивающееся на командной работе и Agile Release Train (ART).
- Large Solution: Дополняет Essential, включает инструменты для координации нескольких ART.
- Portfolio: Управление стратегическими инициативами, ресурсами, рисками на уровне всей компании.
Так же на модели слева от уровней располагаются роли, которые фигурируют на разных уровнях SAFe. Ещё левее находятся основные принципы, которые позволяют сделать бизнес ещё более адаптивным и гибким. Справа описаны практики, которые могут пригодиться на разных уровнях SAFe.
Часто компании берут не Full конфигурацию, а только Essential, так как у них нет потребности полностью реализовывать всю схему
Ключевые элементы
- Agile Release Train (ART) - это средство для объединения релизов множества команд по единому потоку ценностей (применимо как для одного продукта, так и для множества других).
- Команды делятся на 5-12 agile-подкоманд, которые уже, в свою очередь, делятся на 50-150 человек.
- ART: менеджмент, RTE, архитектор, бэклог
- Команда: PO, SM/TC, участники, бэклог
- Все команды работают по интервалу планирования (PI).
- ART sync (Coach Sync + PO Sync), System Demos. Стратегические встречи для координации работы внутри ART.
RTE - это над-роль на уровне Поезда, похожая на Scrum-мастера, т.е. лидер-слуга, который фасилитирует общие встречи, консультирует, помогает наращивать продуктивность и так далее
Системный архитектор - это роль, ответственная за согласованность технической и системной составляющей на уровне Поезда
Интервалы планирования (PI) - это временной интервал, в рамках которого команды Agile-разработчиков непрерывно приносят пользу клиентам в соответствии с целями PI.
- Он включает планирование на 8-12 недель
- Делится на: итерации работы и по одной итерации для инноваций и планирования.
PI планирование - это длительный процесс, который длится два дня и все причастные к работе лица выстраивают план работ на следующую итерацию.
System Demos - это события, которые проходят в конце каждой итерации и позволяют получить обратную связь на результат всех участников поезда.
Заключение
SAFe - это мощный инструмент для масштабируемой Agile-трансформации в крупных компаниях, объединяющий лучшие практики Scrum, Kanban и Lean для достижения более высокой производительности и адаптивности бизнес-процессов.