Ретро: что происходит на этой встрече и что там делать тестировщику

Когда я только начинала работать в командах, которые практикуют Scrum, ретроспектива была для меня самым непонятным митингом спринта. Планирование — понятно, груминг — понятно, дейли — понятно. Но ретро? Я сидела, слушала, кивала и не очень понимала, зачем это всё и что от меня ожидают.

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

Что такое ретроспектива и зачем она нужна

Ретроспектива — это регулярная командная встреча, которая проходит в конце каждого спринта. Её цель простая: остановиться, оглянуться назад и честно ответить на три вопроса.

Что шло хорошо? Что шло плохо? Что мы хотим изменить в следующем спринте?

Звучит просто, но на практике это мощный инструмент улучшения процессов. Именно на ретро команда договаривается, как работать лучше — не в теории, а конкретно, с действиями и ответственными.

Ретро — это не жалобная книга и не разбор полётов с претензиями. Это конструктивный разговор команды о себе.

Кто проводит и как это устроено

Обычно ретроспективу фасилитирует Scrum Master. Именно он отвечает за то, чтобы встреча прошла по структуре, все высказались и разговор не превратился в хаос или монолог самого громкого человека в комнате.

Если Scrum Master в команде нет — эту роль берёт на себя тимлид или кто-то из команды по договорённости.

Формат может меняться от спринта к спринту. Самый распространённый — доска с тремя колонками: «Хорошо», «Плохо», «Улучшить». Каждый молча пишет стикеры, потом их обсуждают вместе. Но бывают и другие форматы: Start/Stop/Continue, 4Ls, Mad/Sad/Glad. Суть одна — собрать честную обратную связь от всей команды.

Длится ретро обычно от 45 минут до полутора часов, в зависимости от размера команды и интенсивности спринта.

Что происходит на самой встрече

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

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

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

В конце команда выбирает 1–3 конкретных улучшения, которые будут сделаны в следующем спринте. Не десять, не список на год вперёд — именно 1–3. Потому что если всё важно, то ничего не важно.

Что происходит после

По итогам ретро появляются Action Items — конкретные задачи с ответственным и сроком. Например: «Добавить в Definition of Done проверку на мобильных устройствах. Ответственный — Иван. Срок — до следующего планирования».

На следующем ретро первым делом смотрят: а что стало с прошлыми Action Items? Выполнены? Нет? Почему? Это не контроль ради контроля — это проверка, что команда действительно меняется, а не просто красиво говорит об этом раз в две недели.

Если Action Items из раза в раз не выполняются — это сигнал. Либо команда берёт на себя слишком много, либо задачи слишком расплывчатые, либо нет реального желания что-то менять. Это тоже тема для следующего ретро.

Что сказать тестировщику на ретро

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

Это не так.

Тестировщик видит продукт иначе, чем все остальные. Именно QA замечает, где требования были неполными и пришлось угадывать. Где тест-кейсы устарели и их никто не обновлял. Где в середине спринта требования изменились и это никто не коммуницировал команде. Где код пришёл на тестирование за день до конца спринта.

Всё это — темы для ретро. И именно об этом стоит говорить.

Не «у нас было много багов» — это ни о чём. А «в этом спринте требования к модулю оплаты пришли на третий день спринта, из-за этого я не успела написать тест-кейсы до начала разработки и мы нашли критический баг только в конце». Конкретно, с причиной и последствием.

Ретро — это одно из немногих мест, где голос QA имеет такой же вес, как голос разработчика или менеджера. Используй это.

Почему ретро часто не работает — и что с этим делать

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

Причин обычно несколько.

Люди не чувствуют психологической безопасности — боятся сказать что-то, что воспримут как жалобу или критику в чью-то сторону. Команда не видит связи между ретро и реальными изменениями — зачем говорить, если всё равно ничего не меняется? Или встреча слишком длинная и все к концу уже просто хотят закончить.

Если ретро не работает в твоей команде — это само по себе тема для ретро. Можно прямо сказать: «Мне кажется, наши ретро не приносят результата. Давайте обсудим, что можно изменить в самом формате».

Это смелость. Но именно такие разговоры и делают команды лучше.