Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

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

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

В. Цель спринта.Цель спринта дает Scrum-команде некоторую гибкость в отношении разрабатываемого функционала в спринте.

Пока команда работает, эта цель служит для нее ориентиром. Для ее достижения команда реализует функционал и технологию. Если же работа отличается от ожидаемой, то команда договаривается с владельцем продукта об изменении объема бэклога спринта в текущем спринте.

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

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

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

• что было сделано с момента прошлой встречи?

• что будет сделано к моменту следующей встречи?

• какие препятствия есть на пути?

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

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

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

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

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

Обзор спринта включает следующие элементы:

• владелец продукта определяет, что можно считать «законченным», а что нет;

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

• команда разработки проводит демонстрацию уже сделанного и отвечает на вопросы об инкременте;

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

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

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

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

Ретроспектива спринта происходит после его обзора и перед последующим планированием. Это ограниченная тремя часами встреча для одномесячного спринта. Для более коротких спринтов обычно выделяется меньше времени. Scrum-цели ретроспективы спринта следующие:

• инспекция успешности спринта: отношения между людьми, процессы и инструменты;

• определение и упорядочение того, что прошло успешно, и того, что нуждается в улучшении;

• разработка плана по внедрению улучшений в процесс работы Scrum-команды.

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

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

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

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