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

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

Требуется время, чтобы делать лучше. Вы должны быть уверены, что затраченное время компенсируется с лихвой тем, что вы получите в результате. Решая техническую проблему вместе с моей командой, я зачастую прошу обозначить, какие качества должно иметь то или иное решение, прежде чем мы приступаем непосредственно к работе над ним. Итак, давайте сделаем это сейчас: Какие же должны быть качества у решения проблемы обозначенной выше, «Как нам лучше справляться?»

Вот мой список:

• Решение должно быть устойчивым, регулярным и длительным
• Вся команда должна увлечься задачей.
• Все участники команды могут принимать участие в работе.
• По мере потребности должна быть возможность привлекать помощь со стороны.
• Само решение должно быть адаптируемым и толерантным к изменениям.

Решение, обладающее такими качествами - командная ретроспектива. Давайте разберёмся с этим подробнее.

Важность командных ретроспектив

Ретроспектива это собрание всего рабочего коллектива, проводимое на регулярной основе, предпочтительно каждую неделю, где команда собирается вместе, чтобы задать вопрос «Как мы продвигаемся?» (или в некоторых случаях «Что за ерунда происходит?»). Позвольте рассказать небольшую историю.

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

И ответ был найден. Мы унаследовали большую базу исходных текстов от одного из наших партнёров по развитию. Они не практиковали разработку через тестирование (TDD) и даже не использовали автоматические методы тестирования. Их код напоминал запутавшийся клубок шерсти, с ним было очень трудно работать, он был невероятно «глючным». Мы пытались привнести в код дисциплину и поставить его под контроль. И вот почему «сцепка» нашей команды начала рассыпаться. Мы зашли на крайне некомфортную территорию, работая над незнакомым кодом без преимуществ тестирования. Это сделало членов команды злыми, раздражительными и слегка напуганными, что привело к напряжению в коллективе. Я бы хотел вам сказать, что после этого всё вернулось в обычное мирное русло, но, конечно же, этого не случилось. Однако, распознав источник эмоционального напряжения в группе, мы смогли слегка успокоить участников нашего коллектива. Более того, это позволило нам сосредоточиться на решении реальных проблем, на решении вопроса о том как поставить под контроль эту базу исходного кода.

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

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

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

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

После того, как вы создали эту самую благоприятную среду, провели игры и определили проблемы, что следует делать для того, чтобы с этими проблемами разобраться? Вот несколько моих предложений:

Подход под названием «Попробуй в течение 2-х недель»

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

Подход на основе измерений

Этот метод сложнее. Он предполагает наличие у команды данных измерений, которые определяют принятие решения о внесении изменений в рабочий процесс. Если необходимых данных нет, команде необходимо собрать эти данные по текущему процессу прежде, чем вносить какие-либо изменения. Иначе, не будет оснований для сравнения. По большинству проектов у нас в Asynchrony Solutions собираются такие данные, как длительность цикла, выполняемые работы и скорость; данные, показывающие насколько быстро команда продвигается вперёд в своей работе. Это позволяет команде видеть, работают ли вносимые изменения и как они влияют на скорость.

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

Устав проекта

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

• Задача и сроки проекта
• Члены команды и рабочие места
• Планирование и оценка
• Мониторинг и измерения
• Управление конфигурацией проекта
• Разработка, тестирование и непрерывная интеграция
• Управление рисками

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

Координатор

Координатор это ключ к хорошей ретроспективе. Хороший координатор знает, когда лучше дать открытой дискуссии продолжаться, а когда перейти к игровым упражнениям для того, чтобы вывести членов команды на откровенность. Опытный координатор знает, как задавать зондирующие вопросы, не подталкивая при этом команду к решению. А когда собрание превращается в свару или препирательство на пустом месте (а это может произойти легко), координатор возвращает беседу в нужное русло.

Постоянное совершенствование – понемногу за раз

Моя команда за четыре года прошла через многое. Это медленный, непрерывный процесс, который никогда не закончится. Наши первые шаги к улучшению рабочего процесса были довольно простыми, мы сосредотачивались на базовых дисциплинах разработки ПО, парном программировании и разработке через тестирование. Затем мы обратили внимание на свои рабочие циклы. Мы перешли с двухнедельного цикла на недельный (что привело к ухудшениям), а затем отменили циклы и перешли на систему Канбан (что привело к значительным улучшениям).

Последнее изменение в процесс работы мы внесли два месяца назад и оно было достаточно крупным. Мы изменили весь процесс Канбан для того, чтобы сосредоточиться на минимальной коммерчески ценной функциональности (Minimal Marketable Features, MMF), а не на индивидуальных требованиях к ПО. MMF - это набор требований к ПО, который и составляет конечный поставляемый продукт. При том что каждое требование необходимо для того, чтобы придать ценности продукту в глазах конечного пользователя, индивидуальное требование может не обладать достаточной ценностью для включения его в релиз. Сосредоточив усилия на MMF, мы надеемся улучшить целостность пользовательского опыта в своих релизах. Мы продолжаем постепенно улучшать этот новый процесс, по мере того, как мы всё больше изучаем его. А наши еженедельные ретроспективы играют важную роль для определения того, как этот процесс нам помогает, и того, что ещё предстоит улучшать.

Оригинал статьи

Об авторе

Марк Болбс (Mark Balbes), кандидат наук и вице-президент компании Asynchrony, рассказывает, как вести организацию по направлению к более эффективным бизнес процессам.

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile