В шапке
Процессы по Scrum. Демо спринта

Процессы по Scrum. Демо спринта

Продолжаю серию статей про Scrum. В прошлый раз мы рассмотрели, как выполняется ежедневный Scrum-митинг, читайте об этом здесь>>  

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

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

Итак, на демо приходит вся команда. Для чего? Все просто - каждый участник может показать владельцу продукта результаты своего труда и получить от него уточнения требований или вопросы по сделанному. Можно, конечно, приходить не всем участникам команды, но тогда тот, кто придет от команды, должен быть способен показать все, что сделано, и при этом ответить на вопросы владельца продукта.

Мне очень нравится эта практика, т.к. команда не тратит много времени на «причесывание» ТЗ, а работает непосредственно над продуктом, создавая быстрые прототипы и показывая как это работает. Однако, не все заказчики проектов готовы смотреть части продукта, а не готовый полностью продукт. Поэтому прежде чем что-то показывать представителям заказчика, скрам-мастеру лучше объяснить  им, что при работе по скрам не стоит ожидать законченных и выверенных решений, т.к. команде важно получить быструю обратную связь и если что-то сделано не так, подправить это в следующем спринте.

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

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

Таким образом, знание MBTI мне помогает определить типологические особенности владельца продукта. И, если я понимаю, что он сенсорик, то я не буду ждать от него положительной реакции на мое предложение просматривать концептуальные (читай «сырые») прототипы частей продукта, над которым работает команда проекта. Для сенсориков я буду предлагать смотреть достаточно хорошо сделанные части продукта, которые выглядят законченными.

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

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

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

Что в итоге дает демо спринта?

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

Возникли при прочтении статьи какие-то вопросы? Пишите, я готов обсудить их.

Удачи Вам в Ваших проектах и до связи!

 

Комментарии (0)
Войти как