Agile: оценка и планирование проектов - [72]

Резюме

Существует три способа оценки скорости. Во-первых, можно использовать исторические средние показатели при их наличии. Вместе с тем, прежде чем применять исторические средние показатели, необходимо понять, не изменились ли существенно команда, характер проекта, технология и т. п. Во-вторых, можно отложить оценку скорости до тех пор, пока не будут выполнены несколько итераций. Это обычно наилучший вариант. В-третьих, можно спрогнозировать скорость путем разбивки нескольких историй на задачи и определения объема работ, подходящего для итерации. Этот процесс очень похож на планирование итерации.

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

Вопросы для обсуждения

1. В табл. 16.2 истории, оцениваемые одинаковым числом пунктов, имеют разную оценку задач в часах. Почему? (Если вам нужна подсказка, обратитесь к разделу «Соотнесение оценок задач с пунктами» в главе 14 «Планирование итерации».)

2. Составьте таблицу, подобную табл. 16.3, для вашего текущего проекта. Существует ли возможность каким-либо образом увеличить количество времени, которое каждый член группы может посвящать проекту?

Глава 17 Буферизация планов для компенсации неопределенности

Неопределенность неудобна, определенность — глупа.

Китайская поговорка

Мне нередко жалуются на то, что agile-планирование не очень хорошо работает в некоторых ситуациях. При этом обычно называют следующие условия:

• Планирование проекта осуществляется задолго до его начала.

• Проект необходимо выполнить до жестко установленного срока и реализовать жестко заданный набор функций.

• Проект передается на договорной основе из одной организации в другую.

• Требования понятны только на очень поверхностном уровне.

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

Умение составлять надежные планы в таких условиях чрезвычайно важно. Зачастую использования простого подхода, рассмотренного в предыдущих главах, недостаточно. В подобных условиях общим у всех проектов является то, что каждый из них характеризуется либо дополнительной неопределенностью, либо более серьезными последствиями в случае ошибки. Я, например, был когда-то вице-президентом по разработке программного обеспечения в компании, входящей в список Fortune 40, и календарный график для наших проектов обычно составлялся за 12–18 месяцев до их начала, когда мы верстали бюджет на следующий год. Мы, конечно, не фиксировали требования, однако должны были определять характер продукта, который будет создаваться. Несмотря на то, что представление о требованиях было расплывчатым, нам приходилось принимать обязательства первого уровня, которые позволяли составлять адекватное штатное расписание для организации. Существовала и другая неопределенность: я редко знал задолго до начала проектов, кто именно из моей команды будет над ними работать. Чаще всего исполнителей просто не было в штате.

Сравните эту ситуацию с проектом, в котором от вас требуют установить жесткий срок и взять обязательство по реализации ключевого набора функций. Нарушение сроков или поставка неполной функциональности подорвет репутацию компании в отрасли и вашу репутацию в компании. Даже если вы достаточно хорошо понимаете требования и знаете, кто войдет в состав команды (в отличие от меня в приведенном выше примере), риск допустить ошибку очень значителен.

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

Функциональный буфер

Прошлым вечером я отправился в продовольственный магазин со списком продуктов из 37 пунктов. В моем распоряжении было лишь полчаса, чтобы купить нужные продукты и вернуться домой, поскольку я хотел посмотреть баскетбольный матч, который начался в это время. Как обычно, я начал с одного конца магазина и стал продвигаться к другому. Я шел вдоль полок, а мое внимание было сконцентрировано примерно на 20 товарах, которые нам требовались больше всего. Я знал: если приду домой без молока, хлеба или нарезки из индейки, то в перерыве мне придется снова идти в магазин. Если же я забуду что-то менее важное, то моя жена смирится с этим, у моих дочек будет что поесть, а у меня — возможность спокойно посмотреть баскетбол.

Буферизация проекта с помощью функций точно такой же процесс. Клиентам говорят: «Мы реализуем все функции в этом пакете, а в идеале некоторые функции в том пакете». В agile-проекте функциональный буфер создается очень просто. Сначала клиент выбирает всю абсолютно обязательную работу. Оценки этой работы суммируются. Данная работа представляет собой минимум, который может войти в релиз. Затем клиент выбирает еще 25–40 % работ ближе к узкоспециализированному концу диапазона для проектов с более высокой неопределенностью или меньшей устойчивостью к риску невыполнения календарного графика. Оценки этих работ добавляют к первоначальной оценке и получают суммарную оценку проекта. После этого составляют план проекта как обычно, предусматривая поставку