Гибкое управление проектами и продуктами - [5]

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

Спринт может быть отменен владельцем продукта в случае, если цели спринта устарели.

Планирование спринта

У планирования спринта две основные задачи: выбор элементов журнала пожеланий для реализации и их декомпозиция. Планирование проводится в самом начале спринта и обычно занимает не более дня для спринта длиной в месяц.

Хорошей практикой будет на основе выбранных элементов журнала пожеланий сформулировать цели для спринта, чтобы команда могла работать более сфокусированно. Подробнее о целях спринта можно прочитать в разделе «Умные цели для спринта» гл. 3.

Скрам-митинг

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

1. Что было сделано с предыдущего скрам-митинга?

2. Какие есть проблемы?

3. Что будет сделано к следующему скрам-митингу?

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

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

Обзор спринта (Sprint Review, «демонстрация», или сокращенно «демо») – демонстрация владельцу продукта и заинтересованным лицам работающего функционала продукта, сделанного за спринт. Основная задача проведения обзора спринта заключается в получении обратной связи, общий цикл чего выглядит следующим образом.

Получение обратной связи в рамках Scrum

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

Если взглянуть еще раз на манифест Agile, в нем есть пункт, который непосредственно касается демонстраций: «Готовый продукт важнее документации по нему». Действительно, основной мерой прогресса является функционал нашего продукта, поэтому показывать на демонстрации надо именно программу. Если заказчик находится не в одном помещении с вами, используйте специальные средства демонстрации. Гораздо хуже будет отправить заказчику презентацию или отчет по сделанному функционалу, ведь мы хотим получить качественную обратную связь.

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

К паттернам можно отнести демонстрацию «чужих» реализованных элементов журнала пожеланий и привлечение к демонстрации аналитиков, тестировщиков, верстальщиков, UI-специалистов и т. д. Такой подход позволяет выработать командную ответственность за результат.

Ретроспектива

В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой Scrum, ведь именно они позволяют адаптировать и настроить Scrum, делая из него по-настоящему гибкий фреймворк для управления проектами.

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

Структура ретроспективы. Обычно ретроспектива занимает от 30 минут до четырех часов и ее продолжительность зависит от таких факторов, как:

• длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;

• размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;

• наличие проблем: со временем команда решает проблемы, и ретроспективы сокращаются по времени.

В процентном соотношении принято выделять такую структуру.

Структура ретроспективы

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

1. Что было сделано хорошо?

2. Что можно улучшить?

3. Какие улучшения будем делать?

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

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

Если у команды отсутствуют серьезные проблемы, желательно следующие темы обсудить на ретроспективе:

• скорость команды и ее изменение по сравнению с предыдущими спринтами;

• нереализованные истории пользователей и причины опоздания;

• дефекты и их причины;