cartmendum (cartmendum) wrote,
cartmendum
cartmendum

Непрерывная ретроспектива: первый шаг к Кайдзен

В этой заметке пойдет речь о том, как можно усовершенствовать процесс ретроспективы. Ретроспектива сама по себе является краеугольным камнем любой адаптивной методологии чего-либо. Ортодоксальный скрам предписывает в конце каждого спринта собираться всей командой и искать ответы на вопросы:
  1. Что в этом спринте было хорошо?
  2. Что в этом спринте было плохо?
  3. Что сделать в следующем спринте такого, что бы усилить хорошее и ослабить плохое?
В таком виде у ретроспективы есть ряд недостатков:
  1. Очень много хороших мыслей возникает уже после того, как ретроспектива окончилась и вся команда разбрелась по рабочим местам
  2. Не всегда команда вводит изменения, устраняющие корневую причину того «что в этом спринте было плохо» (Что было плохо — мы зафакапились, что сделаем в следующем спринте — приложим усилия, что бы не зафакапиться. Спасибо, Кэп!)
Анализируя эти недостатки мы начинаем приходить к так называемой непрерывной ретроспективе. Есть непрерывная интеграция, есть непрерывное тестирование, есть даже непрерывное ревью кода, а вот непрерывной ретроспективы нет. Теперь будет!

В нашем отделе процесс только пилотируется и устойчивым его назвать нельзя. Однако кое-какие результаты уже есть...

Непрерывная ретроспектива содержит две практики:
  • «Постоянный» поиск... (решает проблему «хорошей мысли опосля»)
  • ...корневой причины (решает проблему Кэпа)
Для поиска именно корневой причины, а не перечисления симптомов, используется метод Тойота «5-почему» и инструменты мышления теории ограничений. Постоянство поиска означает, что все это происходит на протяжении всего спринта.

Цикл выглядит таким образом:
  1. Как обычно, на ретроспективе при помощи ведущего и команды мы выписываем все неприятности, с которыми мы столкнулись за этот спринт (систематические неприятности проще анализировать)
  2. Каждая неприятность записывается на одну бумажку Post-It и прилепляется на здоровый лист флипчарта
  3. Здоровый лист флипчарта с наклеенными бумажками вешается во всем заметный угол командной комнаты
  4. На протяжении спринта каждый человек в команде может подойти  к флипчарту (с кружкой чая в перерыв, с рюкзаком на плече перед уходом и т. п.) и повтыкать на бумажки:
    • Есть ли между этими бумажками не отмеченная причинно-следственная связь? Если да, то отметить это стрелочкой и переклеить бумажки по необходимости.
    • Видна ли причина какой-либо бумажки? То есть, знаем ли мы ответ на вопрос «Почему утверждение, написанное на этой бумажке истинно»? Если да, то пишем ответ на вопрос «почему?» в виде логического утверждения на еще одной бумажке, клеим на флипчарт и отмечаем причинно-следственную связь.
    • Мы видим бумажку, в которую уже тыкают стрелками несколько других причин. Достаточно ли этих причин, для того, что бы утверждение на бумажке было истинным? Если нет, то лепим недостающую причину и рисуем стрелку.
  5. К концу спринта начинается ретроспектива и к ней мы уже приходим со списком корневых причин нежелательных явлений, выявленных в конце предыдущей ретроспективы
  6. Используя Дерево Будущей Реальности и План Преобразований (подробнее про эти логические построения см. книгу Детмера) составляем список конкретных действий для устранения корневых причи
  7. Вносим выявленные действия в бэклог (туда же, где живут прочие задачи команды, что бы у команды был единый список задач)
  8. Смотрим на результаты предыдущей ретроспективы (выполнили ли все задачи, пришедшие с прошлого раза в бэклог? Принесло ли это желаемый эффект? Нужно ли что-то откорректировать/поправить)
  9. Возвращаемся на шаг 1 (заготавливаем список нежелательных явлений на грядущий спринт)
Пример из практики (немного отфотошопленный)
Обычная ретроспектива
 - Что нам не понравилось?
 - Прям в день релиза прибежал продакт оунер, затребовал срочных изменений и мы зафакапили релиз
 - Что будем делать в следующем спринте?
 - Не в коем случае не соглашаться на какие-либо изменения в день релиза!

Звучит более, чем логоично. Особенно для разработчиков.

В ходе непрерывной ретроспективы за две недели почемуканья получилось что-то вроде
- Мы зафакапили релиз
- Почему?
- Прибежал продакт оунер и потребовал срочных изменений
- Почему?
- Он узнал, что новый релиз не принесет ценности заказчику
- Почему?
- Мы не знали о тонкости Q, когда разрабатывали функционал. Из-за этого интерфейс вообще не пригоден для работы с системой
- Почему мы не знали тонкости Q?
- О нем мы узнали только от продакт оунера, а он увидел результат только в день релиза
- Почему он увидел результат в день релиза?
- А промежуточные результаты мы ему и не показываем


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

Этот пример сильно отфотошоплен и упрощен. На самом деле ответов на первое «Почему?» было два: "прибежал продакт оунер" и "у нас нет легкого способа провести быстрое тестирование". Почемукая в этом направлении команда пришла к необходимости сделать набор легких и быстрых смоук-тестов и встроить их в процесс непрерывной интеграции. «Почему мы не знали про тонкость Q» тоже имеет несколько веток. Одной из них был «затрах во время планирования». Решили вылечить периодическими стори-маппингами перед стенд-апом.

В реальности от «Мы зафакапили релиз» выросло дерево (направленный граф) причинно-следственных связей и только один этот симптом сразу вскрыл не паханное поле для улучшений. При этом скрам в подопытной команде уже достаточно зрелый.

Итого:
  1. Мы используем Дерево Текущей Реальности, что бы обнаружить корневую причину
  2. Мы ищем эту причину в течении спринта (совмещая это дело с праздношатанием или с желанием переключится с лабания кода на что-нибудь другое)
 
И напоследок пруфпик:
Tags: retrospective, scrum
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 16 comments