Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]

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

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

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

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

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

Ниже перечислены ключевые аспекты обзора спринта.

■ Владелец продукта начинает обзор спринта, представляя цель спринта.

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

■ Команда разработки рассказывает о том, что удалось выполнить во время спринта, какие проблемы возникли и как они были решены.

■ Команда разработки демонстрирует готовую функциональность и отвечает на вопросы заинтересованных лиц об инкременте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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