Оценка программного обеспечения сопряжена с проблемами, потому что сам процесс оценки сопряжен с проблемами. В 1995 году строительство нового бейсбольного стадиона в Сиэттле было оценено в 250 миллионов долларов. Стадион был построен в 1999 году за 517 миллионов долларов — ошибка оценки составила более 100 % (Withers 1999). Самым выдающимся случаем превышения затрат за последнее время, вероятно, был проект строительства скоростного шоссе в Бостоне. Затраты, изначально оцениваемые в 2,6 миллиарда долларов, в конечном счете превысили 15 миллиардов — ошибка оценки составила более 400 % (Associated Press 2003).

Конечно, в мире программного обеспечения найдутся свои выдающиеся примеры. Ирландская система PPARC (Personnel, Payroll and Related Systems) была отменена после того, как она превысила свой бюджет в 8,8 миллиона евро на 140 миллионов евро (The Irish Times 2005)! Проект ФБР VCF (Virtual Case File) был свернут в марте 2005 года; при вложениях в 170 миллионов долларов была реализована всего 1/10 запланированных возможностей (Arnone 2005). Подрядчик жаловался, что ФБР сменило 5 руководителей информационной службы и 10 руководителей проектов, не говоря уже о 36 изменениях контракта (Knorr 2005).

4.1. Источники неопределенности в оценках 51.

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

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

Ошибки, закрадывающиеся в оценки, идут из четырех общих источников.

• Неточная информация об оцениваемом проекте.

• Неточная информация о возможностях организации, которой будет поручено исполнение проекта.

• Чрезмерное усердие, направленное на получение точной оценки (то есть попытки оценивать изменяющиеся цели).

• Неточности, обусловленные самим процессом оценки.

В этой главе подробно рассматривается каждый источник ошибок оценки.

4.1. Источники неопределенности в оценках.

Сколько стоит построить новый дом? Это зависит от дома. Сколько будет стоить веб-сайт? Это зависит от сайта. Пока все специфические особенности не будут понятны во всех подробностях, невозможно точно оценить стоимость программного проекта. Нельзя оценить объем работы, необходимый для построения чего-то нового, пока это «что-то» еще не было определено.

Разработка программного обеспечения представляет собой процесс постепенного уточнения. Вы начинаете с общей концепции продукта (своих представлений о программе, которую собираетесь построить) и уточняете ее, руководствуясь целями продукта и проекта. Иногда требуется определить бюджет и сроки, необходимые для реализации заданного объема функциональности. В других случаях нужно понять, сколько функциональности удастся реализовать в заранее определенный срок при фиксированном бюджете. Многие проекты существуют в условиях «золотой середины», то есть некоторой гибкости в выборе бюджета, срока и функциональности. В таких ситуациях различные пути, по которым может пойти программа, порождают сильно различающиеся комбинации затрат, сроков и функциональности.

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

• Желает ли клиент, чтобы введенный телефонный номер проверялся на действительность?.

• Если клиент хочет иметь систему проверки телефонных номеров, какую версию он предпочтет — дешевую или дорогую? (Обычно каждая конкретная функция существуют в нескольких версиях, рассчитанных на 2 часа, 2 дня или 2 недели — например, только для внутренних телефонных номеров США или для международных номеров).

• Если реализовать дешевую версию проверки телефонных номеров, не захочет ли клиент позднее переключиться на дорогую?.

• Нельзя ли воспользоваться готовой системой проверки телефонных номеров или вследствие каких-то проектных ограничений необходимо разработать свою собственную?.

• Как будет спроектирована система проверки? (Обычно разные проектные версии одной функции различаются по сложности как минимум на порядок.).

• Сколько времени потребуется на программирование системы проверки телефонных номеров? (Время, необходимое разным разработчикам на программирование одной возможности, также может различаться на порядок и более.).

• Должна ли система проверки телефонных номеров взаимодействовать с системой проверки адресов? Сколько времени потребуется на интеграцию двух систем?.

• Каким должен быть уровень качества системы проверки телефонных номеров? (В зависимости от уровня принятых мер предосторожности количество дефектов в исходной реализации может различаться на порядок.).

• Сколько времени потребуется на отладку и исправление ошибок в реализации системы проверки телефонных номеров? (Эффективность отладки и исправления одних и тех же ошибок программистами одного уровня может различаться на порядок.).

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.2. Конус неопределенности в календарном представлении.

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

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

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

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

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

