Менеджмент цифрового продукта. От идеи до идеала

➠ Чрезвычайный буфер (emergency buffer). Если почти каждый спринт из-за чрезвычайных ситуаций запланированный объем выполняется не в полной мере, нужно зарезервировать несколько единиц объема под такие работы и делать поправку при планировании.

3.2.3.5. Ежедневный Scrum

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

Цель ежедневного Scrum – обменяться статусами, планами и определить препятствия к достижению цели спринта.

Хорошая практика, когда каждый член команды разработчиков по очереди рассказывает:

➠ что было сделано вчера;

➠ что запланировано на сегодня;

➠ какие препятствия могут помешать выполнить запланированный объем в срок.

Часто для визуализации используется Scrum-доска (см. п. 3.1.3.6.). В этом случае каждый участник передвигает свои задачи по Kanban-доске для изменения статуса (рис. 3.7).

Scrum-мастер модерирует встречу, чтобы не обсуждались темы, не связанные с ежедневным прогрессом. Если команда начинает разбор полетов, то Scrum-мастер предлагает перенести обсуждение на ретро; если начинается обсуждение реализации, то на прояснение бэклога. По другим вопросам предлагается сделать отдельную встречу или перенести обсуждение в чат.

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

3.2.3.6. Обзор спринта

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

3.2.3.7. Лучшие практики обзора спринта

➠ Открытое демо (public demo). На обзор спринта приглашаются все желающие – стейкхолдеры, члены других команд, сотрудники организации и пользователи-спонсоры[46].

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

➠ Выставочное демо (trade show demo). По аналогии с выставкой для каждого реализованного элемента создается «выставочный павильон». Реальные пользователи, стейкхолдеры и другие участники проходят через все павильоны и тестируют функциональность, а представители команды в каждом павильоне фиксируют озарения для улучшений в продукте. Такой подход позволяет протестировать инкремент сразу на нескольких пользователях за ограниченное время.

➠ Блок обратной связи от стейкхолдеров позволяет синхронизировать ожидания, но при этом требует дополнительного времени.

➠ Не показывать почти готовое. Бывает, что элемент почти готов, но не соответствует определению завершенности, например, не развернут на пользователей, но его можно увидеть в тестовом окружении. Статус «почти готово» может сбить с толку, вселить ложные надежды и, самое главное, придется повторно инспектировать артефакт, когда он будет готов.

3.2.3.8. Ретроспектива спринта

Ретроспектива позволяет поддерживать процессы в актуальном состоянии. Scrum-команда инспектирует последний спринт и анализирует его в разрезе ролей, процессов, инструментов и определения завершенности.

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

Важно, чтобы каждый член команды мог высказаться.

3.2.3.9. Лучшие практики ретроспективы

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

➠ Обсуждение положительных моментов в формате благодарения (thanksgiving retro). Участники говорят спасибо за положительные моменты, которые помогали. Это сплачивает и настраивает на позитивную коммуникацию.

➠ Последовательность «коуч – наставник – учитель». Паттерн для Scrum-мастера, который позволяет генерировать проблемы максимально эффективно:

➠ для начала человеку, заявившему о проблеме, предлагается придумать решение самостоятельно (коуч);