Существует три способа оценки скорости. Во-первых, можно использовать исторические средние показатели при их наличии. Вместе с тем, прежде чем применять исторические средние показатели, необходимо понять, не изменились ли существенно команда, характер проекта, технология и т. п. Во-вторых, можно отложить оценку скорости до тех пор, пока не будут выполнены несколько итераций. Это обычно наилучший вариант. В-третьих, можно спрогнозировать скорость путем разбивки нескольких историй на задачи и определения объема работ, подходящего для итерации. Этот процесс очень похож на планирование итерации.
Независимо от выбранного подхода оценки скорости следует представлять в виде диапазона, отражающего присущую оценке неопределенность. Конус неопределенности помогает определить подходящий размер диапазона.
Вопросы для обсуждения
1. В табл. 16.2 истории, оцениваемые одинаковым числом пунктов, имеют разную оценку задач в часах. Почему? (Если вам нужна подсказка, обратитесь к разделу «Соотнесение оценок задач с пунктами» в главе 14 «Планирование итерации».)
2. Составьте таблицу, подобную табл. 16.3, для вашего текущего проекта. Существует ли возможность каким-либо образом увеличить количество времени, которое каждый член группы может посвящать проекту?
Глава 17
Буферизация планов для компенсации неопределенности
Неопределенность неудобна, определенность — глупа.
Мне нередко жалуются на то, что agile-планирование не очень хорошо работает в некоторых ситуациях. При этом обычно называют следующие условия:
• Планирование проекта осуществляется задолго до его начала.
• Проект необходимо выполнить до жестко установленного срока и реализовать жестко заданный набор функций.
• Проект передается на договорной основе из одной организации в другую.
• Требования понятны только на очень поверхностном уровне.
• Организация противится слишком большой гибкости календарных графиков, даже в проектах без жестких сроков и четкого определения поставляемого продукта.
Умение составлять надежные планы в таких условиях чрезвычайно важно. Зачастую использования простого подхода, рассмотренного в предыдущих главах, недостаточно. В подобных условиях общим у всех проектов является то, что каждый из них характеризуется либо дополнительной неопределенностью, либо более серьезными последствиями в случае ошибки. Я, например, был когда-то вице-президентом по разработке программного обеспечения в компании, входящей в список Fortune 40, и календарный график для наших проектов обычно составлялся за 12–18 месяцев до их начала, когда мы верстали бюджет на следующий год. Мы, конечно, не фиксировали требования, однако должны были определять характер продукта, который будет создаваться. Несмотря на то, что представление о требованиях было расплывчатым, нам приходилось принимать обязательства первого уровня, которые позволяли составлять адекватное штатное расписание для организации. Существовала и другая неопределенность: я редко знал задолго до начала проектов, кто именно из моей команды будет над ними работать. Чаще всего исполнителей просто не было в штате.
Сравните эту ситуацию с проектом, в котором от вас требуют установить жесткий срок и взять обязательство по реализации ключевого набора функций. Нарушение сроков или поставка неполной функциональности подорвет репутацию компании в отрасли и вашу репутацию в компании. Даже если вы достаточно хорошо понимаете требования и знаете, кто войдет в состав команды (в отличие от меня в приведенном выше примере), риск допустить ошибку очень значителен.
Для таких случаев характерна либо повышенная неопределенность, либо более серьезные последствия ошибок в графике релиза. Как результат, полезно создавать буфер при составлении календарного графика. Буфер — это допуск на ошибку в оценке. Когда значительна неопределенность или издержки, связанные с ошибкой, создание буфера очень разумно. Буфер помогает защитить проект от влияния неопределенности. Таким образом, буферизация календарного графика проекта становится хорошей стратегией управления риском. В этой главе мы рассмотрим два типа буферов: функциональный буфер и буфер календарного графика (временной буфер).
Функциональный буфер