Добрый день! |
Этапы и мероприятия Scrum
7.4. Груминг технических задач
Теперь мы добрались до рассмотрения специфичного вида активности, чья значимость, однако, не меньше предыдущих.
После того как становится понятен набор бизнес-задач и способ их реализации, которые должна выполнить команда в рамках текущего и следующих спринтов, целесообразно выполнить декомпозицию наиболее сложных и комплексных из них для того, чтобы все члены команды однозначно представляли себе способ и объем планируемой автоматизации, которая должна быть произведена в рамках реализации.
Если провести параллель с классическим подходом к разработке информационных систем, то эта стадия соответствует стадии технического проектирования. Разница состоит в том, что в водопадной и инкрементальной модели за эту стадию отвечает отдельно выделенный специалист - как правило, технический лидер или системный архитектор, а в Agile ответственность за технический груминг ложится на команду в целом.
В Scrum над проектированием работает группа разработчиков, каждый из которых отвечает за область взятых на себя задач и за их гармоническую интеграцию с задачами коллег.
С одной стороны, это повышает риски создания концептуально целостного продукта, но, с другой стороны, снижает вероятность "остаться вдали" от критически важных изменений, которые происходят постоянно при реализации отдельных задач, выполняемых разными разработчиками из Scrum-команды. Совместное взаимодействие членов коллектива позволяет достичь нужного уровня восприятия информации и во многом закладывает базис активности управления знаниями на нужном уровне понимания.
Правила и советы проведения технического груминга соответствует правилам проведения бизнес-груминга. Очень важно, чтобы на техническом груминге присутствовал владелец продукта или кто-то из его представителей. Любое решение, принимаемое в процессе декомпозиции и принятия технического решения, связано с условиями и факторами автоматизируемых бизнес-процессов.
Чем более глубоко происходит интеграция продукта, команды, владельца продукта и других бизнес-пользователей, тем глубже становится понимание того, что нет требований, которые не оказывают влияние на качество результата их совместной работы. Не важно, о каком виде требований идет речь: функциональных или нефункциональных, их решения в любом случае сводятся к качеству создаваемого программного продукта.
7.5. Обзор Спринта
В самом конце каждого спринта наступает момент, когда все члены команды должны продемонстрировать то, что было ими выполнено. Этот этап называется Обзор Спринта.
Эта встреча проводится в заранее запланированном месте, в заранее запланированное время. Цель обзора - показать заинтересованным лицам все, что команда сделала за период спринта. Кажущаяся легкость организации этого мероприятия не должна вводить в заблуждение. Для эффективной демонстрации реализованных задач необходимо потратить немало времени и сил. Отсутствие ясности и прозрачности в организации обзора приводит к тому, что участники этого процесса, кроме членов команды, не понимают статус разработки информационной системы, не понимают ценность реализуемых задач, не понимают, что именно им показывают и для чего это разрабатывается. Чтобы избежать подобных проблем, Scrum-мастер должен с большой ответственностью отнестись к организации этого мероприятия.
Подготовка к обзору не должна занимать у команды более 2 часов. В начале обзора необходимо четко и однозначно озвучить цель прошедшего спринта. Если на обзоре приглашены сотрудники, которые имеют лишь отдаленное представление о разрабатываемом продукте, то следует уделить пару минут, чтобы ввести их в курс дела.
Члены команды рассказывают:
- о поставленных задачах;
- о том, как они решались;
- о том, какие проблемы возникали;
- о том, какие были приняты решения для управления проблемами;
- о том, какие проблемы остались нерешенными.
Если в компании есть проблемы с менеджментом встреч, тогда начинать имеет смысл тогда, когда пришли ключевые участники. Не имеет смысла ждать всех. После того как несколько встреч начнутся вовремя с участием лишь одного или двух пользователей, остальные участники поймут, насколько важно приходить вовремя.
Следует соблюдать назначенный план обзора, который необходимо прописать в описании к встрече. Внезапно возникающие хаотичные дискуссии следует пресекать и выносить за рамки встречи так же, как это делается на дэйли.
Обзор - это не только одно из необходимых мероприятий Scrum. Оно несет в себе множество посылов, управление которыми поможет во внедрении и развитии гибких методологий в вашей компании:
- Положительная оценка работы воодушевляет и мотивирует команду.
- Бизнес-пользователи постепенно начнут более подробно понимать, чем занимается Scrum-команда.
- На обзоре заинтересованные стороны обмениваются жизненно важными отзывами о продукте между собой и с командой.
- Обзор проходит в дружеской атмосфере, поэтому разные команды могут свободно общаться между собой и обсуждать насущные вопросы.
На обзоре необходимо соблюдать следующие принципы:
-
Обзор должно происходить быстро и быть сфокусировано на идее показа реализованной функциональности. Сконцентрируйтесь на создании не столько красивого, сколько динамичного демо. Это поможет приучить всех участвующих к соблюдению заданного тайминга и не отвлекаться на посторонние вещи.
-
Обзор должно быть ориентированным на бизнес-пользователей и подготовленной командой ценностями. Сфокусируйтесь на том, "что мы сделали", а не на том, "как мы это делали". Технические детали очень важны, но смысл демонстрации в том, чтобы показать реализованную ценность. Технические детали команда должна обсуждать в процессе работы.
-
Аудитория обзора может сама попробовать разработанный продукт. Возможность "поиграть" с продуктом действует на пользователей вдохновляюще.
-
Не нужно показывать кучу ошибок и то, как они были исправлены. О них нужно упомянуть, но демонстрировать их не стоит, потому что это заберет у вас много времени и снизит внимание к более важным задачам.
Если команду заставлять проводить обзор, когда у них ничего толком не работает, им будет некомфортно. Команда будет запинаться и спотыкаться, показывая "сырую" функциональность. Это неприятно. Но это действует как горькая пилюля.
В следующий раз команда постарается все доделать к сроку! Команду необходимо приучить к мысли, что обзор придется проводить несмотря ни на что. Если обзор выполнено хорошо, то это оказывает положительное влияние.