Для многих команд разработчиков такое периодическое мероприятие как спринт ревью, или обзор спринта, морально устарел и уже изжил себя. И, похоже, пора перестать этим заниматься. Так считает Майк Кон (Mike Cohn), один из соавторов и основателей Scrum и Scrum Alliance. Звучит еретически? Отнюдь.

Назначение обзоров спринтов

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

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

Лет десять назад отличные команды занимались непрерывной интеграцией кода – после проверки делался билд и запускались автоматизированные тесты, проверявшие отсутствие дефектов. Сейчас отличные команды заняты непрерывной поставкой и развёртыванием. После успешного тестирования сразу же следует развёртывание. И это полностью меняет саму суть обзора спринта.

Представьте ситуацию, когда команда выдаёт порядка семи реализованных функциональных возможностей в день (для отличной команды веб-разработчиков это не является чем-то необычным в наши дни). Каким будет обсуждение по итогам десятидневного спринта? А это, на минуточку, 70 разработанных новых функций. Как воспримут и смогут оценить этот объём заказчики? Скорее всего, для них это будет уже не столь важно. Новая функциональность уже предоставляется пользователям. Важно, что они думают, поскольку уже используют новые возможности.

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

А что на замену?

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

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

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

Обзор спринтов при непрерывной поставке

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

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

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

Образовательный аспект обзоров спринтов

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

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

Что же делать

По мнению Майка, обзор спринта не является обязательной активностью. Для многих команд он остаётся уместным и полезным. Например, команда разработки, которая выпускает релизы раз в квартал, скорее всего, получит пользу от традиционного, формального обзора в конце спринта – как это было описано и использовалось в течение многих лет.

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

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