А Команда Scrum — это группа людей, которые совместно работают над созданием продукта, включающая три ключевые роли:
- Продуктовый владелец
- Scrum-мастер
- Команда разработки

Самоуправляемые и межфункциональные
В Scrum, команда является самоуправляемой и межфункциональной:
- Самоуправляемая команда выбирает, как наиболее эффективно выполнить свою работу — а не подчиняется указаниям извне команды.
- Межфункциональная команда обладает всеми навыками, необходимыми для выполнения работы, не завися от людей вне команды. Модель команды Scrum разработана для оптимизации гибкости, креативности и производительности.
Как команды Scrum эффективно взаимодействуют?
Команды Scrum поставляют продукт поэтапно и итеративно, максимизируя возможности получения обратной связи. Предоставление «готового» продукта гарантирует, что всегда доступна потенциально доставляемая версия.
Scrum определяется набором принципов (или пяти ценностей Scrum), которые следует понимать как простые руководства для эффективной работы в команде. Это:
- Храбрость – особенно при решении сложных задач
- Фокус
- Преданностьсовместным целям команды
- Уважение для членов команды
- Открытость для работы и любых возникающих трудностей
Ключевые концепции Scrum
Scrum состоит из серииСпринтов или итераций разработки. Каждый спринт Scrum включает один и тот же процесс: роли (люди), события (встречи) иАртефакты (осязаемые результаты).
- Спринт — это повторяющийся цикл разработки до завершения проекта.
- Во время каждого спринта требования разрабатываются, тестируются, интегрируются и утверждаются (часто в виде пользовательских историй). Этот процесс продолжается от спринта к спринту.
Как уже упоминалось, фреймворк Scrum состоит из трех различных категорий:Роли, События, иАртефакты:
Роли Scrum
Фреймворк Scrum определяется тремя основными ролями: командой разработки, мастером Scrum и владельцем продукта.
Владелец продукта
Владелец продукта отвечает за максимизацию стоимости продукта и работы команды разработки. Способы достижения этого могут различаться в зависимости от организации, команды Scrum и отдельного лица.
Роль владельца продукта
Владелец продукта — единственный человек, ответственный за управлениепродуктовым бэклогом. Управление продуктовым бэклогом включает:
- Четкое выражение элементов продуктового бэклога;
- Упорядочивание элементов продуктового бэклога для наилучшего достижения целей и задач;
- Оптимизация стоимости работы, выполняемой командой разработки;
- Обеспечение того, чтобы продуктовый бэклог был видимым, прозрачным и понятным для всех, показывая, над чем будет работать команда Scrum в следующий раз; и
- Обеспечение того, чтобы команда разработки понимала элементы продуктового бэклога на необходимом уровне.
Мастер скрам
Мастер скрам отвечает за обеспечение понимания и применения скрама. Мастера скрам достигают этого, обеспечивая соблюдение командой скрам теории, практик и правил.
Мастер скрам — это лидер-слуга для команды скрам. Мастер скрам помогает людям вне команды скрам понять, какие взаимодействия с командой полезны, а какие нет. Мастер скрам помогает всем изменить эти взаимодействия для максимизации ценности, создаваемой командой скрам.
Роль мастера скрам
Мастер скрам служит продукт-владельцу различными способами, включая:
- Определение эффективных методов управления продукт-бэклогом;
- Помощь команде скрам в понимании необходимости ясных и кратких элементов продукт-бэклога;
- Понимание планирования продукта в эмпирической среде;
- Обеспечение того, чтобы продукт-владелец знал, как упорядочивать продукт-бэклог для максимизации ценности;
- Понимание и практика гибкости; и
- СодействиеСобытия скрам по мере необходимости.
Мастер скрам служит команде разработки
Мастер скрам служит команде разработки различными способами, включая:
- Руководство командой разработки в самоорганизации и межфункциональности;
- Помощь команде разработки в создании продуктов высокой ценности;
- Устранение препятствий, мешающих продвижению команды;
- Содействие проведению событий скрам по мере необходимости; и
- Руководство командой разработки в организациях, где скрам еще не полностью внедрен или не понят.
Мастер скрам служит организации
- Мастер скрам служит организации различными способами, включая:
- Руководство и сопровождение внедрения скрама в организации;
- Планирование внедрения скрама в организации;
- Помощь сотрудникам и заинтересованным сторонам понять и принять скрам и эмпирическое разработку продуктов;
- Содействие изменениям для повышения производительности команды скрам; и
- Сотрудничество с другими мастерами скрам для повышения эффективности скрама во всей организации.
Команда разработки
Команда разработки состоит из профессионалов, которые доставляют потенциально доставляемый «Готовый» продукт на каждом спринте. Только члены команды разработки могут создавать инкремент.
Команда разработки самодостаточна и уполномочена организацией организовывать и управлять своей собственной работой. Это синергетическое взаимодействие повышает общую эффективность и результативность команды.
Роль команды разработки
Команда разработки обладает следующими характеристиками:
- Они самодостаточны. Никто (даже Scrum-мастер) не указывает команде разработки, как преобразовать элементы продукт-бэклога в потенциально доставляемый продукт.
- Команда разработки межфункциональна и обладает всеми навыками, необходимыми для создания продукта.
- Scrum не признаёт никаких должностей, кроме «разработчик», для членов команды разработки, независимо от выполняемой работы. Это правило не имеет исключений.
- Scrum не признаёт никаких подгрупп внутри команды разработки, независимо от конкретной области, с которой они работают (например, тестирование или бизнес-анализ). Это правило не имеет исключений.
- Члены команды могут обладать специализированными навыками и опытом, но ответственность лежит на всей команде разработки.
События Scrum
Фреймворк Scrum характеризуется пятью событиями. Это: спринт, Планирование спринта, Ежедневный стендап, обзор спринта, и Ретроспектива спринта.
- Ежедневный стендап спринт (также называемый итерацией) — это основная единица разработки в Scrum. Спринт — это ограниченный по временизадача — то есть она ограничена определённым временем. Длительность каждого спринта заранее определена, обычно составляет от одной до четырёх недель, чаще всего — две недели.
- Планирование спринта — это событие в рамках Scrum, в ходе которого команда определяет, какие элементы продукт-бэклога она будет выполнять в рамках спринта, и обсуждает свой первоначальный план их выполнения.
- Ежедневный стендап ежедневный стендап (также называемый ежедневным стендапом) — это короткое, ограниченное по времени собрание, проводимое ежедневно. Обычно продолжительность этого собрания составляет от 5 до 15 минут и его иногда называют стендапом, утренним брифингом или ежедневной синхронизацией.
- Обзор спринта обзор спринта происходит после окончания спринта. Во время обзора ответственный за продукт объясняет, что было завершено, а что нет в ходе спринта. Затем команда представляет выполненную работу и обсуждает прогресс, трудности и способы улучшения.
- Собзор спринта проводится после каждого спринта, сразу после обзора спринта. Он предоставляет команде возможность проанализировать свою работу и разработать план улучшения на следующий спринт.
Артефакты Scrum
Артефакты — это физические записи, содержащие подробную информацию о проекте. Артефакты Scrum включают список продукта, список спринта, и увеличения продукта.
- Ссписок продукта — это приоритизированный список функций, ошибок или технических задач, которые в настоящее время не находятся в процессе выполнения. С точки зрения ответственного за продукт, он должен включать всю ценную работу.
- По мере изменения требований к продукту, ответственный за продукт и другие члены команды совместно пересматривают и корректируют список продукта по мере необходимости.
- Ссписок спринта — это список всех элементов списка продукта, выбранных для спринта. Этот список формируется путем приоритизации элементов из списка продукта до тех пор, пока команда не посчитает, что достигла своей емкости спринта. Члены команды регистрируют задачи в списке спринта с учетом навыков и приоритетов, следуя принципам саморегулируемой модели Scrum.
- Сувеличение продукта — это сумма всей завершенной работы по продукту в ходе спринта, плюс вся работа, завершенная в предыдущих спринтах. Цель спринта — создать готовый продукт. Команда Scrum определяет, что означает состояние «Готово» для увеличения продукта, но все члены команды должны согласиться и понимать это определение.
Жизненный цикл Scrum
Жизненный цикл Scrum начинается со списка продукта, но не предоставляет руководства по его разработке или приоритизации. Вместо этого он включает серию спринтов, которые в конечном итоге приводят к созданию потенциально доставляемого увеличения продукта, как показано на диаграмме ниже.
Во время этих спринтов все необходимые действия по разработке продукта выполняются на небольшой части общего продукта. Ниже приведено объяснение ключевых этапов жизненного цикла Scrum:

