Ретроспектива – это регулярные собрания команды для обзора событий и полученного опыта за прошедший рабочий период (спринт) для увеличения эффективности работы через корректировку процессов и поведения.
Часто один из самых главных эвентов управления командой и увеличения эффективности разработки игнорируется или сводится к формальности. Например, это происходит от оставшихся в команде устаревших типов мышления “Я - начальник, ты - дурак” или “Ненавижу встречи, дайте мне просто кодить”.
Старайтесь избавляться от такого мышления. PO является частью команды и не должен продавливать своё мнение за счет авторитета. Хороший выход это иметь на роли фасилитатора собрания человека, который не является по должности начальником команды.
Мы все люди, мы все совершаем ошибки. Мы собираемся тут, не для того, чтобы искать виноватых. А чтобы понять причины проблем, и понять, что мы можем сделать в будущем, чтобы они не повторялись.
Для еще не сработавшейся команды можно добавить во Вступление собрания прочтение основного принципа ретроспективы:
“Независимо от того, что мы обнаружим, мы понимаем и искренне верим, что каждый сделал все возможное, учитывая то, что он знал в то время, свои навыки и способности, доступные ресурсы и сложившуюся ситуацию.”
У вас уже должен быть какой то внутренний документ команды типа Устава, где вы записываете софт, процессы. Добавьте в него правила коммуникации между членами команды, правила разрешения конфликтов, расписание собраний и их предельную продолжительность.
Для раскачки команды и склонения собрания в позитивный настрой можно спрашивать по кругу 3 вопроса, сначала круг одного вопроса, потом круг следующего:
Чем из того, что вы сделали за эти 2 недели, вы гордитесь?
Что из того, что вы сделали, помогло другим?
Теперь, когда вы знаете гораздо больше, что бы вы сделали по-другому?
Проверка гипотез
На Ревью вы уже рассмотрели достигли ли вы целей, продемонстрировали выполненные задачи, рассказали с какими трудностями столкнулись и как их преодолели.
Теперь вы должны рассмотреть повлияли ли изменения в процессы с прошлой ретроспективы на результат. Если команда не видит результатов изменения, то они в принципе теряют интерес к изменению процессов и к ретроспективе, как к пустой трате времени. Так и рождаются “Ненавижу встречи, дайте мне просто кодить”.
Первым делом узнайте были ли внедрены ответственными людьми новые изменения. Если вы подготавливали измеряемые гипотезы, то проверьте достигли ли они нужного результата. Остальные гипотезы проверьте опросом команды считают ли они, что эксперименты привнесли достаточные позитивные изменения.
Краткое обращение к событиям выделившимся за спринт:
Задайте по 3 вопроса каждому участнику:
Что больше всего понравилось за этот спринт?
Что больше всего не понравилось за этот спринт?
Кого хотели бы отблагодарить из команды и за что (обязательно). Отметьте того, кого больше всех благодарят, его можно наградить какой нибудь незначительной мелочью.
Определение важных тем и выявление первопричин:
Любой член команды может предложить 1 тему для обсуждения, которую он считает самой важной за спринт. Все темы обсуждаются по очереди.
Требуется найти первопричину каждой темы, методично углубляясь к сути с помощью последовательных вопросов “Почему” это происходит.
Предложения по улучшению эффективности работы команды:
Дайте каждому члену команды сгенерировать по 3 идеи, которые могут улучшить эффективность работы команды, основываясь на озвученных проблемах и позитивных событиях. Проголосуйте, какие из них хотите взять на внедрение. Старайтесь искоренять повторение проблем, старайтесь увеличивать вероятность воспроизведения позитивных событий.
Предложите измеряемые эксперименты по этим идеям. Измеряемость экспериментов нужна, чтобы понять, когда эксперимент оказался неудачным, и что следует перейти к следующему. Не стоит забывать, что изначальная причина для проведения этого эксперимента всё еще не отработана должным образов.
Пример отслеживаемого эксперимента:
Если мы введем это изменение, то количество известных ошибок в софте сократится до десяти и менее.
Не стоит вводить больше 3х изменений за раз - их сложно внедрять и сложно отслеживать. Команде должно хватать времени на их прямые обязанности. Так же сложнее понять, какой из экспериментов дал результаты, а какой нет.
Укажите кто будет ответственен за внедрение экспериментов.
Остальные идеи сохраните в список на будущее.
В Завершении собрания можно провести ROTI (Return on Time Invested) опрос о прошедшем мероприятии.
Все участники оценивают прошедшее собрание по 5 бальной шкале: насколько полезным вы считаете для вас было прошедшее собрание? Возможно вам придется добавить тему на обсуждение про саму ретроспективу, и почему команда считает её мало полезной.
Задокументируйте результаты и решения.
Хорошая оценка потраченного времени на собрание по 1-2х недельному периоду средней команды ~7 человек - около 1 часа.
Такой мини фреймворк, разбитый на фазы, предоставит вам хорошее основание, которое поможет вам эффективно планировать и проводить ретроспективы. Помните, однако, что каждая ретроспектива уникальна.
