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

Я впервые столкнулся с этой концепцией при создании оценки для первого издания своей книги «Code Complete» (McConnell 1993). Около двух лет было потрачено на сбор материала для книги, написание прототипов глав и прочую подготовку. В эти два года мне казалось, что книга будет занимать от 250 до 300 страниц. Идея не была подкреплена никакими аналитическими выкладками — просто представления, засевшие у меня в голове.

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

книги в плане и оценил каждую секцию по отдельности. В табл. 15.1 показан примерный вид полученных данных.

Таблица 15.1. Оценки количества страниц в черновом варианте «Code Complete», полученные субъективным суждением и методом декомпозиции

Фактически до этого момента я использовал два метода оценки: собственную интуицию, подсказывавшую диапазон от 250 до 300 страниц, и экспертную оценку с декомпозицией, которая вела к оценке в 802 страницы. Между двумя оценками существовало значительное расхождение, и я должен был понять, почему они так сильно отличаются.

Я был привязан к своим 250-страничным представлениям о длине книги и подумал: «Оценка в 802 страницы не может быть правильной. Наверняка я где-то ошибся». Я решил оценить книгу еще раз и получить «правильный» ответ.

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

1,64 страницы. Далее я перебрал все пункты примерной структуры всей книги, просуммировал пункты и умножил сумму на 1,64. В табл. 15.2 показана оценка, полученная этим способом.

Таблица 15.2. Оценка количества страниц в черновом варианте «Code Complete» с использованием примерной структуры и исторических данных

Третья оценка в 759 страниц менее чем на 5 % отличалась от второй оценки (802 страницы). Из-за близости оценок я четко уяснил, что моя книга займет не 250-300 страниц, как думал в течение двух лет, а от 750 до 800 страниц.

Мой опыт был типичным проявлением более общего принципа: объединение результатов, полученных разными оценщиками (или с применением разных методов), повышает точность оценки (Jorgensen 2002, Tockey 2004).

СОВЕТ № 66 -.

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

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

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

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

Как только я принял схождение моих оценок, внезапно стало очевидно, что этот размер подтверждается и другими данными. Одна из моих глав-прототипов занимала 72 страницы. В 250-страничной книге это составило бы 29 % общего объема. Тем не менее после завершения этой главы у меня pi в мыслях не было, что проект готов на 29 %. На интуитивном уровне я знал, что глава составляет не более 10 % книги. Когда две сходящиеся оценки открыли мне глаза, я понял, что длина прототипа подтверждает общую длину книги в диапазоне 750-800 страниц.

Наиболее точная оценка обычно формируется по данным, специфическим для конкретного проекта. В итоге у меня получилась рукопись из 749 страниц; ее объем всего на 10 страниц (1 %) отличался от оценки, полученной с использованием исторических данных того же проекта.

Исходная интуитивная оценка была основана на чтении других книг из диапазона 250-300 страниц. До этого я книг не писал и поэтому наивно предположил, что если написать 250-300 страниц текста, то получится книга из 250-300 страниц. Однако количество страниц в издаваемой книге увеличивается из-за пустых.

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

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

СОВЕТ № 67.

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

Позднее меня попросили провести оценку программного проекта для одного из моих клиентов. На рис. 15.1 крестиками отмечены отдельные оценки, созданные мной для этого проекта. Размер крестика представляет мою уверенность в каждой оценке. Треугольником обозначена «самая точная оценка» в 75 человеко-месяцев и 12 календарных месяцев. Хотя в расположении крестиков существует некоторый разброс, все оценки, в которых я был уверен, отличались от «самой точной оценки» в пределах 5 %. Квадрат изображает деловую цель моего клиента — 25 человеко-месяцев при 5 календарных месяцах.

В этом конкретном случае клиент решил действовать, руководствуясь деловой целью в 5 календарных месяцев и 25 человеко-месяцев. Решение оказалось неудачным. В конечном счете проект был выдан через 14 календарных месяцев при 80 человеко-месяцах работы, причем группа реализовала гораздо меньше функциональности, чем планировалось первоначально.

СОВЕТ № 68 -.

Если деловая цель противоречит нескольким сходящимся оценкам, лучше доверьтесь оценкам.