В рунете появились очень интересные статьи по проведению ретроспектив.
Почитайте, мне показалось интересным
Заодно хочу поделиться нашим опытом проведения ретроспектив.
Мы довольно долго искали более или менее "устойчивую" форму проведения ретроспектив. Наш формат ретроспектив исходит из наиболее серьезных проблем их проведения. Из-за этих проблем команды забрасывают проводение ретро на начальном этапе их внедрения:
* Проведение ретроспективы "из книжки" требует некоторых навыков фасилитации. А для многих само слово "фасилитация" звучит пугающе
* Ретроспективы превращаются в ППР (пришли, поговорили, разошлись :-). Никаких реальных действий по результатам не принимается. Это очень демотивирует команду.
* Команда берется улучшать сразу все. Многое не получается. Проблема тут в том, что нет обратной связи по результатам предпринятых улучшений. Это тоже сильно демотивирует
* Ретроспектива исходит только из анализа проблем. Как только мы порешали основные проблемы, ретроспектива вырождается.
Я расскажу, к какому формату мы пришли в итоге. Возможно, это не самый идеальный вариант проведения. В книжках можно встретить намного более интересные практики ретроспектив. Они замечательные, мы их любим, но они все-таки требуют от ведущего знания некоторой теории и практики фасилитации.
Это как высокоточное и технологичное оружие. С таким оружием нужно уметь обращаться. Оно требует от бойца серьезных навыков и знаний. К примеру, винтовка М-16 обладает высокой кучностью и убойной силой. Однако, самое массовое штурмовое оружие в мире - Автомат Калашникова. Он прост, надежен, им может пользоваться даже ребенок. Идеальная практика должна быть именно такой. Минимум сложных правил. Максимум ценности.
Формат ретроспективы
Итак. Ведущий разделяет доску или флипчарт на 4 части:
* Плюсы. Что шло хорошо в прошлой итерации
* Минусы. Какие проблемы были в прошлой итерации
* Идеи. Какие идеи появились по ходу ретроспективы
* План. Какие улучшения мы запланируем на следующую итерацию
Задача команды - просто заполнить таблицу. Конечной целью является План. Все остальное - средства по его созданию.
Несколько общих правил проведения
* Все высказываются по очереди и вспоминают плюсы и минусы прошлой итерации
* Очень полезно держать перед глазами Burn Down Chart и доску задач и обращаться к ней в случае необходимости
* Удобнее всего отдельные айтемы записывать на клейких листочках. Тогда их можно при необходимости сгруппировать в один пункт, выкинуть или переписать.
* Нет смысла спорить, является ли важным или даже релевантным предложенный кем-то плюс, минус или идея. Если айтем кому-то не нравится, он просто не попадет в план
* План удобнее отложить на потом. Сначала заполнить плюсы, минусы и идеи
* В любой момент можно вернуться назад к плюсам, идеям или минусам и что-то добавить
* В план должны попадать конкретные вещи, которые вы точно планируете сделать в следующей итерации. Тут главное не планировать никаких "будем работать еще усерднее". Только конкретные действия
* Пункты плана бывают двух типов:
1) Задача. Она должна встать в план следующей итерации. Примеры:
- Прикрутить рассылку уведомлений по почте к билд-серверу
- Обсудить дизайн нового модуля
- Выработать соглашения по кодированию (Coding Styles)
2) Правило. Процессный регламент. Примеры:
- Парное программирование для задач, которые будут отмечены при планировании итерации
- В план итерации попадают задачи, длительность которых не более двух дней
- Добавить в Definition Of Done ревью кода
* После ретроспективы задача должна попасть на планирование и затем на доску задач в разделе To Do. Тогда ее кто-то подберет и сделает. За попадание листочка на планирование отвечает скрам-мастер
* За соблюдение правила отвечает команда. Скрам-мастер следит за тем, что команда исполняет принятые ею правила
* Ретроспектива начинается с того, что скрам-мастер вытаскивает листочки с планом прошлой ретроспективы. Команда решает, перевешивать листочки в минусы или плюсы.
* Идеи следуют из минусов, но ими не ограничиваются. Можно предложить идею, которая не связана ни с какими проблемами. Например "давайте в следующей итерации попробуем парное программирование!"
* Совершенно необязательно и даже, пожалуй, вредно пытаться внедрить все улучшения за один раз. Имеет смысл заниматься столько теми, которые вы осилите. 3-6 пунктов в разделе План вполне достаточно.
Жирным шрифтом я выделил пункты, которые считаю критичными для успеха ретроспективы.
И наконец, по поводу поднятого Денисом Миллером вопроса. Как лучше назвать минусы - "что можно улучшить" или "проблема"? С моей точки зрения, использование слова "проблема" только тогда является демотиватором, когда вы проблемами не занимаетесь и их не решаете. В конце концов мы все тут инженеры и наша задача - решение проблем, не так ли? Так что я не вижу смысла пользоваться эвфемизмами и иносказаниями. С другой стороны, решенная проблема - это хороший мотиватор. Мне кажется, использование формулы "что нужно улучшить" отбирает у команды успех, если проблема действительно решена!
Здесь
