Ich habe über den Cone of Uncertainty gelesen, als ich mich auf die Zertifizierung zum Product Owner vorbereitet habe. Ich hatte noch nie von diesem Framework gehört, also beschloss ich natürlich, mehr darüber zu erfahren und es hier zu teilen.

Das Grundkonzept des Cone of Uncertainty wurde laut Wikipedia von den Gründern der AACE International (American Association of Cost Engineers) für das Ingenieurwesen und das Bauwesen in der chemischen Industrie entwickelt.

„Der Hauptzweck der Softwareschätzung ist nicht die Vorhersage des Projektergebnisses, sondern die Feststellung, ob die Projektziele realistisch genug sind, um das Projekt so zu steuern, dass sie erreicht werden“ – Steve McConnell.

Der Name Cone of Uncertainty wurde erstmals von Steve McConnell verwendet, um das Konzept in seinem Software Project Survival Guide zu beschreiben, als er es als Klassifizierungssystem für Standardschätzungen mit Unsicherheitsbereichen vorschlug und es als Kegelabbildung darstellte. In der Softwarebranche bezeichnete Barry Boehm das Konzept als „Funnel Curve“ (Trichterkurve).

Der Unsicherheitskegel kann in der Softwareentwicklung eingesetzt werden, wo sich das Umfeld extrem schnell ändert, einschließlich der verfügbaren Technologien und der Unternehmensziele. Man kann mit Fug und Recht behaupten, dass die Engineering-Kosten in der Software-Entwicklung direkt proportional zum Ausmaß der Ungewissheit sind.

Das Projektmanagement unterscheidet sich von der Software-Entwicklung, wo in der Regel eine bessere Vorhersagbarkeit und ein besseres Gesamtverständnis der Risiken möglich ist und die Fähigkeit besteht, die Projektrisiken drastisch zu reduzieren. In der Softwareentwicklung hingegen machen die Unbekannten und der äußere Druck das Umfeld extrem unbeständig und unvorhersehbar.

Gerade in der Softwareentwicklung ist es das Ziel, auf eine Reduzierung der Ungewissheiten und eine Minimierung der Risiken hinzuarbeiten. Eine Möglichkeit, dies zu erreichen, besteht darin, die Forschung in alle Phasen einzubeziehen und auch die Quellen der Variabilität so weit wie möglich aus dem Produkt oder Projekt zu entfernen.

Eine Möglichkeit, dies zu erreichen, besteht darin, die Anzahl der Entscheidungen über Umfang und Ressourcen zu reduzieren. Wie wir wissen, ist Scrum ein Rahmenwerk, das dabei hilft. Alternativ kann bei der Softwareentwicklung der Lean-Startup-Ansatz angewandt werden.

Der Cone of Uncertainty stellt die Entwicklung der Menge der Best-Case-Unsicherheiten während eines Projekts dar. Da man in der Anfangsphase nicht viele Informationen über das Projekt hat, besonders wenn es sich um ein neues Produkt handelt, enthalten die Schätzungen viele Unsicherheiten und die Risiken sind hoch. Je mehr Arbeit geleistet wird, desto mehr Informationen hat das Team über das Produkt, und die Unsicherheiten werden geringer.

Wie man schätzt

Eine Vorhersage des Erfolgs ist äußerst schwierig. Viele Faktoren können Ihre Schätzung beeinflussen und zu den Projektunsicherheiten beitragen. Bei der Ausarbeitung der Schätzung ist es eine gute Möglichkeit, sich auf ein anderes, ähnliches Projekt zu stützen.

Eine Möglichkeit, den Kegel der Ungewissheit einzuführen, besteht darin, eine Reihe von Ungewissheiten in Ihre Schätzung aufzunehmen. Die Idee ist, dass die Unsicherheiten und Schwankungen im Laufe des Projekts abnehmen, da zu Beginn des Projekts die Zahl der Unsicherheiten am höchsten ist.

Zu Beginn eines Projekts gibt es mehr Unsicherheiten, da viele spezifische Projektdetails unbekannt sind und erst im Laufe der Entwicklung des Produkts definiert werden. Die Verwendung des Unsicherheitskegels hilft Ihnen und dem Team, den Bereich der Unvorhersehbarkeit zu verstehen und auch die Verpflichtungen zu Beginn zu begrenzen, um Unsicherheiten zu vermeiden.

Die Schätzungen sollten immer mit diesem Gedanken erfolgen und durch historische Informationen über frühere Projekte unterstützt werden, um das wahrscheinlichste Szenario in einem Bereichsformat vorherzusagen, wie es durch den Unsicherheitskegel dargestellt wird.

Die Menge der Variationen schwankt je nach Projektphase und Projekttyp. Bedenken Sie, dass die Anzahl der Unsicherheiten zu Beginn des Projekts am höchsten ist und mit dem Fortschreiten des Projekts in den meisten Fällen abnehmen wird.

