✓ у PO и SM есть время на подготовку индикаторов к обзору для руководства.
Наконец, разделение на части предлагает возможность провести ретроспективу между внутренним обзором и внешним обзором. Это иногда более практично с организационной точки зрения.
Команда Peetic организует обзоры раз в две недели по пятницам. Подготовка обзора проходит утром с 10 до 11 часов. Команда решает, кто будет проводить демо, а Селина представит историю заинтересованным сторонам. Обзор состоится в 2 часа дня. Мона и Жиль регулярно в нем участвуют. Кевин приходит по возможности, иногда вместе с клиентами.
11.5 Антипаттерны
Ситуация. ПО гибкое, и любые изменения могут быть быстро внесены. За несколько минут до обзора команда обнаруживает небольшой дефект и собирается сразу его исправить.
Последствия. Изменения могут вызвать регрессию.
Как сделать лучше? Не рекомендуется вносить никаких изменений в код в последний момент.
Если время не позволяет пройти тесты, чтобы убедиться в отсутствии регрессий, код не следует менять.
Многие команды, причем, не только от обучающиеся, лично столкнулись с законом Мерфи и произносили знаменитое все работало идеально буквально минуту назад!
Ситуация. Команда представляет результаты. В частности, когда демонстрацию проводит разработчик, возникает сильный соблазн показать все, что сделано – даже если работа еще не закончена. Разработчик начинает с того, что завершено, а заканчивает тем, что еще не сделано.
Последствия. Заинтересованные стороны растеряны и теряют доверие к команде.
Как сделать лучше? Демонстрацию нужно рассматривать как подведение итогов работы спринта. В ходе демо обсуждаются только завершенные действия, равно как в сводке матчей по регби идет счет только успешным поражениям ворот противника.
Рисунок 11.4 – Команда показывает только то, что завершено
Ситуация. Обсуждение связано с тем, как прошел спринт, задачами и препятствиями.
Последствия. Теряется фокус на продукт.
Как сделать лучше? Для заинтересованных сторон важен именно продукт с историями, которые он содержит.
Способы работы команды – предмет обсуждения во время ретроспективы, а не обзора.
Некоторые команды придают слишком большое значение индикатору спринта (burndown-графикам) и представляют его во время обзора. Это не самая лучшая идея: данный индикатор нужен только команде во время спринта, а присутствующих на обзоре интересуют лишь завершенные истории. Команда может показать burndown-график сезона, но не спринта.
Ситуация. Команда забывает пригласить заинтересованные стороны. Обзор протекает в границах Scrum-команды.
Последствия. Теряется интерес к проведению обзора.
Как сделать лучше? Проводить обзоры спринтов – значит иметь возможность представлять результаты как можно более широкой аудитории, чтобы развивать и укреплять отношения. Приглашения рассылаются всем заинтересованным сторонам.
Их участие в обзоре позволяет не назначать еще какие-либо встречи, они уже не нужны. В организациях, где развита культура комитетов (например, руководящий комитет, комитет по контролю), могут отменить все остальные встречи и оставить только обзоры спринта.
Проведение обзоров позволяет избежать специальные демонстрации для важных людей, которые обычно не утруждают себя присутствием. Было бы напрасной тратой времени назначать им дополнительные встречи, когда уже запланирован обзор. Если кто-то не может присутствовать – не страшно, следующий обзор уже не за горами.
В некоторых организациях команды не хотят приглашать людей извне, потому что продукт еще недостаточно готов. Так бывает из-за опасений, что аудитория будет разочарована – ведь продукт пока не содержит всего, что было запланировано. Но было бы ошибкой лишать себя преимуществ обратной связи. Лучше всего рассказать публике о Scrum и пригласить на обзор.
Можно напомнить приглашенным лицам, что это незавершенный продукт и что другие функции будут добавлены позднее. Хороший способ сделать это – представить kanban-таблицу функциональностей.
Ситуация. Увлеченные демонстрацией, участники Scrum-команды забывают запросить обратную связь.
Последствия. Отсутствие обратной связи.
Как сделать лучше? Обратная связь отлично работает по итеративному процессу. И обзор спринта – идеальный момент, чтобы ее запросить. Присутствующие могут вклиниться во время обзора и задать свои вопросы. Команда отвечает либо разъяснением неправильно понятого пункта, либо объяснением, что данный пункт уже находится в лотке доработки, либо добавлением новой записи в песочницу.
Бэклог обновляется вместе с получением обратной связи. Это приводит к появлению новых историй в песочнице. Перед планированием следующего спринта Владелец продукта рассмотрит запросы и, возможно, добавит что-то в работу. Совсем простые запросы (изменение метки, цвета и т. д.) будут сгруппированы в одну историю.
Процесс получения обратной связи во время обзора, тем не менее, регулируется и ограничивается. Нужно настаивать на использовании результата спринта после обзора: люди, которые хотели бы попробовать данный продукт, могут это сделать в специальной среде, а затем дать более полную обратную связь.
12Улучшение через ретроспективу
В крупных компаниях ближе к концу проекта отдел контроля качества или какой-либо его аналог напоминает руководителю проекта, что следует подвести итоги и оценить проделанную работу.
Подведение итогов – это возможность оценить течение проекта и составить список основных моментов. Цель анализа – получение знаний и опыта: как команде, так и людям извне.
К сожалению, подведение итогов проекта проводится слишком поздно: работа уже закончена, команда распалась. И уроки, которые команда извлекает, невозможно применить в рамках этого проекта.
Ретроспектива спринта существует именно для того, чтобы команда могла постоянно развиваться. При применении Scrum участники не дожидаются окончания проекта, чтобы подвести итоги: ретроспектива происходит после каждого спринта.
Продолжая аналогию с регби, можно сравнить ретроспективу с разговором команды на тему мы переиграем этот матч – при том, что в этом разговоре участвуют только игроки и они настроены на больший успех в следующем матче.
Scrum – это не процесс. Однако ретроспектива – это улучшение процесса. Не противоречит ли одно другому?
Нет! Процесс не навязывается команде. Это команда создает процесс, основываясь на структуре, предложенной Scrum, особенно во время ретроспективы.
На основе опыта, извлеченного из прошедшего спринта, команда определяет, что для нее работает хорошо, а что не очень. Коллективно участники находят, что нужно изменить в их работе – их процессе.
12.1 Практика коллективного улучшения
Термин ретроспектива в основном используется в художественной сфере, чтобы расположить творения создателя в хронологическом порядке: вот телеканал «France 3» этим летом предлагает для зрителей ретроспективу Хичкока, или в газете «La Dépêche» появляется статья о ретроспективе Сауры в музее Les Abattoirs. Часто ретроспектива посвящена шедеврам тех, кого уже нет в живых…
Ретроспектива спринта – не о возвращении к прошлому, а о возможности извлечь из него опыт и всей командой уверенно идти в будущее.
Рисунок 12.1 – Спесивый (высокомерный) Scrum-мастер выставил burndown-графики в экспозиции-ретроспективе своих спринтов
Во время ретроспективы команда задается вопросами о том, как она поработала во время прошедшего спринта. Это один из столпов эмпирического подхода – инспекция, ведущая к адаптации. В данном случае, в отношении окончившегося спринта.
Инспекция и адаптация происходят в течение всего жизненного цикла продукта, ведь всегда есть что-то, что можно улучшить.
Ретроспектива позволяет извлечь выгоду из применяемых практик, чтобы избежать повторения одних и тех же ошибок, обмениваться различными точками зрения и адаптироваться ко всевозможным новшествам (например, технологиям, используемым для разработки, или Agile-техникам).
Ретроспектива – это момент в конце спринта, когда команда останавливается, размышляет и рассуждает о своем опыте.
Как говорил Жебе (прим. пер.: Жорж Блондо, французский художник) в комиксе «Год 01»: мы останавливаемся и думаем.
Рисунок 12.2 – Необходимость в ретроспективе
По моему опыту, ретроспектива длится немногим более часа и проводится в тот же день, что и обзор – примерно в 16 часов.
После ретроспективы команда Peetic отмечает окончание спринта в баре и применяет известный праздничный паттерн: демо, ретро, аперо [38].
Для коротких спринтов также можно за один день провести и обзор, и ретроспективу, и планирование следующего спринта. В этом случае ретроспектива состоится ближе к обеду (и «трилогия» в таком случае станет демо, ретро, ресто) или после него.
В собрании участвует вся Scrum-команда. Важно не забыть, что Владелец продукта тоже входит в состав команды.