Подавляющая масса исследований и отчетов подтверждает тенденцию к превышению бюджетов и сроков программных проектов. В среднем, это превышение составляет порядка 30 процентов1. Более того, если мы сравним точность оценивания в 1980-х и ту, которая фигурирует в недавних исследованиях, мы не обнаружим существенной разницы (Единственный анализ, предполагающий существенное улучшение качества оценки, встречается в отчетах Chaos Reports от Standish Group. Однако, это «улучшение», вероятнее всего, проистекает из того факта, что исследователи улучшили качество своих данных, перейдя от излишне перегруженной проблемными проектами, к более репрезентативной выборке2). Методы оценки также существенно не изменились. Несмотря на интенсивные исследования в области формальных моделей оценки, доминирующим методом продолжает оставаться «экспертная оценка»3
Очевидное отсутствие прорывов в улучшении методологии оценки трудозатрат, не означает, что мы не стали больше знать об этом. В данной статье, я попытаюсь обобщить некоторые из знаний, которыми мы, на мой взгляд, теперь располагаем. Некоторые из этих знаний могут потенциально улучшить качество оценки, некоторые, по всей видимости, не смогут его улучшить, а некоторые касаются того, что мы знаем о том, чего мы не знаем в отношении оценки трудозатрат при разработке ПО. Все материалы, который я использую, чтобы подтвердить свои тезисы, опубликованы1.
Что мы знаем
Проанализировав исследования, посвященные оценке трудозатрат, я выбрал семь результатов, которые согласуются с большинством исследований:
Не существует «лучшей» модели или методики оценки
Множество исследований посвящено сравнению точности оценки, полученной с помощью различных моделей и методов, при этом мы наблюдаем большое разнообразие «победителей» в этих состязаниях на точность4. Основной причиной этой нехватки стабильности в результатах видится то, что многие ключевые соотношения, например такая, как между размером проекта и трудоемкостью разработки, существенно варьируют от контекста к контексту5. Вдобавок к этому, переменные с крупнейшим влиянием на трудоемкость тоже варьируются, подталкивая нас к выводу о том, что модели и методы оценки должны быть подобраны под контекст, в котором они применяются.
Отсутствие стабильности ключевых соотношений также объясняет, почему статистически продвинутые модели оценки, как правило, не улучшают или практически не улучшают точность оценки по сравнению с простыми моделями. Статистически продвинутые модели излишне полагаются на исторические данные и могут давать даже худшие результаты, чем простые модели, будучи применены в ином контексте. Полученные результаты позволяют предположить, что компаниям-разработчикам лучше строить свои собственные модели оценки, чем ожидать, что универсальные методики и инструменты будут аккуратны в их конкретном контексте.
Зацикленность клиента на низкой цене приводит к перерасходу бюджета проекта
Тенденция к недооцениванию трудозатрат наиболее ярко проявляется в ситуациях, когда выбор поставщика делается на основании цены, например, при запросах котировок. В менее цено-чувствительных ситуациях, таких как «in-house разработка», такой тенденции нет — фактически, здесь даже можно столкнуться с обратным явлением. Это позволяет предположить, что ключевой причиной недооценки является сосредоточенность клиента на получении наименьшей возможной цены, т.е., когда поставщики, которые недооценили трудозатраты, имеют больше вероятности стать исполнителями. Это наблюдение предполагает, что клиенты могут избежать перерасхода бюджетов, уделяя меньшее внимание оценочной стоимости и большее — компетенциям исполнителя.
«Минимум-максимум» интервалы оценок слишком узки
Интервалы оценки, такие как 90-процентный доверительный интервал, систематически слишком узки, чтобы отразить действительно имеющуюся неопределенность потребности в трудозатратах. Несмотря на уверенное подтверждение нашей неспособности оценить минимальные и максимальные уровни трудозатрат, текущие методы оценки продолжают предполагать, что это решаемая задача. Это особенно ярко проявляется при использовании PERT-методов (оценивание по трем точкам), в которых предполагаемая оценка строится на основе наиболее вероятной, минимальной и максимальной оценок.
Вместо использования экспертных оценок для определения минимальной и максимальной величин оценки трудозатрат, разработчики должны использовать исторические данные о предыдущих ошибках оценивания, чтобы задавать реалистичные интервалы «минимум-максимум»6.
Легко ввести в заблуждение тех, кто оценивает, но трудно избавиться от заблуждения
Любое оценивание трудозатрат в области разработки ПО, даже опирающееся на формальные модели оценки, требует экспертного суждения. Но, хотя экспертное суждение может быть достаточно точным, оно также сильно подвержено влияниям внешних факторов. Вероятно, самое сильное (и негативное) влияние возникает, когда те, кто занимается оценкой трудозатрат, до или во время оценивания, получают информацию о бюджете, ожиданиях заказчика, доступном времени на реализацию, или других величинах, которые могут выступить т.н. «якорями притягивания оценки». Не замечая этого, специалисты будут давать такую оценку, которая находится неоправданно близко к значениям «якорей». Например, знание того, что клиент ожидает низкую цену или небольшое количество человеко-часов, вероятнее всего приведет к недооценке трудозатрат. На экспертное суждение может также повлиять запрос, содержащий «нагруженные» слова, такой как «Сколько может стоить такой маленький и простой проект?»
Несмотря на множество исследований о том, как избавиться от ложных посылок и как нейтрализовать предвзятость при оценке, до сих пор не выявлено надежных методов для этого. Основным выводом из этой ситуации является то, что лица, ответственные за оценивание, должны всячески оберегаться от нерелевантной информации и информации, могущей сформировать заблуждение — например, с помощью удаления таковой из документации о требованиях.
Релевантные исторические данные и чек-листы улучшают точность оценки
Одним из хорошо задокументированных способов повышения точности оценки является использование исторических данных и чек-листов оценки. Когда исторические данные релевантны, и чек-листы приспособлены под нужды компании, меньше шансов на то, что те или иные активности будут упущены, и больше — на то, что будет сделан достаточный запас на риски, и предыдущий опыт будет переиспользован по максимуму. Это в свою очередь приводит к более реалистичной оценке. Особенно, если данные по похожим проектам могут быть привлечены для т.н. «оценки по аналогии»7, точность оценки существенно улучшается.
Несмотря на очевидную полезность такого рода инструментов, многие компании до сих пор не используют их для улучшения точности своих оценок.
Совмещение независимых оценок улучшает точность оценки
Среднее от нескольких оценок из различных источников, скорее всего, будет точнее чем большинство индивидуальных оценок. Ключевым фактором для улучшения точности является именно «независимость» оценок, то есть полученные оценки должны отличаться по экспертизе, бекграунду экспертов и применяемому процессу оценки. Процесс оценки по какому-либо "дельфийскому методу", например, «покер планирования», при использовании которого разработчики показывают свои независимо полученные оценки трудозатрат (свои «карты»), выглядит особенно полезным в контексте оценки трудозатрат на разработку ПО.
Групповой, структурированный процесс оценки привносит дополнительную ценность по сравнению с механическим объединением оценок, потому что обмен знаниями увеличивает общий суммарный объем знаний в группе. Негативные эффекты применения групповых суждений, такие как "групповое мышление" и готовность к большему риску в группе (по сравнению с индивидуальным принятием решения), не задокументированы для случаев оценки трудозатрат на разработку ПО.
Оценочные модели, в среднем, оказываются менее точны по сравнению с оценками экспертов. Однако, разница в процессах оценки по моделям и оценки экспертами, делает объединение обоих подходов особенно полезным для повышения точности оценки.
Оценки могут быть вредны
Оценки не только предсказывают будущее, но зачастую и влияют на него. Слишком низкие оценки могут привести к снижению качества, возможной переделке работы на последующих этапах, и более высоким рискам провала проекта; слишком высокие оценки могут снижать продуктивность согласно закона Паркинсона, который гласит, что «любая работа полностью занимает все отведенное на нее время».
Вот почему важно тщательно проанализировать, действительно ли на данном этапе необходимо оценивать трудозатраты. Если на самом деле это не абсолютно необходимо, может оказаться надежнее работать без оценки, или же отложить их на более поздний этап, когда появится дополнительная информация. Гибкие («agile») методологии разработки ПО — которые предполагают планирование лишь ближайшего спринта или релиза, используя обратную связь от предыдущих спринтов или релизов — могут быть хорошим способом избежать вреда, причиняемого оценками, выполненными на слишком раннем этапе.
Чего мы не знаем
Существует несколько проблем, связанных с оценкой, для которых до сих пор не найдено удовлетворительного решения, несмотря на тома исследований. Три из них особенно ярко подчеркивают скудость наших познаний в этой сфере
Как аккуратно оценивать трудозатраты в мега-крупных, сложных программных проектах
Мега-проекты предьявляют повышенные требования к оценке трудозатрат. Не только потому, что на кону большие ставки, но и в силу нехватки релевантного опыта и исторических данных. Многие из активностей, типичных для мега-проектов, такие как решение организационных вопросов, в которые вовлечено множество участников с различными интересами и целями, очень тяжело аккуратно оценить, т.к. они, как правило, затрагивают изменения в бизнес-процессах и подразумевают сложные взаимодействия между участниками проекта и существующим программным обеспечением.
Как измерять размер и сложность программ для точной оценки
Несмотря на годы исследований в отношении измерения размеров и сложности программ, ни одна из предложенных метрик не является достаточно хорошей, когда речь заходит об оценке трудозатрат. Некоторые контексты размера и сложности, видимо, облегчают корректную оценку, но такие контексты встречаются достаточно редко.
Как измерять и предсказывать продуктивность
Даже если Вы хорошо оценили размер и сложность проекта, [для надежной оценки] Вам необходимо надежно предсказывать и продуктивность команд и членов команд, которым предстоит работать над ним. Такое предсказывание осложнено на удивление большими различиями в производительности между командами и внутри команд. Не существует ни одного надежного метода для такой оценки (за исключением, возможно, выполнения реалистичных тестовых заданий — trialsourcing).
На текущий момент, мы даже не знаем, присуща ли проектам в области разработки ПО «экономия на масштабе» (производительность растет с увеличением размера проекта) или же «де-экономия» (производительность снижается с увеличением размера проекта). Большинство эмпирических исследований как будто указывают на то, что в среднем проектам по разработке ПО присуща «экономия на масштабе», в то время как большинство практикующих специалистов верят в обратное. К сожалению, результаты исследований, подтверждающих наличие «экономии», по всей видимости, являются следствием того, как организовано исследование, а не раскрывают глубинных связей между масштабом проекта и производительностью.
Таким образом, то, что нам на сегодняшний день известно об оценке трудозатрат при разработке ПО, на самом деле не позволяет нам решить проблемы оценки трудозатрат на реальных проектах. Однако, мы можем указать на несколько практик, которые, как правило, позволяют повысить надежность таких оценок. В частности, компании, вероятно, смогут повысить точность своих оценок, если они:
— будут разрабатывать и применять простые модели, адаптированные под их контексты, в сочетании с методом экспертного оценивания;
— использовать исторические данные об ошибках оценивания для построения интервалов «минимум-максимум»;
— избегать ситуаций, в которых эксперт рискует подвергнуться воздействию информации, вводящей в заблуждение, или нерелевантной информации;
— использовать чек-листы, апробированные в данной организации;
— использовать структурированные методы группового оценивания, с гарантией независимости оценок;
— избегать раннего оценивания, основанного на неполной информации.
Высоко-конкурентные тендеры, с ориентацией на самую низкую стоимость, с высокой вероятностью приведут к выбору чересчур оптимистичного Исполнителя, и, как следствие, к срывам сроков исполнения контракта и низкому качеству ПО. В других областях это называется "проклятие победителя". В долгосрочной перспективе, большинство заказчиков начнет понимать, что их зацикленность на самой низкой цене контракта в области разработки ПО в конечном счете негативно отражается на успехе проекта. До тех пор, компании-разработчики должны стараться отслеживать те ситуации, когда они могут быть выбраны только в случае излишне оптимистичной оценки проектов, и иметь в запасе стратегии реагирования для противодействия или избегания «проклятия победителя».
Источники:
1. T. Halkjelsvik and M. Jørgensen, “From Origami to Software Development: A Review of Studies on Judgment-Based Predictions of Performance Time,” Psychological Bulletin, vol. 138, no. 2, 2012, pp. 238–271.
2. M. Jørgensen and K. Moløkken-Østvold, “How Large Are Software Cost Overruns? A Review of the 1994 CHAOS Report,” Information and Software Technology, vol. 48, no. 4, 2006, pp. 297–301.
3. M. Jørgensen, “A Review of Studies on Expert Estimation of Software Development Effort,” J. Systems and Software, vol. 70, no. 1, 2004, pp. 37–60.
4. T. Menzies and M. Shepperd, “Special Issue on Repeatable Results in Software Engineering Prediction,” Empirical Software Eng., vol. 17, no. 1, 2012, pp. 1–17.
5. J.J. Dolado, “On the Problem of the Software Cost Function,” Information and Software Technology, vol. 43, no. 1, 2001, pp. 61–72.
6. M. Jørgensen and D.I.K. Sjøberg, “An Effort Prediction Interval Approach Based on the Empirical Distribution of Previous Estimation Accuracy,” Information and Software Technology, vol. 45, no. 3, 2003, pp. 123–136.
7. B. Flyvbjerg, “Curbing Optimism Bias and Strategic Misrepresentation in Planning: Reference Class Forecasting in Practice,” European Planning Studies, vol. 16, no. 1, 2008, pp. 3–21.
Об авторе
Магне Йоргенсен работает исследователем в Simula Research Laboratory и профессором в Университете Осло. Основные направления его научной работы — вопросы оценки трудозатрат, процессы поиска исполнителя, аутсорсинг, и оценка компенций разработчиков ПО. Связаться с ним можно по эл. почте magnej@simula.no
Автор: 62mkv
