---

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

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

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

Организации распределяют свои команды по разным местам по многим причинам:

• Технические причины: Знания, необходимые для создания отдельных компонентов программного обеспечения, недоступны непосредственно в головном офисе,
• Причины, связанные с компетенциями: На месте нет некоторых компетенций для выполнения разных видов деятельности в разработке программного обеспечения. Например, автоматизация тестирования, проектирование пользовательского интерфейса или интеграция собственного программного обеспечения с продуктами других поставщиков могут потребовать привлечения экспертов вне головного офиса,
• Причины, связанные с масштабом: Для поставки результатов клиентам в заданные сроки проекту требуется больше людей. В таком случае проектной организации понадобится больше участников, чем разумно объединять в одну Scrum-команду. Это может потребовать нескольких сплочённых Scrum-команд вместо бесконечного увеличения одной команды,
• Причины, связанные с бизнесом: Использование трудовых ресурсов из регионов с более низкими затратами или обеспечение непрерывной работы с помощью инженеров в разных часовых поясах может иметь веское экономическое обоснование.

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

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

Организация проекта: несколько команд

Самый простой способ расширить применение фреймворка Scrum в крупном проекте — увеличить число команд в одном месте.

Если для выполнения проекта необходимо сотрудничество нескольких команд, лучше наращивать их число постепенно.

Что это означает для вас?

Несколько команд в одном месте

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

Увеличение числа команд

Есть два распространённых способа создавать новые Scrum-команды:

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

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

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

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

Независимо от выбранного способа добавления новых Scrum-команд в организацию помните о следующих принципах:

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

Организация проекта: распределённые команды

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

Несколько команд в нескольких местах

Если не решать эти проблемы, последствия будут серьёзными.

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

Есть четыре важные рекомендации, которые помогут вам справиться с этими трудностями:

• Вы обеспечиваете обучение новых участников Scrum-команды фреймворку Scrum по программе Scaled Scrum Expert,
• Вы обеспечиваете полноценное знакомство новых участников Scrum-команды с проектом, чтобы они хорошо понимали, ради чего работают. Не только с технической точки зрения, но и с точки зрения профессиональной бизнес-ценности, чтобы своими рабочими решениями повышать ценность собственного вклада,
• Вы обеспечиваете установление норм проекта. Как и у отдельной Scrum-команды, имеющей свои нормы общения, планирования и выполнения работы, у проектной организации из нескольких команд должны быть нормы более высокого уровня. Тогда команды смогут вместе общаться, планировать, работать, решать проблемы и создавать ценность для клиентов и бизнеса.
• Вы обеспечиваете хотя бы временную совместную работу новых участников с опытными участниками проекта. Для этого могут потребоваться поездки в удалённые офисы и обучение на рабочем месте. Это совершенно нормально и даже желательно. Благодаря такому подходу знания передаются плавно, а между людьми из разных команд и мест налаживается двусторонний личный диалог.

Виртуальные команды

Ещё один вариант распределённой Scrum-команды — размещение её участников в разных местах. Такую команду называют «виртуальной командой».

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

Виртуальные команды

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

Команда Владельца продукта Scrum

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

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

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

Ответственный Владелец продукта при поддержке такого сотрудничества сосредоточивается на том, чтобы:

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

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

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

Компонентные команды и функциональные команды

Распределяя работу между командами, мы можем возложить на них ответственность за определённые компоненты или функции программного обеспечения. Поэтому мы называем их «компонентной командой» или «функциональной командой».

Компонентные команды

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

Команда Владельца продукта Scrum

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

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

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

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

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

Компонентные команды

Функциональные команды

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

Функциональные команды

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

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

Как выбрать между компонентными и функциональными командами?

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

Компонентные и функциональные команды

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

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

Scrum-мастер в распределённой проектной среде

В распределённой проектной среде роль Scrum-мастера ещё важнее. При такой организации проекта:

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

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

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

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

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