Размер шрифта
Цвет фона и шрифта
Изображения
Озвучивание текста
Обычная версия сайта
Российская платформа управления
проектами по принципам Agile
+7 (800) 101-08-31
+7 (800) 101-08-31
Заказать звонок
E-mail
c@aspro.ru
Адрес
454021, г. Челябинск, ул. Молодогвардейцев, 31, 8 этаж
Режим работы
Пн. – Пт.: с 9:00 до 18:00
Регистрация
Возможности
Кейсы
Блог
Тарифы
Контакты
Возможности
Кейсы
Решения
  • Для команд на удаленке
  • Для IT-разработки
  • Для ВУЗов
Тарифы
Блог
    +7 (800) 101-08-31
    Войти
    Регистрация
    Возможности
    Кейсы
    Решения
    • Для команд на удаленке
    • Для IT-разработки
    • Для ВУЗов
    Тарифы
    Блог
      +7 (800) 101-08-31
      Войти
      Регистрация
      Телефоны
      +7 (800) 101-08-31
      Заказать звонок
      E-mail
      c@aspro.ru
      Адрес
      454021, г. Челябинск, ул. Молодогвардейцев, 31, 8 этаж
      Режим работы
      Пн. – Пт.: с 9:00 до 18:00
      • Возможности
      • Кейсы
      • Решения
        • Решения
        • Для команд на удаленке
        • Для IT-разработки
        • Для ВУЗов
      • Тарифы
      • Блог
      Войти
      Регистрация
      • +7 (800) 101-08-31
        • Телефоны
        • +7 (800) 101-08-31
      • 454021, г. Челябинск, ул. Молодогвардейцев, 31, 8 этаж
      • c@aspro.ru
      • Пн. – Пт.: с 9:00 до 18:00

      Играем по-крупному: фреймворки для масштабирования Agile

      Главная
      —
      Блог
      —
      Статьи
      —Играем по-крупному: фреймворки для масштабирования Agile
      30 июня 2023

      Agile и его модели управления хорошо зарекомендовали себя в небольших командах и стартапах. Ведь построить горизонтальную команду из небольшой группы людей куда проще, чем на тех же принципах наладить работу крупной организации.

      Однако с ростом компаний и увеличением штата начинаются сложности. В основе гибких методологий лежит распределение ответственности, а в больших командах с этим уже сложнее. Как правило, крупные коллективы переходят от Agile к директивным и вертикальным схемам работы. Самоорганизованные команды превращаются в простых исполнителей, а сама суть Agile теряется.

      Как же быть, если команду нужно наращивать, а терять гибкость не хочется? Ответ прост: Agile следует масштабировать.

      Это не значит, что стоит пытаться на тех же началах организовать работу уже десятков и сотен сотрудников. Стендап на 150 человек — это не масштабирование Agile, а трата времени. Работать в том же формате с увеличенной командой не получится.
      Масштабирование Agile предполагает организацию взаимодействия между продуктовыми командами. Они сохраняют свою продуктивность, но действуют как одно целое уже в больших масштабах.

      В этой статье мы поговорим о нескольких фреймворках, которые помогают перенести принципы Agile на работу более крупных коллективов и построить взаимодействие между несколькими командами.

      Scrum of Scrums

      Самый простой и сравнительно популярный фреймворк — Scrum of Scrums (SoS). Как можно догадаться по названию, он предполагает кооперацию нескольких Scrum-команд.

      Но для начала освежим в памяти несколько фактов. Во-первых, держим в уме, что количество участников Scrum-команды не должно превышать 10 человек. Во-вторых, состав ее следующий:

      • Scrum-мастер;
      • владелец продукта;
      • разработчики.

      Для применения Scrum of Scrums нужно разбивать эти единицы на более автономные. Структурировать команды можно несколькими способами.

      Способ первый. Подходит, если в компании трудится несколько независимых Scrum-команд над разными продуктами. Достаточно будет выделить владельцев продукта из каждой — их собрание и будет отвечать за общую стратегию и координацию между разработчиками из разных команд.

      Scrum of Scrums: схематично

      Способ второй. Предположим, несколько Scrum-команд в компании работают над одним сложным продуктом. Например, CRM-системой, состоящей из множества разных модулей. Разработчики не успевают, командам не хватает согласованности — отсутствие кооперации оборачивается повторными проверками, двойной работой и долгим рефакторингом кода. Scrum of Scrums предлагает раздробить и пересобрать все команды:

      • Разработчики со всех команд объединяются, а затем дробятся на автономные единицы по 1-3 человека во главе с опытным коллегой-наставником. Ключевой признак — компетенции группы.
      • На всех разработчиков будет достаточно 1-2 Scrum-мастеров.
      • Владельцы продукта также собираются в небольшую отдельную команду для решения операционных вопросов.

      Scrum of Scrums для крупных коллективов

      Scrum of Scrums может использоваться как отдельный инструмент организации рабочего процесса в более сложных фреймворках масштабирования Agile. 

      Кроме того, его можно масштабировать до более высоких уровней во фреймворк Scrum@Scale. Он предполагает создание целой экосистемы из множества команд на основе Scrum of Scrums.

      LeSS

      LeSS (сокращение от Large Scale Scrum — Scrum в крупных масштабах) — это методика применения принципов Scrum в крупных проектах или нескольких Scrum-командах одновременно. В общих чертах LeSS предполагает частичное сращение команд.

      У LeSS есть 2 варианта реализации — классический LeSS и LeSS Huge.

      LeSS классический

      Стандартный LeSS подходит для организаций, где над одним продуктом совместно трудится от 2 до 8 команд. Однако в отличие от SoS, LeSS предполагает, что у всех Scrum-команд будут общие:

      • владелец продукта;
      • бэклог с задачами;
      • спринты;
      • мероприятия по планированию и обзору спринтов.

      В остальном принципы Scrum применяются как обычно: команды работают по Scrum в том же режиме, но отчитываются одному владельцу продукта.

      LeSS: Scrum для нескольких команд

      LeSS Huge

      Приставка Huge (огромный, гигантский) говорит о масштабе применения методики. LeSS Huge помогает организовать работу коллективов, численность которых может достигать 100 человек, разбитых на 8 и более команд.

      В LeSS Huge речь также идет о группе команд с одним владельцем продукта. При этом в силу масштаба вся работа делится на области требований (Requirement Areas). Это не конкретные части продукта, а скорее направления, по которым группируется функционал продукта.

      Вернемся к примеру с разработчиками CRM-системы со множеством модулей. Допустим, одна часть ее модулей связана с управлением финансами, а другая — с управлением проектами. Получается следующая картина:

      • Финансы и проекты — это области требований.
      • По областям требований разбивается бэклог.
      • Одна область может распределиться между несколькими командами, каждая из которых работает над конкретным модулем.

      В помощь владельцу продукта также создается команда помощников — Area Product Owners, дословно «владельцы области продукта». За каждым из APO закрепляется своя область.

      LeSS Huge: Scrum для очень крупных команд

      Модель Spotify

      Довольно замысловатую структуру продуктовых команд реализовали разработчики музыкального сервиса Spotify. От компании модель и получила свое название.

      Как выглядит команда в модели Spotify

      Она уже значительно отступает от Scrum, но использует некоторые его элементы в своей основе. Структура команды представлена в виде матрицы и делится на следующие элементы:

      Клан (tribe) — это группа в 100-200 разработчиков, задействованных в работе над конкретным продуктом или проектом. Основная единица в модели Spotify. Именно клан и превращен матрицу.

      Отряд (squad) — самоорганизующаяся кросс-функциональная команда, аналог Scrum-команды. В отряде задействованы разные специалисты. Например, фронтендер, UX-дизайнер и копирайтер. Они реализуют новый функционал.

      Отдел (chapter) — функциональная группа, которая контролирует работу конкретных специалистов из разных команд. Например, отдел фронтенда, отдел UX-дизайна, отдел копирайтинга и т.д.

      Отделы существуют параллельно отрядам, но решают общие организационные вопросы и отвечают за обмен знаниями и применение инструментов внутри конкретных проектов компании или кланов. Например, решает, какой стек используют фронтендеры, создают редполитику и Tone of Voice для копирайтеров.

      Аналогичные операционные вопросы в рамках всей компании или нескольких структурных подразделений решают схожие единицы — гильдии (guilds).

      Кроме того, в компании могут существовать и другие структуры более высоких уровней. Например, за кооперацию разработчиков разных продуктов, которые как-то связаны между собой, могут отвечать бизнес-юниты (business units).

      Таким образом, один разработчик может принадлежать сразу к нескольким разным коллективам внутри одной компании.

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

      SAFe

      SAFe (сокращение от Scaled Agile Framework — «масштабированный фреймворк для Agile») — один из наиболее популярных организационных фреймворков для крупных компаний. Технически это целая платформа для построения организационных и рабочих процессов. SAFe реализует одновременно принципы бережливого производства и манифеста Agile-разработки.

      Цель SAFe — создать из крупной организации гибкую систему, которая позволяет легко управлять разработкой нескольких разных продуктов или проектов, а также обеспечивать согласованное взаимодействие между разными Agile-командами.

      Ключевые моменты SAFe:

      • SAFe выстраивает многоуровневую иерархическую структуру, которая делится на уровни Портфеля, Программы и Команды. На каждом уровне есть свои роли, зоны ответственности и артефакты.
      • Большое внимание в SAFe уделяется координации и синхронизации работы между командами и уровнями. Для этого проводятся регулярные мероприятия по планированию итерации, а на разных уровнях нередко используется упомянутый ранее Scrum of Scrums.
      • SAFe также предоставляет набор методов для управления зависимостями между командами и уровнями проектов. Так сводятся к минимуму риски, связанные с интеграцией различных частей продукта.
      • Во многом SAFe основан на сочетании принципов Lean и Agile — устранении потерь, регулярном сборе обратной связи, постоянном совершенствовании, а также гибкости в работе и планировании. SAFe поощряет и включение в рабочие процессы практик из Kanban и других гибких методологий с поправкой на масштабирование.

      Как работает фреймворк SAFe


      SAFe считается один из самых сложных фреймворков в реализации. Руководитель, который выстраивает работу компании по SAFe, должен непременно учитывать множество факторов и добиваться слаженности между разными командами и уровнями всей системы. При этом несостоятельность какой-либо части структуры может привести к тому, что SAFe просто не будет работать.

      Enterprise Scrum

      Майк Бидл, один из создателей манифеста Agile, в 2010-х работал над созданием своего фреймворка для масштабирования — Enterprise Scrum («Scrum для бизнеса»).

      В основе Enterprise Scrum лежит идея перехода от разработки конкретного продукта к регулярной поставке ценности для пользователя, а уровень управления от одной команды переносится на бизнес в целом. Соответственно, роль владельца продукта превращается во владельца бизнеса (business owner).

      Работу по Enterprise Scrum Бидл основывал на следующих принципах:

      • Руководитель отслеживает не только производительность команды, а сразу множество метрик. Сколько и каких — владелец бизнеса решает сам. Важно отслеживать баланс и взаимосвязи между ними.
      • Роль Scrum-мастера также превращается в роль коуча. Он следит не только за соблюдением ритуалов Scrum, но и за эмоциональным состоянием команды.
      • Для работы над общими целями несколько Scrum-команд могут объединяться на основе Scrum of Scrums.
      • Фреймворк поощряет эксперименты. Enterprise Scrum не запрещает добавлять в рабочие процессы различные практики из других методологий. Например, WIP-лимиты из Kanban.
      • В основе разработки лежит не решение конкретных задач, а реализация пользовательских историй. Команды поставляют не просто продукт или его часть, а какую-либо ценность (business value).

      Под ценностью можно понимать, например, функционал для приложения, который реализует конкретную потребность клиентов: заказ на несколько адресов одновременно в приложении для доставки еды или новый способ оплаты.

      Увы, документация для Enterprise Scrum так и не была полностью закончена. В 2018-м Майк Бидл умер. Поэтому фреймворк не нашел широкого распространения и в полном виде практически не используется.

      Итоги

      Ни один фреймворк, каким бы простым, сложным или эффективным он не был — не панацея. Прежде чем выбирать, какой-либо способ организации рабочих процессов, важно тщательно проанализировать, в каком состоянии находится компания и готова ли она вообще масштабироваться.

      Помните, что важны не правила и фреймворки, а люди и взаимодействие между ними. Ну а организовать работу команды, будь это автономная единица или часть крупной компании, вам поможет Аспро.Agile.

      Проекты
      Гибкое управление наукой: как СибГИУ перешли на Аспро.Agile
      Гибкое управление наукой: как СибГИУ перешли на Аспро.Agile
      «Для нас удобнее, чем планировщик ToDo от Microsoft», — команда разработчиков выбрала российский таск-трекер
      «Для нас удобнее, чем планировщик ToDo от Microsoft», — команда разработчиков выбрала российский таск-трекер
      Статьи
      Статьи
      11 января 2023
      Scrum и Kanban: сходства и различия
      Модель управления, в которой руководитель раздает поручения, а сотрудники регулярно по ним отчитываться, постепенно изживает себя. Современные управленцы чаще склоняются в сторону прозрачных рабочих моделей. Сдвиг этот происходит во многом благодаря гибким методологиям. Kanban — одна из них.
      Статьи
      27 сентября 2022
      Agile-подход: почему он появился
      Назад к списку
      • Обновления 20
      • Статьи 21
      • Видео 24
      • СМИ о нас 1
      Возможности
      Кейсы
      Блог
      Контакты
      Документация
      Руководство по Agile
      API
      Сравнение сервисов
      Реферальная программа
      +7 (800) 101-08-31
      +7 (800) 101-08-31
      Заказать звонок
      E-mail
      c@aspro.ru
      Адрес
      454021, г. Челябинск, ул. Молодогвардейцев, 31, 8 этаж
      Режим работы
      Пн. – Пт.: с 9:00 до 18:00
      c@aspro.ru
      © 2023 Аспро.Agile
      Лицензионное соглашение Политика конфиденциальности
      Главная Кейсы Блог Тарифы