Конус неопределенности

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

Исследователи обнаружили, что оценкам проектов на разных стадиях присущи прогнозируемые уровни неопределенности. Конус неопределенности на рис. 4.1 показывает, что оценки становятся более точными по мере продвижения работы над проектом. (В последующем объяснении для простоты рассматривается последовательная методология разработки. В конце раздела объясняется, как применить эти концепции к итеративным проектам.) Конус неопределенности 53

По горизонтальной оси отложены основные ключевые этапы проекта — исходная концепция, согласованное определение проекта, завершение постановки требований и т. д. Может показаться, что терминология ориентирована на конкретные программные продукты, но это объясняется лишь ее происхождением. Скажем, «определение продукта» просто обозначает согласованное представление о программе, или концепцию программы, и в равной степени относится к веб-службам, внутренним системам организаций и к большинству других разновидностей программных проектов.

alt="Рис. 4.1. Конус неопределенности для основных ключевых этапов проекта" />

о с

Рис. 4.1. Конус неопределенности для основных ключевых этапов проекта

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

Как видно из графика, оценки, созданные на очень ранней стадии проекта, подвержены высокой степени ошибок. Оценки, созданные на стадии исходной концепции, могут отличаться в большую или меньшую сторону до 4 раз (что также выражается в виде 0,25х, то есть 1/4). Полный диапазон от верхней оценки до нижней составляет 4х/0,25х, то есть 16х!

Руководство и клиенты часто задают вопрос: «Если дать вам еще неделю на работу над оценкой, сможете ли вы уточнить ее так, чтобы снизить степень неопределенности?» Вопрос вполне логичный, но, к сожалению, ответить на него положительно невозможно. Исследования Луиса Ларанхейра показывают, что точность оценки программного проекта зависит от степени уточнения определения программы (Laranjeira 1990). Чем точнее определение, тем точнее оценка. Оценка изменчива, прежде всего, потому, что неопределенность заложена в самом проекте. Единственным способом сокращения неопределенности в оценке является сокращение ее в проекте.

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

В действительности все ключевые точки группируются в начальной части графика проекта. После перерисовки в календарном представлении конус принимает вид, показанный на рис. 4.2.

Неопределенность в оценке проекта (объем работы, затраты, функциональность)

Как видно из этого рисунка, точность оценки быстро возрастает в течение первых 30 % проекта и улучшается с ±4х до ±1,25х.

Можно ли победить конус неопределенности?

Говоря о конусе неопределенности, необходимо учитывать одну важную (и сложную) концепцию: конус неопределенности представляет лучшую точность, которая может быть обеспечена в различных ключевых точках проекта. Конус представляет

Конус неопределенности 55

ошибку оценки, разработанную опытными специалистами. Результат вполне может оказаться pi хуже. Получить более точную оценку невозможно; разве что вам может больше повезти.

СОВЕТ № 11

Проанализируйте воздействие конуса неопределенности на точность вашей оценки. Ваша оценка не может быть более точной, чем это возможно на текущей позиции проекта внутри конуса.

Конус не сужается автоматически

Мы говорим о конусе неопределенности как о наилучшей оценке еще и потому, что при недостаточно хорошем управлении проектом (или недостаточной компетентности оценщиков) ожидаемого уточнения оценки может и не быть. На рис. 4.3 показано, что происходит, когда управление проектом не направлено на снижение неопределенности — последняя принимает вид не конуса, а облака, которое не рассеивается до самого конца проекта. Проблема даже не в том, что оценки не сходятся — не сходится сам проект (то есть неопределенность не вытесняется в степени, необходимой для поддержки более точных оценок).

Неопределенность в оценке проекта (объем работы, затраты, функциональность)

Время

Рис. 4.3. При недостаточно качественной оценке или управлении проектом возникает «облако неопределенности», представляющее еще большую ошибку оценки по сравнению с той, что заложена в конусе

Конус сужается только при принятии решений, направленных на устранение неопределенности.

СОВЕТ № 12

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

4х

2х

1,5х

Неопределенность ^ 25х в оценке проекта (объем работы,              1,0х

затраты,              0,8х

функциональность) Q 67х

0,5х

