Скрам

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

■ Владелец продукта описывает текущее состояние бэклога продукта. При необходимости он прогнозирует возможные даты завершения разработки продукта, основываясь на текущих показателях прогресса.

■ Проводится обзор того, как изменения рынка или использование продукта могли повлиять на порядок элементов бэклога продукта.

■ Выполняется обзор сроков, бюджета, возможностей и позиций на рынке для будущих релизов или возможностей продукта.

■ Заинтересованные лица делятся своими впечатлениями, предлагают желаемые изменения бэклога продукта и порядка его элементов. Они могут:

■ высказывать любые комментарии, замечания или критику в отношении готового к поставке инкремента;

■ указать функциональные возможности, которые не были реализованы или не соответствуют их ожиданиям, и попросить включить такие функции в бэклог продукта;

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

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

■ В конце обзора спринта скрам-мастер сообщает место и дату следующего обзора спринта владельцу продукта, команде разработки и всем заинтересованным лицам.

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

Ретроспектива спринта

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

Цели проведения ретроспективы спринта:

■ инспекция прошедшего спринта применительно к людям, отношениям, процессам и инструментам. Обнаружение и упорядочение того, что прошло хорошо, и того, что нуждается в улучшении;

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

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

Ретроспектива может проходить в разных форматах. Например, скрам-мастер может попросить всех участников ответить на два вопроса:

■ Что было хорошо во время последнего спринта?

■ Что можно улучшить в следующем спринте?

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