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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

Рис. А3.3. Система из трех подсистем

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

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

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

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

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

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

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

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

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

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

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

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

Планирование релиза. Философия Scrum фокусируется на «магии воспользоваться возможностями в ближайшей перспективе», в отличие от «черной магии по точному предсказанию именно того, что будет доставлено через 6–12 спринтов». Эта философия – прорыв в мышлении на уровне команды, потому что это позволяет Scrum-командам фокусироваться на текущей работе в ближайшие 30 дней и таким образом производить работающее программное обеспечение более надежно. Но, по мере того как количество команд растет, применение дополнительного анализа и точности к спринтам за пределами непосредственного горизонта помогает избежать архитектур, которые требуют в дельнейшем существенного рефакторинга, который хотя и весьма поощряется в гибком методе разработки, но становится менее практичным по мере увеличения масштаба приложений и количества существующих внедрений. Дополнительное планирование релиза, который предоставляет нам архитектурный путь, часто бывает оправданным. Таким образом, искусство планирования спринта может включать функции планирования «что будет через несколько спринтов» и «что если планирование…», которые помогают командам идти на компромиссы в бэклогах и обсуждать разумное видение и дорожную карту продукта со спонсорами.

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

Развитие инфраструктуры в спринтах. В Scrum внедрение этого уровня инфраструктуры не разовое событие, подготовленное «заранее» командой внедрения.

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

Рис. А3.4. Добавление инфраструктурных элементов в спринт

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