Разберитесь, что такое ревью спринта, какие задачи оно решает и как правильно проводить, чтобы улучшить командную работу.

Спринт–обзор (или спринт–ревью, Sprint Review) – в методологии Scrum является важным событием, наступающим в конце каждого спринта, то есть временного отрезка, в рамках которого выполнялись определенные задачи по проекту. В рамках собрания команда может продемонстрировать демо с достигнутыми результатами.

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

Встреча с спринт–ревью обычно проводится Scrum–мастером. Его миссия заключается в том, чтобы выполнять роль фасилитатора. То есть он управляет остальными участниками, чтобы обзор результатов прошел эффективно.

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

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

Формат спринт–ревью подразумевает, что встреча может длиться около 1,5-2 часов. Этот фактор зависит от продолжительности отдельно взятого спринта в рамках реализации проекта. Поэтому собрание требует тщательной подготовки как со стороны скрам–мастера, так и со стороны команды.

Условно процесс спринт–ревью можно поделить на несколько этапов.

Первый: вступление.

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

Второй: демонстрация результатов.

Участники разработки демонстрируют те результаты, которых им удалось достичь в рамках завершившегося спринта. Они показывают либо личные итоги, если команда небольшая, либо успехи своего подразделения.

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

Третий: обсуждение.

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

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

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

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

Четвертый: завершение встречи.

Скрам–мастер подводит итоги спринт–ревью и устанавливает планы на будущий спринт. Согласовываются фронт работ с учетом всех изменений, если они возникли.

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

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

К основным видам документации можно отнести такие:

– Обновленный бэклог продукта.

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

– Обратная связь от участников спринт–ревью.

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

– Конспект встречи может быть сформирован в формате отчета.

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

– Дорожная карта или план действий.

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

Формат документа выбирается в зависимости от культуры и специфики компании, которая занимается разработкой программного обеспечения. Свои требования могут выдвинуть заказчики и другие заинтересованные лица проекта.

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

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

Во–первых, ошибки могут быть допущены на этапе подготовки:

– команда не подготовила отчет;

– выполнены не все задачи;

– скрам–мастер не согласовал время и дату встречи;

– не подготовлено место проведения встречи;

– нет сопроводительных материалов, чтобы участники могли лично ознакомиться с отчетом о проделанной работе;

– не все заинтересованные стороны могут принять участие, так как возникли другие срочные обязательства перед встречей.

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

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

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

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

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

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

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

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

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

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

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

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