Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, "обучающих" материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.

Кто присутствует

Ретроспектива это в первую очередь мероприятие, направленное внутрь команды. Его решения -- это решения для самой команды, и вырабатываться они должны внутри. Вполне допустимо на ретроспективу принести те самые две пиццы, использовать нецензурные выражения (но не друг на друга!), принести куклу большого начальника и/или заказчика. Важно, чтобы каждый член команды чувствовал, что он может высказать своё мнение, и это не то что не приведёт к какому-нибудь негативу, а ровно наоборот -- будет использовано для пользы команде.

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

Очень желательно на первых двух-трёх ретро присутствие профессионального скрам-мастера. Причём не сертифицированного, а именно профессионального, который не просто прошёл сертификацию и обучение, а применял свои навыки проведения ретроспектив на практике хотя бы год. При кажущейся простоте мероприятие очень просто сваливается в "не туда", и по его итогам даже не понятно, а почему и как это исправить.

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

Когда

Ретроспектива должна проводиться регулярно. Вообще всё в Scrum должно делаться регулярно. И планирование, и обзор, и ретро. "Сила" методологии именно в том, чтобы превратить непредсказуемый творческий процесс разработки в предсказуемый и планируемый.

Ретро должно проводиться после обзора спринта. Чтобы на ретро команда могла обсудить в том числе и то, как результаты команды были представлены (успешно или нет) заказчикам. Ретро должно проводиться до планирования следующего спринта. Во-первых потому, что планирование следующего спринта, это уже следующий спринт, а во-вторых, потому что в числе результатов могут быть какие-то задачи, которые команда поставит самой себе. И они должны будут войти в следующий спринт.

Что нужно для ретро?

Если ретро проводится в "реальном мире", потребуются стикеры/листочки (по 6-10 штук на человека), ручки и доска с маркером.

В "виртуальном" мире достаточно обойтись расшаренным экраном с двумя/тремя блокнотами, либо одним экраном Confluence / MS Word с тремя полями. Условно их пока можно назвать "плюсы", "минусы" и "действия".

Для целей геймификации можно использовать онлайн-инструменты типа fun retro / easy retro, но пока что ни один из этих инструментов не вписался в тот рецепт, который будет описан ниже.

Будучи хорошим начальником (или планируя им стать) -- принесите на ретро орешков, конфет, печенек (*закадровое узнаваемое дыхание*), запланируйте общий ланч с пиццей без отрыва от "производства".

Начало ретро

В начале всем участникам команды раздаётся задание. Нужно придумать и записать (пока что в тайне от других членов команды -- это важно):

(+) Не менее N таких вещей, которые им понравились в текущем спринте, и которые они не хотели бы терять в процессе предлагаемых в рамках ретро изменений.

(-) Не более N таких вещей, которые не нравятся, и хотелось бы поменять.

Не нужно пытаться "оптимизировать" процесс и просить членов команды записать эти пункты заранее в качестве домашнего задания. Всё равно им придётся на это тратить время, верно? Пусть лучше потратят его все сразу в одном месте, не мучаясь угрызениями совести за несделанную домашнюю работу и без смущающих взглядов коллег, которые были такими замечательными, что сделали заранее (читай -- за 5 минут до встречи, отвлекаясь от какой-нибудь скучной еженедельной встречи).

Сначала про "плюсы". Этот пункт важен, хотя бы для закрепления того, что команда сделала хорошо. Похвалить самих себя -- тоже важно. Наверное это подтвердит любой психолог. Граница снизу здесь нужна, чтобы каждый член команды заставил себя, во-первых, вспомнить прошедший спринт, а, во-вторых, включился таким образом в ретроспективу. "Не хотим терять" -- это важная подсказка. Например она сразу отекает такие вещи, которые не зависят от команды. Нет смысла обсуждать возможность удалённой работы, если не команда решает этот вопрос. Или есть смысл упомянуть, как нравится текущий CI и быстрое прохождение ревью, ведь именно от команды (обычно) он и зависит.

