Майк Кон - Agile: оценка и планирование проектов

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

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

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

Поскольку наши оценки представляют собой пункты для каждого элемента при вероятности 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) 2= 4. Временной буфер — это квадратный корень из суммы этих квадратов [8] Именно поэтому этот метод определения размера буфера обычно называют «квадратный корень из суммы квадратов». . Временной буфер в нашем случае равен квадратному корню из 90, или 9,4, которые мы округляем до 9. Общая продолжительность проекта представляет собой сумму 50 %-ной оценки и буфера проекта, в нашем случае 17 + 9 = 26.

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

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

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

Хотя такой расчет значительно проще, у него есть серьезный недостаток — в нем не учитывается фактическая неопределенность конкретных пользовательских историй в проекте. Допустим, у нас есть две истории, каждая из которых оценена в пять пунктов. Обе они вносят одинаковый вклад в буфер проекта (половину своего размера, или по 2,5 пункта). Это правило сохраняется несмотря на то, что одна из этих историй может иметь 90 %-ную оценку 100, а другая — 10.