Резюме
Большинство проектов отличаются очень высокой неопределенностью. Эта неопределенность зачастую не полностью отражается в календарном графике и в сроках, устанавливаемых проектной командой. Иногда неопределенность настолько высока или значительна, что при оценке продолжительности проекта для ее учета необходимо принимать дополнительные меры. Это особенно характерно для случаев, когда проект планируют задолго до начала работ, когда нужно уложиться точно в срок, реализовав относительно жесткий набор функций, когда проект передается сторонней организации, когда требования определены лишь поверхностно или когда неправильное определение срока влечет за собой значительные последствия (финансовые или иные).
Наиболее распространенными являются функциональные и временны́е буферы. Функциональный буфер создается, когда требования к продукту приоритизированы и признано, что реализовать можно не все функции. В DSDM-процессе, например, рекомендуется считать 30 % работ опциональными, создающими функциональный буфер для проекта. Когда время истекает, календарный график все равно можно выдержать, отказываясь от реализации элементов функционального буфера.
Временной буфер, в свою очередь, создается путем включения в календарный график дополнительного времени с учетом неопределенности, присущей размеру команды. Функциональный буфер можно сконструировать на основе присвоения каждой пользовательской истории двух оценок — с 50 %-ной и 90 %-ной вероятностью. Формула «извлечение квадратного корня из суммы квадратов» позволяет найти подходящий размер временнóго буфера.
Проект следует защищать от неопределенности функций с помощью функционального буфера и от неопределенности календарного графика с помощью временнóго буфера. Функциональный буфер можно комбинировать с временны́м буфером. Обычно это дает хороший результат, поскольку позволяет уменьшить размер обоих буферов.
Вопросы для обсуждения
1. Дает ли затрата дополнительных усилий на расчет временнóго буфера какие-либо выгоды в условиях вашей организации?
2. Предусмотрены ли в вашем текущем проекте буферы для компенсации какого-либо типа неопределенности? Если да, то какие? Если нет, то какие типы буферов были бы наиболее полезными?
3. Есть ли признаки проявления закона Паркинсона или синдрома студента в вашей организации? Что еще, помимо предложений, представленных в этой главе, вы можете предпринять для снижения влияния этого закона и синдрома?
Глава 18
Планирование проекта с участием нескольких команд
Занимайтесь планированием, а о планах забудьте.
Мэри Поппендик
Нередко говорят, что agile-команды состоят не более чем из 7–10 разработчиков. Команды такого размера могут выполнить довольно большой объем работы, особенно при использовании agile-процесса, который открывает возможности для повышения производительности и поощряет ее повышение. Вместе с тем встречаются проекты, к которым хотелось бы привлечь более крупную команду. В таких случаях вместо создания команды из 100 человек agile-подход предполагает создание нескольких небольших команд. В agile-проекте может участвовать десяток небольших команд вместо одной огромной команды из 100 человек.
В этой главе мы возьмем то, что узнали в предыдущих главах, и применим к задаче планирования проекта, в котором участвуют несколько команд. Для планирования крупного проекта с участием нескольких команд необходимо:
1. Принять общую базу для оценок.
2. Быстрее добавлять детали в пользовательские истории.
3. Выполнять опережающую разработку планов.
4. Включать в план поддерживающие буферы.
При осуществлении проекта может потребоваться применение некоторых или всех этих приемов в зависимости от количества участвующих команд, а также от того, насколько часто и интенсивно им придется координировать свою деятельность. Как правило, я рекомендую командам использовать столько дополнительных приемов, сколько необходимо, начиная с установления общей базы и т. д., вплоть до создания поддерживающих буферов.
Принятие общей базы для оценок
Хотя было бы хорошо предоставить каждой команде возможность по своему усмотрению выбирать, в чем проводить оценку — в пунктах или идеальных днях, в большинстве случаев проекты с участием нескольких команд выигрывают от оценки в одних и тех же единицах и установления их базового смысла. Представьте, как трудно было бы предсказывать, сколько еще времени потребуется для реализации набора пользовательских историй, если бы одна их часть оценивалась в идеальных днях, а другая — в пунктах. Хуже того, представьте, насколько все усложнилось бы, если бы одна команда оценила набор историй в 20 пунктов, а другая — в 100 пунктов.
В начале проекта команды должны встретиться и определить, что они будут использовать, пункты или идеальные дни. Затем им нужно установить общую базу для оценок с тем, чтобы оценка одной команды была идентична оценке другой команды, если бы эта работа попала к ней. Каждая пользовательская история оценивается только одной командой, но оценки должны быть эквивалентными, независимо от того, какая команда оценивает работу.
Существует два способа определения общей базы. Один из них эффективен, только если команды работали вместе в предыдущем проекте. В этом случае они могут выбрать несколько пользовательских историй из прошлого проекта и принять их оценки за ориентир. Допустим, команды используют для оценки идеальные дни, тогда им нужно выбрать пару-тройку историй, каждая из которых оценивается в один идеальный день. Затем нужно найти несколько историй, которые оцениваются в два идеальных дня, и т. д. Таким образом надо подобрать порядка двух десятков старых историй и договориться о новой оценке каждой из них. После согласования таких базовых историй команды могут самостоятельно оценивать другие истории, сравнивая их с базовыми (т. е. выполняя оценку по аналогии).
Второй подход похож на первый, однако предполагает коллективную оценку разнообразных новых пользовательских историй. При этом выбирают различные истории, которые планируется включить в новый релиз. Эти истории должны иметь разные размеры и относиться к таким областям системы, с которыми их связывают большинство оценщиков. Либо вся большая команда, либо представители каждой из небольших команд, когда команда в целом слишком велика, собираются и согласуют оценки этих историй. Как и в первом случае, эти оценки затем становятся базовыми и используются для сравнительной оценки будущих историй.
Отдельные команды могут рассматривать оценку в разных единицах без общей базы, только если создаваемые продукты реально не связаны друг с другом и абсолютно исключена возможность перехода разработчиков из одной команды в другую. Так или иначе, даже в такой ситуации я рекомендую устанавливать общую базу, поскольку это упрощает обмен информацией по проекту.
