Движение по шоссе. Ретроспектива. Сбор данных и генерация идей

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

1. В начале встречи можно спросить команду про то, как они думают, какие есть аналогии между разработкой ПО и движением по шоссе у них есть:

— Какие аналогии между разработкой и потоком авто есть у вас?

Участники не обязательно должны отвечать на этот вопрос, задача этого вопроса — погрузить в контекст.

2. Далее мы сами отвечаем на этот вопрос, предложив команде свои аналогии. Показываем то, как может выглядеть часть рисунка и делимся выводами, которые можно сделать на основании нарисованных ситуаций:

    

• Количество полос дороги = WiP
• Больше запросов  (затор) — ниже время доставки ценности
• Чтобы увеличить пропускную способность (расширить дорогу), нужно время на внедрение например инженерных практик
• На этот момент пропускная способность может временно снизиться
• Мы можем сделать выделенную полосу, придумать способы оптимизации работы, чтобы лучше доносить самое ценное

3. Далее предлагаем участникам (в зависимости от количества человек) индивидуально, в парах или тройках нарисовать движение по дороге как они видят текущий процесс разработки: 10 мин. При необходимости скрам-мастер может дать подсказки:

— Подумайте какая это дорога, сколько на ней полос, она одинаковая или разная по ширине, есть ли какие-то ответвления, перекрестки, полосы разгона и т д, кто еще кроме нас есть на дороге. как мы с ними взаимодействуем, на чем мы едем, что нам мешает, что помогает и т д

4. После этого участники по очереди показывают и рассказывают свои варианты группе. Вы и группа можете задавать уточняющие вопросы:

— Что здесь имеется в виду?

— Что поможет преодолеть этот участок дороги быстрее?

— Что еще может нам помочь?

— Есть еще какие-то идеи?

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

5. На следующем этапе мы голосуем за принятые решения или (если их немного и они все важны для команды) принимаем их все и составляем план действий.

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