Проведение ретроспектив – это активность, которую каждая agile-команда проводит для того, чтобы решать свои проблемы. Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.
Зачем нужна ретроспектива?
Это не праздный вопрос, его часто задают начальники, когда им предлагают провести ретроспективу. Они спрашивают: «Зачем? Мы можем сами все решить». Почему же нельзя сделать так, чтобы какой-то начальник или эксперт пришел, посмотрел и сказал, что команде надо делать, а что в рабочем процессе стоит изменить?
Основных причин две. Во-первых, если мы приходим к команде с готовыми решениями, возникает феномен, который называется «not invented here». Даже если члены команды понимают, что это правильное решение и его нужно выполнять, у них нет чувства собственности по отношению к нему. Такие решения, не «выстраданные» самим коллективом, а «навязанные» или предложенные сверху, имеют меньше шансов на реализацию.
Во-вторых, сейчас разработка ПО – настолько сложная и запутанная вещь, что вряд ли найдется специалист, который сможет, не зная контекста, расписать, как на самом деле должны работать процессы в конкретной команде при решении определенной задачи. Чтобы это выяснить, надо что-то пробовать, проводить эксперименты, смотреть, к чему приводят те или иные решения. Только попробовав, можно понять, хороша или не очень та или иная практика в контексте данной команды.
Тем не менее, существуют такие вещи как good practice или best practice. Это практики, которые многие используют и которые многим помогают. Возьмем, например, code review: хорошая это практика или плохая? Одним командам она помогает. Другие пытаются ее использовать, и ничего хорошего из этого не выходит. Так происходит потому, что эта конкретная практика, не хороша и не плоха как таковая: ее можно оценить только в контексте конкретной команды и ситуации.
Хотя бы поэтому невозможно сказать заранее, даст она какое-то преимущество или нет. Сode review – это один пример. На самом деле этот эффект характерен для любой практики – никогда нельзя знать заранее, насколько она будет эффективна в той или иной ситуации.
Цели и результаты
В основе ретроспективы лежит концепция цикла Деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы – к ее окончанию получить план изменений. Но важно понимать, что это не план окончательных изменений в процессе – это план эксперимента на ближайший период. Мы что-то пробуем, а потом смотрим, что из этого вышло, и на основании этого принимаем решение.
Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan.
Ретроспектива, как и любая командная встреча, должна иметь какую-то цель. Цель ретроспективы – получить план процессного эксперимента. Однако многие команды этого не понимают. Например, на ретроспективе команды порой пытаются придумать какие-то глобальные решения своей проблемы, и упираются в то, что у них не получается этого сделать. Они застревают и в итоге вообще ничего не делают. Если команда с такой проблемой сталкивается, то надо ей объяснить, что двигаться надо маленькими шагами, пробуя разные вещи и проверяя, что из этого выходит.
Если команда просто считает, что ретроспектива – это встреча для того, чтобы обсудить свой рабочий процесс и как-то его улучшить, то, как правило, все сводится к тому, что люди приходят, о чем-то разговаривают, выливают свою боль, облегчают душу – в итоге это ни к чему это не приводит. Так происходит потому, что цель не достигнута, план не получен.
Задача ведущего – привести команду в процессе ретроспективы к конкретному плану. План – это одно из двух: либо действия, либо новая договоренность. Все, к чему ретроспектива сводится – это список из действий, которые надо совершить, и договоренностей, которых отныне нужно придерживаться.
Что такое действия? Это конкретные задачи с известными исполнителями. Причем если выполнить действие должен тот, кого нет сейчас в комнате, из присутствующих выбирается человек, который берет на себя ответственность объяснить отсутствующему, что и как нужно сделать, а также проконтролировать результат. В итоге за каждое действие отвечает кто-то из присутствующих на ретроспективе.
Какие бывают ретроспективы?
Вообще ретроспективы разумно подразделять на несколько типов:
- ретроспектива в самом общем смысле слова;
- ретроспектива по качеству;
- ретроспектива по проблемам;
- ретроспектива по какому-либо отдельно взятому вопросу.
Ретроспектива вообще нацелена в самом широком смысле на понимание того, что происходит в команде, какие у нее есть проблемы и что с этим можно сделать. Ее иногда называют психотерапевтической ретроспективой. Она, как правило, начинается с вопроса: «Какие вы видите проблемы?»
Ретроспектива по качеству обычно сводится к тому, что на ней обсуждаются либо недавно произошедшие инциденты, либо дефекты. Ретроспективу посвящают тому, что обсуждают эти дефекты и анализируют, почему они возникли, то есть строят диаграмму глубинных причин дефектов. Так или иначе, в этом случае работу ведут с конкретными проблемами с качеством.
Есть ретроспективы, на которых работа ведется с проблемами, возникающими у заказчика или у владельца продукта. Это третий тип ретроспективы. Четвертый тип – когда есть конкретная специфическая проблема, и ретроспектива посвящается ее решению.
В чем проблема?
Какие в процессе ретроспективы могут возникнуть дисфункции, и как с ними бороться? Вот одна из дисфункций: команда считает, что у нее нет проблем, ее рабочий процесс достаточно хорош, и не видит смысла в его улучшении. Как правило, это не так. Но команде этого просто так не объяснить.
Для того, чтобы сдвинуть коллектив с этой позиции, полезно пригласить на ретроспективу кого-то из стейкхолдеров – заказчика или пользователей, которые знают, что с командой не все в порядке (заказчики вообще очень редко полностью удовлетворены работой команды). Они могут быть удовлетворены до определенной степени, но, как правило, у них все равно есть какие-то мысли на тему того, «что команда могла бы сделать лучше». Если такой заказчик приходит на ретроспективу и рассказывает это команде, ей уже некуда отступать, она начинает обсуждать направления для дальнейшего роста.
Еще одна дисфункция – когда на ретроспективе говорит в основном кто-то один или 2-3 человека, а все остальные сидят и молчат. На самом деле этим людям есть, что сказать. Просто, если все внимание на себя забирает, к примеру, лидер команды, он начинает доминировать, а остальные просто слушают.
Почему это плохо? Если каждый будет открыто высказывать свои мысли, то вероятность найти лучшие решения намного возрастет. Когда мы участвуем в групповой дискуссии, мы друг друга подстегиваем. Это и помогает придумать лучшее решение.
Часто справиться с этой проблемой помогает ведущий (фасилитатор) ретроспективы, который будет следить за тем, чтобы каждый из присутствующих высказал свою точку зрения. Иногда для того, чтобы участники ретроспективы более свободно выражали свое мнение, полезно давать им возможность не высказывать свои соображения вслух, а записывать их на клейких листках (их обычно прикрепляют на стену или специальную доску, причем это могут сделать как сами участники, так и – для пущей «анонимности» – фасилитатор).
Формат ретроспективы: наши предложения
В литературе описываются различные форматы проведения ретроспективы – от простых до крайне специфических. В одном из материалов в нашем блоге мы предложили свой вариант: его отличительные особенности – простота и эффективность. В основном именно это и требуется от подобных мероприятий.
Вместо того, чтобы выставлять жесткий тайминг и последовательность действий, мы предлагаем просто расчертить доску на 4 основные области и заполнять ее по ходу обсуждения:
- Плюсы. Что шло хорошо в прошлой итерации?
- Минусы. Какие проблемы были в прошлой итерации?
- Идеи. Какие идеи появились по ходу ретроспективы?
- План. Какие улучшения мы запланируем на следующую итерацию?
Поскольку основная задача ретроспективы – создание плана, все действия и промежуточные этапы служат лишь средством для достижения поставленной цели. Сначала каждому участнику дается возможность высказаться о плюсах и минусах прошедшей итерации. Минусы и плюсы возникают не сами по себе – основой для них служит план, составленный на предыдущей ретроспективе, при этом команда сама решает, куда отнести тот или иной пункт плана: был ли он выполнен (успех) или нет (неудача).
Как правило, новые идеи рождаются в процессе обсуждения минусов прошлой итерации, однако ими не ограничиваются: такой формат ретроспективы не препятствует свободному обсуждению. При этом фасилитатор или скрам-мастер должен следить за тем, чтобы обсуждения не перерастали в поиск виноватых: для достижения цели важно не столько то, «кто виноват», сколько то, «что с этим делать дальше». Споры по поводу той или иной идеи на данном этапе тоже бесполезны: в план все равно попадут только те идеи, с которыми согласны все участники ретроспективы.
После обсуждения плюсов, минусов и идей команда переходит к составлению плана, куда попадают не просто результаты обсуждения, а (как уже было отмечено) конкретные действия («Выполнить…», «Обсудить…», «Сформировать…») или правила («Задачу Х выполнять с использованием подхода Y»). Не стоит при этом пытаться выработать пути решения всех возможных проблем команды – для эффективной работы на следующей итерации достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполним и только демотивирует команду.
Стоит еще раз отметить, что форматы проведения ретроспективы могут быть различными. Важно одно: ретроспективы – это не единичное мероприятие, они проводятся регулярно, и по результатам каждого такого собрания выполняется основная цель – создается план на ближайшую итерацию. Если отнестись к этой процедуре не «формально», понимать ее цели и задачи, заранее знать наиболее типичные проблемы, возникающие в ходе ретроспективы, можно создать благоприятные условия развития настоящей самоорганизующейся команды.
Автор: Tsybdenova
