Руководство по скраму | 16. Масштабирование Скрама

Опубликовано: 2022-05-16

Скрам-команда должна состоять из десяти человек. Но что делать, когда над одним проектом должна работать большая группа специалистов? Или если организация решит следовать гибкому способу управления? Чтобы решить эту проблему, разработчики Scrum предложили [email protected] Это безмасштабная архитектура для организации целых команд по принципам Scrum.

Масштабирование Scrum – содержание:

  1. Введение
  2. [электронная почта защищена]
  3. Скрам из скрамов
  4. Дальнейшее масштабирование и проблемы [email protected]
  5. Резюме

Введение

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

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

Большинство организаций, применяющих гибкие методы управления в масштабе, выбирают модель SAFE или Scaled Agile Framework. Однако сегодня мы не будем сосредотачиваться на SAFE , а обсудим другую модель под названием [защищенная электронная почта] , поскольку, согласно 15-му отчету State of Agile за 2021 год, это второй лучший выбор среди компаний, которые выбирают agile.

[электронная почта защищена]

В 1996 году создатели Scrum Джефф Сазерленд и Кен Швабер работали над большим проектом. Пока они это делали, у них возникли проблемы с синхронизацией небольших команд, работающих в Scrum. Они придумали способ его масштабирования, который в итоге назвали [email protected]

Аналогом официального Scrum Guide было [email protected] Guide , которое определяет этот способ масштабирования работы как:

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

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

Скрам из скрамов

Scrum of Scrums — это скрам-команда, в которой люди играют традиционные скрам-роли. Однако, поскольку задача Scrum of Scrums — интегрировать результаты работы нескольких Scrum Teams, ей нужны дополнительные посты:

  • Команда владельцев продукта — группа владельцев продукта, которые встречаются для согласования приоритетов и создания единого видения продукта.
  • Главный владелец продукта - владелец продукта Scrum-команды или лицо, которое занимается исключительно Scrum of Scrums.
  • Scrum of Scrums Master — человек, который наблюдает за эффективностью Scrum of Scrums.

Они встречаются на одних и тех же Scrum Events и используют схожие Артефакты.

Scaling Scrum

Дальнейшее масштабирование и проблемы [email protected]

Немасштабируемая архитектура [email protected] означает , что она позволяет выполнять масштабирование более одного раза. Если организации необходимо координировать команды в еще большем масштабе, она может организовать Scrum of Scrums.

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

scaling

Масштабирование Scrum — резюме

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

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

Если вам нравится наш контент, присоединяйтесь к нашему сообществу занятых пчел в Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 16. Scaling Scrum caroline becker avatar 1background

Автор: Кэролайн Беккер.

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

Просмотреть все сообщения

Руководство по скраму:

  1. Глоссарий основных терминов, ролей и понятий
  2. Что такое Скрам?
  3. Скрам-ценности
  4. Как внедрить Scrum в вашей компании?
  5. Скрам-команда — что это такое и как она работает?
  6. Кто такой владелец продукта?
  7. Самые распространенные ошибки владельца продукта
  8. Кто такой скрам-мастер?
  9. Характеристики хорошего скрам-мастера
  10. Самые распространенные ошибки скрам-мастера
  11. Какую статистику и показатели должен отслеживать скрам-мастер?
  12. Сотрудничество между владельцем продукта и скрам-мастером
  13. Команда разработчиков в Scrum
  14. Самые распространенные ошибки разработчиков
  15. Скрам артефакты
  16. Масштабирование Скрама
  17. Бэклог спринта
  18. Что такое бэклог продукта?
  19. Что такое пользовательские истории?
  20. Создание лучшей пользовательской истории с INVEST
  21. Самые распространенные ошибки User Story
  22. Критерии приемлемости пользовательской истории
  23. Оценка и баллы в Scrum
  24. Планирование покера
  25. Игра на оценку команды
  26. Определение приращения
  27. Скрам-события
  28. Что такое спринт в Scrum?
  29. Обязательства команды Scrum — цель продукта, цель спринта и определение завершения
  30. Что такое диаграмма выгорания?
  31. Как создать и интерпретировать диаграмму выгорания?
  32. Преимущества и недостатки диаграммы выгорания
  33. Канбан-доски в Scrum и Scrumban
  34. Скорость в Scrum — скорость команды разработчиков
  35. Ежедневный Скрам
  36. Планирование спринта
  37. Обзор спринта
  38. Что такое ретроспектива спринта?
  39. Распространенные ошибки во время ретроспективы спринта
  40. Развитие бэклога продукта