Зачем на самом деле в IT-компаниях проводят «собрание-ретроспективу»

Зачем нужны ретроспективные митинги в СКРАМе?

В Agile в целом и в SCRUM в частности есть немало дурацких ритуалов и традиций, вроде «стоячих собраний» (aka stand-up meeting) или «вычесывания волос» (он же grooming). Однако сегодня поговорим про другую характерную хомячковую активность — так называемое «ретроспективное собрание».

Такое собрание, как правило, проводится в конце спринта (англ. Sprint — забег, двухнедельная итерация в разработке ПО), либо между концом одного спринта и началом следующего. Как можно догадаться из названия, цель сего действа — посмотреть назад, оглянуться в прошлое и поностальгировать, так сказать.

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

Скрам-мастер (или его и.о.) задает два вопроса всем членам команды:
1. Что было сделано хорошо в прошедшем спринте?
2. Что надо улучшить в следующем?
И далее на основании ответов команда предлагает решения по улучшению процесса разработки софтины.

По официальным практикам на таких собраниях фиксируют в том числе и удачные ситуации/решения, возникшие в ходе работы. И всё собрание якобы такое позитивистско-конструктивное, когда по корпоративному новоязу «беда» превращается в «сложную, но интересную задачу», а провал в «опыт, на котором мы научились». Но по факту если всё хорошо, то об этом никто не говорит. Зачем тратить время на очевидное? Похвалить команду и так можно за пару секунд: «Молодцы, хлопцы! Хорошо справились!». К сожалению, такого рода пряник малоэффективен. По крайней мере в головах «эффективных менеджеров». Тогда они назначают «ретроспективу».

Поскольку на этих собраниях обсуждение позитивных моментов выглядит натужно и нелепо а-ля «Молодец, Иннокентий, что смог залить код на сервер и мы успели!» (хотя Иннокентий всего лишь выполнял свою работу), ретроспетива, предназначенная как для пряника, так и для кнута, превращается в один большой сеанс массового истязания кнутом.

Если во время двухнедельного спринта у команды случились какие-то проблемы, то в лучшем случае им удастся спихнуть всё на какие-нибудь внешние факторы, будь то поздно подоспевшая документация или внезапно измененные заказчиком требования (привет, SCRUM!). В худшем случае — продакт-оунер будет дрючить программистов, тестировщиков и дизайнеров. Но не сам, а их же языками.

Например:

Как ты считаешь, Ипполит, что бы ты мог сделать лучше в следующем спринте?

От этого вопроса нельзя отвертеться. Может быть по факту ничего лучше сделать было и нельзя, так как Ипполит реально зависел от внешних факторов — например от американского офиса, который не дописал в срок важный кусок кода. Но ты не можешь сказать «У меня нет идей» или «Я бы ничего не улучшал». Да и команда не посмеет сказать «Мы сделали всё что было в наших силах». Увы, не за это им платят. От хомяков требуют всегда одного — «больше, лучше, быстрее». Это мир капитализма, детка.

Прибыль на нервах айтишников или Почему капиталистический Agile победил социалистический Waterfall

Просто хорошо выполненная работа не устраивает заказчика. Сделал задачу за день? В следующий раз постарайся за полдня! Зачем? А потому что прогресс! Прогресс — это ведь всегда хорошо. Если же улучшений нет, то это смерти подобно. Поэтому на ретроспективе ты не отвертишься, даже если не виновен в проблемах, с которыми столкнулась команда и проект.

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

Таким образом «любимый» всеми потогонный SCRUM де-факто привнес в жизнь айтишников регулярные двухнедельные взбучки, именуемые красивым словом «ретроспектива». Как раз в копилку словаря корпоративного IT-новояза! Но ежики этого не понимают и каждый раз в порыве оптимизма ждут с нетерпением очередной ретроспективы, как будто на ней будет что-то приятное (кроме возможности улизнуть от работы), или хотя бы конструктивное, а не очередной «разбор полетов», основанный на тех событиях спринта, о которых и так в курсе каждый член команды.