Гибкая модель Scrum
- Бизнес определяет приоритеты, а команда самостоятельно организуется, чтобы определить наилучший способ доставки функций с наивысшим приоритетом.
- Ответственный за продукт представляет бизнес, отвечает за поддержание списка продукта (списка функций) и установление приоритетов разработки.
- Во время планирования спринта команда берет небольшую часть из верхней части списка, добавляет ее в список спринта и решает, как ее доставить.
- Scrum основан на итеративных циклах, называемых спринтами, которые обычно длятся от 2 до 4 недель, в течение которых продукт проектируется, кодируется и тестируется, а ежедневные стендапы отслеживают прогресс (ежедневный стендап).
- В ходе этого процесса ответственный за Scrum поддерживает фокус команды на ее целях.
- В конце спринта работа должна быть готова к передаче заинтересованным сторонам.
- Спринт завершается обзором спринта и ретроспективой.
- В следующем спринте команда выбирает еще одну часть бэклога продукта и начинает снова.
- Процесс продолжается до тех пор, пока весь бэклог не будет завершен — или пока работа не прекратится из-за ограничений по времени или бюджету.
- Это продолжается до тех пор, пока проект не будет признан завершенным, либо когда работа прекратится (срок, бюджет и т.д.), либо когда весь бэклог будет завершен.