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