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-мастера на службе команде разработки:

• проводит тренировки команды разработки по самоорганизации и кросс-функционалу;

• обучает команду разработки создавать продукты высокой ценности;

• устраняет помехи, мешающие прогрессу команды разработки;

• содействует проведению событий Scrum по просьбе команды или по необходимости;

• тренирует команду разработки в организационной среде, где Scrum еще не полностью адаптирован и понятен.

В. Scrum-мастер на службе организации. Обязанности Scrum-мастера на службе организации:

• направляет и тренирует организацию на ее пути адаптации к Scrum;

• планирует этапы внедрения Scrum в организации;

• помогает сотрудникам компании и заинтересованным лицам понять и принять Scrum и принципы эмпирической разработки продуктов;

• выступает инициатором изменений, которые повышают продуктивность Scrum-команды;

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