Допустим, нам нужна 90 %-ная уверенность в выполнении календарного графика. Одним из путей достижения этого является оценка срока реализации каждой пользовательской истории с 90 %-ной вероятностью и использование полученных оценок. Однако если сделать это, то календарный график проекта почти наверняка окажется слишком растянутым. Чтобы посмотреть, как работает временной буфер, вернемся к моей поездке в аэропорт, вероятный календарный график которой показан на рис. 17.3.
Первое число для каждой задачи (в светлом прямоугольнике) — оценка продолжительности выполнения задачи с 50 %-ной вероятностью. По моим предположениям, одна половина задач потребует больше времени, а другая — меньше. Второе число (в затемненном прямоугольнике) — это дополнительное время, необходимое для достижения 90 %-ной вероятности. Дополнительное время, представляющее собой разницу между 50 %-ной и 90 %-процентной оценками, называют
Сложение оценок с 50 %-ной вероятностью дает мне ожидаемый срок, равный одному часу и 10 минутам. Однако, если я выйду из дома так близко ко времени вылета, малейшая задержка приведет к опозданию на рейс. Вместе с тем сложение оценок с 90 %-ной вероятностью дает в сумме два часа 50 минут. Мне совершенно не хочется выезжать почти за три часа до вылета, поскольку вероятность того, что все пойдет наперекосяк, очень мала. Что мне реально хочется получить, так это план проекта, подобный приведенному на рис. 17.4.
План на рис. 17.4 строится на основе оценок с 50 %-ной вероятностью, к которым прибавляется проектный буфер. Такой план намного разумнее, чем тот план, который полностью построен на суммировании оценок с 50 %-ной или 90 %-ной вероятностью. В плане на рис. 17.4 защищается только конечный срок, который имеет принципиальное значение: общий срок проекта. Поскольку совершенно не важно, потребует ли та или иная задача на пути в аэропорт больше времени, мне не нужно создавать буфер для обеспечения своевременного завершения задач. Это позволяет мне сконструировать календарный график, где нет локального запаса для отдельных задач, зато часть этого запаса добавляется в буфер, защищающий календарный график в целом. Обратите внимание на то, что календарный график с буфером на рис. 17.4 занимает только один час 58 минут — почти на час меньше, чем график, полученный в результате суммирования оценок с 90 %-ной вероятностью.
Еще лучше то, что перенос локального запаса в буфер проекта в целом позволяет избежать влияния закона Паркинсона и синдрома студента. Как мы знаем из главы 2 «Почему планирование дает неудовлетворительные результаты», закон Паркинсона гласит, что работа растягивается так, чтобы занять все отведенное на нее время. Синдром студента (Goldratt, 1997) — это склонность откладывать дела на последний момент, что мешает их успешному завершению, например начинать работу над курсовым проектом в колледже за три дня до срока сдачи. Устраняя проблемы, связанные с законом Паркинсона и синдромом студента, такой подход делает вероятность выполнения более короткого календарного графика с буфером выше, чем вероятность выполнения более длинного графика.
Первое, что требуется для создания временнóго буфера, это пересмотр нашего процесса оценки таким образом, чтобы обеспечить генерирование двух оценок для каждой пользовательской истории или функции. Точно так же, как и в случае поездки в аэропорт, нам нужны оценки с 50 %-ной и 90 %-ной вероятностью. Получить их довольно просто: когда команда соберется для проведения оценки, начните с 50 %-ной оценки первой истории. Затем дайте 90 %-ную оценку этой истории, прежде чем переходить к следующей истории или функции.
Определение размера буфера проекта