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

Почему не успели сделать все запланированные задачи?
Стоит ли перенести время Daily Scrum Meeting (ежедневное собрание — “летучка”, на которой обязательно должны присутствовать все члены команды) на более раннее (более позднее) время?
А не сменить ли систему контроля версий?
Может быть, стоит заказывать пиццу, если работаем после 20.00?
 
На первых этапах внедрения Scrum ретроспективы проходят бодро. Команда получает «законную» возможность зафиксировать и даже решить проблемы, о которых все знают, но до которых обычно не доходят руки. Но после того как проходит первый эффект, ретроспектива часто вырождается в формальность или вообще не проводится. Почему так происходит? Объяснений может быть несколько: на ретроспективе по разным причинам не затрагиваются системные проблемы; решения, принятые на ретроспективе, не выполняются.
 

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

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

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

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

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

 

Тестирование на основе моделей
Многие знают, как разработать программу и могут даже рассказать, как это сделать, но объяснить, что значит создать программу с высоким качеством, значительно труднее.

 

CUSTIS

Компания CUSTIS была основана в 1996 году выпускниками МФТИ для решения нестандартных задач в области разработки прикладного программного обеспечения. Сегодня компания специализируется на заказной разработке и внедрении учетно-аналитических систем для организаций, имеющих уникальные бизнес-процессы или высокую динамику их изменения.
Информационная система должна полностью отвечать требованиям клиента и не сдерживать его развитие, поэтому успех бизнеса CUSTIS определяется адекватностью созданной методами системного анализа формализованной модели бизнеса реальному положению дел. Обобщая знания и опыт заказчика в данной модели, учитываются текущие требования бизнеса и намечаются точки его дальнейшего роста, а затем эта модель реализуется в информационной системе.

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

Сделай сам

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

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

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

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

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

Проекты

Крупной ретейловой компании потребовалась информационная система для обеспечения поставок товара со складов во множество розничных магазинов, расположенных по всей стране. Система должна функционировать в режиме 24/7, обеспечивая работу нескольких сотен пользователей. Важной особенностью проекта было то, что в нем впервые применялся новый стек технологий разработки CUSTIS.
Разработка системы продолжалась 16 месяцев, после чего комплекс был сдан в промышленную эксплуатацию. За эти месяцы функциональность системы была расширена, добавились новые модули, возросла нагрузка (в несколько раз увеличилось количество документов, обрабатываемых в течение дня), расширилась география пользователей. Кроме этого менялась команда: несколько разработчиков перешли в другие команды передавать опыт работы с новыми технологиями, приходили новые люди, которые обучались непосредственно в проекте.
Роль Scrum и ретроспективы, как части методологии, заключалась в том, чтобы с первых дней проекта спаять команду и дать ей возможность оставаться единым целым, ассимилируя новых членов и менее болезненно переживая уход ветеранов.
Размер команды составлял в среднем шесть человек (2 инженера и 4-5 программистов), трудозатраты -- 14 человеко-лет, объем кода -- 150 тыс. строк. В проекте использовались: Net 3.5, C#, Web Services, собственный стек технологий, включающий ORM и тонкий клиент. Среда разработки Visual Studio 2008, Visual Studio 2010, PL/SQL Developer.

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

***

Зрелая agile-команда может сама решать широкий спектр проблем: от технологических до организационных, корни которых уходят в психологию людей. Все эти аспекты могут быть очень разными для разных команд, но в любой команде важно не бояться доверять друг другу, обсуждать проблемы и совместно решать их. Именно так и создаются самоорганизующиеся команды, о которых говорит манифест Agile.
 
 
Василий Кудрявцев (vkudriavtsev@custis.ru) — ведущий программист, компания CUSTIS (Москва).

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF