Владелец продукта может помочь внести ясность в выбранные элементы бэклога и пойти на компромисс. Если команда разработки решает, что у нее слишком много либо слишком мало работы, она может повторно обсудить требования бэклога с владельцем продукта. Команда может пригласить людей со стороны для получения информации по технической или предметной области продукта.
По окончании планирования спринта команда разработки должна быть в состоянии объяснить владельцу продукта и 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-команды. Хотя изменения могут быть внесены в любое время, ретроспектива спринта предоставляет формальную возможность сфокусироваться на инспекции и адаптации.
Статья VII. Scrum-артефакты
Scrum-артефакты работа для обеспечения прозрачности и возможностей для инспекции и адаптации. Определенные Scrum-артефакты специально спроектированы таким образом, чтобы обеспечить максимальную прозрачность ключевой информации, необходимой для обеспечения Scrum-команды возможностями по успешной поставке «законченных» инкрементов.
Раздел 7.01. Бэклог продукта
Бэклог продукта упорядоченный список всего, что может быть в нем нужным, единственный источник требований для любых изменений, которые может потребоваться внести в продукт. Ответственность за бэклог продукта, включая его содержимое, доступность и упорядочение, несет владелец продукта.
Бэклог продукта никогда не бывает полным. Начальная версия этого документа содержит только первоначально известные и наиболее понятные требования, он постоянно обновляется по мере обновления самого продукта и среды, в которой он разрабатывается. Бэклог продукта динамичен, он постоянно меняется, чтобы соответствовать требованиям продукта, его конкурентоспособности и пригодности, и существует ровно до тех пор, пока существует сам продукт.
Бэклог продукта содержит все особенности, функции, требования, усовершенствования и информацию по исправлению дефектов, то есть те данные, которые и определяют изменения, необходимые в следующих релизах продукта. Каждому элементу бэклога продукта присваиваются описание, порядковый номер и стоимость.
Бэклог продукта часто упорядочивается по ценности, риску, приоритету и необходимости. Наиболее высокие позиции в списке приводят к немедленным действиям по разработке.
Более высокие позиции более четкие и детализированные. На основании большей ясности и детализации даются более точные оценки. Те требования бэклога продукта, которые команда разработки будет реализовывать во время текущего спринта, детализированы и разбиты на части таким образом, что любое из них может быть выполнено и «закончено» в рамках одного спринта. Требования бэклога продукта, которые можно выполнить в течение одного спринта, считаются «подготовленными», или «применимыми», для следующего планирования спринта.
Со временем продукт начинает использоваться и приобретает ценность, а рынок дает обратную связь, и бэклог становится более объемным и исчерпывающим. Требования никогда не перестают меняться, поэтому бэклог продукта живой артефакт. Изменения в бизнес-требованиях, условиях рынка или технологиях могут привести к изменениям в бэклоге продукта.
Довольно часто случается, что над одним продуктом работают несколько Scrum-команд. В этом случае используется только один бэклог продукта для определения групп работ на выполнение.
Поддержка бэклога продукта активность по добавлению деталей, оценок и упорядочивания элементов. Это непрерывный процесс, во время которого владелец продукта и команда разработки трудятся над требованиями бэклога продукта, которые проверяются и пересматриваются. Тем не менее они могут быть обновлены владельцем продукта в любое время по своему усмотрению.
Scrum-команда решает, как и когда должна производиться поддержка бэклога продукта. Обычно это занимает не более 10 % времени Scrum-команды.
Команда разработки отвечает за все оценки. Владелец продукта может оказывать влияние на команду разработки, помогая ей понять требования и идя на компромиссы, но люди, которые будут выполнять работу, делают окончательную оценку сами.
Команда разработки отвечает за все оценки. Владелец продукта может оказывать влияние на команду разработки, помогая ей понять требования и идя на компромиссы, но люди, которые будут выполнять работу, делают окончательную оценку сами.
А. Отслеживание динамики движения к цели. В любой момент можно суммировать работу, оставшуюся до достижения цели. Владелец продукта отслеживает объем этой работы как минимум на каждом обзоре спринта, сравнивая оставшийся объем работы с предыдущим, чтобы оценить динамику движения к цели и возможность уложиться в желаемое время завершения. Эта информация прозрачна для всех заинтересованных лиц.