Использование альтернативных оценок

Область применения методов этой главы

Альтернативные оценки

Что оценивается Размер проекта Стадия разработки

Итеративный или последовательный стиль Возможная точность

Размер, объем р^бот, сроки, функциональность М С Б

Ранняя-поздняя

Оба

Высокая

Идеального метода опенки не существует, поэтому применение нескольких альтернативных методов приносит пользу во многих ситуациях.

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

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

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

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

Глава              Оценка              №              1.

              оценка «по интуиции»              оценка с декомпозицией

Предисловие              —              4

Введение              —              5

Модели              —              11

Предварительные условия —              52

Послесловие              —              20

Обзор тем              —              20

ИТОГО              250-300              802

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

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

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

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

Третья оценка в 759 страниц менее чем на 5 % отличалась от второй оценки (802 страницы).

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

СОВЕТ № 66 />Используйте несколько альтернативных методов оценки и проанализируйте совпадения или расхождения результатов.

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

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

о              планируемых сроках и обязательствах, которые я ца себя принимал.

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

Как только я принял схождение моих оценок, внезапно стало очевидно, что этот размер подтверждается и другими данными. Одна из моих глав-прототипов занимала 72 страницы.

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

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

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

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

СОВЕТ № 67

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

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

125-

100 -

75-

50-

25-

0-

0

12

14

4              6              8              10

Срок (месяцы)

Рис. 15.1. Пример альтернативных оценок в программном проекте

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

СОВЕТ № 68

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

Дополнительные ресурсы

Tockey, Steve. «Return on Software». MA: Addison-Wesley, 2005. В главе 22 книги Токи обсуждаются оценки с применением альтернативных методов. Глава 23 посвящена учету неточности в оценках, а главы 24-25 — особенностям принятия решений в условиях риска и неопределенности (j0rgensen 2002).