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

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

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

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

1) масштабирование организации: комплексные Scrum-команды;

2) создание инфраструктуры для гибкости предприятия;

3) координация комплексных команд.

Каждый из этих вызовов рассмотрен ниже.

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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