Гибкие методологии. Ретроспектива

    Ретроспектива (от лат. retrospectare, «взгляд назад») — взгляд в прошлое, обозрение того, что было в прошлом.

    В гибких методологиях существует такое понятие как «ретроспектива». С первого взгляда может показаться, что это совершенно ненужный элемент. Но я точно знаю, что использование ретроспектив улучшило процесс разработки в моей команде.
    Итак, несколько определений:

    Ретроспектива — собрание, которое проводит проектная команда в конце каждой итерации, чтобы обсудить, чему мы научились, как команда и строить планы на следующие итерации, основываясь на извлечённых уроках.
    Ретроспектива – это командная активность пересмотра ближайшего отрезка времени работы команды с целью улучшения процесса работы этой же команды в этом же проекте.

    Все звучит довольно просто и логично, но нашей команде удалось сделать ретроспективы полезными и эффективными далеко не сразу.

    Что нужно для проведения ретроспективы?
    1. Команда (Agile советует собирать всех, включая заказчиков, но у нас собираются только разработчики)
    2. Помещение для проведения – желательно, что бы это была отдельная комната, например, переговорка ( что бы никому не мешать, да и что бы нам никто не мешал)
    3. Доска для рисования или закрепленные для рисования листы
    4. Маркеры (желательно нескольких цветов)
    5. Время от получаса до двух (длительность зависит от частоты проведения рестроспектив, количества человек в команде, сформированности самой команды)

    Как проходит ретроспектива?
    Можно выделить несколько этапов:
    1. Опрос мнений(что хорошего и что плохого было в прошедшей итерации?) и фиксирование их на доске
    2. Голосование
    3. Выделение и обсуждение основных злободневных проблем (Набравших большинство голосов)
    4. Определение путей решения выбранных проблем, ответственных за них
    5. Фиксирование достигнутых результатов (Обсуждение задач, которые решались по результатам прошлых ретроспектив)

    У каждой ретроспективы должен быть ведущий: «человек с маркером». В описании методологии не рекомендуется, что бы таким ведущим был руководитель. Наша команда пришла к методу: «эстафетной палочки»: т.е. ведущие меняются от ретроспективы к ретроспективе. Самое главное, что должен делать, вернее НЕ делать ведущий – это не переиначивать слова и высказывания на свой лад, потому как это может искажать смысл высказывания.

    Опрос мнений можно проводить в открытую, а можно анонимно (тогда ведущий собирает листочки, с написанными на них пунктами). Самое главное в процессе опроса мнений – не скатываться на обсуждение этой проблемы, а только зафиксировать ее.

    И никогда не забываем о пунктах «хорошо», о них следует спрашивать в первую очередь.
    «Что понравилось в прошедшей итерации?», «какие положительные моменты ты бы мог отметить?», «что бы ты хотел записать в раздел «хорошо»?» — примерные вопросы, которые задает ведущий членам команды. Аналогично по разделу «плохо».

    Кстати говоря, количество пунктов, их «серьезность» и превалирование какого-либо раздела, довольно четко показывает «сформированность» команды, «поставленность» процессов и т.п.

    Голосование может проходить разными способами. Можно выявлять «приоритерезацию» задачи для человека (поднятие 5, 4, 3 пальцев и т.д.). Наша команда избрала путь ограничения количества голосов. Каждый может голосовать только за треть пунктов. (Если в разделе «хорошо» 12 пунктов, то у человека 4 голоса и значит поднять руку и проголосовать он может за любые 4 пункта из 12).
    Ведущий подсчитывает голоса и пишет цифру напротив каждого пункта. Выделяются самые «популярные» темы в каждом из разделов. Обычно их по 3-4, это и есть самые волнующие команду проблемы и отмеченные всеми «приятности».
    (Вот тут-то и понадобятся цветные маркеры – отделить цифры голосов от номеров пунктов и для обводки).
    Пункты из раздела «хорошо» просто фиксируются в отчете по ретроспективам. (Команда должна помнить свои достижения!)
    А вот с пунктами из раздела «плохо» надо еще поработать. Очень хорошо, если команда обсудив, придумает решение этим проблемам, или хотя бы начальный путь, по которому необходимо двигаться для решения. Здесь же выбирается ответственный за задачу, который должен сделать все возможно для ее решения.
    Мы для удобства отслеживания задач по ретроспективам заводим их в Jira и поступаем как с обычными задачами по проектам.

    В самом конце ретроспективы кратко обсуждается результаты прошлых ретроспектив, ответственные рассказывают о том что было сделано. ( «А вот это у нас теперь есть! И теперь мы делаем так-то и так-то. Это же мы в прошлый раз придумали.») Иногда происходит корректировка прошлых задач и переназначение ответсвенных.

    Начав писать статью, я поняла, что тема довольно обширная. Если сообществу будет интересно узнать дальше, то я напишу продолжение, где расскажу о возникающих проблемах и способах, которыми мы с ними боролись.

    Комментарии 25

      +1
      сколько человек у вас в команде?
        +1
        сейчас нас 7 человек
        +1
        Хорошая статья, спасибо.
        Я бы жирным отметил, что ретроспектива — это обсуждение положительных и отрицательных элементов процесса.
        Насчет ведущего: главная задача ведущего, кроме записи и собственно организации митинга, не давать команде сваливаться в бурные обсуждения одной проблемы, это роль фасилитатора — а значит ее не факт что может выполнять каждый.
        «собираются только разработчики» — хм, а как же тестеры? они не входят в проектную команду?

        ps. а вы используете «доску»?
          +1
          Вообще с ведущим мы еще точно не решили, возможно остановимся на ком-нибудь одном, у кого лучше всего будет получаться :)

          Идея участия тестеров в ретроспективах у нас была и есть, но пока с этим трудности: тестеры у нас находятся в другом офисе и поэтому существует этакое разделение. Хотя утренние скрамы у нас совместные.

          Если Вы про доску с задачами, то да, используем.
            +1
            подключайте тестеров. это полезно и для девелоперов, и для самих тестеров, и для проекта :)

            А мы вот доску использовали всего три двухнедельных спринта и отказались от нее. построили процесс занесения и ведения тикетов в баг-трекере так, чтобы главный принцип agile соблюдался — таски не назначаются на конкретных людей, а любой член команды берет на выполнение любой тикет из спринта и ставит in progress — в итоге все видят, у кого что и доска становится не нужна.
              0
              Спасибо за совет и внимание к статье :)

              Мы с доски думаем перейти на «виртуальную» в Jira. Хотя реальная с цветными листочками удобна и привычна :)
                +4
                Agile Wall Report в Jira мы используем для наглядности прогресса спринта :)

                А интерес к статье раскрывается просто: применяем в команде (6 человек) Agile Scrum с октября месяца. Методология показала себя весьма эффективной и кроме этого приносит нам fun в работе :)
                Поэтому интересует все, связанное со scrum, особенно, когда приводят примеры внедрения scrum'а из личного опыта.

                Обязательно пишите еще статьи, буду с удовольствием читать и комментировать.
                +1
                Мне кажется, что доска сильно удобнее Jira:

                1. Cоздает командное пространство — рядом с доской удобно проводить scrum meetings и обсуждения.
                2. Способствует коммуникации — движение задач происходит не в виртуальном мире, а в реальном. Вся команда видит все изменения на доске не прилагая к получению этой информации никаких усилий (открыть браузер).
                3. Субъективно улучшает настрой — приятно пару раз в день вставать из-за стола и перевешивать реальную бумажку.
                  +1
                  В каждом методе есть свои достоинства и недостатки. А когда команда распределенная без «виртуальной доски» никак :)

                  Хотя кинуть взгляд на белую доску в цветных листочках, что бы посмотреть сколько в работе, сколько закрытых, а сколько еще новых задач — очень приятно :)
                    0
                    С распределенной командой — да, ничего не поделаешь ;)
                      +1
                      Можно попытаться слегка развиртуализировать доску в jira повесив проектор с taskboard на стену, который бы обновлялся раз в минуту. Проекторы нынче не дорогие =)
            +1
            У меня есть вопрос по «гибкой методологии», на который мне мало кто может дать внятный ответ.

            Как вы ведете проектную документацию и согласовываете ее с заказчиком? Согласовываете при каждом изменении?
            По сути большинство документации о внедрении, и разработки ПО, составляется для того, что бы менеджеры или руководители прикрыли свою жопу. Как они вообще соглашаются, что-либо делать, без прикрытия своей 5 точки?
              +1
              Тут дело в следующем, когда подписывается договор, до заказчика доносится идея о том, что представитель заказчика обязательно учавствует в работе команды.
              На основе спецификации (ТЗ) на весь проект пишутся UserStory.
              В начале каждого спринта представитель заказчика вместе с руководителем проекта планируют задачи на этот спринт. Сколько и какие конкретно userstory должны быть реализованы (напоминаю, что результат спринта — готовый продукт, в котором реализованы не все фичи).
              Заказчик сам утверждает спринт, а значит понимает, что будет сделано. постоянно видит работу. и внесение изменений в изначальное ТЗ — означает только, что на следующий спринт могут быть выбраны фичи, которые не планировались при старте проекта.
                0
                shtulberg правильно написал. Хотя основное ТЗ согласовывается изначально, но доработки идут все время, обычно это дополнения и уточнения. Конечно же, их обсуждают с заказчиком.
                +2
                Раньше я называл это разбором полётов. Теперь буду знать, что это практика называется ретроспективой. =)) Спасибо, полезная статья.
                  0
                  Ну все-таки разница есть :) Вот у меня выражение «разбор полетов» сразу же ассоцируется с негативом, а ретроспектива очень положительное мероприятие. Как по результатам, так и по процедуре проведения.
                  Обсуждаются не личные промахи людей, а проблемы в самом процессе :) Ведь многие ошибкииз-за этого и происходят.
                    +1
                    Нет, это не разбор полетов :) Главная задача и, одновременно, проблема рестроспектив — это не превращать собрание в утомительную «обязаловку», где начинаются взаимные обвинения.
                    Кстати, у нас выходило так, что заказчик был основным «ступором» митинга, то есть описание какой-то проблемы занимало достаточно долгое время, прерывать его никому не хотелось, — в итоге большая часть времени уходила, к сожалению, впустую
                      +1
                      Разбор полетов обычно проводится после завершения проекта, когда уже поздно что-то менять (и скорее всего проект уже оказался не совсем успешным:) ).

                      Прелесть ретроспективы же в том, что мы анализируем двух (или одно-)недельную итерацию и можем улучшить свою работу прямо на следующий день после ретроспективы.
                        +1
                        На сколько я понял, то ретроспектива ориентирована не на конкретный проект, а на рост команды проекта и на улучшения процессов работы.
                          +1
                          но команда ведь во время проведения ретроспективы занимается конкретным проектом, разве нет? :)
                      +1
                      Отличная статью. С удовольствием прочту продолжение
                        +1
                        В прошлом году проводили встречу AgileRussia на тему ретроспектив, осталась достаточно подробная презентация.

                        Еще из полезного — помимо опроса в стиле «что было хорошо, а что плохо», очень здорово проходят ретроспективы c помощью диаграммы starfish, когда команда опрашивается в стиле «что работало хорошо, чего не хватало, что нужно улучшить и т.п. (см картинку по ссылке)».

                        Этот способ позволяет взглянуть на прошедшую итерацию немного под другим углом, нежели обычная ретроспектива.
                          +1
                          сорри, ссылки почему-то не отобразились.
                          на презентацию по ретроспективам: lobasev.ru/2008/06/blog-post.html
                          на Starfish ретроспективу: www.thekua.com/rant/2006/03/the-retrospective-starfish/
                            0
                            Спасибо за идею, может попробуем в будующей ретроспективе ее реализовать :)
                            +1
                            У нас тоже каждая итерация заканчивается ретроспективой. Понравилась идея разделить мнения на три группы:
                            1) В следующей итерации я бы сделал это так же
                            2) В следующей итерации я бы это улучшил
                            3) Конкретные идеи по улучшению

                            На практике это легко позволяет выявить что идет хорошо, а где есть проблемы.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое