Ретроспективы Спринта, которые действительно меняют поведение
Узнайте, как проводить Ретроспективы Спринта, формирующие реальные привычки. Сосредоточьтесь на единичных конкретных улучшениях, помещенных напрямую в Бэклог Спринта.
Большинство Ретроспектив Спринта превращаются в вежливый выпуск пара, который ничего не меняет. Команда жалуется на нестабильные автотесты или неясные критерии приемки, клеит стикеры на виртуальной доске и возвращается к работе. Через две недели те же самые проблемы возникают снова. Руководство по Scrum 2020 года определяет Ретроспективу Спринта как событие для планирования способов повышения качества и эффективности. Если в понедельник утром команда ведет себя точно так же, событие прошло впустую.
Иллюзия списков действий
Команды часто завершают Ретроспективу с пятью размытыми намерениями. Они обещают лучше общаться, писать более чистый код и вовремя обновлять рабочие задачи. Это лишь пожелания, а не действия. Привычки людей не меняются от благих намерений. Если у задачи по улучшению нет конкретного исполнителя и проверяемого критерия, она просто растворяется под давлением текущей работы.
Руководство по Scrum предлагает практическое решение: наиболее важные улучшения внедряются как можно быстрее и могут быть добавлены в Бэклог Спринта на следующий Спринт. Это размещение имеет решающее значение. Если пункт улучшений отсутствует на доске рядом с продуктовыми задачами, разработчики забывают о нем при ежедневном выборе приоритетов. Добавление улучшения в Бэклог Спринта дает ему такую же видимость, как и пользовательским функциям.
Выберите ровно один небольшой эксперимент
Грандиозные планы улучшений почти всегда проваливаются. Попытка исправить автотесты, код-ревью и уточнение бэклога за один Спринт перегружает команду и лишает ее способности адаптироваться. Настоящее изменение поведения требует крошечных, последовательных шагов.
Относитесь к результатам Ретроспективы как к проверяемым экспериментам. Вместо попыток перестроить весь рабочий процесс выберите одно точечное изменение на предстоящий Спринт:
- Не брать в работу новые задачи, если более двух pull request ожидают проверки.
- Обязать Product Owner и одного разработчика тратить десять минут на разбор крайних случаев перед стартом работы над задачей.
- Запускать набор тестов локально перед отправкой любой ветки в репозиторий.
- Посвящать первые три минуты Daily Scrum разбору заблокированных задач, прежде чем обсуждать остальное.
Определите наблюдаемый критерий выполнения
Если невозможно проверить, внедрила ли команда изменение, нельзя оценить и его эффект. Размытые цели вроде ускорения рассмотрения pull request порождают субъективные споры вместо ясности. Конкретное обязательство с Ретроспективы четко определяет, что именно считается выполнением.
Например, сформулируйте эксперимент предельно ясно: каждый pull request получает обратную связь в течение четырех рабочих часов, либо автор пишет об этом в общий чат команды. В конце Спринта вы не спрашиваете участников, как они оценивают процесс код-ревью. Вы проверяете, проводились ли проверки в течение этих четырех часов. Эмпиризм опирается на наблюдения и факты, а не на воспоминания.
Замыкание петли обратной связи
Самый надежный способ убить интерес к Ретроспективе заключается в игнорировании прошлых договоренностей. Прежде чем начинать новый разговор об очередных проблемах, откройте Бэклог Спринта и оцените пункт улучшений с прошлой Ретроспективы. Выполнила ли его команда? Стала ли поставка более предсказуемой, а качество выше?
Если эксперимент не решил проблему, отбросьте его и попробуйте другой подход. Если он сработал, сделайте его стандартной практикой и переходите к следующей проблеме. Ретроспективы становятся ценными только тогда, когда команда видит реальную пользу от собственных решений, меняющих их повседневную работу.