Ретроспектива: как и зачем ее проводить

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

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

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

Для их устранения, можно использовать разные способы поиска решения. Иногда плохие моменты, это только “симптомы”, а не сама “болезнь”, и чтобы докопаться до сути, можно использовать технику 5 вопросов. Эта стандартная ретроспективная практика - задать пять вопросов, где ответив на пятый мы точно найдем решение, хотя может понадобиться всего лишь два.

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

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

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

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

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

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

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

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