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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать следующий пост на тему ретроспектив.

Ссылки:

• Статья Rachel Davies
  “How To: Live and Learn with Retrospectives”
• Статья Boris Gloger’s blog and presentation
  “Heartbeat Retrospectives”
• Книга Norman Kerth
  ”Project Retrospectives: a handbook for team reviews”
• Книга Esther Derby, Diana Larsen
  ”Agile Retrospectives: Making Good Teams Great”
• Книга Jean Tabaka
  “Collaboration Explained”