Этапы и мероприятия Scrum

7.4. Груминг технических задач

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

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

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

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

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

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

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

7.5. Обзор Спринта

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

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

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

Члены команды рассказывают:

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

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

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

Обзор - это не только одно из необходимых мероприятий Scrum. Оно несет в себе множество посылов, управление которыми поможет во внедрении и развитии гибких методологий в вашей компании:

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

На обзоре необходимо соблюдать следующие принципы:

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

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

• Аудитория обзора может сама попробовать разработанный продукт. Возможность "поиграть" с продуктом действует на пользователей вдохновляюще.

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

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

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