Frühzeitige Verpflichtungen im Projekt werden mehr Unsicherheiten und Risiken mit sich bringen. Wenn Sie in der Lage sind, die Erwartungen zu steuern und sicherzustellen, dass Ihre Stakeholder ein realistisches Verständnis der Gesamtprojektrisiken und Annahmen haben, können Sie besser mit dem Team zusammenarbeiten und ihr Vertrauen gewinnen.

Steve McConnell sagt, dass der Unsicherheitsfaktor zu Beginn des Projekts gleich 4 ist (für hoch und niedrig). Zu früh eingegangene Verpflichtungen können zu Ineffizienzen und mangelndem Vertrauen führen und die Fähigkeit, ein Projekt erfolgreich zu managen, verringern. Behalten Sie das im Hinterkopf!

Die Rolle von Agile

Agile hilft definitiv bei der Entwicklung der Schätzung und zwingt das Team auch dazu, ständig neue Schätzungen vorzunehmen, wenn es mehr lernt, und das ist eine tolle Sache. Je mehr man über das Produkt und den Markt erfährt, desto einfacher wird es, eine Schätzung abzugeben. Agile und der Kegel der Ungewissheit sind eine leistungsstarke Kombination, da Agile die Teams dazu befähigt, ein Ergebnis zu liefern; es ist jedoch nicht die Antwort auf alle Fragen Ihres Teams.

So wie der Markt heutzutage bei der Softwareentwicklung funktioniert, sollten wir immer eine Strategie entwickeln, um die Hypothese zu testen und die Innovation so weit wie möglich voranzutreiben. Agile hilft uns auf jeden Fall dabei, generell bessere Schätzungen abzugeben.

Der Hauptunterschied zu Agile besteht darin, dass es mehrere Iterationen zulässt. Das Team fühlt sich vielleicht wohler, wenn es die Iterationen in kleinen Chargen schätzt und plant, während es mehr über das Produkt und den Markt lernt.

Wenn wir den agilen Ansatz verwenden, beschleunigen wir unsere Fähigkeit zu lernen mit konstanten Iterationen und Einsatz, so dass das Team die Erkenntnisse schneller validieren und mehr über den Markt lernen kann, was die Unsicherheiten reduzieren kann.

Wie man es anwendet

Das Cone of Uncertainty Framework sollte Teil des Projektrisikomanagements und aller bekannten und unbekannten Risiken sein. Das Ziel des Rahmens ist es, Ihnen zu helfen, die Projektrisiken besser zu verstehen, indem Sie sich auf Ungewissheiten vorbereiten.

Die Rolle des Rahmens im Schätzungsprozess besteht darin, den wahrscheinlichsten Verlauf zu bestimmen und auch den oberen und unteren Bereich der Wahrscheinlichkeiten zu berechnen. Dies kann mit Hilfe von Formeln und auf der Grundlage von Schätzungen früherer Projekte mit Hilfe von Empirie geschehen.

Das Rahmenwerk wird bei verschiedenen Arten von Produkten und Projekten verwendet, weil es eine wirksame Methode ist, die Risiken einer Investition aufzuzeigen. Der Cone of Uncertainty zeigt die Höhe des Risikos, indem er den Grad der Gewissheit über den Produktlebenszyklus in Form eines Trichters darstellt.

Empirie ist ein großartiger Verbündeter des Frameworks, da es so viel einfacher ist, etwas auf der Grundlage früherer, ähnlicher Erfahrungen zu messen. Mit Hilfe des Trichters kann man feststellen, ob das Projekt machbar und möglich ist. Man hofft, dass die Unsicherheiten im Laufe der Zeit abnehmen werden und dass die Berücksichtigung dieser Tatsache Ihrem Team helfen wird, bessere Schätzungen zu entwickeln.

Vorteile der Verwendung des Unsicherheitskegels:

• Verringerung der Mehrdeutigkeit.
• Bestimmt die wahrscheinlichste Schätzung.
• Berechnet den oberen und unteren Bereich der Wahrscheinlichkeiten.
• Hilft zu bestimmen, wie viel Risiko sich das Team leisten kann und wie hoch die zusätzliche Finanzierung ist.
• Betont die Bedeutung zusätzlicher Forschung.

Tipps zur Schätzung:

• Schätzungen sind zu Beginn des Projekts unsicher, sie sind vage, basieren aber hoffentlich auf einem empirischen Prozess.
• Schätzungen müssen regelmäßig überprüft werden, wenn mehr über das Projekt bekannt ist.
• Annahmen sollten transparent sein und täglich doppelt überprüft werden.
• Schätzungen sollten Unsicherheiten berücksichtigen und in den Projektplänen und Kanban-Boards sichtbar sein.

Unwägbarkeiten Fakten:

• Es ist schwierig, den Markt zu verstehen und zu wissen, was er will.
• Der Markt verändert sich ständig.
• Wettbewerb wird es immer geben.

Viel Spaß! ❤