Рабочий процесс scrum

Спринт (или итерации) является основной единицей разработки в scrum. Спринт представляет собой определенный таймбокс, то есть ограничение определенной продолжительности. Продолжительность фиксируется заранее для каждого спринта и обычно составляет от одной недели до одного месяца, двух недельный спринт является наиболее распространенным.

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

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

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

Планирование

В начале спринта Скрам команда проводит спринт планирование для:

Общение по определению объема работ, которые предполагается сделать во время этого спринта;
Выбор элементов Бэклога продукта, которые могут быть завершены в один спринт;
Подготовка спринта, определение необходимых работ, чтобы закончить некоторые элементы Бэклога продукта;
Определение тайм-боксов – четырех-часовых лимитов на двухнедельные спринты (пропорциональная продолжительность для остальных спринтов);
- В течение первой половины, вся скрам-команда (а это команда-разработчиков, scrum-мастер, а также product owner- владелец продукта) выбирают работы-задачи из Бэклога, которые могут быть достигнуты в этом спринте;
- Во второй половине команда разработчиков декомпозирует работы (задания), необходимые для предоставления этих элементов Бэклога продукта, в результате чего подтверждается спринт;
  - Некоторые элементы Бэклога продукта могут быть разделены или переориентированы если выявленные работы, не достижимы в этом спринте.

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

Ежедневный scrum в начинается в одной и той же комнате. Это централизованное расположение помогает команде начать вовремя. Каждый день во время спринта команда проводит ежедневный скрам (обычно стоя) с конкретными руководящими принципами:

Ежедневный скрам. Все члены команды разработчиков должны готовиться. Ежедневный Скрам…
…начинается точно по времени, даже если некоторых членов команды не хватает;
…должен начаться каждый день в одном и том же месте и в одно и то же время;
…ограничен (timeboxed) пятнадцатью минутами.
Могут присутствовать посторонние, хотя обычно только команда scrum обменивается мнениями о текущей ситуации;
Особенностью ежедневного скрам-митинга является то, что каждый участник группы отвечает на 3 локоничных и простых вопроса:
- Мои вчерашние выполненные задачи? Каким образом я помог команде-разработчиков достигнуть цели-спринта?
- Какие я ставлю себе задачи на сегодня, чтобы нам совместно достичь цели-спринта?
- Наблюдаю ли я какие-либо ограничения, мешающие мне или команде разработчиков достигнуть цели-спринта?

Любое ограничение (например, камень преткновения, риск, проблема, задержка зависимостей, необоснованность предположения), выявленных на ежедневном scrum-митинге должно быть записано скрам мастером и перенесено на scrum доску. Детальное обсуждение во время ежедневного скрам-митинга не производится.

Обзоры и ретроспективы

Команда проводит два мероприятия в конце спринта: обзор и ретроспектива спринта.

Действия команды во время обзора спринта:

Обзор работ, которые были выполнены и планирование работ, которые не были завершены;
Представлена готовые работы для заинтересованных сторон (например демо)

Руководящие принципы для обзора спринта:

Недоделанные работы не могут быть продемонстрированы;
Рекомендуемая продолжительность – два часа для двухнедельного спринта (пропорционально для других длительностей спринтов)

В ретроспективе спринта, команда:

Размышляет о прошлом спринте;
Определяет и согласовывает процесс непрерывного совершенствования действий.

Руководящие принципы для ретроспектив спринта:

В ретроспективе спринта лишь два главных вопроса: что было хорошего во время спринта? Что можно улучшить в следующем спринте?
Рекомендуемая продолжительность – 1-1,5 часа на двухнедельный спринт(пропорционально для других длительностей спринтов)
Это событие закреплено за скрам мастером

Дополнительно

Следующие мероприятия обычно выполняются на практике, хотя и не рассматриваются всеми как основная часть методологии scrum:

Уточнение Бэклога

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

Элементы Бэклога:

могут быть разбиты на несколько более мелких;
критерии приемки могут быть уточнены;
зависимости, последователи и подготовительные работы могут быть определены и согласованы при техническом согласовании.

Хотя данная практика не входит в основной скрам, уточнение Бэклога было принято как способ управления качеством элементов Бэклога, с рекомендуемым объемом до 10% времени спринта.

Скрам скрамов

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

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

Работа построена по аналогии с ежедневным скрам-митингом, и каждый представитель готовит свои ответы на следующие четыре вопроса:

Какие риски, ограничения, зависимости и предположения, ваша скрам-команда выдвинула с нашей последней встречи?
Какие риски, ограничения, зависимости и предположения, ваша команда будет выдвигать, прежде чем мы встретимся снова?
Есть ли любые новые риски, препятствия, зависимости и допущения, замедляющие вашу команду или которые становятся у вас пути?
Собираетесь ли вы ввести новый риск, препятствие, зависимость и предположение, которое будет мешать другой команде?

Как Джефф Сазерленд прокомментировал,

С тех пор как я изначально дал определение скрам скрамов (Кен Швабер работал в IDX в то время со мной), я могу точно сказать, что скрам скрамов – это не “Мета Скрам”. Скрам скрамов, каким я его использовал, несет ответственность за предоставление рабочих версий софта от всех команд в конце спринта, или за релизы во время спринта. Ответственность за это несет Мастер скрам скрамов. Так скрам скрамов – это механизм более оперативной поставки ПО.

Возможно, будет полезно почитать: