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

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

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

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

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

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

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

Качество

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

Тестировщики могут проанализировать эффективность тестирования и предложить варианты автоматизации тестирования или обосновать необходимость выделения изолированного окружения для тестирования.

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

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

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

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

Проведение

Подготовка

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

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

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

Ход митинга

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

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

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

Позитив

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

Ошибки

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

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

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

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

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

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

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

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

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

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

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

А дальше что?

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

Итого

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

А вы проводите ретроспективы? :)

Обсуждение

Picture_130?1356409798

А мы отказались от ретроспектив. И от ревью тоже. Иногда, очень редко и очень недолго проводятся, но только в случае серьёзных проблем.

Picture_432?1356409809
-1

А как вы улучшаете процесс разработки?

Picture_130?1356409798

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

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

Picture_432?1356409809

Процесс надо улучшать не только, когда есть очевидные проблемы, но и когда их нет.

Например, что мы можем сделать, чтобы функциональные тесты ранались не 2 часа, а 20 минут?

Можно ли сократить время тестирования билда?

Ну и тп

Picture_130?1356409798

А нам не нужно ускорять работу тестов. У нас всё деплоится без запуска тестов. Тесты, конечно, есть, но работают в фоне. Если мы будем заморачиваться на тестах, мы никогда не выложим свежий код.

У нас более 1000 реплик БД, несколько сотен серверов фронт-энда, внутренние приложения и миллионы посетителей ежедневно. У нас другие метрики успешности процессов.

Missing-male

Своими постами из Амстердама вы сбиваете с толку белорусских аутсорсеров :)

Picture_432?1356409809

Колитесь, что у вас за проект ;)

Picture_130?1356409798

Я ж уже где-то говорил, что сайтик у нас, http://www.booking.com/ называется.

Missing-male

Гы:) так епам тожеж самое делает :)

Picture_130?1356409798
-1

Не смеши меня. :-P

Missing-male
-2

ой да ладно.

ухать за бугор может ЛЮБОЙ маломальский девелопер со знаением языка.

не нужно себя причислять в мегокасту избранных.

на сим флейм заканчиваю.

Picture_130?1356409798

Ну так учи язык и завидуй молча. :-P

Missing-male
-1

ТЫ думаешь я его не знаю? :)

Picture_130?1356409798
-1

По крайней мере с русским у тебя точно есть проблемы. ;)

Missing-male

маладец, дунул в муку :)

галанцы это умеют.

Picture_432?1356409809

Гы. Ниче так. Понятно. Вам реально надо столько серверов? На клауд не собираетесь переходить?

Picture_130?1356409798
-1

> Вам реально надо столько серверов?

Ну, лишних, вроде нету. :)

> На клауд не собираетесь переходить?

Нет.

Missing-male
ret
– Lead JavaScript Developer в Targetprocess

клевый сайт, жаль только что в Минске ничего найти не получается :(

Picture_130?1356409798

Белорусские отели настолько круты, что им не нужны дополнитеотные каналы сбыта! :)

425430dd6319f7df5899a4626125ae5c?1427577634

Проводим.

Missing-male
+1

Польза есть от этого ?

425430dd6319f7df5899a4626125ae5c?1427577634

Сложно сказать, но я думаю, что да!

Picture_186?1356409800
-1

Если сложно сказать, то это очень смахивает на Cargo Cult (http://ru.wikipedia.org/wiki/Культ_карго)

425430dd6319f7df5899a4626125ae5c?1427577634
-1

ой, какие все умные

Missing-male

интересно, может в России то же попробовать


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси