Scrum Master (курс) : Лекция 12
Цели
Понять зачем нужен и как проводить ретроспективу
Тезисы
Ретроспектива проводится в конце спринта, после ревью
Цель: оценка процесса feedback и улушение процесса
Время - до 45 минут на каждую неделю спринта (3 часа на месячный спринт)
Участники - вся Scrum Team
- DevTeam
- PO
- SM
Важные части:
- Обсудить были ли спринт успешен
- Обсудить что способоствовало успешному завершению спринта
- Обсудить что препястовало успешному завершению спринта
- Обсудить что можно улучшить
- Выбрать одно изменение которое позволит улучшить процесс и добавить его в вследующий sprint backlog.
Важные моменты:
Только команда должна присутствовать на ретроспективе. Если будут в присутсвовать другие люди, особенно заказчик или руководтво (от кого зависит оплата людей!) то люди не будут обсуждать свободно и принимать решение, они будут искать распоряжений для исполнения. А если они не приняли решения сами то и commitment он будет добиться сложно. Ну и стимулируется как минимум две негативных с точки зрения скрама модели:
- “Нам что сказали - то мы сделали”
- “Это не мы плохо сделали, это их дурацкая идея была”
Нельзя делать это митинг просто критикой, т.е. исключительно том, что делали плохо. Причин две, обе важные
- Если митинг будет только о негативном - то у команды не будет желания туда ходить. А нам нужна вовлеченность команды на этот митинг
- Сохранить правильное иногда даже важнее чем устранить неправильное, все команды многократно наблюдали что когда команда сама не осознала важность каких-то действий (как минимум по TDD все тут хотя бы раз проехались) - эта практика легко теряется если не закреплять.
Конкретные способы вовлечения людей на ретроспективе:
- Провести brainstorm на карточках/dot voting для определения что помогло, что мешало и выбора следующего изменения.
- Поиграть в прокурора и адвоката - назначить одного рассказывать только о плохом, а другого только о хорошем.
- ВАЖНО не просто обсуждать - а ввести сразу паттерн - не просто “было хорошо”, а “было хорошо, предлагаю закреплять вот так” и не просто “было плохо”, а “было плохо, лучше бы сделать вот так”. Не возводить в абсолют, но всегда использовать при попытке когда критика превращается в базар.
- Использовать sailboat для визуализации.
- Можно сделать “карту погоды/карту настроений спринта”
- Можно сделать retrospective kanban - где слева “было плохо”, “пробовали изменять”, “успешно применяли”, “улучшали”, “критически помогло успеху”
ссылки:
