Почему я об этом пишу?
Потому что за 7 лет работы в отрасли я убедился в эффективности этой практики и честно считаю, что данная практика должна использоваться шире.
Потому что каждый год я провожу порядка 10 ретроспектив и накопился кое-какой опыт.
Здесь не будет теории на тему ретроспективы, здесь будут мои мысли и опыт на тему ретроспектив. Хотите теории - смотрите выступление Бориса Вольфсона и презентацию.
Это первая часть, здесь я расскажу про общие моменты - те моменты про которые лучше знать до того как вы начнете этим заниматься.
0. Все идет от тебя.
Очень редко звезды становятся в такое положение, что все участники ретроспективы настроены именно на ретроспективу и будут конструктивно обсуждать проблемы, искать пути их решения. Бывает, но редко. Поэтому ретроспективе нужен ведущий или фасилитатор.
Это вы - менеджер, лидер, или просто человек заинтересованный в том чтобы что-то стало лучше. Без вас и вашей готовности - не будет ничего.
1. К ретроспективам нужно относится как к капитальной инвестиции.
Ретроспектива помогает вам и вашей команде учится у самих себя.
На это нельзя забивать, это нельзя переносить и тем более пропускать.
И ваша задача как руководителя, тимлидера или просто человека заинтересованного в том чтобы процесс ретроспектив был обязательным, эффективным и регулярным.
Этот процесс не построит сам себя, его никто не построит у вас под заказ.
Это можете сделать только вы. И вы же должны будете его поддерживать.
Это произойдет не быстро, с муками и проблемами, но другого пути я пока не видел.
2. Про регулярность.
Рекомендую как минимум для начала пользоваться простым правилом:
конец итерации = ретроспектива.Даже если интерации недельного размера? Да, даже если так. Хотя бы первое время. Команда сама должна рассказать вам на ретроспективе почему ее нужно делать реже.
Я не рекомендую делать ретроспективы реже чем раз в 2 месяца - в условиях интенсивной разработки это огромный срок времени, за который проект может перейти уже в предтерминальную стадию и пользы вы уже не извлечете.
Второй момент - некоторые вещи за 2 месяца могут вполне себе забыться, зато всплыть потом, еще через полгода и лечить вы их будете уже с большими усилиями.
Каким бы коротким не был ваш проект, если вы хотите проводить в нем ретроспективы вы должны еще и заложить время на реализацию решений принятых на ретроспективе.
Ретроспектива, которая делается в конце проекта называется Post Mortem и помогает как вскрытие грудной клетке при насморке.
3. Ретроспективы, скоупы, бэклоги и как оно друг с другом связано.
Результатом каждой ретроспективы для команды является список задач по улучшению их собственного процесса разработки. Список задач составляется с использованием мантры Кто-Что-Когда, но вот про Когда - есть один нюанс.
Сроки могут быть не очень жесткими. По умолчанию - точно должно быть сделано до следующей ретроспективы и проверено что улучшение работает как и ожидалось. Или не как ожидалось и надо думать что делать.
Если вы практикуете любое из течений Agile, то список задач по улучшению становится частью вашего бэклога на следующую итерацию. Обязательно становится. Тут никаких отмазок быть не может. Ввиду этого в вашем маленьком уютненьком agile мирке все должно быть устроено так : итерация - демо - ретроспектива - планирование - и никак иначе. Ретроспективы до демо быть не может - все надеюсь понимают почему.
Планирования до ретроспективы быть не может - потому что вы еще не подумали как вы на следующей итерации будете делать свою работу лучше.
Тут можно попробовать возразить, сказав что заказчик или его product owner порежет любые таски которые не входят в скоуп разработки. И, да - порежет если вы ему такую возможность дадите. То как вы выпускаете ему софт - это зона вашей компетенции. То как вы планируете объем задач на итерацию - это тоже зона вашей компетенции. Если не вы его планируете, а заказчик/менеджер/владелец продукта - то у вас уже есть серьезная проблема, которая заключается в доверии между вами и заказчиком.
Я не призываю вас делать улучшения партизанскими методами, хотя и про такие случаи я слышал, я призываю вас договариваться. И договоренность эта очень проста: "каждую итерацию мы тратим 1/5/10/20% времени на улучшение процесса".
Все улучшения выполненные в рамках ретроспективы, особенно если они носят не совсем очевидный характер должны быть показаны и измеряны на следующей ретроспективе.
Для заказчика это кстати тоже полезно, сами наверное понимаете почему.
Раз в несколько ретроспектив (или раз в полгода) нужно показывать людям дайджест того что было улучшено за эти несколько ретроспектив.
Поверьте мне - это очень полезная, и самое главное вдохновляющая, практика. Когда люди видят сколько они сделали и как это сказалось на их повседневной жизни - это ободряет и позволяет вам легче проводить ретроспективу.
4. Бытовые правила проведения ретроспективы.
Хорошо проведенная ретроспектива - это по нагрузке как целый рабочий день.
Поэтому лично я рекомендую ставить ретроспективу на вторую половину дня и не планировать активностей после нее. Это связано с тем что у мозга человека тоже есть инерция, и если вы очень хорошо штурмовали проблему на ретроспективе, а после нее у вас какая-то сторонняя встреча, то это не значит что ваш мозг перестал думать в этом направлении.
Далее вспоминаем отличную старую пословицу "Хорошая мысля приходит апосля" - по той же самой инерции участники ретроспективы могут вам выдать готовое решение или интересную мысль не сразу, а на следующее утро. Поэтому и результаты ретроспективы со списком задач лучше рассылать на следующий день.
По той же инерции мышления ретроспектива не бывает менее чем на 1,5-2 часа - люди приходят на нее с какими-то своими мыслями в головах и им нужно их аккуратно сложить, включить "режим ретроспективы", вспомнить и подумать.
Моя рекомендация - планировать не меньше двух часов - больше можно.
Вполне себе допустимо что после того как вы провели ретроспективу в офисе вы полным составом отправитесь пить чай-кофе/пиво/ужинать все вместе и там она продолжиться в более неформальной обстановке. Это нормально и даже хорошо, главное не забыть с собой ручку и бумагу :).
Ретроспективу лучше проводить не в том помещении в котором вы постоянно находитесь, и уж точно не сидя за компьютером.
Лучше переместиться в другое помещение - переговорку, комнату - это выводит людей из зоны комфорта зато позволяет вам быстрее перевести их в нужный режим работы.
Никаких ноутбуков, планшетов, телефонов.
Телефоны на время ретроспективы на беззвучный режим и в дальний угол комнаты - потеря внимания для любого участника ретроспективы - это продолбанная ретроспектива.
Эти бытовые правила касаются команд стандартных размеров, то есть до 7 человек.
Если вам нужно провести ретроспективу на 7 и более человек, то сложность подобного рода задачи растет нелинейно.
Само собой - все участники ретроспективы должны находиться в одном месте физически. Если у вас распределенная команда, то это сильно усложняет, хотя я слышал и об удачных кейсах.
