Софт за 30 дней. Как Scrum делает невозможное возможным

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

Масштабирование Scrum для больших приложений (как показано на рис. А3.2) оставляет этот ключевой принцип на месте.

.

Рис. А3.2. Система, создаваемая тремя Scrum-командами в течение трех спринтов

Таким образом, масштабирование для приложения с участием 300 человек включает в себя организацию около 30 Scrum-команд. Как обсуждалось ранее, комплектация команды должна быть полной, чтобы она могла разрабатывать потенциально готовые к выпуску элементы функциональности после каждого спринта. В большинстве случаев это требует реорганизации команд вокруг отдельных свойств продукта, сервисов, компонентов и подсистем, а не по индивидуальной роли (например, команда разработчиков, команда тестирования и тому подобное). Мы обсуждали эти организационные препятствия и ранее, и, как видим, они усугубляются по мере увеличения размера нашего проекта.

Организация следует за архитектурой

Кроме того, мы не можем легко формировать Scrum-команды без понимания того, как каждая индивидуальная команда может относительно целостно предоставить функциональные возможности для конечного пользователя. В свою очередь, это предусматривает, что мы раскладываем архитектуру приложения на компоненты и подсистемы, которые имеют концептуальную целостность и могут представлять бизнес-ценность сами по себе[19]. Scrum подготавливает эту архитектурно-производственную деятельность на фазе подготовки спринта и первых спринтах, с помощью первых Scrum-команд. Этот метод особенно хорошо работает в период распространения Scrum в организации и развертывания для большого проекта. Здесь первые команды создают контрольные точки потребительской ценности и в то же время закладывают архитектуру приложения, способную принять дополнительные команды, обучение которых происходит примерно в это же время. По мере того как формируется новая команда, ее роль в большой системе становится ясной и появляется общая картина, как на рис. А3.2.

1.6.2. Координирование Scrum-команд из Scrum-команд

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

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

Ежедневное общение: Scrum над Scrum

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

1) что вчера сделала моя команда для достижения целей спринта?

2) что моя команда будет делать сегодня?

3) какие препятствия могут помешать моей команде достичь целей спринта?

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

Планирование релиза на уровне системы и отслеживание.Рисунок А3.2 ошибочно дает понять, что вопрос по разделению организации на команды по работе над отдельными функциями продукта, сервисами и подсистемами довольно простой: команды сделают свою работу, и интегрированная система получится естественным образом. Опыт показывает, что это крайне маловероятно. Даже когда индивидуальным командам ставится задача достичь целей спринта и скоординировать интеграцию между командами и подсистемами, присутствует целый ряд больших трудностей. Это необходимость в создании целостной системы, когда мы встраиваем и тестируем наши интеграции со всеми подсистемами и где подсистемы работают вместе для обеспечения более широких требований пользователей, а вся система должна соответствовать требуемому уровню качества, производительности и надежности. Теперь нам требуется, чтобы любая работа отдельной команды считалась законченной и интегрированной и работа всех команд по интеграции тестированию должна быть закончена. Это показано на рис. А3.3.