Ретроспектива в Agile-командах

Ссылки сюда (1) →

Василий Кудрявцев

ведущий программист и Scrum-Master, компания CUSTIS

Открытые системы, декабрь 2010.[1] Статья в рубрике ПРОГРАММНАЯ ИНЖЕНЕРИЯ.

Agile-методологии проникли в российскую индустрию разработки программного обеспечения уже несколько лет назад и имеется немало отчётов и статей о том, как приступать к внедрению методологии Scrum или других разновидностей agile-методологий и практик. Однако, что делать дальше, когда проблемы начального этапа остались в прошлом, а работа по принципам Scrum стала для команды нормой?

Чем дольше команда работает по принципам Agile, тем интереснее становятся проблемы, которые ей приходится решать. С одной стороны, выясняется, что вещи, которые на этапе внедрения казались очевидными и не вызывали вопросов, видятся разными людьми по-разному. С другой стороны, некоторые практики, например, полная кроссфункциональность (взаимозаменяемость членов команды), оказываются неприменимы и приходится изменять процесс. Опыт команд, внедрявших Scrum, показывает, что полная кроссфункциональность встречается нечасто и в нашей практике, например, вместо «универсальных разработчиков» команду составляют разработчики и аналитики-тестировщики — такая конструкция для нас оказалась оптимальной.

Впрочем, аgile-методологии поощряют адаптацию известных практик, равно как и разработку собственных. Scrum даже предоставляет конкретный инструмент для этого — ретроспективу, которая согласно каноническому определению, предназначена для совместного обсуждения членами команды прошедшей итерации. Важно зафиксировать, что было хорошо и как это можно сохранить, понять, что нужно добавить в процесс для повышения эффективности работы и получаемого от неё удовольствия. И, конечно, нужно выявлять проблемы, возникшие во время итерации, а также искать возможные пути их решения. Стоит подчеркнуть, что ретроспектива предназначена не столько для решения технических задач, сколько для улучшения процесса в целом. Типичные вопросы, обсуждаемые на ретроспективе:

• Почему не успели сделать все запланированные задачи?
• Стоит ли перенести время Daily Scrum Meeting (ежедневное собрание — «летучка», на котором обязательно должны присутствовать все члены команды) на более раннее (более позднее время)?
• А не сменить ли систему контроля версий?
• Может быть, стоит заказывать пиццу, если работаем после 20.00?

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

• на ретроспективе по разным причинам не затрагиваются системные проблемы;
• решения, принятые на ретроспективе, не выполняются.