День 2363. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 58. Если не тратить время на учёбу и совершенствование, то не стоит ждать, что следующий проект будет реализован лучше предыдущего
Процесс размышления о событии, имеющий целью пережить следующее событие, называется ретроспективой («обзором результатов разработки» или «постмортемом» - даже если проект был реализован). Все команды разработчиков ПО должны проводить ретроспективы в конце цикла разработки (выпуска или итерации), по завершении проекта и при возникновении неожиданного или разрушительного события.

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

Ретроспектива помогает ответить на четыре вопроса:
1. Что получилось хорошо и что мы хотели бы повторить?
2. Что получилось не так хорошо и где в следующий раз следует поступить иначе?
3. Что нас удивило и может быть опасным в будущем?
4. Есть ли что-то, чего мы ещё не понимаем и должны исследовать?

Ретроспектива должна проводиться с привлечением всех участников и не должна использоваться для обвинения кого-то. Важно объективно и беспристрастно исследовать прошлый опыт. Каждый участник ретроспективы должен помнить первый закон Керта: «Какие бы факты ни вскрылись в ходе ретроспективы, мы должны понимать и искренне верить, что каждый старался делать свою работу максимально хорошо, с учётом имеющейся информации, навыков и способностей, доступных ресурсов и ситуации, сложившейся на тот момент.»

Время ретроспективы зависит от объёма проекта, качества выполнения работы и количества нового материала, который еще предстоит узнать. Agile-команде может потребоваться 30-60 минут на обсуждение итогов двухнедельного спринта. В больших проектах можно выделять до нескольких дней. Чем больше потенциальных рычагов для улучшения будущих результатов, тем целесообразнее тратить время на подведение итогов.

Ретроспектива — структурированная и ограниченная по времени последовательность действий: планирование, начало мероприятия, сбор информации, определение приоритетов проблем, анализ проблем и принятие решения о том, что делать с информацией. Члены команды делятся своим опытом работы над проектом: что произошло, когда и чем закончилось. Рекомендуется спрашивать мнение всех участников проекта, поскольку точка зрения каждого уникальна. Важно узнать эмоциональный фон участников во время выполнения проекта. Это позволяет найти идеи, повышающие чувство удовлетворенности работой.

Участники ретроспективы сообщают любые данные, собранные командой, в виде типичных метрик:
- размер — количество и объём требований, пользовательских историй и других элементов;
- трудозатраты — запланированные и фактические;
- время — запланированная и фактическая календарная продолжительность;
- качество — количество дефектов и их виды, производительность системы и другие качественные характеристики.

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

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

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.