Статья VI. События Scrum
Предписанные мероприятия используются в Scrum для создания регулярности и минимизации потребности в совещаниях, не оговоренных Scrum. Продолжительность всех мероприятий фиксирована. Это гарантирует, что на планирование будет тратиться необходимое количество времени, потому что дополнительные траты времени непозволительны.
Сам спринт, как и мероприятия, из которых он состоит, дает возможность для инспекции и адаптации. Мероприятия специально разработаны таким образом, чтобы обеспечить критическую прозрачность и контроль. Отказ от одного из таких мероприятий приводит к уменьшению прозрачности и потере возможной инспекции и адаптации.
Раздел 6.01. Спринт
Сердце Scrum – спринт длительностью в один месяц или менее, в течение которого создается «законченный», потенциально готовый к выпуску и использованию инкремент продукта. Спринты составляют непрерывную последовательность разработки. Следующий спринт начинается сразу же по окончании предыдущего.
Спринты состоят из планирования, Scrum-митингов, разработки, обзора спринта, а также ретроспективы спринта.
Во время спринта:
• не допускается внесение никаких изменений, которые могли бы поставить под угрозу цель спринта;
• состав команды разработки остается неизменным;
• цели относительно качества не должны сокращаться;
• объем работ может быть уточнен и повторно обговорен между владельцем продукта и командой разработки по мере накопления знаний.
Каждый спринт – проект длительностью не более одного месяца. Как и другие проекты, спринт используется для достижения целей. Каждый спринт состоит из определения того, что нужно разработать, дизайна и гибкого плана, служащего ориентиром при разработке, работы по проекту и полученного в результате продукта.
Продолжительность спринта ограничена календарным месяцем. Если спринт слишком длительный, может измениться само определение того, что должно быть реализовано, могут возникнуть дополнительные сложности либо вырасти риски. Спринты делают процесс разработки прогнозируемым, обеспечивая инспекцию и адаптацию на пути к цели проекта как минимум каждый календарный месяц. Спринты также ограничивают риски по тратам одним календарным месяцем.
А. Отмена спринта. Спринт можно отменить до его завершения. Только у владельца продукта есть право на то, чтобы отменить спринт, хотя он может сделать это и под влиянием заинтересованных лиц, команды разработки или Scrum-мастера.
Спринт отменяют в случае, если его цель перестает быть актуальной. Это может произойти вследствие изменения направления работы компании, изменения рыночных условий или технологий. В общем, спринт нуждается в отмене, если в силу некоторых обстоятельств в нем уже нет необходимости. Однако, принимая во внимание его небольшую продолжительность, отмена редко имеет смысл.
Когда спринт отменяют, все «законченные» элементы бэклога продукта рассматриваются. Владелец продукта их принимает при условии, что они представляют потенциально готовый к выпуску инкремент функционала. Все незаконченные пункты бэклога продукта переоцениваются и возвращаются в список. Объем работы, проделанный над ними, быстро убывает, поэтому нуждается в пересмотре.
Отмена спринта требует дополнительных ресурсов, так как все должны перегруппироваться для следующего планирования спринта и приступить к новому спринту. Отмена спринта – травматическое событие для Scrum-команды и, в общем, нетипична.
Раздел 6.02. Планирование спринта
Работа на предстоящий спринт планируется во время процесса планирования. План действий создается при совместной работе всей Scrum-команды.
Для спринта длиной в месяц встреча ограничена восемью часами. Для более коротких спринтов на планирование обычно выделяется пропорционально меньше времени. Например, для двухнедельного спринта проводится четырехчасовое планирование.
Мероприятие по планированию спринта состоит из двух частей, и на каждую отводится половина общего времени собрания. Каждая часть последовательно отвечает на следующие вопросы:
• что может быть получено в инкременте продукта следующего спринта?
• как будет выполняться работа, необходимая для создания инкремента продукта?
А. Часть 1. Что будет сделано в этом спринте? В этой части команда разработки прогнозирует функционал, который будет разработан в течение спринта. Владелец продукта озвучивает упорядоченный список задач команде разработки, и вся Scrum-команда совместно вырабатывает понимание работы, которую необходимо проделать в этом спринте.
Входные параметры для этой встречи – бэклог продукта, последний разработанный инкремент, текущие возможности команды разработки, а также ее последняя производительность. Количество элементов из бэклога, которые команда способна выполнить до окончания спринта, определяется исключительно самой командой. Только команда разработки может оценить объем работы, который она в состоянии завершить в следующем спринте.
После того как команда разработки спрогнозировала элементы бэклога продукта, которые она выполнит в спринте, Scrum-команда формирует цель спринта, то есть задачу, которая будет достигнута в результате спринта благодаря реализации бэклога продукта и которая объясняет команде разработки, для чего она создает инкремент.
Б. Часть 2. Как выбранная работа будет сделана? После того как цель спринта определена, команда разработки решает, каким образом воплотить функционал в «законченном» инкременте продукта. Элементы бэклога продукта, выбранные для этого спринта вместе с планом для их разработки, называются бэклогом спринта.
Команда разработки обычно начинает с проектирования системы и работы, необходимой для того, чтобы превратить бэклог продукта в функционирующий инкремент. Работа может быть разного объема, и предполагаемые усилия также могут различаться. Однако обычно во время планирования спринта команда разработки рассчитывает на достаточный объем работы. Задача, запланированная командой на первые дни спринта, разбивается на части длительностью в день или менее. Команда сама организовывает свою деятельность как во время планирования спринта, так и на протяжении его.
Владелец продукта может помочь внести ясность в выбранные элементы бэклога и пойти на компромисс. Если команда разработки решает, что у нее слишком много либо слишком мало работы, она может повторно обсудить требования бэклога с владельцем продукта. Команда может пригласить людей со стороны для получения информации по технической или предметной области продукта.
По окончании планирования спринта команда разработки должна быть в состоянии объяснить владельцу продукта и Scrum-мастеру, каким образом она, работая как самоорганизованная команда, достигнет цели спринта и создаст ожидаемый инкремент.
В. Цель спринта. Цель спринта дает Scrum-команде некоторую гибкость в отношении разрабатываемого функционала в спринте.
Пока команда работает, эта цель служит для нее ориентиром. Для ее достижения команда реализует функционал и технологию. Если же работа отличается от ожидаемой, то команда договаривается с владельцем продукта об изменении объема бэклога спринта в текущем спринте.
Цель спринта может быть шагом к большей цели в дорожной карте разрабатываемого продукта.
Раздел 6.03. Scrum-митинг
Scrum-митинг – это 15-минутное мероприятие для команды разработки с целью синхронизации действий и создания плана работы на ближайшие 24 часа. Он проводится для инспекции проделанной работы с момента предыдущего ежедневного Scrum-митинга и для прогноза того, что может быть сделано до следующего.
С целью избежать путаницы Scrum-митинги проводятся в одном и том же месте, в одно и то же время. Во время встречи каждый член команды разработки рассказывает коллегам следующее:
• что было сделано с момента прошлой встречи?
• что будет сделано к моменту следующей встречи?
• какие препятствия есть на пути?
Команда разработки использует Scrum-митинг для оценки динамики продвижения к цели спринта и оценки отклонения от планируемого объема работ бэклога спринта. Scrum-митинг оптимизирует вероятность, что команда разработки достигнет цели спринта. Команда разработки часто встречается сразу же после ежедневного Scrum-митинга для более детального обсуждения или перепланирования оставшейся работы в спринте. Члены команды разработки должны быть готовы ежедневно объяснять владельцу продукта и Scrum-мастеру, как они намерены работать вместе в качестве самоорганизованной команды для достижения цели и создания предполагаемого инкремента в оставшееся время спринта.
Scrum-мастер отвечает за то, чтобы команда разработки провела встречу, однако ответственность за управление Scrum-митингом лежит именно на команде разработки. Scrum-мастер следит, чтобы время, отведенное на Scrum-митинг, не превышало 15 минут, и контролирует, чтобы в Scrum-митингах участвовали только члены команды разработки.
Scrum-митинги делают более эффективным общение внутри команды, сводя к минимуму другие встречи, помогают определять и устранять препятствия на пути разработки, способствуют быстрому принятию решений, а также повышают уровень осведомленности команды разработки. Это ключевое мероприятие для инспекции и адаптации.
Раздел 6.04. Обзор спринта
Мероприятие по обзору проводится в конце спринта для инспекции инкремента и при необходимости адаптации бэклога продукта. Во время обзора спринта Scrum-команда и заинтересованные лица обсуждают выполненную во время спринта работу, а также изменения, которые могли возникнуть в бэклоге продукта за время спринта, и намечают дальнейшие шаги, которые могут быть предприняты для оптимизации ценности. Это не официальная встреча, а скорее презентация инкремента, предназначенная для получения обратной связи и развития сотрудничества.
Обзор спринта длиной в месяц представляет собой четырехчасовое мероприятие. На более короткие спринты обычно тратят пропорционально меньше времени. Например, обзор двухнедельного спринта занимает два часа.
Обзор спринта включает следующие элементы:
• владелец продукта определяет, что можно считать «законченным», а что нет;
• команда разработки обсуждает, что во время спринта прошло гладко, с чем возникли трудности и как эти проблемы были решены;
• команда разработки проводит демонстрацию уже сделанного и отвечает на вопросы об инкременте;
• владелец продукта обсуждает состояние бэклога продукта и делает предположения касательно возможной даты завершения, принимая во внимание скорость продвижения к этой дате;
• вся группа совместно решает, что делать дальше; таким образом, обзор спринта дает ценный вклад в последующее мероприятие по его планированию.
Результатом обзора спринта служит пересмотренный бэклог продукта, в котором определены возможные его элементы на следующий спринт. Бэклог продукта может быть полностью пересмотрен из-за вновь открывшихся возможностей.
Раздел 6.05. Ретроспектива спринта
Ретроспектива спринта дает Scrum-команде возможность инспектировать себя и создавать план улучшений для следующего спринта.
Ретроспектива спринта происходит после его обзора и перед последующим планированием. Это ограниченная тремя часами встреча для одномесячного спринта. Для более коротких спринтов обычно выделяется меньше времени. Scrum-цели ретроспективы спринта следующие:
• инспекция успешности спринта: отношения между людьми, процессы и инструменты;
• определение и упорядочение того, что прошло успешно, и того, что нуждается в улучшении;
• разработка плана по внедрению улучшений в процесс работы Scrum-команды.
Scrum-мастер поощряет Scrum-команду пересмотреть процессы разработки в рамках фреймворка Scrum, чтобы сделать ее более эффективной и приятной в следующем спринте. Во время каждой ретроспективы спринта Scrum-команда ищет пути улучшения качества разрабатываемого продукта, адаптируя определение «законченности».
До окончания ретроспективы Scrum-команда должна определиться с улучшениями процесса работы, которые она реализует в следующем спринте. Внедрение этих изменений в следующем спринте – адаптация после инспектирования самой Scrum-команды. Хотя изменения могут быть внесены в любое время, ретроспектива спринта предоставляет формальную возможность сфокусироваться на инспекции и адаптации.