Sprint Retrospective Meeting – Ретроспектива в Scrum

Sprint Retrospective Meeting, наравне со Sprint Reviews Meeting, проводится в последний день спринта. Задачи, в отличие от Sprint Reviews Meeting, ставятся совершенно иные. Если обзорная встреча имеет цель посмотреть на результат продукта, то ретроспектива призвана посмотреть на результат команды.

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

Ретроспектива Scrum – очень полезное мероприятие и не стоит к нему относится посредственно. В качестве примера можно привести автомобиль и замену его масла. Грубым интервалом замены масла считается порядка 15 000 км., то есть через такое число километров необходимо слить старое масло и залить новое, иначе качество работы двигателя может ухудшиться или, более того, это может привести к серьезной поломке автомобиля и даже его выходу из строя. Scrum Team также нуждается в подобной «замене масла», чтобы работа всегда была в наивысшей степени эффективной.

Большинство Scrum Team переходят к ретроспективе (Sprint Retrospective Meeting) сразу после обзора (Sprint Review Meeting). Вся команда Development Team, а также Scrum Master и Product Owner участвуют в этом процессе. Хотя стоит отметить, что участие Product Owner необходимо не во всех видах Sprint Retrospective Meeting. У ретроспективы нет очень сильных временных ограничений, но есть формула золотой середины: длина Sprint Retrospective Meeting равна 75% часа (45 минут), умноженные на количество недель в Sprint. Если у вас четырехнедельный Спринт, то время на ретроспективу в Scrum следует выделить равное 60 * 0.75 * 4 = 180 минутам. То есть на ретроспективу следует потратить 180 минут, что равняется трем часам. Иногда, правда, некоторые команды не придерживаются этой формулы и просто отводят час для такого анализа, а если происходят горячие споры, то время увеличивается.

На самом деле способов проводить подобные встречи достаточно много. По этому поводу даже написаны целые книги, например «Agile Retrospectives: Making Good Teams Great» и «Project Retrospectives: A Handbook for Team Reviews».

Самым распространенным и простым способом (что не отменяет его эффективности), является способ Start-Stop-Continue.

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

Начать делать;
Прекратить делать;
Продолжить делать.

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

После мозгового штурма Sprint Retrospective Meeting может начаться голосование по конкретным вопросам, которые будут учитываться в следующем спринте. В следующей ретроспективе будут рассматриваться оставшиеся пункты из прошлой встречи.

Пример Sprint Retrospective Meeting в разработке интернет-магазина

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

После завершения Sprint и проведения Sprint Reviews Meeting, команда Scrum собралась для обсуждения эффективности её работы, которая была оценена каждым самостоятельно.

Scrum Master решает задать вопрос каждому лично и узнать ответы на все три вопроса.

Участник №1:

Я считаю, что команде следует начать использовать более развернутые листы тестирования
----
Я считаю, что команда должна продолжить использовать текущий вид Product Backlog, он оптимально подходит.

Участник №2

-----
Мне кажется, команде надо прекратить использовать текущую IDE, её «неповоротливость» замедляет работу.
Команде однозначно следует продолжить использовать текущую систему контроля версий и облачных сохранений, с ней мы менее беспокоимся о потерях и более концентрируемся на работе.

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

Scrum Master составляет список всех пожеланий и затем устраивает голосование. Во время голосования команда решает, что из предложенного надо первым делом внести в очередь улучшений и исправить в следующем спринте, а что оставить на потом.