The Scrum Framework — второе издание

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

---

Несколько Scrum-команд:
Лучшие практики гибкого управления проектами

Управление несколькими Scrum-командами похоже на направление стада талантливых овец: каждая команда уникальна, но движется к общей цели. Этот метод повышает эффективность и скорость и позволяет работать со сложными проектами с разными техническими задачами. Интересно, что дело не только в масштабируемости или быстрой поставке продуктов, но и в использовании разных навыков, чтобы одновременно заниматься каждой историей, функцией и трудностью. Теперь рассмотрим оптимальную структуру таких команд.

Управление и координация нескольких Scrum-команд требуют структурированного подхода: ясных каналов общения, синхронизированных циклов Спринтов и регулярных совместных встреч, например Scrum of Scrums. Важно установить общий бэклог продукта, обеспечить прозрачность общей работы и учитывать зависимости для успешного межкомандного сотрудничества.

Преимущества нескольких Scrum-команд

Наличие нескольких Scrum-команд может дать проекту разные преимущества, улучшая его результаты. Рассмотрим их подробнее.

Повышенная масштабируемость

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

Это особенно полезно в сложных проектах, требующих межфункционального сотрудничества и разных навыков. Распределяя работу между командами с уникальными компетенциями, организации могут учесть все аспекты проекта и эффективно использовать необходимые навыки.

Эффективная работа со сложными проектами

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

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

Более быстрая поставка продуктов или функций

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

Используя общие усилия нескольких команд, организации также могут оптимизировать рабочие потоки и циклы разработки. Одновременная работа с пользовательскими историями, функциями и техническими трудностями делает создание продукта эффективнее, принося пользу организации и конечным пользователям.

Более гибкое распределение ресурсов

Несколько Scrum-команд дают организациям большую гибкость распределения ресурсов. Можно менять размеры команд с учётом требований, выделять специальные ресурсы и быстро приспосабливаться к новым потребностям. Это позволяет эффективно отвечать на изменения проекта и оптимизировать использование ресурсов по приоритетным областям.

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

Эти преимущества показывают, что несколько Scrum-команд дают не только больше возможностей и эффективности, но и лучшую адаптацию к меняющимся требованиям.

Изучая гибкие подходы, важно понимать работу нескольких Scrum-команд. Теперь перейдём к тонкостям их организации для максимальной эффективности.

Scrum of Scrum

Для координации разных Scrum-команд можно проводить встречи Scrum of Scrum. Они похожи на Ежедневный Scrum, но внимание направлено на уровень команд.

В этом практическом примере встреча проходит ежедневно и ограничена, например, 15 минутами. Scrum не требует Scrum of Scrums и не предписывает частоту или длительность. Каждая команда направляет одного участника, который отвечает на вопросы:

• Что команда завершила?
• Что команда планирует завершить сегодня?
• Есть ли препятствия?

Ответы должны сосредоточиваться на том, что влияет на другие команды.

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

Общие Обзоры Спринта

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

Общие Ретроспективы Спринта

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

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

Межкомандное планирование — бэклог продукта Scrum

Несколько команд одного продукта используют единый бэклог продукта и одного ответственного Владельца. В этом историческом примере координации такую ответственность несёт человек с названием «главный Владелец продукта Scrum», работающий со специалистами или делегированными контактными лицами; они не являются независимыми Владельцами того же продукта.

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

Расписание Спринтов

В распределённом Scrum можно выбирать способ синхронизации команд. Один из вариантов — синхронные Спринты, когда все команды начинают и заканчивают их в один день.

Синхронные Спринты — самый простой подход, облегчающий общение и координацию.

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

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

Оценки трудоёмкости

Общему прогнозу нужны совместимые единицы и ясные допущения. Если команды выбирают для этого общую шкалу стори-пойнтов, им следует совместно её откалибровать; Scrum не требует универсальных значений или сравнений скоростей команд. Если работа охватывает компоненты, привлекайте людей, понимающих все усилия и зависимости.

Организация ваших Scrum-команд

Для максимального раскрытия возможностей нескольких Scrum-команд необходима продуманная структура. Рассмотрим две эффективные модели —Разделение по функциям или компонентам и Матричная структура— и их пользу для гибкого управления проектами.

Разделение по функциям или компонентам

В этой структуре команды организуют по конкретным функциям или компонентам продукта. При компонентном подходе одна команда может отвечать за интерфейс, другая — за базы данных. Функциональная команда, напротив, объединяет навыки для полного пользовательского результата. Это разные структуры с разными компромиссами интеграции. Такое разделение даёт ряд преимуществ:

• Сосредоточенные компетенции: Каждая команда становится экспертом своей области, глубже понимает её и эффективнее решает проблемы.
• Быстрое принятие решений: Отвечая за определённые функции, команды могут быстро принимать локальные решения. Функциональные команды полного цикла могут сокращать зависимости; одна компонентная специализация их не устраняет.
• Более быстрая поставка: Сосредоточившись на отдельных функциях или компонентах, команды могут быстрее поставлять решения, становясь более самостоятельными и продуктивными.

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

Матричная структура

Ещё один подход к организации нескольких Scrum-команд — матрица. В этой гибридной модели у людей могут быть функциональные и проектные линии подчинения за пределами Scrum-команды. Это организационное решение, а не требование Scrum; оно не должно отменять самоуправление команды или ответственность Владельца продукта за бэклог. Матричная структура даёт несколько преимуществ:

• Эффективное общение: Благодаря двойным линиям подчинения информация свободнее передаётся между участниками и разными функциональными областями.
• Среда, ориентированная на сотрудничество: Эта структура поддерживает сотрудничество людей из разных подразделений, которые вместе работают над проектами, обмениваясь взглядами и компетенциями.
• Соответствие целям организации: Понимая и функциональные приоритеты, и цели проекта, команды лучше согласуют работу с общими целями организации и стратегическими инициативами.

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

Продуманная организация создаёт основу сплочённых высокоэффективных Scrum-команд — через сосредоточенные компетенции разделения по функциям или компонентам либо через слаженное сотрудничество матричной модели.

Понимать важность структуры Scrum-команд необходимо для оптимальных результатов. Теперь рассмотрим ещё один важный аспект управления несколькими командами — преодоление коммуникационных трудностей.

Преодоление коммуникационных трудностей

Управляя несколькими Scrum-командами, бывает непросто сохранять общее понимание. Эффективное общение необходимо, чтобы каждая знала свою роль, зависимости и прогресс остальных. Без него возникают риски рассогласования, дублирования усилий и упущенных возможностей сотрудничества.

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

Например, одна команда завершила задачу, которую ждала другая, но из-за плохого общения вторая этого не знает. Она задерживает свою работу, полагая, что первая ещё занята задачей. Недостаток прозрачности и общего понимания создаёт ненужные преграды.

Чтобы преодолеть трудность и поддержать общение нескольких Scrum-команд, рассмотрите регулярные Scrum of Scrums и инструменты сотрудничества как часть стратегии гибкого управления проектами.

Регулярные встречи Scrum of Scrums

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

Например, представители могут делиться прогрессом и вопросами межкомандного взаимодействия. Это помогает понимать влияние своей работы на других и упреждающе решать проблемы. Регулярные обсуждения позволяют заранее выявлять конфликты и недоразумения и устранять их до обострения.

Использование инструментов сотрудничества

Современные средства, например Jira, Trello или Microsoft Teams, помогают слаженно общаться, делиться обновлениями, отслеживать зависимости и сохранять прозрачность всех команд.

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

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

Вооружившись такими методами управления несколькими Scrum-командами, далее рассмотрим лучшие практики формирования высокоэффективных кросс-функциональных команд.

Лучшие практики формирования кросс-функциональных команд

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

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

Представьте дизайнеров, Разработчиков и тестировщиков, совместно создающих новую функцию. Эстетическое чутьё дизайнера обеспечивает привлекательность и удобство; технические знания Разработчика — слаженную функциональность; внимание тестировщика к деталям — качество и надёжность. Такой целостный подход даёт разносторонний качественный результат.

Ещё одна важная практика — ротация. Периодическое перемещение участников между Scrum-командами способствует обмену знаниями и идеями. Это разрушает обособленность и предотвращает чрезмерно узкую сосредоточенность на своей области.

Например, Разработчик одной команды временно присоединяется к другой, делясь компетенциями в решении сложных технических задач. Он не только решает проблемы, но и передаёт знания и лучшие практики. Так же тестировщики могут изучать стратегии друг друга, а дизайнеры — обмениваться новаторскими принципами проектирования.

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

Эти лучшие практики формирования кросс-функциональных команд создают условия эффективного гибкого управления проектами и рабочую среду совместного решения проблем и непрерывного совершенствования.

Эффективная поставка программного обеспечения требует структурированного подхода, согласованного с рассмотренными гибкими методами. Теперь изучим, как организации обеспечивают её в современной быстро меняющейся технологической среде.

Обеспечение эффективной поставки программного обеспечения

Эффективная поставка программного обеспечения крайне важна для гибкого управления проектами. Она включает согласование процессов и стандартов ради целостного качественного продукта. Начнём с ключевых аспектов успешной поставки в Agile-проектах.

Согласование Определения готовности (DoD)

Согласование Определения готовности (DoD) всех Scrum-команд необходимо для стабильного соответствия стандартам качества и критериям приёмки. DoD служит списком обязательных требований, которые нужно выполнить, прежде чем считать историю завершённой. Общие стандарты обеспечивают понимание и соблюдение одинаковых ожиданий к каждому Инкременту. Это формирует общее понимание качества и полноты и способствует поставке единого качественного продукта.

Непрерывная интеграция и развёртывание (CI/CD)

Внедрение конвейеров непрерывной интеграции и развёртывания (CI/CD) — ещё один важный элемент эффективной поставки. Они автоматизируют сборку, тестирование и развёртывание, облегчая быструю интеграцию изменений кода и слаженную поставку Инкрементов конечным пользователям.

Внедрение конвейеров CI/CD способствует:

• Более быстрой обратной связи: CI/CD помогает раньше выявлять ошибки и дефекты разработки, немедленно их исправлять и уменьшать влияние на следующие этапы.
• Улучшению сотрудничества: Автоматизация интеграции и развёртывания позволяет командам разработки и эксплуатации эффективнее сотрудничать и синхронизироваться на протяжении всего жизненного цикла поставки.
• Снижению рисков: Автоматизированное тестирование в CI/CD уменьшает ручное вмешательство и человеческие ошибки, обеспечивая тщательную проверку каждого Инкремента перед развёртыванием.

Например, после фиксации изменений кода в системе контроля версий конвейер CI/CD запускает автоматические тесты новой функциональности. Обнаруженные проблемы сразу передаются команде разработки для устранения, чтобы в продукт интегрировался только стабильный надёжный код.

Согласуя Определение готовности и внедряя CI/CD, Agile-команды создают надёжную основу эффективной поставки Инкрементов при соблюдении стандартов качества. Эти практики — основа упорядоченного процесса поставки, отвечающего требованиям клиентов и рынка в динамичной бизнес-среде.

Разобравшись в эффективной поставке программного обеспечения, теперь рассмотрим оптимизацию поставки бизнес-ценности в гибком управлении проектами.

Оптимизация поставки бизнес-ценности

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

Совместное согласование ради бизнес-ценности

Представьте группу Владельцев продукта хорошо сыгранным оркестром. У каждого музыканта (Владельца продукта) своя партия, но тесное сотрудничество гармонизирует усилия и создаёт особенный значимый результат. Координация предотвращает конфликт приоритетов и ведёт к общей цели — максимальной бизнес-ценности.

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

Согласованные метрики и ключевые показатели эффективности

Ещё один важный аспект оптимизации бизнес-ценности нескольких Scrum-команд — согласованные метрики и ключевые показатели эффективности (KPI). Имея стандартизированные метрики, например время цикла, время от запроса до поставки и удовлетворённость клиентов, вы можете эффективно измерять и оптимизировать общую поставку ценности. Это направляет все команды на содержательные бизнес-результаты.

Согласованные определения помогают анализировать результаты и зависимости со временем. Рассматривайте различия в контексте, а не ранжируйте команды по сырым стори-пойнтам и не предполагайте прямую сравнимость разной работы. Это также обеспечивает межкомандную прозрачность и улучшает решения на основе данных.

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

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

Оптимальная поставка бизнес-ценности требует стратегического согласования Владельцев продукта и общих метрик. Эти практики улучшают результаты и укрепляют культуру единства и ответственности Scrum-команд.

Какие основные факторы нужно учитывать при масштабировании до нескольких Scrum-команд?

Ответ: основные факторы — эффективное межкомандное общение и сотрудничество, согласование приоритетов и целей, планирование и распределение ресурсов и непрерывное совершенствование через регулярную обратную связь. Исследования показывают, что организации, успешно масштабирующие Agile-практики, добиваются большей успешности проектов, продуктивности и удовлетворённости клиентов (источник: State of Agile Report).

Какие примеры организаций показывают эффективное использование нескольких Scrum-команд?

Ответ: один из успешных примеров — Spotify. Компания внедрила «модель Spotify», организовав разработку в автономные кросс-функциональные скводы, трайбы, чаптеры и гильдии. Это усилило сотрудничество, ускорило выход на рынок и повысило продуктивность. Согласно практическому исследованию McKinsey & Company, после внедрения модели Spotify сообщила о сокращении сроков поставки на 20% и росте удовлетворённости сотрудников на 20%.

Как несколько Scrum-команд могут повысить сотрудничество и продуктивность?

Ответ: через межкомандное общение, обмен знаниями и ресурсами и культуру сотрудничества. Это улучшает координацию и согласование усилий, повышая эффективность и ускоряя поставку качественных продуктов. Согласно исследованию McKinsey & Company, организации с сотрудничающими командами в 5 раз чаще демонстрируют высокую результативность.

Какие стратегии обеспечивают эффективную координацию и согласованность нескольких Scrum-команд?

Ответ: прежде всего общее видение и ясные цели сохраняют общий фокус. Регулярное общение, например ежедневные стендапы и Обзоры Спринта, поддерживает прозрачность и сотрудничество. Межкомандные зависимости нужно выявлять и прорабатывать заранее, избегая узких мест. Kanban-доски и средства управления проектами также повышают прозрачность и облегчают координацию. Согласно опросу Scrum.org, организации, эффективно согласующие и координирующие Scrum-команды, наблюдают средний рост общей продуктивности на 25%.

Как эффективно управлять конфликтами и зависимостями нескольких Scrum-команд?

Ответ: конфликтами и зависимостями нескольких Scrum-команд можно эффективно управлять с помощью ряда стратегий. Во-первых, открытое общение и сотрудничество помогают рано выявлять и решать конфликты. Во-вторых, межкомандные методы координации, например Scrum of Scrums или Agile-управление программами, дают структуру управления зависимостями и согласования усилий. Наконец, выделенный Agile-руководитель проекта или Scrum-мастер с сильными навыками ведения может существенно помочь разрешению конфликтов и управлению зависимостями. Согласно опросу VersionOne, организации, активно управляющие зависимостями нескольких Scrum-команд, добиваются большей успешности проектов и удовлетворённости клиентов.

Должна ли каждая Scrum-команда вести отдельный бэклог продукта, если они вместе работают над одним продуктом?

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

Что должен вести Владелец продукта, если несколько команд работают над одним продуктом?

Ответ: Владелец продукта должен вести единый консолидированный бэклог продукта. Он обеспечивает общее видение и приоритизацию всего продукта. Централизованный бэклог позволяет обоснованно решать приоритеты функций, улучшений и общего направления. Подход поддерживает прозрачность, уменьшает дублирование и эффективнее распределяет ресурсы между командами. Регулярное общение и сотрудничество необходимы для учёта зависимостей, уточнения элементов и соответствия меняющимся потребностям заинтересованных сторон и рынка.

Основные выводы о нескольких Scrum-командах

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

Основные выводы

• Создание сообщества: Живое сообщество необходимо для успеха нескольких Scrum-команд. Оно включает эффективное общение, сотрудничество и общую приверженность принципам Agile.
• Роли и ответственность: Ясные роли, например Scrum-мастера и заинтересованные стороны, обеспечивают подотчётность и упорядочивают рабочий поток. Понимание особых обязанностей каждой роли необходимо для полноценной Agile-среды.
• Церемонии и события: Регулярные события — Планирование Спринта, ретроспективы и ежедневные стендапы — сердцебиение Agile-разработки. Эти структурированные встречи поддерживают сотрудничество, прозрачность и непрерывное совершенствование команды.
• Обучение и итерации: Культура обучения и итеративной разработки лежит в основе Scrum. Команды должны приоритизировать непрерывное совершенствование и адаптивность для эффективной поставки ценности заинтересованным сторонам.
• Самостоятельность и самоорганизующиеся команды: Возможность самоорганизации поддерживает творчество и причастность. Самостоятельность в определённых границах ведёт к более эффективному решению проблем и инновациям.
• Приоритизация и скорость команды: Приоритизация задач и понимание скорости необходимы для эффективного управления проектами. Они помогают сосредоточиваться на наиболее важном и поддерживать устойчивый темп разработки.

Заключительные мысли о нескольких Scrum-командах

В динамичной среде управления несколькими Scrum-командами поддержка коуча незаменима. Он не только направляет к совершенству Agile, но и стимулирует сотрудничество и постоянное улучшение. Однако эффективность требует не одного коучинга, но и неизменной поддержки руководства. Лидеры создают условия успеха Agile. Ретроспективы становятся общим обязательством: команды осмысливают результаты и совместно уточняют стратегии. По мере продвижения сочетание коуча, поддержки руководства и ретроспектив движет команды к устойчивому росту и инновациям.

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