Ретроспективы: формальность или польза?

Ретроспективы, как известно, являются обязательной практикой многих гибких методологий. В частности, таких как XP, семейства Crystal, SCRUM.

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

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

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

Почему же это так?

Давайте начнём с начала.

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

Одно «но» – завершённому проекту от этого уже было ни холодно ни жарко. Его команде тоже. Вскрытие же, как никак!

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

Почему? Да просто потому, что каждая итерация такого проекта сама является мини-проектом, по завершению которого должен быть ощутимый результат. На его основании  можно сделать определённые выводы и таким образом повлиять на процесс разработки следующей итерации и, как следствие, на процесс всего проекта.

Звучит просто и логично.

На деле же провести эффективную ретроспективу может быть весьма нелегко.

Я составил список самых распространённых причин, которые заставляют команды если и не избегать ретроспектив, то, как минимум, относиться к ним как к формальности:

• Книги по методологии, используемой командой, очень бегло описывают процедуру ретроспектив, и команда просто формально выполняет предписанные шаги («раз надо, так надо, не будем спорить с гуру»);

• Из-за преобладания диктаторской манеры руководства (в компании и, как следствие, в команде), её члены не чувствуют, что могут что-то изменить и, таким образом, по праву делегируют формирование процесса разработки своему всеведающему начальству («ты у нас умный, на тренинги вон ходишь – сам и решай, а то потом всё равно скажешь делать по-твоему»);

• Команда находится на раннем этапе становления, когда её члены боятся открыто высказывать свои мысли и поэтому не решаются идти на потенциальный конфликт с коллегами («всё равно со мной никто не согласится, я лучше посижу молча, а потом сделаю, как хочу»);

• Команда не объединена единой целью и поэтому успех или неуспех предыдущей итерации субъективен, а общий прогресс никого не интересует («я всё сделал хорошо, не вижу о чём тут ещё говорить»);

• Команда ещё не научилась конструктивному поиску решений и ретроспективы перерастают в поиск частных решений для неважных проблем («раз у нас есть два часа, давайте поговорим о чём-нибудь интересном»);

Несомненно, есть и другие причины. Но перечисленные я лично видел и переживал. И с ними нужно бороться.

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

Кто – конечно же команда. Как – при помощи грамотного лидера-фасилитатора!

Больше о ретроспективах, можно даже в форме книжки.

Статья от 08/2008