Софт за 30 дней. Как Scrum делает невозможное возможным - Джефф Сазерленд

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

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

Обзор спринта включает следующие элементы:

• владелец продукта определяет, что можно считать «законченным», а что нет;

• команда разработки обсуждает, что во время спринта прошло гладко, с чем возникли трудности и как эти проблемы были решены;

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

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

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

Результатом обзора спринта служит пересмотренный бэклог продукта, в котором определены возможные его элементы на следующий спринт. Бэклог продукта может быть полностью пересмотрен из-за вновь открывшихся возможностей.

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

Ретроспектива спринта происходит после его обзора и перед последующим планированием. Это ограниченная тремя часами встреча для одномесячного спринта. Для более коротких спринтов обычно выделяется меньше времени. Scrum-цели ретроспективы спринта следующие:

• инспекция успешности спринта: отношения между людьми, процессы и инструменты;

• определение и упорядочение того, что прошло успешно, и того, что нуждается в улучшении;

• разработка плана по внедрению улучшений в процесс работы Scrum-команды.

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

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

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

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

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

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

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

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

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

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

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

Scrum-команда решает, как и когда должна производиться поддержка бэклога продукта. Обычно это занимает не более 10 % времени Scrum-команды.

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

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