Die "Cone of Uncertainty" oder Schätzen war immer unmöglich

Schätzen in Software Projekten war schon immer ein Desaster. Schon vor über 30 Jahren hat die NASA herausgefunden, dass zu Anfang eines Software Entwicklungsprojektes die Schätzungen so ungenau sind, dass man davon ausgehen kann, dass man sich um den Faktor 4 verschätzt habe.

Meine Suche nach "Cone of Uncertainty" in Google hat doch tatsächlich gezeigt, dass es dazu fast nichts brauchbares im Internet gibt. Der deutsche Artikel in Wikipedia dazu ist vollkommen unbrauchbar. Der englische Wikipedia Artikel dazu ist wesentlich besser. Meine Einschätzung, dass die Leute dieses Wissen also ignorieren ist damit zutreffen. Im Artikel von Wikipedia lesen wir:

"The original conceptual basis of the Cone of Uncertainty was developed by Barry Boehm (Boehm 1981, p. 311). Boehm referred to the concept as the "Funnel Curve" (Stutzke 2005, p. 10). Boehm's initial quantification of the effects of the Funnel Curve were subjective (Boehm 1981, p. 311). Later work by Boehm and his colleagues at USC applied data from a set of software projects from the U.S. Air Force and other sources to validate the model. The basic model was further validated based on work at NASA's Software Engineering Lab (NASA 1990)."

The first time the name "Cone of Uncertainty" was used to describe this concept was in Software Project Survival Guide (McConnell 1997)." [1]

Der Artikel weiter: "Original research on the Cone of Uncertainty stated that in the beginning of the project life cycle (i.e. before gathering of requirements) estimates have in general an uncertainty of factor 4 on both the high side and the low side (Boehm 1981). This means that the actual effort or scope can be 4 times or 1/4th of the first estimates. This uncertainty tends to decrease over the course of a project, although that decrease is not guaranteed (McConnell 2006, p. 38)."

Agile Schätzmethoden, wie unser Magic Estimation [2], erfüllen die Forderungen, die sich aus der Forschung Boehms ergeben:

  • Estimates (e.g. on duration, costs or quality) are inherently very vague at the beginning of a project
  • Estimates and project plans based on estimations need to be redone on a regular basis
  • Uncertainties can be built into estimates and should be visible in project plans
  • Assumptions that later prove to be mistake are major factors in uncertainty

Aber auch diese können, obwohl McConnel in seinem Buch Software Estimation behauptet sie seien wesentlich valider, nicht verhelen. Es bleiben Schätzungen.

[1] http://en.wikipedia.org/wiki/Cone_of_Uncertainty

[2] Boris Gloger, Scrum - Produkte zuverlässig und schnell entwickeln, Hanser, 3. Auflage, 2011

Agile Toolbox
Scrum
bgloger-redakteur
March 18, 2011

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

FRAGE: Warum macht ihr eigentlich kein SAFe?
Boris Gloger

FRAGE: Warum macht ihr eigentlich kein SAFe?

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?
Boris Gloger

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?
Boris Gloger

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?

FRAGE: Was kostet eine agile Transformation?
Boris Gloger

FRAGE: Was kostet eine agile Transformation?

FRAGE: Welche Rolle spielt Training?
Boris Gloger

FRAGE: Welche Rolle spielt Training?

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?
Boris Gloger

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

FRAGE: Was sind die Hauptunterschiede zwischen klassischen Beratungen und borisgloger?
Boris Gloger

FRAGE: Was sind die Hauptunterschiede zwischen klassischen Beratungen und borisgloger?

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?
Boris Gloger

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

FRAGE: Habt ihr Beispiele für konkrete Situationen, in denen ihr Kunden bei einer schwierigen Herausforderung geholfen habt?
Boris Gloger

FRAGE: Habt ihr Beispiele für konkrete Situationen, in denen ihr Kunden bei einer schwierigen Herausforderung geholfen habt?

FRAGE: Welche Vorteile bietet es uns, wenn wir borisgloger beauftragen, anstatt die Transformation mit Internen voranzutreiben?
Boris Gloger

FRAGE: Welche Vorteile bietet es uns, wenn wir borisgloger beauftragen, anstatt die Transformation mit Internen voranzutreiben?

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?
Boris Gloger

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

FRAGE: Warum sollten wir mit borisgloger arbeiten?
Boris Gloger

FRAGE: Warum sollten wir mit borisgloger arbeiten?