Ретроспективы. Формальность или польза?
Ретроспективы – как известно, являются обязательной практикой многих гибких методологий. В частности таких как 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”
