Что мы знаем и чего не знаем об оценке трудозатрат в разработке ПО

Original author: Magne Jørgensen
  • Translation
Подавляющая масса исследований и отчетов подтверждает тенденцию к превышению бюджетов и сроков программных проектов. В среднем, это превышение составляет порядка 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
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 9

    +3
    Жаль, что у пунктов не расставлены веса, что влияет в наибольшей степени. Я наверное к тому, что желание низкой цены — самая распространенная причина урезания сроков.

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

    Выглядит это например так: «за сколько сделаете в простейшем виде?». Ответ обычно «за X дней, без этого, этого и этого». После чего все соглашаются, что это, это и это не нужно, и проект идёт в реализацию. Через X дней всё готово, из того что обсуждали. Однако выясняется, что то, что исключили, было очень нужно, потому что заказчик еще прикупил систему B, которая без тех фич, что выбросили — не нужна. На испытаниях у заказчика финального продукта акт не подписывается, так как «система нефункциональна». В лучшем случае всё выливается в доп. соглашение, но формально срок сорван. Какой-нибудь топ-топ-топ у заказчика ставит себе галочку — подрядчик подвел. А свои менеджеры сто отговорок найдут.

    Всякое конечно бывает, но нельзя напрямую (без рассмотрения рисков) связывать просрочку проектов только с ошибками в оценке.
      +1
      Ответ обычно «за X дней, без этого, этого и этого». После чего все соглашаются, что это, это и это не нужно, и проект идёт в реализацию.
      — «это, то что нужно» где-либо зафиксировано? если да, то ИМХО затем тот факт что
      заказчик еще прикупил систему B, которая без тех фич, что выбросили — не нужна
      вообще не должен волновать исполнителя. А в целом, это больше чисто российская, мне кажется, специфика, нет еще увы должного уважения к документу, договору, в котором по идее должны быть обозначены все эти возможности.
        0
        Это всего лишь один из возможных «например», иллюстрирующий мысль о том, что срок или просрочка всего проекта не всегда связаны только с оценками или ошибками в оценках. В иллюстрации конечно много из «российской специфики», но я вам скажу и восточные партнеры (был у меня один сингапурец) — большие любители порезать ценник.

        Конечно, наибольшая часть ИТ-проекта — это трудозатраты и сроки, связанные с ними. Но если например заказчик фидбэк выдает с задержкой в месяц на еженедельные билды (вот это уже англоязычные товарищи есть одни), то это риск, и срыв сроков здесь не вина исполнителя. А проект выезжает из договорной даты. И деньги за этапы соответственно.
      +4
      Мне кажется существенная проблема планирования это то что перепутаны такие вещи как прогноз и обещание.

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

      Я думаю что давать обещание на дату завершения проекта, который зависит от миллиона факторов, глупо. Расчитывать на такое обещание тоже глупо. А вот спрогнозировать вполне можно. Некоторые даже умеют делать это очень точно — в пределах 100% погрешности.
      Прогнозы можно использовать для выбора между разными альтернативами и попытаться прикинуть, какой вариант скорее всего окажется выгоднее, его и использовать. Для этого и нужны прогнозы — они подсказывают направление движения.

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

        А есть опыт применения описанных инструментов? было бы здорово почитать об этом…
        0
        Мне кажется, что помимо объективных проблем трудности оценки трудозатрат, в постсоветских реалиях добавляется ещё и проблема откатов. Разработчик нередко вынужден закладывать в трудозатраты откат, который увеличивая бюджет, не позволяет заложить в оценку запас прочности, адекватный рискам (ведь надо ещё и конкурентоспособную цену назвать).
          +1
          Мой (скромный) опыт говорит о том, что хорошо и стабильно оценивать сроки получается при сочетании трех параметров: опыта, контекста и мотивации. По пунктам:
          -Опыт. Тут все просто и очевидно: человек, который никогда не оценивал сроки, делает это хуже; человек, у которого уже есть опыт оценки и работы со своей оценкой, со временем оценивает лучше. То же самое верно для команд.
          -Контекст. Под контекстом я имею в виду любое окружение: технологии, команду, тип проекта. Человек, который всю жизнь работал с одним языком программирования, может серьезно ошибиться с оценкой проекта на другом языке; человек, долгое время работавший в стабильной команде, может серьезно ошибиться, выставляя сроки для другой команды (или выставляя сроки для себя после перехода в новую команду), и так далее.
          -Мотивация. Если у людей нет стимула выставлять максимально точную оценку, они и не будут этим заниматься.

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

          P.S. «Зацикленность клиента на низкой цене приводит к перерасходу бюджета проекта» — это проблема всего бизнеса, а не проблема оценки сроков при разработке ПО. "Просто посмотрите, сколько подрядчиков при тендере на строительство шоссе называли условия лучше, чем конкурент, чтобы заполучить контракт и потом превысить смету на два миллиарда долларов и срок — на полтора года. Это бизнес. Когда речь идет о том, чтобы оставить свою компанию на плаву, ты пойдешь на всё".

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

            Only users with full accounts can post comments. Log in, please.