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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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