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

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

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

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

Команда разработки самоорганизуется, чтобы выполнить от начала и до конца все работы, необходимые, чтобы превратить элементы бэклога продукта, разъясненные и упорядоченные[22] владельцем продукта, в версии продукта. Термин «разработка» относится ко всей работе, которую команда разработки делает на протяжении спринта. Она может включать создание прототипов, тестирование, написание кода, подготовку документов, интеграционную работу, активности по выпуску, и т. д. В нее входит вся работа, необходимая для того, чтобы гарантировать, что не позднее конца каждого спринта инкремент продукта окажется пригодным для использования и что технически он может быть выпущен для пользователей или потребителей продукта либо сервиса. Такое состояние инкремента называется «готово». Качества и критерии, которые нужно удовлетворить для этого и которые также влияют на работу команды разработки, фиксируются в определении готовой работы.

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

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

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

2.5.2. Время

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

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

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

■ планирование спринта,

■ ежедневный скрам,

■ обзор спринта,

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

Каждый спринт начинается с планирования спринта, когда команда разработки вытягивает работу в спринт из существующего на данный момент бэклога продукта. Команда берет тот объем работы, который представляется ей реалистичным для спринта, чтобы результат оказался готовым к выпуску. Выбранная работа – это прогноз[23], представляющий собой понимание команды на момент выбора. Команда разработки может посмотреть на объем работы, который был сделан в среднем в предыдущие спринты, и сравнить этот объем с планом на предстоящий спринт, чтобы слегка повысить точность прогноза.

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

Прогноз создается, анализируется и детализируется в план работ для ограниченного по времени спринта – это бэклог спринта. После окончания фиксированного по времени планирования спринта (или даже раньше) команда разработки начинает действовать по совместно разработанному плану. Планирование спринта никогда не занимает более восьми часов.

Чтобы управлять и отслеживать работу, команда разработки проводит ежедневные 15-минутные встречи, которые называются ежедневный скрам. Эта встреча – своего рода оперативная планерка. Команда оптимизирует план предстоящей работы на основании реального продвижения к цели спринта. Адаптация фиксируется как обновление бэклога спринта. Реальный прогресс в выполнении бэклога спринта визуализируется, показывается объем оставшейся работы. Если реальный прогресс не совпадает с намеченным, команда разработки консультируется с владельцем продукта.

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

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

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

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

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

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

Объем работы, который команда делает за спринт, иногда называют скоростью. Скорость – показатель того объема работы, который команда смогла выполнить в предыдущих