Ich habe eine Drei-Punkte-Schätzung für eines meiner Projekte verwendet. Formel ist
%Vor%Das heißt,
%Vor%Hier
%Vor%und es besteht weniger Wahrscheinlichkeit, dass der schlimmste Fall oder der beste Fall eintritt. In gutem Glauben, wahrscheinlich (M), ist das, was es braucht, um die Arbeit zu erledigen.
Aber ich weiß nicht, warum sie 4(M)
benutzen. Warum haben sie sich um 4 multipliziert ???. Nicht 5,6,7 usw. verwenden
Warum ist die wahrscheinlichste Schätzung so gewichtet four times
wie die anderen beiden Werte?
Ich habe mich einmal damit beschäftigt. Ich habe es geschickt versäumt, den Trail aufzuschreiben, also ist das aus dem Gedächtnis.
Soweit ich feststellen kann, haben die Standarddokumente es aus den Lehrbüchern bekommen. Die Lehrbücher haben es aus den ursprünglichen 1950er Jahren in einer Statistikzeitschrift aufgeschrieben. Die Beschreibung in der Zeitschrift basierte auf einem internen Bericht, der von RAND im Rahmen der gesamten Arbeit zur Entwicklung von PERT für das Polaris-Programm erstellt wurde.
Und hier wird die Spur kalt. Niemand scheint eine klare Vorstellung davon zu haben, warum sie diese Formel gewählt haben. Die beste Vermutung scheint zu sein, dass es auf einer groben Annäherung einer normalen Verteilung basiert - streng genommen ist es eine Dreiecksverteilung. Eine Kurve mit klumpigen Glockenkurven nimmt im Grunde an, dass der "wahrscheinliche Fall" innerhalb von 1 Standardabweichung der wahren mittleren Schätzung liegt.
4 / 6ths approximieren 66,7%, was ungefähr 68% entspricht, was ungefähr der Fläche unter einer Normalverteilung innerhalb einer Standardabweichung des Mittelwerts entspricht.
Alles, was gesagt wird, gibt es zwei Probleme:
Hier gibt es eine Ableitung:
Falls der Link nicht mehr funktioniert, gebe ich hier eine Zusammenfassung.
Wenn wir also einen Moment von der Frage abweichen, ist das Ziel hier, eine einzige mittlere (durchschnittliche) Zahl zu finden, die wir sagen können die erwartete Zahl für eine gegebene 3-Punkte-Schätzung. Das heißt, wenn ich das Projekt X mal versuchen würde und alle Kosten des Projekts für insgesamt $ Y aufsummieren würde, dann erwarte ich die Kosten für einen Versuch, $ zu sein Y / X. Beachten Sie, dass diese Zahl abhängig von der Wahrscheinlichkeitsverteilung dem Ergebnis modus (wahrscheinlich) entsprechen kann oder auch nicht.
Ein erwartetes Ergebnis ist nützlich, weil wir beispielsweise eine ganze Liste erwarteter Ergebnisse addieren können, um ein erwartetes Ergebnis für das Projekt zu erzeugen, selbst wenn wir jedes einzelne erwartete Ergebnis anders berechnet haben.
Ein Modus andererseits ist nicht einmal eindeutig pro Schätzung, deshalb ist das ein Grund, warum es weniger nützlich ist als ein erwartetes Ergebnis. Zum Beispiel ist jede Zahl von 1-6 die "wahrscheinlichste" für einen Würfelwurf, aber 3,5 ist das (einzige) erwartete durchschnittliche Ergebnis.
Die Begründung / Forschung hinter einer 3-Punkte-Schätzung ist, dass diese Zahlen in vielen (meist?) realen Szenarien von Menschen genauer / intuitiver geschätzt werden können als ein einziger erwarteter Wert:
Um diese drei Zahlen in einen erwarteten Wert zu konvertieren, benötigen wir jedoch eine Wahrscheinlichkeitsverteilung , die alle anderen (potenziell unendlichen) möglichen Ergebnisse jenseits der von uns produzierten 3 interpoliert.
Die Tatsache, dass wir sogar eine 3-Punkte-Schätzung machen, geht davon aus, dass wir nicht genügend historische Daten haben, um einfach den erwarteten Wert für das, was wir gerade tun, zu suchen, also wahrscheinlich nicht Ich weiß nicht, was die tatsächliche Wahrscheinlichkeitsverteilung für das, was wir schätzen, ist .
Die Idee hinter den PERT-Schätzungen ist, dass wir, wenn wir die tatsächliche Kurve nicht kennen, einige Standardeinstellungen in eine Beta-Verteilung (die im Grunde nur eine Kurve ist, die wir in viele verschiedene Formen anpassen können) einfügen und diese Standardwerte verwenden für jedes Problem, dem wir gegenüberstehen könnten. Wenn wir die tatsächliche Verteilung kennen oder Grund zu der Annahme haben, dass die von PERT vorgeschriebene Standard-Beta-Verteilung für das vorliegende Problem falsch ist, sollten wir natürlich die PERT-Gleichungen für unser Projekt nicht verwenden . p>
Die Beta-Verteilung hat zwei Parameter A
und B
, die jeweils die Form der linken und rechten Seite der Kurve festlegen. Günstigerweise können wir den Modus, den Mittelwert und die Standardabweichung einer Beta-Verteilung berechnen, indem wir einfach die minimalen / maximalen Werte der Kurve sowie A
und B
kennen.
PERT setzt A
und B
für jedes Projekt / Schätzung auf Folgendes:
Wenn M > (O + P) / 2
, dann A = 3 + √2
und B = 3 - √2
, sonst werden die Werte von A
und B
vertauscht.
Nun passiert es einfach, dass wenn Sie diese spezifische Annahme über die Form Ihrer Beta-Verteilung machen, die folgenden Formeln genau wahr sind:
Mittelwert (erwarteter Wert) = (O + 4M + P) / 6
Standardabweichung = (O - P) / 6
Also, zusammenfassend
Ist das nicht eine gut funktionierende Daumenzahl?
Der Unsicherheitskegel verwendet den Faktor 4 für die Anfangsphase des Projekts.
Das Buch "Software Estimation" von Steve McConnell basiert auf dem" Cone of Uncertainty "-Modell und gibt viele" Daumenregeln ". Jede angenäherte Zahl oder eine Daumenregel basiert jedoch auf Statistiken aus COCOMO oder ähnlichen soliden Untersuchungen, Modellen oder Studien.
Idealerweise werden diese Faktoren für O, M und L unter Verwendung historischer Daten für andere Projekte in derselben Firma in derselben Umgebung abgeleitet. Mit anderen Worten, das Unternehmen sollte 4 Projekte innerhalb der M-Schätzung abgeschlossen haben, 1 innerhalb von O und 1 in L. Wenn mein Unternehmen / Team 1 Projekt innerhalb der ursprünglichen O-Schätzung abgeschlossen hätte, würde ich 2 Projekte innerhalb von M und 2 innerhalb von L verwenden eine andere Formel - (O + 2M + 2L) / 5. Macht es Sinn?
Der Kegel der Unsicherheit wurde oben erwähnt ... es ist ein bekanntes Grundelement, das in agilen Schätzpraktiken verwendet wird.
Was ist das Problem damit? Sieht es nicht zu symmetrisch aus - als ob es nicht natürlich ist, nicht wirklich auf realen Daten basiert?
Wenn du das jemals machst, dann hast du recht. Der Unsicherheitskegel, der im obigen Bild gezeigt wird, basiert auf Wahrscheinlichkeiten ... nicht auf tatsächlichen Rohdaten von realen Projekten (aber meistens wird es so verwendet).
Laurent Bossavit schrieb ein Buch und gab auch eine Präsentation, in der er seine Forschung darüber präsentierte, wie dieser Kegel entstand (und andere "Fakten", die wir oft an Software-Engineering glauben):
Die Kobolde des Software Engineerings
Gibt es echte Daten, die einen Unsicherheitskegel unterstützen? Der nächste, den er finden konnte, war ein Kegel, der bis zu 10x in positiver Y-Richtung gehen kann (so können wir nach unserer Schätzung bis zu 10 Mal weniger Zeit haben, wenn das Projekt 10 mal länger dauert) / p>
Kaum jemand schätzt ein Projekt, das viermal früher endet ... oder ... keuch ... zehnmal früher.
Tags und Links estimation software-estimation