О точности оценки

О точности оценки

[Одно из распространенных определении оценки — ...] «...наиболее оптимистичный прогноз, вероятность исполнения которого отлична от нуля». ...Руководствуясь этим определением, мы неизбежно приходим к методу оценки, который можно назвать «поиском самой ранней даты, когда вы еще не можете точно сказать, что проект не будет закончен вовремя».
Том Демарко (Тот DeMarco).
Неточность оценок программных проектов, замутненных нереалистичными целями и недостижимыми обязательствами, оставалась проблемой в течение многих лет. Еще в 1970-х годах Фред Брукс указывал, что «нехватка календарного времени загубила больше проектов, чем все остальные причины вместе взятые» (Brooks 1975). Десять лет спустя Скотт Костелло заметил, что «давление предельных сроков является величайшим врагом разработки программного обеспечения» (Costello 1984). В 1990-х годах Кейперс Джонс указал, что «слишком подробные или иррациональные графики, вероятно, оказывают наиболее разрушительное влияние на судьбу всех программных проектов».
Том Демарко сформулировал свое общее определение в 1982 году. Несмотря на успехи, о которых я упоминал в первой главе, за прошедшие годы изменилось не так уж много. Вероятно, вы уже согласны с тем, что точные оценки ценнее неточных. В этой главе описаны преимущества точных оценок и тех данных, на которых они базируются.
3.1. Что лучше — переоценка или недооценка?.
На интуитивном уровне ясно, что точная оценка закладывает идеальную основу для планирования проекта. Наличие точных оценок позволяет эффективно координировать работу между несколькими разработчиками. Результаты, выдаваемые одно группой для другой группы, планируются с точностью до дня, часа или минуты. Но мы знаем, что точные оценки встречаются редко, и раз уж нам все равно суждено ошибиться — в какую сторону это лучше сделать? В сторону завышения или занижения?.
Аргументы против переоценки.
Начальство и другие заинтересованные стороны иногда опасаются, что при переоценке проекта вступит в силу закон Паркинсона — принцип, согласно которому любая работа заполняет все отведенное для нее время. Если дать разработчику 5 дней на решение задачи, которую можно решить за 4 дня, разработчик придумает, чем заняться в лишний день. Если дать группе 6 месяцев на завершение проекта, который можно завершить за 4 месяца, группа найдет способ использовать лишние два месяца. В результате некоторые начальники сознательно поджимают оценки, пытаясь избежать действия закона Паркинсона.
Другая потенциальная проблема — «студенческий синдром» Голдрэтта (Goldratt 1997). Если выделить разработчикам слишком много времени, они работают спустя рукава. Когда проект близится к концу, начинается аврал, и скорее всего, разработчики не успеют сдать проект к сроку.
Недооценка также часто применяется еще по одной похожей причине — из-за желания внушить группе разработчиков чувство срочности проекта. Обоснование выглядит примерно так.
Разработчики говорят, что проект займет 6 месяцев. Наверняка, в их оценках есть какие-нибудь допуски и излишества, которые можно отжать. Кроме того, в проект нужно заложить плановую срочность, чтобы обеспечить его приоритетное исполнение. Значит, нужно настаивать на 3-месячном сроке. Конеч7ю, я не верю, что проект можно завершить за 3 месяца, по разработчикам назову именно этот срок. Если я прав, разработчики все сделают за 4 или 5 месяцев. В худшем случае потребуются те 6 месяцев, которые были названы в изначальной оценке.
Насколько убедительны эти аргументы? Чтобы выяснить это, необходимо изучить аргументы в пользу смещения в другую сторону, то есть переоценки.
Аргументы против недооценки.
Недооценка создает множество проблем — как очевидных, так и скрытых.
• Снижение эффективности планирования. Заниженные оценки подрывают эффективность планирования и закладывают неверные предположения в планы выполнения некоторых операций. Они могут привести к ошибкам планирования в численности группы — скажем, заложенная в план численность группы окажется меньше необходимой. Также могут быть подорваны возможности координации между группами — если группа не успевает завершить работу к положенному сроку, другие группы не смогут использовать ее результаты.
• Если ошибка оценки приводит к нарушению плана всего на 5 % или 10 %, она не вызовет серьезных проблем. Однако многочисленные исследования показали, что оценки программных проектов часто оказываются неточными на 100 % и более (Lawlis, Flowe, and Thordahl 1995; Jones 1998; Standish Group 2004; ISBSG 2005). Если предпосылки планирования неверны до такой степени, планы среднего проекта настолько отрываются от реальности, что становятся практически бесполезными.
• Статистическое снижение вероятности своевременного завершения. Разработчики обычно склонны оценивать объем работы на 20-30 % ниже реального (van Genuchten 1991). Даже если просто воспользоваться их обычными оценками, планы проекта будут слишком оптимистичными. Дальнейшее сокращение оценок делает своевременное завершение еще менее вероятным.
• Плохая техническая база ухудшает результат по сравнению с номиналом. Заниженная оценка может привести к тому, что на предварительные операции (такие, как постановка требований и проектирование) будет потрачено слишком мало времени. Если же требованиям и проектированию уделено недостаточно внимания, вам придется переделывать и то и другое на более поздних стадиях проекта, причем с большими затратами, чем при своевременном выполнении этих операций (Boehm and Turner 2004, McConnell 2004a). В конечном итоге работа над проектом займет больше времени, чем при точной оценке.
• Деструктивная динамика поздней стадии работы над проектом ухудшает результат по сравнению с номиналом. При переходе проекта в состояние «опоздания» рабочим группам приходится тратить время на действия, не нужные для «своевременных» проектов. Вот лишь несколько примеров:.
* Дополнительные встречи с начальством с обсуждением хода работ и мер, призванных вернуть проект на правильный путь.
* Частые переоценки для определения уточненной даты завершения проекта.
* Общение к важными клиентами по поводу нарушения срока поставки (в том числе и посещение собраний с участием этих клиентов).
« Подготовка промежуточных версий продукта для выставок, демонстраций и т. д. Если бы проект был готов вовремя, можно было бы использовать саму программу вместо промежуточных версий.
« Дополнительные дискуссии по поводу того, какие требования абсолютно необходимо включить в задание из-за задержки проекта.
« Решение проблем с наспех сделанными обходными решениями, которые пришлось реализовать ранее из-за поджимающих сроков.
У всех перечисленных действий есть одна важная особенность: они совершенно не нужны, если работа над проектом идет по графику. Дополнительные действия отвлекают от продуктивной работы и задерживают сдачу проекта по сравнению с точной оценкой и-планированием.
Сравнивая аргументы.
«Студенческий синдром» Голдрэтта может оказывать влияние на программные проекты, но я обнаружил, что самым эффективным способом его устранения является активное отслеживание задач и буферное управление (то есть управление проектом), по аналогии с предложениями Голдрэтта, а не смещение оценок.
Как видно из рис. 3.1, лучшие результаты проекта достигаются при самых точных оценках (Саймонс 1991). Если оценка занижена, неэффективность планирования ведет к повышению затрат и затягиванию проекта. Если оценка завышена, начинает действовать закон Паркинсона.
Рис 3.1. Потери от недооценки превышают потери от переоценки, поэтому если точная оценка невозможна, старайтесь ошибаться в сторону завышения, нежели в сторону занижения.
Я считаю, что закон Паркинсона применим к программным проектам; объем работы растет, заполняя все отведенное время. Однако намеренная недооценка проекта из-за закона Паркинсона оправдана лишь в том случае, если потери из-за переоценки превышают потери из-за недооценки. В области программного обеспечения потери от переоценки являются линейными и ограниченными — работа заполняет все отведенное время, но не более того. С другой стороны, потери от недооценки нелинейны и неограничены — ошибки планирования, недостаточные предварительные операции и создание новых дефектов приносят больший ущерб, чем переоценка, причем предсказать размер этого ущерба заранее почти невозможно.
СОВЕТ № 8 -.
Избегайте намеренной недооценки. Потери от недооценки превышают потери от переоценки. Если вас беспокоит возможная переоценка, решайте проблемы посредством планирования и управления, а не за счет смещения оценки.
3.2. Достижения в области оценки программных проектов.
История достижений в области оценки программных проектов помогает сделать ряд интересных выводов относительно природы возникающих проблем. В последнее время группа The Standish Group каждые два года публикует отчет «The.
Chaos Report» с описанием результатов программных проектов. В 2004 году 54 % проектов завершались с опозданием, 18 % полностью проваливались, а 28 % завершались в положенный срок и в рамках бюджета. На рис. 3.2 изображены результаты за 10 лет, с 1994 по 2004 год.
Обратите внимание: в данных The Standish Group даже не существует категории для досрочного завершения проектов! Лучшим из возможных результатов было соответствие ожиданиям «вовремя/в рамках бюджета» — а все остальные результаты ему уступали.
Рис. 3.2. Результаты проектов по данным отчета The Standish Group «Chaos Report» изменяются от года к году. Около 3/4 всех программных проектов сдаются с опозданием или проваливаются.
Кейперс Джонс дает другое представление статистики о результатах проектов. На основании многолетних наблюдений Джонс заметил, что успех проекта зависит от его размера. Иначе говоря, в крупных проектах возникает больше проблем, чем в мелких. Таблица 3.1 доказывает это утверждение.
Как видно из данных Джонса, чем крупнее проект, тем ниже вероятность его своевременного завершения и тем выше вероятность полного провала.
В ходе многих исследований были получены результаты, соответствующие результатам The Standish Group и Джонса, — примерно четверть всех проектов завершается своевременно; еще четверть отменяется; и около половины проектов сдается с опозданием и/или превышением бюджета (Lederer and Prasad 1992; Jones 1998; ISBSG 2001; Krasner 2003; Putnam and Myers 2003; Heemstra, Siskens and van der Stelt 2003; Standish Group 2004).
Существует множество причин, по которым проекты нарушают поставленные цели. Плохая оценка — лишь одна из них, но отнюдь не единственная. Эта тема подробнее рассматривается в главе 4.
Таблица 3.1. Зависимость результата проекта от его размера
Размер в функциональных пунктах (и примерное количество строк программного кода)
Преждевременное.
завершение
Своевременное Опоздание завершение
Провал.
(отмена)
10 FP (1000 строк)
11 %
81 %
6%
2%
100 FP (10 000 строк)
6%
75%
12%
7%
1000 FP (100 000 строк)
1 %
61 %
18%
20%
10 000 FP (1 000 000 строк)
28%
24%
48%
100 000 FP (10 000 000 строк)
0%
14%
21 %
65%
Источник: «Estimating Software Costs» (Jones 1998).
Насколько велики нарушения сроков?.
Количество проектов, нарушающих сроки или выходящих за рамки бюджета, — один показатель. Степень расхождения проектов с поставленными целями — другой фактор. Согласно первому обзору The Standish Group, среднее превышение сроков составляло около 120 %, а среднее превышение затрат — около 100 % (Standish Group 1994). Тем не менее точность оценки, вероятно, была еще хуже, чем показывают эти числа. Группа Standish Group обнаружила, что из проектов, завершавшихся с опозданием, обычно исключалась значительная часть функций; это делалось для обеспечения хотя бы того бюджета и сроков, с которыми проект в итоге завершался. Разумеется, оценка таких проектов строилась не для усеченной версии, которая в конечном счете получалась, а для полноценной исходной версии. Если бы в опаздывающих проектах реализовывалась вся запланированная функциональность, нарушение планов было бы еще большим.
По данным одной компании.
Данные о результатах проектов для одной конкретной компании, полученные от одного из моих клиентов, показаны на рис. 3.3.
Точки, сгруппированные на линии 0 в левой части графика, представляют проекты, о которых разработчики сообщили как о завершенных; тем не менее при интеграции результатов с другими группами оказалось, что проекты требуют доработки.
Диагональная линия представляет идеальную точность планирования. В идеале график должен состоять из точек данных, сгруппированных вблизи от диагональной линии. Вместо этого почти все 80 показанных точек данных находятся над линией и представляют нарушения сроков. Одна точка расположена под линией, и еще несколько — на линии. Линия демонстрирует стандартное определение «оценки» по Демарко — самая ранняя дата, к которой проект может быть завершен.
Рис. 3.3. Результаты оценок для одной организации. Данные по отрасли показывают, что почти 100 % занижение оценок компании является типичным явлением.
Данные используются с разрешения.
Общесистемная проблема программной отрасли.
Мы часто говорим о проблеме оценки в отрасли разработки программного обеспечения нейтрально — вроде бы иногда проекты переоцениваются, иногда недооцениваются, нам просто не удается получить правильную оценку.
Но в отрасли разработки программного обеспечения не существует проблемы нейтральной оценки. Статистика ясно показывает, что в отрасли разработки программного обеспечения существует проблема недооценки. Прежде чем заниматься повышением точности оценок, необходимо начать с их увеличения. Это становится изрядной проблемой для многих организаций.
3.3. Преимущества точных оценок.
Ваши оценки стали достаточно точными, и вы перестаете беспокоиться о больших ошибках оценки как в одну, так и в другую сторону. Действительно точные оценки дают немало дополнительных преимуществ.
• Возможность отслеживания состояния проекта. Один из лучших способов отслеживания состояния основан на сравнении запланированного прогресса с фактическим. Если запланированный прогресс был достаточно.
реалистичным (то есть основанным на точных оценках), становится возможным отслеживание прогресса на предмет соответствия планам. Если же запланированный прогресс является фикцией, проект обычно начинает существовать сам по себе, без какой-либо связи с планами, и вскоре оказывается, что сравнивать фактический прогресс с запланированным уже бессмысленно. Таким образом, хорошие оценки закладывают базу для отслеживания проекта.
• Повышение качества. Точные оценки помогают избежать снижения качества, обусловленного приближающимся сроком сдачи. Как показали исследования, около 40 % всех ошибок программирования возникает из-за стресса; этих ошибок можно было бы избежать за счет правильного планирования и снижения нагрузки на разработчиков (Glass 1994). Когда сроки «поджимают» особенно сильно, готовая программа содержит примерно в 4 раза больше ошибок, чем программа, разработанная в менее стрессовых условиях (Джонс 1994). Одна из причин состоит в том, что рабочая группа на скорую руку «лепит» версии функций, которые безусловно должны быть завершены к моменту выхода программы. Также оказалось, что излишнее давление сроков является основной причиной для выпуска модулей, содержащих ошибки, исправление которых обходится чрезвычайно дорого (Jones 1997).
• Проекты, с самого начала ориентирующиеся на минимизацию числа дефектов, обычно также имеют самое короткий срок сдачи (Jones 2000). Но если в результате давления руководства создаются нереалистичные оценки и страдает качество, ничем хорошим это не кончится: бюджет и график также пострадают.
• Улучшение координации с функциями, не связанными с программированием. Программные проекты обычно координируются с другими видами деятельности: тестированием, написанием документации, маркетинговыми кампаниями, обучением торгового персонала, финансовыми прогнозами, обучением службы поддержки и т. д. Ненадежный график сдачи проекта способен привести к сбоям взаимосвязанных функций, а это может нарушить весь график проекта. Хорошая оценка программного проекта предусматривает более тесную координацию всего проекта, включая как программные, так и прочие виды деятельности.
• Повышение качества бюджета. Как бы очевидно это ни прозвучало, точная оценка способствует выработке точного бюджета. Организация, не обеспечивающая точных оценок, подрывает свои возможности по прогнозированию стоимости проектов.
• Повышение доверия к группе разработчиков. Ирония судьбы: после того как группа, работающая над проектом, создает оценку, начальники, отделы маркетинга и продаж превращают эту оценку в оптимистичную цель — невзирая на все возражения разработчиков. Затем разработчики нарушают оптимистичную цель, и тогда начальники, отделы маркетинга и продаж обвиняют их в том, что они не умеют оценивать! Исполнительная группа,.
которая твердо держится на своих позициях и настаивает на точной оценке, пользуется большим доверием в своей организации.
• Получение ранней информации о рисках. Одной из самых частых упущенных возможностей в области разработки программного обеспечения является неправильная интерпретация исходного несоответствия между целями и оценками проекта. Финансовый директор говорит: «Проект нужно сделать за 4 месяца, потому что нас ждет крупная выставка», а исполнительная группа говорит: «По нашим лучшим оценкам, на проект уйдет не менее 6 месяцев». Как вы думаете, что будет дальше? Как правило, финансовый директор обсуждает оценку с руководством проекта, а на группу начинают давить с требованиями обеспечить 4-месячный график.
• Неверно! Обнаружение несоответствия между целью проекта и оценкой проекта должно рассматриваться как чрезвычайно полезная, крайне редкая информация о риске, появившаяся на ранней стадии проекта. Такое расхождение с довольно высокой вероятностью указывает на то, что цели проекта не будут соблюдены. На ранней стадии возможны различные корректировочные меры, многие из которых обладают высокой эффективностью. Вы можете переопределить объем работы, набрать дополнительный персонал, перевести лучших работников на проект или изменить некоторые функции. Возможно, вы даже решите, что с проектом вообще не стоит связываться.
• Но если оставить несоответствие без внимания, возможностей корректировки на более поздней стадии будет гораздо меньше, и они будут обладать куда меньшей эффективностью. Как правило, приходится выбирать между двумя вариантами: нарушением сроков и бюджета и отказом от важных функций.
СОВЕТ № 9 -.
Несоответствие между деловыми целями и оценкой проекта следует рассматривать как ценную информацию о возможной неудаче проекта. Принимайте меры на ранней стадии, когда еще можно что-то сделать.
3.4. Значение предсказуемости по сравнению с другими желательными атрибутами проекта.
Организации, занимающиеся разработкой программного обеспечения, и люди, ведущие собственные проекты, пытаются достичь ряда целей. Вот лишь некоторые из них.
• Срок. Кратчайший возможный срок для реализации заданной функциональности с заданным уровнем качества.
• Бюджет. Минимальные затраты на реализацию заданной функциональности за заданное время.
• Функциональность. Максимальный набор возможностей при доступном времени и затратах.
Относительные приоритеты этих общих целей (а также других, более специфических) зависят от проекта. Разработки на базе динамических методологий обычно отдают предпочтение динамичности, повторяемости, надежности, устойчивости и наглядности (Cockburn 2001, McConnell 2002). Модель СММ института SEI обычно фокусируется на целях эффективности, улучшаемое™, предсказуемости, повторяемости и наглядности.
Во время дискуссий с руководством я часто спрашиваю: «Что для вас важнее: возможность изменять решения относительно функциональности или заранее известные затраты, сроки и функциональность?» По крайней мере 8 раз из 10 мне отвечают: «заранее известные затраты, сроки и функциональность» — другими словами, предсказуемость. Другие эксперты в области разработки программного обеспечения также отмечали это явление (Moseman 2002, Putnam and Myers 2003).
После этого я часто говорю: «Допустим, я могу предложить вам результаты проекта, аналогичные варианту № 1 или варианту № 2 на рис. 3.4. Также будем считать, что вариант № 1 означает, что проект будет завершен за предполагаемый срок в 4 месяца, но он может быть сдан как на один месяц раньше, так и на 4 месяца позже. С другой стороны, вариант № 2 означает, что проект будет завершен в срок 5 месяцев (вместо 4), но я могу гарантировать, что отклонение составит не более недели. Какой вариант вы предпочтете?»
Рис. 3.4. При выборе между коротким средним сроком при большой неустойчивости и более длинным средним сроком при малой неустойчивости большинство коммерческих организаций выбирает второй вариант.
По собственному опыту могу сказать, что почти все руководители выбирают вариант № 2. Сокращенные сроки, предполагаемые вариантом № 1, не принесут никакой пользы, потому что организация не может твердо рассчитывать на них. Так как превышение срока может достигать 4 месяцев, приходится планировать 8-месячный график вместо 4-месячного или вообще отказаться от какого-либо планирования вплоть до фактического завершения проекта. Гарантированный 5-месячный срок варианта № 2 выглядит гораздо лучше.
За прошедшие годы в отрасли разработки программного обеспечения важнейшими показателями считались время до внедрения продукта на рынок, затраты и гибкость. Каждая из этих целей важна, но руководители высшего звена более всего ценят предсказуемость. Организации должны брать на себя обязательства перед клиентами, инвесторами, поставщиками, рынком и т. д. В основе всех этих обязательств лежит предсказуемость.
Сказанное вовсе не означает, что предсказуемость должна обладать наивысшим приоритетом в ваших проектах. Скорее, речь идет о том, что вам не следует делать априорные предположения о приоритетах вашей фирмы.
СОВЕТ № 10 -.
Многие организации ценят предсказуемость выше, чем срок разработки, затраты или гибкость. Обязательно выясните, какие показатели считаются приоритетными в вашем случае.
3.5. Недостатки распространенных методов оценки.
Поскольку неудачи при оценках программных проектов встречаются сплошь и рядом, можно сделать вывод, что методы, используемые для построения оценок, малоэффективны. Их следует тщательно проанализировать... и выбросить!.
Альберт Ледерер (Albert Lederer) и Джайеш Прасад (Jayesh Prasad) обнаружили, что самым распространенным методом оценки является сравнение нового проекта с похожим проектом из прошлого, причем на основании исключительно личных воспоминаний. Как выяснилось, эта методика имеет мало общего с точной оценкой. Стандартные методы, основанные на «интуиции* и «предположениях», связываются с превышением затрат и сроков (Lederer and Prasad 1992). Другие исследователи также выяснили, что догадки, интуиция, неструктурированные экспертные оценки, неформальные аналогии и т. д. являются преобладающими стратегиями, используемыми в 60-85 % всех оценок (Hihn and Habib-Agahi 1991, Heemstra and Kusters 1991, Paynter 1996, Jorgensen 2002, Kitchenham et al. 2002).
В главе 5 приводится более подробный анализ источников ошибок оценки, а в остальных главах книги представлены альтернативы для этих общих методов.

Популярные статьи

Свежие статьи