Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - читать онлайн книгу. Автор: Роб Коул, Эдвард Скотчер cтр.№ 22

Не пренебрегайте организацией – зарезервируйте подходящее помещение со всем оборудованием, необходимым для презентации, настройте его заранее и подготовьте саму презентацию. Будет очень неприятно, если результат двухнедельных трудов будет испорчен неудачной презентацией.

Придерживайтесь простого формата и не слишком углубляйтесь в детали – представьте, что среди слушателей сидит ваша пожилая и нетерпеливая тетушка Роуз и вам нужно говорить понятно, но в то же время профессионально. И не слишком увлекайтесь – нет ничего плохого в том, чтобы управиться за 15 минут.

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

• Все карточки помещаются на стол, а Скрам-мастер поясняет, все ли было закончено, а если нет, то почему.

• Скрам-мастер обновляет пользовательские истории, входящие в спринт.

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

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

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

• Прочим присутствующим предоставляется возможность высказать свое мнение.

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

В конце каждого спринта, как только обзор итогов закончен и Владелец продукта и прочие заинтересованные уходят, довольные, команда собирается вместе, чтобы обсудить прошедшую работу. Это называется «ретроспектива», и она проводится непременно, даже если все прошло точно в соответствии с планом. Можно многое почерпнуть как из ошибок, так и из гладко прошедшей работы. Никогда не предполагайте, что это пустая трата времени, и не бросайтесь тут же в следующий спринт.

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

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

Блистательный пример

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

Как только команда все записала, предложите просмотреть записки и сгруппируйте их по темам. Каждой теме дайте название.

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

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

Артефакты Скрама – это элементы, необходимые команде для успеха. Обязательная большая тройка – это журнал пожеланий продукта, журнал пожеланий спринта и диаграмма сгорания задач. Есть и другие инструменты, но эти основные. Большинству более чем хватает и этих трех.

Журнал требований продукта

Журнал требований продукта (бэклог продукта) – это список идей, которые нужно воплотить в продукте; можно также назвать его списком желаний. Этот журнал служит для того, чтобы требования владельца продукта были донесены до команды в четком, ясном и постоянно доступном формате. Он включает в себя все, что может понадобиться команде в ходе работы, – не только специфические задачи, но и прочие пожелания.

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

Журнал требований спринта

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

Диаграмма сгорания задач

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