Ретроспективы или разбор полетов

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

О чем говорить?

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

Управление проектом

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

Качество

Про качество проекта обычно можно говорить очень и очень долго :) Прежде всего, стоит оценить общее изменение качества на проекте с момента прошлой фазы. Если оно ухудшилось - понять причины и наметить курс на их устранение. Если улучшилось - понять, что было для этого сделано и как поддерживать такой темп в будущем. Тестировщики могут проанализировать эффективность тестирования и предложить варианты автоматизации тестирования или обосновать необходимость выделения изолированного окружения для тестирования.

Коммуникации

Здесь стоит рассмотреть, легко ли общались между собой все члены команды, причем особое внимание стоит уделить коммуникациям между разными отделами, в т.ч. тестировщиками и разработчиками. Стоит проверить доступность человека с важными знаниями для объяснения и knowledge transfer. Важно не допускать "отфутболивания" тестировщиков, когда несколько разработчиков не берут на себя ответственность за баг, а отсылают тестировщика друг к другу.

Технические аспекты

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

Проведение

Подготовка

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

Наметьте цели

Настройте людей на рабочий лад, задайте цели митинга, напомните фазу, которую будете анализировать: что в ней делали, что не успели сделать, что важного в ней случилось.

Ход митинга

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

Протоколирование

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

Позитив

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

Ошибки

Говорят только несколько человек

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

Поиск виноватого

Что бы ни было, не ищите виновного - пользы это не принесет, а человеку будет неприятно. Любая проблема - проблема команды, и решать ее надо вместе.

Растекание мыслию по древу

Не расплывайтесь при описании проблемы, зрите в корень и говорите, что пошло не так. Если сотрудник не в состоянии сам определить проблему, но четко видит симптомы, ему должны помочь остальные члены команды. Внесите исследование этого случая в беклог и назначьте ответственного.

Принятые решения не выполняются

Спрашивается: зачем собирались? Цель ретроспективы - повысить эффективность команды путем выполнения определенных действий. Действия не выполняются - эффективность не повышается.

Все принятые решения назначаются на следующую итерацию

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

А дальше что?

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

Итого

Ретроспективы - мощный инструмент менеджера для повышения эффективность работы команды. Как и любой инструмент, при неправильном применении он может принести больше вреда, чем пользы, соответственно, надо следить за собой и не пользоваться им во зло. А вы проводите ретроспективы? :)

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.