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

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

Наиболее распространенными являются функциональные и временны́е буферы. Функциональный буфер создается, когда требования к продукту приоритизированы и признано, что реализовать можно не все функции. В DSDM-процессе, например, рекомендуется считать 30 % работ опциональными, создающими функциональный буфер для проекта. Когда время истекает, календарный график все равно можно выдержать, отказываясь от реализации элементов функционального буфера.

Временной буфер, в свою очередь, создается путем включения в календарный график дополнительного времени с учетом неопределенности, присущей размеру команды. Функциональный буфер можно сконструировать на основе присвоения каждой пользовательской истории двух оценок — с 50 %-ной и 90 %-ной вероятностью. Формула «извлечение квадратного корня из суммы квадратов» позволяет найти подходящий размер временнóго буфера.

Проект следует защищать от неопределенности функций с помощью функционального буфера и от неопределенности календарного графика с помощью временнóго буфера. Функциональный буфер можно комбинировать с временны́м буфером. Обычно это дает хороший результат, поскольку позволяет уменьшить размер обоих буферов.

1. Дает ли затрата дополнительных усилий на расчет временнóго буфера какие-либо выгоды в условиях вашей организации?

2. Предусмотрены ли в вашем текущем проекте буферы для компенсации какого-либо типа неопределенности? Если да, то какие? Если нет, то какие типы буферов были бы наиболее полезными?

3. Есть ли признаки проявления закона Паркинсона или синдрома студента в вашей организации? Что еще, помимо предложений, представленных в этой главе, вы можете предпринять для снижения влияния этого закона и синдрома?

Нередко говорят, что agile-команды состоят не более чем из 7–10 разработчиков. Команды такого размера могут выполнить довольно большой объем работы, особенно при использовании agile-процесса, который открывает возможности для повышения производительности и поощряет ее повышение. Вместе с тем встречаются проекты, к которым хотелось бы привлечь более крупную команду. В таких случаях вместо создания команды из 100 человек agile-подход предполагает создание нескольких небольших команд. В agile-проекте может участвовать десяток небольших команд вместо одной огромной команды из 100 человек.

В этой главе мы возьмем то, что узнали в предыдущих главах, и применим к задаче планирования проекта, в котором участвуют несколько команд. Для планирования крупного проекта с участием нескольких команд необходимо:

1. Принять общую базу для оценок.

2. Быстрее добавлять детали в пользовательские истории.

3. Выполнять опережающую разработку планов.

4. Включать в план поддерживающие буферы.

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

Хотя было бы хорошо предоставить каждой команде возможность по своему усмотрению выбирать, в чем проводить оценку — в пунктах или идеальных днях, в большинстве случаев проекты с участием нескольких команд выигрывают от оценки в одних и тех же единицах и установления их базового смысла. Представьте, как трудно было бы предсказывать, сколько еще времени потребуется для реализации набора пользовательских историй, если бы одна их часть оценивалась в идеальных днях, а другая — в пунктах. Хуже того, представьте, насколько все усложнилось бы, если бы одна команда оценила набор историй в 20 пунктов, а другая — в 100 пунктов.