Мои рекомендации

Эффективны оба подхода — и планирование итерации на основе скорости, и планирование итерации на основе обязательств. Я, однако, предпочитаю подход на основе обязательств. Хотя скорость играет критическую роль в планировании релиза, я не считаю, что она должна играть такую же роль при планировании итерации. Для такого заявления есть две причины.

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

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

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

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

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