Ретроспективы в проектах были придуманы очень давно, просто назывались они раньше postmortem analysis и проводились только в конце проекта. Это означает, что проект уже завершен (часто неуспешно), и наша задача извлечь из этого проекта уроки на будущее.

Но есть нюансы:

• Проекту уже никак не помочь, так как он завершен (поэтому postmortem)
• Так как проект уже завершен, то такой анализ часто проводится формально
• Проектная команда будет разбросана по другим проектам (привет, матричная структура), и наработанные знания и опыт распылятся

Поэтому в современных процессах ретроспективный анализ встроен в сам процесс разработки и обязан проводиться постоянно. Именно это максимально повышает шансы проекта завершиться успешно. В Scrum ретроспективы обязаны быть раз в спринт, а Kanban говорит о том, что мы должны улучшаться непрерывно.

Вроде бы все просто, но что на практике?

Вспомните последнюю ретроспективу вашей команды.

Насколько она была полезная?

Какого уровня проблемы выявила команда?

Как глубоко эти проблемы были раскопаны в поисках реальных причин их возникновения?

Насколько неочевидные идеи придумала команда для улучшения?

Были ли реализованы эти улучшения и помогли ли они?

Очень часто ответы на эти вопросы немного удручают..

Этот тренинг призван помочь команде научиться:

1. Вовремя обнаруживать проблемы и делать их видимыми всей командой
2. Глубоко анализировать найденные проблемы и искать корневые причины их возникновения (уметь отделять симптомы проблем от настоящих причин)
3. Совместно придумывать неочевидные, контекстные решения, которые с большой вероятностью могут сработать
4. Всей командой воплощать принятые решения в жизнь