СОВЕТ № 11 -.

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

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

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

Время.

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

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

СОВЕТ № 12 -.

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

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

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

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

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

СОВЕТ № 13 -.

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

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

Таблица 4.1. Ошибка оценки в ключевых точках работы над проектом

Источник: По материалам «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 %; это позволяет добиться поставленных целей при качественном управлении проектом, не утрачивая основных преимуществ итеративной разработки. Рабочие группы могут оставить часть запланированного времени на требования, которые еще предстоит определить, в конце проекта. В функциональность проекта вводится небольшая неопределенность, которая в данном случае играет скорее положительную роль — ведь данная возможность используется только в том случае, если в ходе работы над проектом будут выявлены новые желательные возможности. Промежуточный подход обеспечивает долгосрочную прогнозируемость затрат и сроков в сочетании с умеренной гибкостью в требованиях.

4.3. Хаотические процессы разработки.

Конус представляет неопределенность, присущую даже в хорошо управляемых проектах. Плохое управление проектом создает дополнительную неопределенность — «факторы хаоса», которых можно было бы избежать.

Типичные примеры хаотических факторов:.

• поверхностный анализ исходных требований;.

• отсутствие участия конечного пользователя в постановке требований;.

4.4. Нестабильные требования 59.

• плохое проектирование, порождающее многочисленные ошибки в программном коде;.

• плохая методология программирования, требующая продолжительного исправления ошибок;.

• недостаточная квалификация персонала;.

• неполное или неумелое планирование проекта;.

• присутствие «звезд» в группах;.

• отказ от планирования из-за давления;.

• отсутствие автоматизированной системы контроля исходных кодов.

Я привел лишь частичный список возможных хаотических факторов. За более полной информацией обращайтесь к главе 3 моей книги «Rapid Development» (McConnell 1996) и к статье по адресу

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

СОВЕТ № 15 -.

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

4.4. Нестабильные требования.

Изменения в требованиях часто называют среди стандартных источников неопределенности при оценке (Lederer and Prasad 192, Jones 1994, Stutzke 2005). Кроме всех типичных проблем общего плана, нестабильные требования создают две специфические проблемы.

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

Во-вторых, изменения в требованиях часто не отслеживаются, а проект не подвергается переоценке, как это должно быть. В хорошо управляемом проекте исходный набор требований принимается за точку отсчета, на основании которой оцениваются затраты и сроки. По мере добавления новых или пересмотра старых требований оценки затрат и стоимости также должны пересматриваться с учетом этих изменений. На практике руководители проектов часто пренебрегают обновлением оценок стоимости и затрат при изменении требований. Возникает парадоксальная ситуация: оценка исходной функциональности могла быть правильной, но после того, как проект был расширен десятками новых требований (согласованных, но не учтенных), у него не остается ни малейшего шанса выдержать исходную оценку. Все согласны, что добавленные возможности были полезными, — а проект становится опоздавшим.

Конечно, описанные в книге методы помогут улучшить оценку в условиях высокой изменчивости требований, однако совершенствование оценки само по себе не решит проблем, возникающих из-за нестабильных требований. Эффективные меры должны приниматься на уровне управления проектом, нежели на уровне оценок. Если рабочая ситуация не позволяет стабилизировать требования, подумайте о применении альтернативных подходов, предназначенных для сред с высокой изменчивостью, — коротких итераций, экстремального программирования, Scrum, DSDM (Dynamic System Development Method ) и т. д.

СОВЕТ № 16 -.

В условиях нестабильных требований следует ориентироваться на стратегии управления проектом вместо стратегий оценки (или совместно с ними).

Оценка роста требований.

Если потребуется оценить влияние нестабильности требований, один из возможных путей заключается в простом включении допуска на рост и/или изменения требований в оценки. На рис. 4.5 показан видоизмененный конус неопределенности, учитывающий приблизительно 50%-*й рост требований в ходе работы над проектом. (Рисунок приведен только для наглядности. Конкретные точки данных не поддерживаются данными тех исследований, что и точки исходного конуса.)

Рис 4.5. Конус неопределенности с поддержкой изменения требований в ходе проекта.

4.5. Пропущенные операции 61.

