Agile: оценка и планирование проектов

• Метод квадратного корня из суммы квадратов является самым надежным, если оцениваются не менее 10 пользовательских историй или функций. Если же в вашем проекте меньше 10 элементов, то, скорее всего, можно обойтись без буфера.

• На буфер проекта должно приходиться не менее 20 % общего срока этого проекта. Буфер меньшего размера не всегда обеспечивает адекватную защиту проекта в целом.

Комбинирование буферов

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

Именно сочетание функционального и временнóго буферов обеспечивает реальную защиту проектов от неопределенности. Взгляните на три проекта, показанные на рис. 17.5. В секции а) представлен проект, где необходимо поставить заказчику четко определенный набор функций, но можно варьировать сроки. В секции b) представлена противоположная ситуация: проект, где дата завершения фиксирована, но допускается гибкость в отношении реализованных функций. В секции с) видно, что создание и функционального, и временнóго буфера позволяет команде выдержать дату поставки и одновременно реализовать минимальный набор функций. При создании плана релиза наша цель заключается в использовании буферов таким образом, чтобы команда могла принять эти виды обязательств.

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

1. Один-два дополнительных человека для создания буфера по персоналу в небольшом проекте почти всегда вносят прямой вклад в срок проекта. Увеличение штата с 30 до 33 разработчиков вряд ли заметно повысит производительность, если вообще повысит. Если же штат увеличивается с четырех разработчиков до пяти, то производительность практически наверняка вырастет.

2. Очень трудно создавать буферы для чего-то небольшого. Когда в проекте, где занято 30 человек, создается резерв из трех работников и полный штат увеличивается до 33, мы получаем 10 %-ный буфер по персоналу. Аналогичный буфер для проекта, в котором заняты три человека, составит всего 0,3 разработчика. Понятно, что часть человека не добавишь в проект.

Временной буфер — это не раздувание сроков

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

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

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

Ограничительные оговорки

Хотя понимание того, как создать один или несколько буферов в проекте, очень важно, полезно также помнить о некоторых ограничениях, связанных с использованием буферов.

• При добавлении временнóго буфера используйте подход с двумя оценками, описанный в этой главе, а при использовании одной оценки следите за тем, чтобы она была 50 %-ной. Добавление временнóго буфера к и без того пессимистичным 90 %-ным оценкам приведет к чрезмерному удлинению сроков.