Определение размера буфера проекта

Размер буфера проекта на рис. 17.4 определен как 53 минуты. Как я получил его? На основе 50 %-ных и 90 %-ных оценок для этого проекта, как показано на рис. 17.4. Прелесть присвоения двух оценок каждой пользовательской истории в том, что цифры предельно ясно указывают на уровень риска срыва графика, связанный с каждым элементом. Например, если одну историю оценивают в 3–5, а вторую в 3–10, то мы знаем, что вторая история привносит в проект более значительный риск срыва графика. Буфер проекта должен иметь такой размер, чтобы компенсировать риск срыва графика, связанный с запланированной работой. Возьмем экстремальный вариант: если вы составляете календарный график проекта, то вам потребуется меньший буфер проекта для задач с оценкой 3–7 по сравнению с задачами, которые имеют оценку 3–100. Если проект включает в себя трехпунктовые задачи, который могут обернуться 100-пунктовыми, то проекту нужен более значительный буфер, чем при задачах, которые в наихудшем случае могут потянуть только на 10 пунктов. Иначе говоря, спред между 50 %-ными и 90 %-ными оценками влияет на размер буфера проекта[7].

Поскольку наши оценки представляют собой пункты для каждого элемента при вероятности 50 % и 90 %, разница между ними равна примерно двум стандартным отклонениям. Стандартное отклонение для каждого элемента равно (w_i — a_i) / 2, где w_i представляет наихудший случай (90 %-ную оценку) для истории i, а a_i — средний случай (50 %-ную оценку) для той же истории. Нам нужно, чтобы буфер проекта защищал проект в целом на таком же 90 %-ном уровне, как и у каждой задачи с ее 90 %-ной оценкой. Это означает, что наш буфер проекта должен составлять два стандартных отклонения, которые определяются по следующей формуле:

где ? — стандартное отклонение. Эту формулу можно упростить до такого вида:

Посмотрим, как эта формула применяется для определения размера временн?го буфера. Предположим, что наш проект включает в себя шесть пользовательских историй, представленных в табл. 17.2, и что каждая история имеет 50 %-ную и 90 %-ную оценки. Оценки могут быть как в пунктах, так и в идеальных днях. В последней колонке табл. 17.2 приведен результат расчета, в котором из наихудшей (90 %-ной) оценки истории вычитают среднюю (50 %-ную) оценку этой истории, а разность возводят в квадрат. Для первой истории, например, результат составляет (3–1)² = 4. Временной буфер — это квадратный корень из суммы этих квадратов[8]. Временной буфер в нашем случае равен квадратному корню из 90, или 9,4, которые мы округляем до 9. Общая продолжительность проекта представляет собой сумму 50 %-ной оценки и буфера проекта, в нашем случае 17 + 9 = 26.

Буфер, рассчитанный в табл. 17.2, интуитивно понятен. Наибольший вклад в размер буфера вносит та пользовательская история (первая история), которая имеет наибольшую неопределенность (разница в восемь пунктов между 50 %-ной и 90 %-ной оценками). В то же время история, где неопределенность отсутствует (последняя история), не добавляет в буфер ничего.

Создание буфера для календарного графика в одних случаях приводит к увеличению длины проекта на одну или несколько итераций, а в других — нет. Чаще всего приводит. Допустим, команда в нашем примере спрогнозировала свою скорость как девять пунктов на итерацию. Если проект был оценен в 17 пунктов (сумма 50 %-ных оценок), то следовало бы ожидать завершения проекта за две итерации. Однако при включении в проект буфера полный объем работы становится равным 26 пунктам, для реализации которых потребуются три итерации при скорости команды, равной девяти пунктам.