Другое важное назначение "+"-пунктов, это возможность позже, когда будут предлагаться действия по решению проблем (action point'ы), выбирать те из них, которые минимальным образом будут влиять на то, что команда не хочет потерять.

Важно, чтобы плюсы и минусы записывались на листочках независимо друг от друга. Тем самым мы избавляемся от "проблемы +1", когда люди вместо раздумывания над проблемой просто присоединяются к чужому ответу (аналогичная ситуация происходит, например, при планировании, от чёго защищает "слепое" покер-планирование).

Минусы. В идеале нужно, чтобы участники сразу записали что им не нравится. Не action point, не то, что они предлагают сделать, а то, что им непосредственно мешает в работе. Но в принципе на первые 4-6 ретроспектив достаточно, чтобы участники хоть что-нибудь записали. А далее ведущий уже вытянет из них всю правду (*дьявольский смех за кадром*).

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

Анализ

Начинаем с плюсов. Тут можно просто выписать их в первую колонку (наклеить стикеры), при возможности сгруппировав их для удобства наблюдения и красивого представления вышестоящему начальству. Просто пока помните, что эти плюсы -- это что ваша команда хочет сохранить хотя бы на следующий спринт и не потерять при выполнении action point'ов.

Минусы. Самый сложный этап. Игра в доктора "наоборот".

Берём каждый стикер (присланный нам в персональные предложения пункт) и... не записываем его. А проверяем, что данный пункт описывает симптом, а не болезнь. Почему? Потому что потом мы должны будем предложить такое решение, которое будет наиболее эффективным способом избавиться от симптома. И "лечение" самой болезни может быть одним из, но не самым эффективным (с точки зрения усилий и времени) способом. Кроме того, данный симптом может быть вызван несколькими причинами, и возможно только одну из них нужно будет убрать, и это вовсе не та, которую изначально назвал член команды.

Ещё раз. Каждый пункт надо записать в виде симптома, а не болезни (и точно не в виде action point'а). Например. Член команды записывает на стикере "у нас неоптимальный CI-скрипт". Если оставить как есть, единственным возможными способом решения данной проблемы будет, очевидно, переписать CI-скрипт. Но нужно ли?

Уточняем у члена команды, "[Олег], на что в твоей работе влияет то, что CI-скрипт не оптимален"? Внезапно оказывается, что:

• скрипт медленно работает

  • медленная работа приводит к медленному прохождению pull request'ов

    • невозможность распарраллелить работу приводит к простою

      • это приводит к медленной работе члена команды

• скрипт работает недетерминированно, иногда проваливаясь из-за фазы луны и положения Сатурна в созвездии козерога

  • это приводит к необходимости ручного перезапуска CI

    • это приводит к медленной работе члена команды

На каком шаге остановиться -- сказать сложно. Но в любом случае каждый следующий шаг описывает более общую проблему. В целом все пункты так или иначе сводятся к одному конкретному -- "замедление работы команды". Поэтому тут важно остановиться где-то за 1-2 пункта до этого.

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

• поставить больше CI-агентов для сборки и распараллелить его работу / сборку / разрешить параллельную работу нескольких сборок одновременно

• поставить посильнее машину для CI

• выкинуть часть действий из CI-скрипта, не переписывая его кардинально

• полностью переписать CI-скрипт

• научить пользователя переключаться между ветками в git, позволив ему распараллелить работу и не ждать CI

• сделать простой скрипт для перезапуска failed-сценариев 2-3 раза

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

Кроме того, более обще записанная формулировка имеет больше шансов пересечься с "минусом" от другого участника. А это хорошо -- значит у нас не 30 разных проблем, а, скажем, 7-10 (сгруппированных). К этому и надо стремиться.

Очень важно при попытке вытащить из члена команды более общую проблему не задавить его авторитетом и не подложить свою проблему вместо его. Все мы люди, все мы субъективны, и можем увидеть в чужой проблеме вовсе не то, что беспокоит члена команды, а что беспокоит нас самих. Уметь оставлять свои проблемы в стороне и слушать (и слышать) другого человека, наверное, самое важное для того, кто собирается в IT работать с людьми. Но это очень и очень сложно. Ничего страшного, если Вас по началу будут поправлять и говорить, "нет, это вовсе не то, что меня беспокоит, меня беспокоит другое". Замечательно, если Вам будут это говорить. Гораздо хуже, если с Вами молча согласятся, чтобы не спорить и побыстрее закончить.

Голосование

Изначально считаем, что за каждый пункт подано столько голосов, сколько изначальных "минусов" было сгруппировано в него. Далее я предлагаю членам команды проголосовать дополнительно за 1 или 2 пункта (из сгруппированных 7-10), Но только за те, в которых нет пунктов, которые они формулировали сами (или в которые были переформулированы их "минусы").

В результате формируется отсортированный "по голосам" список проблем.

Блиц-этап

На данном этапе включаем секундомер и предлагаем по 60 секунд на решение каждой проблемы, кроме Top3 (в любом порядке). В рамках этих 60 секунд можно предложить "быстрое" решение проблемы. Не важно, насколько сильно оно решает проблему, главное, чтобы хоть как-то решало. Если никто из членов команды не против предложенного решения, оно записывается в action point'ы. Если против -- решение сразу же откидывается без обсуждения (время на обсуждение не тратится).

60 секунд это скорее ориентир. На то, что не нужно тратить много времени на блиц-проблемы, которые не являются самыми больными местами в процессе.

Перерыв на кофе

Перед перерывом на кофе окончательно формулируем top3 проблем, которые нужно обсудить, и предлагаем членам команды пойти покурить/попить/выпить/отойти проверить почту.

Обсуждение. Action Points

Итак, у нас есть top3 проблем. Самые больные, самые серьёзные, самые мешающие команде. На каждую проблему хоть час обсуждения (поэтому ретро и занимает от 3-х часов). Как придумать возможные решения -- не знаю. Однако, знаю, что делать с возможными решениями.

Во-первых, не надо отбрасывать решения, которые не решают проблему целиком. Нас вполне устроят решения, которые решают проблему хотя бы частично. Хоть на 20%, но облегчают жизнь команды. Кто знает, может именно этих 20% хватит, чтобы в следующий раз проблему не включили в top3?

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

В-третьих, формулировка. Формулировка должна быть такой, чтобы у команды был минимальный шанс не выполнить пункт.

Полученные шаги записываются в action point'ы.

Почему ретро может не помочь

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

Признаками проблем являются:

• Ретроспектива проводится за полчаса. Это не ретроспектива, это отчёт-доклад команды "как у нас всё хорошо, как здорово и дружно мы живём, дорогой дедушка Ленин". Явный признак того, что мероприятие проводится для галочки, без той пользы, которую могло бы принести полноценное ретро.

• Повторяющиеся в две-три ретроспективы похожие описания проблем. Команда предполагает, что теоретически эти проблемы можно было бы попытаться решить какими-то действиями внутри команды. Может быть даже предлагает action point'ы.Но в какой-то момент эти проблемы просто исчезают из анализа, потому что команда уже привыкла к тому, что высказывать их бесполезно. Но сами проблемы-то никуда не делись!

• Если таких проблем много, то в какой-то момент появляются фразы "слишком много времени тратится на ретроспективы". Это прямо-таки прямой сигнал о том, что с ретроспективой всё плохо. И да, без изменения формата ретро далее проводить бессмысленно.

• Невыполненные action point'ы (при том, что проблема не ушла). Возможно они были очень неудачно сформулированы. А возможно тот, кто должен был их выполнить, забыл/забил/не захотел их делать.

Самой большой проблемой является понять, что у нас вас проблемы. Вы можете спокойно смотреть на красивые отчёты о ретроспективах в confluence, показывать начальству, а члены команды почему-то не хотят на них ходить. Моя рекомендация -- приглашайте на ретро раз в полгода кого-то со стороны. Не начальника, а методолога, коллегу из параллельной (или далёкой) команды. Возможно пригласить даже его сразу как фасилитатора -- попробуйте формат ретроспективы от другой команды. Пусть её проведёт тот, кто не привык к вашему формату.