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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Scrum не рассматривает время, проведенное над пунктами бэклога спринта. Оставшиеся время и дата – единственные переменные, представляющие интерес.

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

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