Еще слайды, на этот раз с мартовской встречи AgileRussia на тему "Роль ретроспектив в создании эффективного процесса разработки".
А вы пробовали у себя в проекте проводить ретроспективы?
Наверняка, хотя бы один раз пробовали. А почему они не прижились? Команда посчитала их не нужными? Или у вас не хватает времени на их проведение?
Правильно проведенная ретроспектива дает уникальную возможность максимально рано узнать о тех проблемах, которые зреют в проекте и найти эффективные и своевременные способы их решения.
вторник, 3 июня 2008 г.
Роль ретроспектив
Подписаться на:
Комментарии к сообщению (Atom)
2 коммент.:
Как вот объяснить участнику проекта, что ему ничего плохого не будет за критику коллег и менеджера. Или иначе - как научить людей высказывать замечания, чтобы коллеги на них не обижались?
На ретроспективах нельзя критиковать ни коллег, ни начальство. Иначе первые обидятся на коллег и не будут участвовать ни в каком анализе проблем, а вторые просто запретят проведение таких ретроспектив :)
Важно помнить и донести до каждого Первое Правило Ретроспективы - каждый старался как мог и сделал все, что было в его силах (слайд ХХ).
Поэтому критике подвергаем только результат (или его отсутствие) - и думаем не о том, что Петя идиот (сломал сборку в день поставки релиза и, не зная об этом, ушел домой), а о том, почему это произошло (не были разделены ветки релиза и девелопмента, выпуск релиза осуществлялся не всей командой) и как недопустить такой ситуации в будущем (при подготовке релиза девелопмент осуществляется _только_ в основной ветке, исправление ошибок - в основной и релизе; вся команда дожидается отправки релиза заказчику и только потом празднует успех и расходится по домам).
Приведенный пример, кстати, из жизни. Уже не изменить то, что произошло, но точно можно в следующий раз сделать лучше. Проверено.
Главное, не переходить на личности. За этим четко должен следить ведущий ретроспективы.
Ну и не забывать про action items - результаты ретроспективы должны быть обязательно отработаны.
Отправить комментарий