в свои оценки возможность 40 % роста требований (NASA SEL 1990). Аналогичная концепция присутствует в модели оценки Cocomo II (Boehm et al. 2000).

4.5. Пропущенные операции.

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

Одним из самых распространенных источников ошибок оценки — необходимые задачи, которые не были включены в оценку проекта (Lederer and Prasad 1992, Coombs 2003). Аналитики обнаружили, что это явление проявляется как на уровне планирования проектов, так и на уровне отдельных разработчиков. В одном из исследований обнаружилось, что разработчики обычно довольно точно оценивают ту работу, которую ясно представляют себе, но при этом забывают от 20 до 30 % необходимых задач, что приводит к 20-30%-й ошибке в оценке (van Genuchten 1991).

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

В табл. 4.2 перечислены требования, часто не учитываемые при оценке проекта.

Таблица 4.2. Функциональные и нефункциональные требования, часто не учитываемые при оценке проекта

СОВЕТ № 17 -.

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

В табл. 4.3 перечислены факторы, относящиеся к разработке программного обеспечения, о которых часто забывают при составлении оценки.

Таблица 4.3. Действия по разработке программного обеспечения, часто не учитываемые при оценке проекта.

«Время разгона» для новых участников группы.

Обучение новых участников группы.

Координация управления/встречи руководства.

Развертывание.

Преобразование данных.

Установка.

Настройка.

Прояснение требований.

Сопровождение системы управления пересмотром проектных решений (Revision Control System).

Поддержка сборки.

Сопровождение сценариев, необходимых для выполнения ежедневной сборки.

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

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

Создание тестовых данных Управление программой бета-тестирования Участие в техническом рецензировании Работа по интеграции.

Обработка запросов на внесение изменений.

Присутствие на собраниях, посвященных управлению изменениями/назначению приоритетов.

Координация с субподрядчиками.

Техническая поддержка существующих систем.

Работа по сопровождению предшествующих систем во время проекта.

Работа по исправлению дефектов.

Настройка производительности.

Изучение нового инструментария.

Административная работа, связанная с отслеживанием дефектов.

Координация с тестовой группой (для разработчиков).

Координация с разработчиками (для тестовой группы).

Ответ на вопросы группы контроля качества.

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

Рецензирование технической документации.

Демонстрация программы клиентам или пользователям.

Демонстрация программы на выставках.

Демонстрация программы или прототипа высшему руководству, клиентам и пользователям.

Общение с клиентами и конечными пользователями; поддержка установки бета-версий на оборудовании клиента.

Рецензирование планов, оценок, архитектуры, детальных проектов, поэтапных планов, кода, тестовых случаев и т. д.

СОВЕТ № 18 -.

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

В табл. 4.4 перечислены факторы, не относящиеся к разработке программного обеспечения, но также часто не учитываемые при составлении оценки.

Таблица 4.4. Факторы, не связанные с разработкой программного обеспечения, часто не учитываемые при оценке проекта

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

СОВЕТ № 19 -.

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

Кроме использования этих таблиц для идентификации частей программного продукта или операций, которые должны быть включены в оценку, также стоит рассмотреть возможность применения методики WBS (Work Breakdown Structure) для всех стандартных факторов, учитываемых в оценке. В разделе 10.3 обсуждается оценка с применением WBS и рассматривается обобщенный пример WBS.

4.6. Необоснованный оптимизм.

Оптимизм атакует программные проекты из всех источников. Что касается оценки проекта со стороны разработчиков, вице-президент Microsoft Крис Питерс (Chris Peters) заметил: «Никогда не следует опасаться того, что оценка, созданная разработчиком, окажется излишне пессимистичной, потому что разработчики всегда назначают слишком оптимистичные сроки» (Cusumano and Selby 1995). Изучив 300 программных проектов, Майкл ван Генахтен заметил, что в оценках разработчиков обычно закладывается допуск на оптимизм, составляющий от 20 до 30 % (van Genuchten 1991). Хотя руководители иногда жалуются на обратное, разработчики не склонны к завышению при оценках проектов — наоборот, их оценки обычно оказываются заниженными!.

СОВЕТ № 20 -.

Не уменьшайте оценки, полученные от разработчиков, — скорее всего, они и без того излишне оптимистичны.

