Ретроспектива

После Agile Practitioners Gathering я стал более широко воспринимать тему ретроспективы.

Ретроспектива – одна из наиболее игнорируемых практик. Почему же ее не используют? В основном потому, что видят трудности с ее внедрением, но не видят особых преимуществ.

Понятно, что использовать практику, не дающую никакой пользы, нет смысла. Но некоторые практики могут приносить долгосрочную пользу – что не всегда принимается во внимание.

Очевидные цели ретроспективы:

  • Собрать информацию, получить обратную связь
  • Что-то улучшить на основе полученной информации

Звучит красиво, но на практике это не так легко. Основными проблемами являются:

  • «Бюрократическая» атмосфера, люди не хотя давать реальную информацию, так как это в итоге может превратиться в «охоту на ведьм»
  • Члены команды не учитывают долговременных плюсов ретроспективы, но очень хорошо замечают кратковременные трудности, и быстро прекращают проводить ретроспективу
  • В случае неправильной организации, без четких целей ретроспектива не приносит реальной пользы, это пустая трата времени

Чтобы немного сгладить впечатление, что ретроспектива это что-то из области теоретической фантастики, приведу некоторые не совсем явные преимущества:

  • Может повысить открытость, так как люди привыкают давать и получать обратную связь
  • Так как в результате ретроспективы команда получает возможность «подстроить» процесс под себя, то шанс того, что основа процесса будет одинакова для многих проектов в компании (основа та же, отличаются в основном настройки), возрастает
  • Ретроспектива может помочь улучшить процесс на уровне всей компании
  • Она помогает адекватно отреагировать на изменения, а не просто игнорировать их

В данной статье я в основном остановлюсь на проведении ретроспектив:

  • Преимущества с разных точек зрения
  • Как проводить
  • Различные инструменты и подходы
  • Ретроспектива на более высоком уровне

Преимущества с различных точек зрения

С точки зрения компании:

  • Получение информации и обратной связи
  • Обучение и улучшение
  • Создание открытой атмосферы (хотя не для всех компаний это преимущество)
  • Поощрение людей к действию и активности

С точки зрения менеджера проекта:

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

И, наконец, преимущества с точки зрения команды:

  • Возможность быть услышанным
  • Подстройка процесса под реальные нужды, устранение лишних вещей

Как проводить

Для ретроспективы нужна хорошо продуманная организация. Я бы выделил 3 области:

  • Подготовка
  • Проведение
  • Реализация решений

Подготовка

На этом этапе одной из наиболее важных вещей является четкое и понятное объяснение всем, зачем это надо и как это поможет конкретным людям.

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

Проведение

Для ретроспективы обязательно нужен ведущий (фасилитатор). Это может быть член команды, Scrum master, человек из другой команды или даже профессиональный ведущий. Периодически можно менять фасилитатора.

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

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

Затем необходимо определить, что работает хорошо, а что является проблемой. После определения проблем предлагаются решения. На практике выявление проблем и решения для них предлагаются часто одновременно.

По итогам составляется action log. Стоит быть реалистичным, и не включать в action log так много элементов, что они заведомо не будет сделаны за следующий спринт.

В результате ретроспективы у нас есть:

  • Список работающих практик
  • Список проблем
  • Action log с конкретными действиями и ответственными людьми

Реализация решений

Ретроспектива без реальных изменений – это просто трата времени. Action log помогает сконцентрироваться именно на действиях, а не просто на разговорах.

Имеет смысл сделать action log наглядным и заметным. Например, распечатать и повесить в комнате команды. Когда какой-нибудь элемент завершен, можно сразу отмечать это на распечатке (например, перечеркнуть или поставить галочку). Когда команда видит, что что-то реально улучшается, энтузиазм в отношении ретроспективы повышается.

Различные инструменты и подходы

Существует большое количество инструментов и форматов для проведения ретроспективы. Рассмотрим только некоторые:

  • What went well/What could be improved
  • Keep this/Ongoing problems/Try this/
  • Bug fix analysis/Knowledge sharing/Fix process/Roles/Practices
  • Starfish
  • Timeline

What went well/What could be improved

Это один из самых простых форматов. Вопрос “What went well?” помогает выявить хорошо работающие элементы. А второй вопрос направлен на выявление проблем. Ответами на второй вопрос являются проблемы, но формулировка подчеркивает конструктивный подход.

Keep this/Ongoing problems/Try this

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

Starfish

Этот набор вопросов основан на starfish диаграмме.

Starfish diagram

Starfish diagram

  • Start doing – что нужно начать делать (например, регулярный peer code review)
  • Stop doing – что нужно прекратить делать (например, собирать бесполезные метрики)
  • Continue doing – это хорошо работает, нужно сохранить
  • More – этим вещам нужно уделять больше внимания (времени)
  • Less – этим вещам нужно уделять меньше внимания (времени)

Bug fix analysis/Knowledge sharing/Fix process/Roles/Practices

Этот вариант предложил Владимир Лешкевич.

Во время bug fix analysis исследуются допущенные ошибки и как их не повторять. Knowledge sharing – knowledge sharing :-). В рамках фазы Fix process анализируется процесс – убираются или добавляются роли и практики.

Timeline

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

Есть несколько подходов к построению timeline – в течение спринта или в начале ретроспективы. Первый позволяет не забыть события, но второй подход проще.

Борис Лебеда предложил вариант с black box’ом – в комнате команды ставится ящик, в который можно бросать заметки с событиями. На ретроспективе все эти заметки достаются, сортируются, выкидываются малозначительные – и получаем набор фактов.

Ретроспектива на более высоком уровне

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

Можно проводить вертикальную ретроспективу (спасибо Юре Шиляеву за идею), включающую заинтересованных лиц с разных уровней (например, команда + division manager, или менеджеры проектов + несколько разработчиков + division manager + CEO). Это облегчает общение между уровнями. Но стоит учитывать психологический аспект – если команда на уровне «performing», она сможет достаточно эффективно проводить такие ретроспективы, члены менее «зрелой» команды могут просто замолчать проблемы. В случае многоуровневых ретроспектив правильная организация обсуждения еще более важна.

Ретроспективы уровня проекта – это сложная практика. А многоуровневые – еще сложнее. Но эффект достаточно заманчивый: всесторонняя обратная связь, прозрачный обмен информацией между уровнями, общее понимание задач и целей.

Это долговременный инструмент

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

Post Author

This post was written by who has written 29 posts on Agile.by.

  • Alexander Byndyu

    Очень интересно. Я раньше не задумывался над проведением формальной ретроспективы. Обычно мы решаем “что работает” и “что не работает” в ходе работы над проектом. Например, во время парного программирования или экспресс-совещаний по утрам. В команде сейчас работает 5 человек. Есть ли смысл проводить рестроспективы в этом случае? Если да, то как часто и кто будет в них участвовать кроме заказчика?

  • http://exploratorydevelopment.com Dmitry Zdanovich

    Если адаптация происходит эффективно и без ретроспективы, то значение ретроспективы уменьшается. Но, имхо, все-таки полезно проводить периодически ретроспективу, чтобы четко сконцентрироваться на анализе и улучшении деятельности. Например, раз в месяц. По поводу участия – it depends. Комбинация команда + заказчик может работать очень позитивно (при условии хороших отношений).
    В дальнейшем можно иногда приглашать менеджера подразделения или ребят из других команд.

  • Sergio

    Ребята, читаю ваш блог довольно регулярно, но являясь нубом во многих аспектах программирования, нахожу многое сложным для понимания. А именно, не складывается пока цельная картина всего процесса разработки. Может кто-нибудь посоветует хороший учебник по Agile, в котором _последовательно_ изложены основные аспекты и понятия?

    • http://thetorch.ru/ Денис Петелин

      Привет.
      Ну вообще есть какбэ классичиские книги типа Agile from the trenches, XP Explained, Agile Project Management with Scrum.
      Если интересно посмотретьуслышать про цикл – заезжай к нам при случае, покажемрасскажем.