Отражение неопределенности в оценках

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

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

Наиболее вероятное время выполнения задачи на рис. 17.1 находится в том месте, где кривая достигает пика. В целом, однако, вероятность выполнения задачи к этому сроку составляет менее 50 %. Это известно потому, что слева от пика находится менее 50 % площади под кривой. Если бы разработчик дал оценку, соответствующую пику на рис. 17.1, он, скорее всего, не выполнил бы работу к названному сроку. Более наглядно это представлено на рис. 17.2, где изображена кумулятивная вероятность завершения задачи в сроки, отложенные по горизонтальной оси, или раньше них.

Если на рис. 17.1 показана вероятность завершения задачи в конкретное время, то на рис. 17.2 представлена вероятность завершения задачи в это время или ранее. В процессе оценки и планирования это более важно для нас, чем вероятность завершения работы в отдельно взятый день (как показано на рис. 17.1).

Посмотреть на рис. 17.2 и кумулятивную вероятность времени завершения задачи можно и иным образом. Представьте, что 100 одинаково квалифицированных и опытных программистов независимо разрабатывают новую функцию. К какой дате каждый из них завершит работу? Результаты могут быть аналогичными тем, что приведены в табл. 17.1. В этой таблице показано число завершивших работу в каждый из дней и, что более важно, суммарное число завершивших работу в определенный день.

Допустим, нам нужна 90 %-ная уверенность в выполнении календарного графика. Одним из путей достижения этого является оценка срока реализации каждой пользовательской истории с 90 %-ной вероятностью и использование полученных оценок. Однако если сделать это, то календарный график проекта почти наверняка окажется слишком растянутым. Чтобы посмотреть, как работает временной буфер, вернемся к моей поездке в аэропорт, вероятный календарный график которой показан на рис. 17.3.

Первое число для каждой задачи (в светлом прямоугольнике) — оценка продолжительности выполнения задачи с 50 %-ной вероятностью. По моим предположениям, одна половина задач потребует больше времени, а другая — меньше. Второе число (в затемненном прямоугольнике) — это дополнительное время, необходимое для достижения 90 %-ной вероятности. Дополнительное время, представляющее собой разницу между 50 %-ной и 90 %-процентной оценками, называют локальным запасом. Мы нередко добавляем локальный запас к оценке, когда хотим быть более уверенными в выполнении задачи. В нашем случае я думаю, что на поиски ключей мне может понадобиться от одной до шести минут. Я могу добраться до аэропорта через 45–75 минут.

Сложение оценок с 50 %-ной вероятностью дает мне ожидаемый срок, равный одному часу и 10 минутам. Однако, если я выйду из дома так близко ко времени вылета, малейшая задержка приведет к опозданию на рейс. Вместе с тем сложение оценок с 90 %-ной вероятностью дает в сумме два часа 50 минут. Мне совершенно не хочется выезжать почти за три часа до вылета, поскольку вероятность того, что все пойдет наперекосяк, очень мала. Что мне реально хочется получить, так это план проекта, подобный приведенному на рис. 17.4.

План на рис. 17.4 строится на основе оценок с 50 %-ной вероятностью, к которым прибавляется проектный буфер. Такой план намного разумнее, чем тот план, который полностью построен на суммировании оценок с 50 %-ной или 90 %-ной вероятностью. В плане на рис. 17.4 защищается только конечный срок, который имеет принципиальное значение: общий срок проекта. Поскольку совершенно не важно, потребует ли та или иная задача на пути в аэропорт больше времени, мне не нужно создавать буфер для обеспечения своевременного завершения задач. Это позволяет мне сконструировать календарный график, где нет локального запаса для отдельных задач, зато часть этого запаса добавляется в буфер, защищающий календарный график в целом. Обратите внимание на то, что календарный график с буфером на рис. 17.4 занимает только один час 58 минут — почти на час меньше, чем график, полученный в результате суммирования оценок с 90 %-ной вероятностью.

Еще лучше то, что перенос локального запаса в буфер проекта в целом позволяет избежать влияния закона Паркинсона и синдрома студента. Как мы знаем из главы 2 «Почему планирование дает неудовлетворительные результаты», закон Паркинсона гласит, что работа растягивается так, чтобы занять все отведенное на нее время. Синдром студента (Goldratt, 1997) — это склонность откладывать дела на последний момент, что мешает их успешному завершению, например начинать работу над курсовым проектом в колледже за три дня до срока сдачи. Устраняя проблемы, связанные с законом Паркинсона и синдромом студента, такой подход делает вероятность выполнения более короткого календарного графика с буфером выше, чем вероятность выполнения более длинного графика.

Первое, что требуется для создания временн?го буфера, это пересмотр нашего процесса оценки таким образом, чтобы обеспечить генерирование двух оценок для каждой пользовательской истории или функции. Точно так же, как и в случае поездки в аэропорт, нам нужны оценки с 50 %-ной и 90 %-ной вероятностью. Получить их довольно просто: когда команда соберется для проведения оценки, начните с 50 %-ной оценки первой истории. Затем дайте 90 %-ную оценку этой истории, прежде чем переходить к следующей истории или функции.