Оптимизм также проявляется и в высшем звене. При изучении 100 оценок проектов Министерства обороны США обнаружился устойчивый «коэффициент фантазии», равный примерно 1,33 (Boehm 1981). Возможно, руководители проектов и начальство и не предполагают, что проекты могут быть сделаны на 30 % быстрее или дешевле, чем в действительности, но они хотят, чтобы это произошло. Это само по себе является проявлением оптимизма.

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

• Над этим проектом мы будем работать более эффективно, чем над предыдущим проектом.

• В последнем проекте все шло наперекосяк. В этом проекте проблем будет меньше.

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

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

4.7. Субъективность и пристрастие.

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

Что касается пристрастия, когда клиенты и руководство обнаруживают, что оценка не соответствует деловой цели, иногда они пытаются оказать больше давления на оценку, на проект и на группу. Избыточное давление, направленное на сокращение сроков работ, встречается в 75-100 %. крупных проектов (Jones 1994).

Что касается субъективности, при рассмотрении различных методик оценки мы от природы склонны полагать: чем больше у нас «регуляторов», то есть мест для подгонки оценки под наш конкретный проект, тем точнее будет оценка.

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

Я встречал один из примеров такого рода, когда учил несколько сотен специалистов использовать модель оценки Cocomo II. Модель включает 17 множителей и 5 масштабных коэффициентов. Чтобы создать оценку Cocomo И, оценщик должен решить, какая регулировка необходима для каждого из этих 22 факторов. Факторы определяют квалификацию группы (выше или ниже среднего), относительную сложность программы (выше или ниже средней) и т. д. Теоретически эти 22 «регулятора» должны обеспечивать тонкую подстройку практически любой оценки. Похоже, на практике они лишь открывают 22 пути для проникновения ошибок в оценку.

На рис. 4.6 показаны диапазоны результатов примерно 100 групп оценщиков, определявших 17 множителей Cocomo II для одной и той же проблемы оценки.

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

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

Если бы методика оценки давала последовательный результат, мы бы увидели тесную группировку результатов вдоль горизонтальной синей линии (средняя оценка). Но как видите, разброс между оценками огромен. Наибольшая оценка превышала наименьшую в 4 раза! Среднее отклонение верхней группы от нижней в рамках одного сеанса было равно 1,7.

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

Напротив, на рис. 4.7 показан диапазон результатов оценки для методики, включающей единственную возможность введения субъективного мнения в оценку, то есть обладающей одним «регулятором» (в данном случае этот регулятор никак не связан с множителями модели Cocomo II).

Вывод «больше регулирующих факторов — не значит лучше» выходит за рамки оценки программных проектов. По выражению эксперта по прогнозированию Дж. Скотта Армстронга (J. Scott Armstrong), «один из самых неизменных и полезных выводов из исследований в области прогнозирования состоит в том, что простые методы в общем случае не уступают в точности сложным методам» (Armstrong 2001).

3 Зак. 893

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

СОВЕТ № 21.

Избегайте включения «регуляторов» в свои оценки. Хотя может показаться, будто регуляторы улучшают точность, на самом деле они вводят в оценку субъективность и снижают реальную точность.

4.8. Импровизированные оценки.

Рабочие группы иногда попадают в ловушку импровизированных оценок. Допустим, ваш начальник спрашивает: «Сколько времени потребуется для реализации предварительного просмотра на веб-сайте Gigacorp?» Вы отвечаете: «Не знаю. Наверное, около недели. Надо подумать». Вы идете к своему столу, анализируете архитектуру и код той программы, о которой спрашивал начальник, замечаете несколько обстоятельств, о которых забыли раньше, подводите итог и решаете, что потребуется около пяти недель. Вы торопитесь зайти в кабинет начальника, чтобы обновить свою первую оценку, но начальник на собрании. На следующий день вы встречаетесь с ним, но не успеваете и рта открыть, как он говорит: «Кажется, проект небольшой, так что я сходу предложил одобрить функцию предварительного просмотра на бюджетном совещании. Комитет по бюджету заинтересовался и хочет увидеть готовый результат на следующей неделе. Вы можете приступить немедленно?».

Я обнаружил, что самая безопасная политика — не давать импровизированных оценок. Ледерер и Прасад выяснили, что интуиция и догадки при оценке программных проектов коррелируются с превышениями затрат и сроков (Lederer and Prasad 1992). Я собрал данные импровизированных оценок по 24 группам. На рис. 4.8 показаны средние ошибки импровизированной оценки в этих 24 группах в сравнении с оценками, прошедшими процесс обсуждения в группах.