0,25х

Время

Рис. 4.4. Конус неопределенности не сужается сам по себе. Вы заставляете его сужаться, принимая решения, которые способствуют устранению источников неопределенности из проекта. Одни решения определяют, что должно быть реализовано в проекте; другие — чего в нем быть не должно. Последующее изменение решений приведет к расширению конуса

Учет конуса неопределенности в оценках программных проектов

Анализ оценок программных проектов показал, что специалисты, начинающие с точечных оценок и определяющие диапазоны на их основании, обычно не корректируют минимальное и максимальное значение с учетом неопределенности в оценке, особенно в ситуациях высокой неопределенности (Jorgensen 2002). Тенденция к использованию зауженных диапазонов преодолевается двумя способами. Во-первых, можно начать с «наиболее вероятной» оценки, а затем вычислить диапазоны с использованием заранее определенных множителей, как показано в табл. 4.1.

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

СОВЕТ № 13

Учитывайте наличие конуса неопределенности, закладывая в своих оценках заранее определенную амплитуду неопределенности.

Источник: По материалам «Software Estimation with Сосото II» (Boehm et al. 2000).

Второй способ основан на отделении «оценки того, что мы знаем» от «оценки неопределенности». Один специалист дает оценки наилучшего и наихудшего случая (то есть концов диапазона), а другой оценивает вероятность того, что фактический результат войдет в этот диапазон (Jorgensen 2002).

СОВЕТ № 14

Учитывайте наличие конуса неопределенности, разделяя оценку на две составляющие: один специалист дает количественную оценку, а другой оценивает ее неопределенность.

Связь между конусом неопределенности и обязательствами

Организации, занимающиеся разработкой программного обеспечения, нередко сами способствуют срыву собственных проектов, принимая обязательства в слишком ранней точке конуса неопределенности. Если обязательства принимаются во время разработки исходной концепции или определения продукта, в них закладывается ошибка от 2х до 4х. Как обсуждалось в главе 1, опытный руководитель проекта способен довести проект до завершения, если оценка отклоняется от действительности не более чем на 20 %. Однако ни одному руководителю не удастся успешно завершить проект, если оценка смещена на несколько сотен процентов.

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

Конус неопределенности и итеративная разработка

Учесть воздействие конуса неопределенности в итеративных проектах несколько сложнее, чем при традиционном последовательном подходе.

Если вы работаете над проектом, который на каждой итерации проходит полный цикл разработки (то есть от постановки требований до выхода готовой версии), то на каждой итерации возникает свой миниатюрный конус неопределенности.

Перед постановкой требований для текущей итерации проект находится в точке согласованного определения продукта и подвержен 4-кратной амплитуде неопределенности в оценках. При коротких итерациях (меньше месяца) переход от согласованного определения проекта к фазам определения требований и завершения проектирования пользовательского интерфейса происходит за несколько дней, а неопределенность снижается с 4х до 1,6х. При фиксированном графике неопределенность 1,6х будет относиться к функциональности, готовой в отведенное время, а не к объему работ или срокам. Некоторые преимущества в оценке, возникающие при использовании коротких итераций, обсуждаются в разделе 8.4.

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

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

Многие группы разработчиков выбирают промежуточные методики, когда большинство требований определяется в начальной стадии работы над проектом, а проектирование, конструирование, тестирование и выпуск производятся короткими итерациями. Другими словами, проект движется последовательно от точки завершения проектирования пользовательского интерфейса (около 30 % календарного времени проекта), а затем переходит на более итеративный путь. Неопределенность, обусловленная воздействием конуса, снижается до ±25 %; это позволяет добиться поставленных целей при качественном управлении проектом, не утрачивая основных преимуществ итеративной разработки. Рабочие группы могут оставить часть запланированного времени на требования, которые еще предстоит определить, в конце проекта. В функциональность проекта вводится небольшая неопределенность, которая в данном случае играет скорее положительную роль — ведь данная возможность используется только в том случае, если в ходе работы над проектом будут выявлены новые желательные возможности. Промежуточный подход обеспечивает долгосрочную прогнозируемость затрат и сроков в сочетании с умеренной гибкостью в требованиях.