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

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

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

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

Журнал «Открытые системы», декабрь 2010.http://www.osp.ru/os/index.html

Статья в рубрике «ПРОГРАММНАЯ ИНЖЕНЕРИЯ».

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

Ретроспектива в Agile

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

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

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

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

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

Об этом не говорят

В каких случаях команда не говорит о реальных проблемах? Часто это может быть связано с взаимными претензиями членов команды друг к другу — всегда тяжело говорить человеку в лицо о том, что он ведёт себя неправильно не только с профессиональной, но и с человеческой точки зрения. Рассмотрим несколько примеров.

Программисты vs. тестировщики

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

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

Сделай сам

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

Обычно для решения таких проблем прибегают к сторонней помощи руководителя, службы персонала, консультантов. Однако зрелая agile-команда, правильно применяя практику проведения ретроспектив, использует её для обсуждений «глаза в глаза» возникающих претензий и недоумений. Таким образом, ретроспектива дает естественный способ решения проблем, поощряя открытое общение внутри команды.

Правила виноделов

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

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

Часто такая ситуация связана с тем, что члены команды согласились с принятыми решениями только формально, считая для себя возможным отступать от них, когда это им удобно. Например, правило «никогда не ломать сборку проекта на сервере непрерывной интеграции» не приживается по технологическим причинам, так как полная сборка с тестированием занимает около полутора часов. В этой ситуации необходимость ожидать успешного завершения процесса сборки вступает в сильное противоречие с желанием сохранить большой объем изменений в системе контроля версий, особенно если сборка проводится в последние часы рабочей недели. Проговорив эту проблему в ходе нескольких ретроспектив, команда сумела модифицировать правило до «не вносить правки, если потом не сумеешь оперативно починить сборку на сервере», например, при помощи удалённого доступа, если речь идёт о предстоящих выходных.

Другой пример. В определённый момент выясняется, что правило об ограничении времени на рефакторинг в общем объёме задач не работает потому, что часть разработчиков занимается в основном инспекцией кода и рефакторингом, но не берет задачи собственно по разработке нового функционала. С формальной точки зрения правило соблюдается на уровне команды, но общий темп разработки снижается. Регулярная ретроспектива помогает прояснить ситуацию и найти удачный выход: временно запретить (с их добровольного согласия, что важно) этим разработчикам брать задачи по Code Review вообще. В течение двух спринтов нормальная пропорция видов деятельности восстановилась, и запрет был снят.

Бывает так, что работающая в нормальных условиях договорённость в экстремальных ситуациях перестаёт соблюдаться. Часто достаточно лишь отследить этот момент и волевым решением команды вернуть течение вещей в нормальное русло. Например, после старта большой, распределенной системы, работающей в режиме 24x7 и имеющей сотни пользователей, доработки и баги посыпались как из рога изобилия. Изменения вносились впопыхах без детальной проработки. На ретроспективе было замечено, что очень часто Code Review не выполнялся, отчего страдало как качество проектных решений, так и их реализация. Было принято решение вернуть Code Review, которое жестко контролировалось в течение спринта. Со временем отпала сама необходимость контроля, поскольку процесс вошёл в норму.

Все в ваших руках

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

Дополнение: Терминология Scrum

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

Результат каждой итерации показывают и обсуждают с заказчиком на собрании, которое называется «Демонстрация». Таким образом, заказчик видит работающее ПО, начиная с самой ранней стадии проекта, и может оперативно указывать на необходимые изменения.

В начале каждой итерации (в Scrum они называются спринтами) команда определяет, какие задачи она успеет сделать, отбирая их из общего приоритезированного списка, который предлагает представитель заказчика, именуемый Product Owner. Для того чтобы выявить, какие задачи будут решены по итогам спринта, команда в начале оценивает их в удобных ей единицах, а затем, в течение итерации, измеряет в них свою скорость работы. Очевидно, что в начале проекта такая оценка будет не слишком точной, но она улучшается по мере накопления командой опыта.

Демонстрация и планирование — единственные точки во времени, когда заказчик имеет право вмешиваться в деятельность команды. Поскольку заказчик и менеджеры не могут влиять на деятельность команды в течение спринта, все внутренние вопросы команда решает сама, в том числе вопросы распределения ресурсов и контроля качества продукта, а также улучшения всех аспектов процесса разработки. Иногда даже команда сама решает кадровые вопросы, привлекая HR-службу лишь как подрядчика в поиске подходящего кандидата. Впрочем, надо признать, что такие случаи скорее исключение, чем правило. Команда, работающая по описанным выше принципам, называется самоорганизующейся. Именно поэтому Scrum относят к agile-методологиям, ведь самоорганизация и при этом частое взаимодействие с заказчиком входят в базовые принципы Agile-манифеста.

---

Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.