Рис. 4.8. Средняя ошибка импровизированных оценок в сравнении с рассмотренными оценками.

Средняя импровизированная оценка обладала средней величиной относительной ошибки 67 %, тогда как у средней рассмотренной оценки ошибка составляла всего 30 % — менее половины. (Пример взят не из области оценок программного обеспечения, поэтому ошибки в процентах не следует применять буквально к оценкам программных проектов.).

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

Хотя Ледерер и Прасад обнаружили, что догадки и интуиция положительно коррелируются с превышением оценок, также выяснилось, что использование «документированных фактов» отрицательно коррелируется с превышением оценок. Другими словами, существует огромная разница между импровизацией и ответом: «Не могу сказать сразу — я должен подойти к столу и проверить кое-какие заметки. Я подойду через 15 минут, если вы не против».

Это может показаться тривиальным, однако импровизированные оценки составляют одну из самых частых причин ошибок, допускаемых при работе над проектами (Lederer and Prasad 1992, Jergensen 1997, Kitchenham et al. 2002). Отказ от импровизированных оценок — один из самых важных моментов в книге.

СОВЕТ № 22 -.

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

Что делать, если начальник звонит вам по сотовому телефону и требует оценку немедленно? Вспомните свой результат в тесте из главе 2. Вам удалось получить 8 правильных ответов из 10? Если нет, то каковы шансы на то, что импровизированная оценка (даже если учесть в ней неопределенности) с вероятностью 90 % будет включать правильный ответ?.

4.9. Излишняя четкость.

В повседневных разговорах люди нередко считают «точность» и «четкость» синонимами. Тем не менее в области оценки между этими двумя терминами существуют принципиальные различия.

Точность указывает, насколько близка оценка к реальному значению. Четкость относится только к представлению числа и в области оценки программных проектов равносильна количеству значащих цифр в оценке. Значение может быть четким, не будучи точным, и наоборот. Простая цифра 3 является точным представлением числа «пи» с точностью до одной цифры, но четким такое представление не является. С другой стороны, число 3,37882 обладает большей четкостью, но точность у него меньше.

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

В табл. 4.5 приводятся примеры чисел, которые являются точными и/или четкими.

Таблица 4.5. Примеры точности и четкости

В контексте оценки программных проектов различия между точностью и четкостью становятся принципиальными. Ключевые фигуры делают предположения относительно точности проекта на основании четкости, с которой им представлена оценка. Если вы представляете оценку в 395,7 дня, руководство будет полагать, что оценка обладает точностью до 4 значащих цифр! Возможно, точность оценки будет лучше отражена в другом формате оценки: 1 год, 4 квартала, или 13 месяцев. Использование оценки 395,7 дня вместо одного года напоминает представление числа «пи» в виде 3,37882 — высокая четкость при снижении точности.

СОВЕТ № 23 -.

Количество значащих цифр в оценке (ее четкость) должно соответствовать точности оценки.

4.10. Другие источники ошибки.

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

• незнакомая область деятельности;.

• незнакомая технологическая область;.

• неверное преобразование оцениваемого времени в проектное (например, предположение о том, что группа будет работать над проектом по 8 часов в день, 5 дней в неделю);.

• неверное понимание статистических концепций (особенно суммирование набора оценок для лучших и худших случаев);.

• бюджетные процессы, подрывающие эффективную оценку (особенно требующие согласования итогового бюджета в широкой части конуса неопределенности);.

• наличие точной оценки масштаба проекта, с внесением ошибок при ее преобразовании в оценку объема работы;.

• наличие точных оценок масштаба и объема работы, с внесением ошибок при их преобразовании в расписание проекта;.

• завышенные ожидания от применения новых средств или методов разработки;.

• упрощение оценки при ее передаче на верхние уровни управления, при формировании бюджета и т. д.

Эти темы подробно рассматриваются в следующих главах.

Факторы, влияющие на оценку.

Сколько будет 68 + 73?.

Инженер: «141». Коротко и мило.

Математик: «68 + 73 = 73 + 68 по свойству коммутативности сложения». Верно, но не слишком полезно.

Бухгалтер: «Обычно 141, но в каких целях вы собираетесь использовать результат?».

Барри В. Бем и Ричард Э. Фарли