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

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

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

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

Журнал «Открытые системы», январь 2011.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-манифеста.

Инструментарий

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

Проекты

Заказчику — крупному ретейлеру — требовалась информационная система для обеспечения поставок товара со складов во множество розничных магазинов, расположенных от Калининграда до Красноярска. Система должна была функционировать в режиме 24/7, обеспечивая работу нескольких сотен пользователей. Важной особенностью проекта было то, что в нем впервые применялся новый стек технологий собственной разработки.

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

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

Размер команды составлял в среднем шесть человек (2 инженера и 4-5 программистов). Трудозатраты: 14 человеко-лет (3500 человеко-дней). Объем кода: 150 тыс. строк. Использованные технологии: Net 3.5, C#, Web Services, собственный стек технологий, включающий ORM и «тонкий» клиент. База данных: Oracle 10g. Среда разработки: сначала Visual Studio 2008,затем Visual Studio 2010, PL/SQL Developer.

Компания CUSTIS

Компания CUSTIS (www.custis.ru) основана в 1996 году выпускниками МФТИ, которые стремились решать сложные нестандартные задачи в области разработки прикладного программного обеспечения. В результате появилась компания, которая выполняет разработку больших корпоративных систем на заказ. Компания никогда не изменяла исходным принципам и научилась непрерывно расти и развиваться в этом непростом секторе ИТ-рынка.

Наш бизнес

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

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

Наш подход

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

Большое внимание мы уделяем технологическому развитию и добиваемся промышленного качества своих систем. Наши процессы разработки прозрачны для клиентов, мы обучаем их нашим технологиям, консультируем в вопросах выбора и применения современных платформ и систем от мировых лидеров ИТ-рынка.

---

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