Ретроспектива (от лат. retrospectare, «взгляд назад») — взгляд в прошлое, обозрение того, что было в прошлом.
В гибких методологиях существует такое понятие как «ретроспектива». С первого взгляда может показаться, что это совершенно ненужный элемент. Но я точно знаю, что использование ретроспектив улучшило процесс разработки в моей команде.
Итак, несколько определений:
Ретроспектива — собрание, которое проводит проектная команда в конце каждой итерации, чтобы обсудить, чему мы научились, как команда и строить планы на следующие итерации, основываясь на извлечённых уроках.
Ретроспектива – это командная активность пересмотра ближайшего отрезка времени работы команды с целью улучшения процесса работы этой же команды в этом же проекте.
Все звучит довольно просто и логично, но нашей команде удалось сделать ретроспективы полезными и эффективными далеко не сразу.
Что нужно для проведения ретроспективы?
1. Команда (Agile советует собирать всех, включая заказчиков, но у нас собираются только разработчики)
2. Помещение для проведения – желательно, что бы это была отдельная комната, например, переговорка ( что бы никому не мешать, да и что бы нам никто не мешал)
3. Доска для рисования или закрепленные для рисования листы
4. Маркеры (желательно нескольких цветов)
5. Время от получаса до двух (длительность зависит от частоты проведения рестроспектив, количества человек в команде, сформированности самой команды)
Как проходит ретроспектива?
Можно выделить несколько этапов:
1. Опрос мнений(что хорошего и что плохого было в прошедшей итерации?) и фиксирование их на доске
2. Голосование
3. Выделение и обсуждение основных злободневных проблем (Набравших большинство голосов)
4. Определение путей решения выбранных проблем, ответственных за них
5. Фиксирование достигнутых результатов (Обсуждение задач, которые решались по результатам прошлых ретроспектив)
У каждой ретроспективы должен быть ведущий: «человек с маркером». В описании методологии не рекомендуется, что бы таким ведущим был руководитель. Наша команда пришла к методу: «эстафетной палочки»: т.е. ведущие меняются от ретроспективы к ретроспективе. Самое главное, что должен делать, вернее НЕ делать ведущий – это не переиначивать слова и высказывания на свой лад, потому как это может искажать смысл высказывания.
Опрос мнений можно проводить в открытую, а можно анонимно (тогда ведущий собирает листочки, с написанными на них пунктами). Самое главное в процессе опроса мнений – не скатываться на обсуждение этой проблемы, а только зафиксировать ее.
И никогда не забываем о пунктах «хорошо», о них следует спрашивать в первую очередь.
«Что понравилось в прошедшей итерации?», «какие положительные моменты ты бы мог отметить?», «что бы ты хотел записать в раздел «хорошо»?» — примерные вопросы, которые задает ведущий членам команды. Аналогично по разделу «плохо».
Кстати говоря, количество пунктов, их «серьезность» и превалирование какого-либо раздела, довольно четко показывает «сформированность» команды, «поставленность» процессов и т.п.
Голосование может проходить разными способами. Можно выявлять «приоритерезацию» задачи для человека (поднятие 5, 4, 3 пальцев и т.д.). Наша команда избрала путь ограничения количества голосов. Каждый может голосовать только за треть пунктов. (Если в разделе «хорошо» 12 пунктов, то у человека 4 голоса и значит поднять руку и проголосовать он может за любые 4 пункта из 12).
Ведущий подсчитывает голоса и пишет цифру напротив каждого пункта. Выделяются самые «популярные» темы в каждом из разделов. Обычно их по 3-4, это и есть самые волнующие команду проблемы и отмеченные всеми «приятности».
(Вот тут-то и понадобятся цветные маркеры – отделить цифры голосов от номеров пунктов и для обводки).
Пункты из раздела «хорошо» просто фиксируются в отчете по ретроспективам. (Команда должна помнить свои достижения!)
А вот с пунктами из раздела «плохо» надо еще поработать. Очень хорошо, если команда обсудив, придумает решение этим проблемам, или хотя бы начальный путь, по которому необходимо двигаться для решения. Здесь же выбирается ответственный за задачу, который должен сделать все возможно для ее решения.
Мы для удобства отслеживания задач по ретроспективам заводим их в Jira и поступаем как с обычными задачами по проектам.
В самом конце ретроспективы кратко обсуждается результаты прошлых ретроспектив, ответственные рассказывают о том что было сделано. ( «А вот это у нас теперь есть! И теперь мы делаем так-то и так-то. Это же мы в прошлый раз придумали.») Иногда происходит корректировка прошлых задач и переназначение ответсвенных.
Начав писать статью, я поняла, что тема довольно обширная. Если сообществу будет интересно узнать дальше, то я напишу продолжение, где расскажу о возникающих проблемах и способах, которыми мы с ними боролись.
В гибких методологиях существует такое понятие как «ретроспектива». С первого взгляда может показаться, что это совершенно ненужный элемент. Но я точно знаю, что использование ретроспектив улучшило процесс разработки в моей команде.
Итак, несколько определений:
Ретроспектива — собрание, которое проводит проектная команда в конце каждой итерации, чтобы обсудить, чему мы научились, как команда и строить планы на следующие итерации, основываясь на извлечённых уроках.
Ретроспектива – это командная активность пересмотра ближайшего отрезка времени работы команды с целью улучшения процесса работы этой же команды в этом же проекте.
Все звучит довольно просто и логично, но нашей команде удалось сделать ретроспективы полезными и эффективными далеко не сразу.
Что нужно для проведения ретроспективы?
1. Команда (Agile советует собирать всех, включая заказчиков, но у нас собираются только разработчики)
2. Помещение для проведения – желательно, что бы это была отдельная комната, например, переговорка ( что бы никому не мешать, да и что бы нам никто не мешал)
3. Доска для рисования или закрепленные для рисования листы
4. Маркеры (желательно нескольких цветов)
5. Время от получаса до двух (длительность зависит от частоты проведения рестроспектив, количества человек в команде, сформированности самой команды)
Как проходит ретроспектива?
Можно выделить несколько этапов:
1. Опрос мнений(что хорошего и что плохого было в прошедшей итерации?) и фиксирование их на доске
2. Голосование
3. Выделение и обсуждение основных злободневных проблем (Набравших большинство голосов)
4. Определение путей решения выбранных проблем, ответственных за них
5. Фиксирование достигнутых результатов (Обсуждение задач, которые решались по результатам прошлых ретроспектив)
У каждой ретроспективы должен быть ведущий: «человек с маркером». В описании методологии не рекомендуется, что бы таким ведущим был руководитель. Наша команда пришла к методу: «эстафетной палочки»: т.е. ведущие меняются от ретроспективы к ретроспективе. Самое главное, что должен делать, вернее НЕ делать ведущий – это не переиначивать слова и высказывания на свой лад, потому как это может искажать смысл высказывания.
Опрос мнений можно проводить в открытую, а можно анонимно (тогда ведущий собирает листочки, с написанными на них пунктами). Самое главное в процессе опроса мнений – не скатываться на обсуждение этой проблемы, а только зафиксировать ее.
И никогда не забываем о пунктах «хорошо», о них следует спрашивать в первую очередь.
«Что понравилось в прошедшей итерации?», «какие положительные моменты ты бы мог отметить?», «что бы ты хотел записать в раздел «хорошо»?» — примерные вопросы, которые задает ведущий членам команды. Аналогично по разделу «плохо».
Кстати говоря, количество пунктов, их «серьезность» и превалирование какого-либо раздела, довольно четко показывает «сформированность» команды, «поставленность» процессов и т.п.
Голосование может проходить разными способами. Можно выявлять «приоритерезацию» задачи для человека (поднятие 5, 4, 3 пальцев и т.д.). Наша команда избрала путь ограничения количества голосов. Каждый может голосовать только за треть пунктов. (Если в разделе «хорошо» 12 пунктов, то у человека 4 голоса и значит поднять руку и проголосовать он может за любые 4 пункта из 12).
Ведущий подсчитывает голоса и пишет цифру напротив каждого пункта. Выделяются самые «популярные» темы в каждом из разделов. Обычно их по 3-4, это и есть самые волнующие команду проблемы и отмеченные всеми «приятности».
(Вот тут-то и понадобятся цветные маркеры – отделить цифры голосов от номеров пунктов и для обводки).
Пункты из раздела «хорошо» просто фиксируются в отчете по ретроспективам. (Команда должна помнить свои достижения!)
А вот с пунктами из раздела «плохо» надо еще поработать. Очень хорошо, если команда обсудив, придумает решение этим проблемам, или хотя бы начальный путь, по которому необходимо двигаться для решения. Здесь же выбирается ответственный за задачу, который должен сделать все возможно для ее решения.
Мы для удобства отслеживания задач по ретроспективам заводим их в Jira и поступаем как с обычными задачами по проектам.
В самом конце ретроспективы кратко обсуждается результаты прошлых ретроспектив, ответственные рассказывают о том что было сделано. ( «А вот это у нас теперь есть! И теперь мы делаем так-то и так-то. Это же мы в прошлый раз придумали.») Иногда происходит корректировка прошлых задач и переназначение ответсвенных.
Начав писать статью, я поняла, что тема довольно обширная. Если сообществу будет интересно узнать дальше, то я напишу продолжение, где расскажу о возникающих проблемах и способах, которыми мы с ними боролись.