Wie lernt man, bessere Schätzungen vorzunehmen? [geschlossen]

Ich sauge an Schätzungen. Wenn mich jemand fragt, wie lange etwas dauern wird, traue ich mich nicht einmal, eine Vermutung anzustellen, da ich völlig daneben liegen werde. Normalerweise bin ich viel zu optimistisch und sollte meine Vermutung mit einem großen X-Faktor multiplizieren ...

Wie kann ich lernen, bessere Schätzungen vorzunehmen? Es wird an meiner Uni nicht unterrichtet, und obwohl wir Fristen für alle Arbeiten haben, denke ich nie darüber nach, wie lange etwas tatsächlich dauern wird. Welches sollte ich. Um aller willen (besonders meiner).

Ich bin immer noch nicht so gut darin, aber ich habe festgestellt, dass es eine große Hilfe sein kann, zu verfolgen, wie lange Sie für Aufgaben veranschlagen und wie lange Sie tatsächlich brauchen. Auf diese Weise können Sie sich ein Bild davon machen, wie weit Sie normalerweise entfernt sind. Dabei kann eine Issue-Management-Software mit Zeiterfassung (in meinem Fall Jira) oder eine Tabellenkalkulation eine große Hilfe sein.

Ich denke vor allem, dass es eine Erfahrung ist.

Murphys Gesetz des Zeitmanagements: Um herauszufinden , wie lange etwas wird dauern, herauszufinden , wie lange es sollte nehmen und verdoppeln.

Bewegen Sie sich dann zur nächsthöheren Zeiteinheit. Daher vergeben wir zwei Wochen für ein eintägiges Projekt.

Sie können lernen, indem Sie sie gemeinsam tun .

Ich benutze Planning Poker . Es ist eine konsensbasierte Technik zur Schätzung.

Ihre Einschätzung muss nachverfolgt und mit Ihrer tatsächlichen Leistung verglichen werden. Sie erhalten die Geschwindigkeit .

Multiplizieren Sie jedes Mal, wenn Sie etwas schätzen, mit Ihrer aktuellen Geschwindigkeit, um eine genaue Schätzung zu erhalten .

Software Estimation von Steve McConnell (MS Press) ist eine gute Lektüre.

Die Hauptsache mit Software-Schätzung wird im Folgenden zusammengefasst

Ohne historische Informationen sind Ihre Schätzungen unbrauchbar.

Dies ist einer der Gründe, warum iterative Projekte viel erfolgreicher sind als große Wasserfallprojekte. Sie versuchen nicht, für jeweils ein Jahr einen Plan aufzustellen, der nur wenige Informationen enthält, außer ein Black-Box-Voodoo, wie es ihrer Meinung nach aussehen sollte. Bei jeder Iteration wird neu geschätzt / geplant, und es liegen die letzten Iterationen vor, auf denen die Schätzungen basieren.

Ein paar andere Punkte zu beachten:

1. Es wird nur langsamer . Die Anwendung der 80/20-Regel bedeutet, dass die härtere Arbeit später kommt, es sei denn, Ihr Projektmanagement ist sehr diszipliniert.
2. Schätzung! = Planung. Schätzung ist der Prozess, um herauszufinden, wie viel Aufwand erforderlich ist, um etwas zu erledigen. Beim Planen wird es in einen Zeitplan eingefügt.
3. Ein Wirkungsgrad von 60% ist fast alles, worauf Sie hoffen können. 70% sind Utopie. Wenn Sie in Tagen schätzen, bauen Sie dies ein. Wenn Sie in Stunden schätzen, vergessen Sie nicht, es später anzuwenden.
4. Erinnere dich an den langen Schwanz . Schätzungen geben eine ungefähre Vorstellung davon, wie lange es "wahrscheinlich" dauern wird, wenn ein gewisses Maß an Risiken und Unbekannten berücksichtigt wird. Der lange Schwanz kommt ins Spiel, weil der tatsächliche Arbeitsaufwand niemals unter 0 liegen wird. OTOH, die maximale Zeit, die dafür benötigt wird, hängt nur davon ab, wie lange Sie bereit sind, damit zu arbeiten, bevor Sie aufgeben. Wie ein ehemaliger Chef von mir sagte "alle Schätzungen sind +/- x% und es ist nie minus".

Ich bin überrascht, dass niemand die PERT-ähnliche Schätzungstechnik erwähnt hat, die in Robert Martins The Clean Coder beschrieben ist . Bei dieser Methode schätzen Sie, wie lange es für drei Szenarien dauern wird: optimistisch ( O), nominal ( N) und pessimistisch ( P). Dann ist die erwartete Dauer = (O+4N+P)/6und Sie erhalten eine Standardabweichung von (P-O)/6.

Dies scheint ziemlich gut zu funktionieren, und ich habe es ein paar Mal verwendet, wenn sich das Management wirklich darum kümmert, wie lange etwas wahrscheinlich dauern wird.

Wie andere kommentiert haben, habe ich auch Schätzungen vorgenommen, indem ich historische Daten untersucht habe ("Wie lange hat es gedauert, um diese ähnliche Sache zu tun?").

Aber meine Lieblingsmethode ist es, überhaupt keine Zeitschätzungen durchzuführen und nur Punktschätzungen durchzuführen und eine Geschwindigkeit über Iterationen zu erhalten. Wenn ein Team ziemlich konsequent ist, wenn es darum geht, die Größe zu bestimmen und die Arbeit abzuschließen (User Stories), sparen Sie eine Menge Zeit, indem Sie nicht einmal fragen, wie lange die einzelnen Schritte dauern werden.

Stundenschätzungen sind nur schwer zu ermitteln und erfordern viel Arbeit, um die Dinge in so kleine Stücke zu zerlegen, dass sie effektiv gemessen werden können. Und selbst dann sind sie selten richtig, weil es zu viele Variablen gibt und wir vergessen, Dinge wie Krankheit, Urlaub oder sogar Ablenkungen zu berücksichtigen.

Wenn ich Stundenschätzungen durchführen muss, versuche ich, diese nur für kleinere Aufgaben innerhalb einer Iteration auszuführen. Ich messe alles in halbtägigen Schätzungen (4, 8, 12 Stunden), sofern ich nicht weiß, dass es weniger sein könnte. Aber ich schätze selten etwas auf weniger als 1 Stunde.

Zunächst und vor allem müssen Sie einen Prozess definieren und ihn einhalten. Schließen Sie die Überarbeitung des Plans am Ende jeder Phase des Prozesses ein. Sie können den Prozess auch überarbeiten, jedoch in geordneter Weise.

Zweitens machen Sie eine Art Design. Design ist der erste Planungsschritt, man baut kein Haus ohne Zeichnungen.

Drittens verfolgen Zeit (Aufwand). Sie sollten zumindest unterscheiden:

• Analyse
• Design
• Code
• Komponententest (einschließlich Fehlerbehebung)
• Integrationstests (einschließlich Fehlerbehebung)

• Abnahmeprüfung beim Anwender (inkl. Behebung von Mängeln)

  Es wäre großartig, wenn Sie den Aufwand für die Fehlerbehebung für jeden Testtyp messen würden, dies erhöht jedoch die Komplexität, sodass Sie dies später tun können.

Viertens identifizieren Sie wichtige Basiselemente für die Schätzung. Zum Beispiel:

• Anzahl der zu automatisierenden Prozesse (Analyse)
• Anzahl der Domain Model Entities (Design)
• Anzahl der Formulare und Berichte (Code)

Fünftens korrelieren Basiselemente und Aufwand. Zum Beispiel:

• Analyseaufwand = X Mannstunden / zu automatisierender Prozess
• Entwurfsaufwand = Y Mannstunden / Domain Model Entity
• Code Aufwand = Z Mannstunden / Formular (oder Bericht); Anzahl der Formen = A * Domain Model Entities
• Einheitentestaufwand = M% * Codeaufwand
• Aufwand für Integrationstests = N% * Codeaufwand
• Abnahmetestaufwand = P% * Codeaufwand

Sechstens: Behalten Sie die Leistung und die Abweichung von den Schätzungen für jedes Projekt im Auge. So können Sie Ihre Korrelationsfaktoren fein abstimmen.

Siebtens wiederholen und verbessern. Sie werden erst am Ende des ersten Projekts viel Einsicht gewinnen, beim dritten fühlen Sie sich wohl beim Planen und Schätzen.

Schauen Sie sich http://en.wikipedia.org/wiki/Personal_Software_Process an , es funktioniert wirklich.

Wenn Sie auf ein Schätzproblem stoßen, versuchen Sie, es in kleinere Teile aufzuteilen. Dann sehen Sie nach, ob Sie bereits ähnliche Arbeiten durchgeführt haben. Wenn Sie haben, sollten Sie bereits eine genaue Vorstellung davon haben, wie lange jedes Stück dauert. Wenn Sie dies nicht tun, sollten Sie damit beginnen, die für verschiedene Arten von Aufgaben benötigte Zeit aktiv zu verfolgen. Dies wird Ihnen bei zukünftigen Schätzungen helfen.

Die benötigte Gesamtzeit ist mehr als die Summe der einzelnen Teile, da Sie einige Zeit für die Integration und das Testen benötigen.

Wenn Sie etwas Ähnliches nicht getan haben, können Sie sich wahrscheinlich auf die Erfahrung anderer verlassen und eine Schätzung von ihnen erhalten. Nehmen Sie dies jedoch nicht zum Nennwert. Nichts lehrt dich wie Erfahrung.

Es ist so, als würde man auf ein Ziel schießen. Frühere Aufnahmen bei der Schätzung sollten Ihnen sagen, wie weit Sie von der Marke entfernt sind, damit Sie sie korrigieren können.

Ich finde es am einfachsten, den Prozess der Aufteilung auf die minimalen Aufgaben wie oben beschrieben durchzuführen, wobei jede Aufgabe herausgearbeitet und dann diese Schätzung verdoppelt wird. Dann addiere ich sie und addiere fünfzig Prozent. Das gibt mir eine ungefähre Projektzeit unter idealen Bedingungen. Wenn die Arbeit praktisch parallel zu anderen stattfinden wird, wird es länger dauern. Wenn Sie auf andere Menschen warten müssen, müssen Sie damit rechnen, dass sie doppelt so lange brauchen, wie Sie glauben. Das Warten auf Inhalte, Feedback oder andere Informationen dauert oft viel länger als möglich.

Wo ich arbeite, erarbeiten wir für jeden Schritt des Prozesses eine Best-Case- / Expected-Case- / Worst-Case-Schätzung, die als Richtlinie und auch zur Bewertung der von Ihnen vorgenommenen Schätzungen hilfreich ist.

Die Technik ist nicht so wichtig, außer dass Sie in der Lage sein müssen, die Versuchung des Programmierers zu bekämpfen, Aufgaben zu unterschätzen. Wichtig ist jedoch, konservativ zu sein, wenn Sie etwas liefern können. Wenn Sie sieben Wochen brauchen, um etwas zu bauen, und Sie acht Wochen versprochen haben, können Sie etwas früher eintreffen und gut aussehen oder zusätzliche Tests durchführen und sich der Zuverlässigkeit sicher sein. Wenn Sie sechs Wochen versprochen haben, können Sie schlecht aussehen, auch wenn es absolut nicht Ihre Schuld ist. Im Zweifelsfall konservativ raten.

Sie können versuchen, eine Erfolgsbilanz darüber zu erstellen, wie hoch die Schätzung und wie hoch die tatsächliche Anzahl der Aufgaben war, um einen ausreichenden Datensatz zu erstellen und dann zu ermitteln, welcher Multiplikator für bestimmte Elemente in Ihrer Liste verwendet werden muss. Zugegeben, dies ist eine Probeübung, aber es hat bei mir anscheinend gut funktioniert. Es gibt auch für viele Versuche etwas zu sagen, bevor das Muster wahrscheinlich auftaucht. Dies ähnelt wahrscheinlich vielen anderen Antworten, die besagen, dass man sich auf "Mach es einfach!" Beschränken könnte. So haben die meisten von uns die Fähigkeit entwickelt. Ist es ein großer Schmerz zu sehen, wie falsch man sein kann, wenn man Schätzungen vornimmt? Ja, aber wenn die Schätzungen besser werden, kann sich irgendwann jeder freuen.

Wenn Sie das Projekt in kleinere Aufgaben zerlegen und Schätzungen für diese durchführen können, sind Sie insgesamt genauer. Jede Aufgabe, die länger als ein paar Tage dauert, sollte weiter unterteilt werden. Wenn Sie es nicht weiter aufschlüsseln können, haben Sie wahrscheinlich eine Anforderungslücke. Wenn Sie einen Back-of-the-Servietten-Kostenvoranschlag für eine einzeilige Anforderung durchführen müssen, kann Ihnen nichts wirklich viel helfen. Leider arbeiten viele Geschäfte die meiste Zeit so.

Anstatt ein Buch darüber zu schreiben, möchte ich Ihnen nur einen kleinen Rat geben, wie Sie die "Aufschlüsselungsmethode" anwenden können:

• Teilen Sie Ihre Aufgabe in kleinere Teilaufgaben auf. Schätzen Sie jede Aufgabe so gut wie möglich.

• Fügen Sie eine Aufgabe für Planung und Entwurf hinzu (einschließlich der aktuellen Aufgaben). Schätzen Sie diese ein.

• Wenn Sie noch keine haben, fügen Sie eine Aufgabe hinzu, um die Aufgaben zusammenzuführen. Diese Aufgabe scheint zunächst nicht sinnvoll zu sein. Wenn Sie jedoch diese "Aufschlüsselungsmethode" verwenden, gibt es immer zeitaufwendige Dinge zu tun, die "zwischen Aufgaben fallen" und die "Aufgaben zusammenziehen". Dieser kann schwierig abzuschätzen sein. Versuch dein Bestes.

• Fügen Sie eine Aufgabe zum Testen und Dokumentieren hinzu. Ihre Aufgabe erfordert möglicherweise nicht viele Tests und Dokumentationen, aber Sie sollten sich zumindest ein wenig Gedanken darüber machen.

• Addieren Sie die Aufgabenschätzungen, um eine Gesamtschätzung zu erhalten.

• Fahren Sie fort und multiplizieren Sie diese Gesamtschätzung mit zwei ††. Auf diese Weise haben Sie Zeit zum Auffüllen von:

  1. Beende die Dinge, die du in deiner ursprünglichen Aufgabenliste übersehen hast
  2. Beende Dinge, von denen du nichts gewusst hast, bis du loslegst
  3. Integrieren Sie das Feedback anderer Personen und nehmen Sie Änderungen vor
  4. Lassen Sie sich von anderen Dingen wie Besprechungen stören
  5. Beende öfter vor der Schätzung als dahinter

Und zu guter Letzt haben Sie keine Angst, Schätzungen für sich selbst zu erstellen, die wahrscheinlich völlig falsch sind. Manchmal kann es hilfreich sein, einfach alles zu skizzieren, egal wie ungenau es sein mag.

†† Mit zunehmender Erfahrung kann dieser "Fudge-Faktor" auf Ihren persönlichen Stil und Ihre Arbeitsumgebung abgestimmt werden.

Die Formel, die funktioniert, wenn ich für mich selbst arbeite:

1. Führen Sie eine Aufschlüsselung der Aufgaben auf eine Granularität von 1 bis 4 Stunden durch. Ich finde, dass ich mit diesen normalerweise genau bin

2. Der Unbekannte Faktor: Multiplizieren Sie mit dem Faktor 2, der auf die Anzahl der Unbekannten erhöht wird. Dh wenn Sie eine Couchdb-Anwendung entwickeln wollen, aber jetzt etwas über Javascript und http wissen, dann addieren Sie 2 ^ 2 als Multifaktor.

3. Kontextwechsel-Faktor: Multiplizieren Sie den Faktor um 1,5, wenn Sie in einer perfekten Umgebung arbeiten (zu Hause in der Lernecke usw.), oder um 2,5, wenn Sie in einer makellosen Umgebung arbeiten (Büro / überfüllter Ort usw.).

Ich finde, dass dies innerhalb von +/- 20% der tatsächlichen Zeit liegt !!

Lerne deine eigene Vorurteile. Wenn Ihre letzte Schätzung um den Faktor zwei zu niedrig war, verdoppeln Sie beim nächsten Mal Ihre ursprüngliche Schätzung. (Natürlich macht es das Gesetz von Hofstadter schwer, das richtig zu machen ...)

Es ist auch immer eine gute Idee, sich daran zu erinnern, wie viel Arbeit nach der ersten Veröffentlichung der vorherigen Arbeit benötigt wurde, und dies der nächsten Schätzung hinzuzufügen. Zum Beispiel hat Ihre letzte Aufgabe 2 Monate gedauert, aber nach dem Start haben Support, Hotfixes und zusätzliche Änderungen Sie einen weiteren Monat gekostet. Schätzen Sie also beim nächsten Mal 3 Monate für eine ähnliche Aufgabe.

Zum Öffnen lesen Sie "Software Engineering Economics" von Barry Boehm und "Controlling Software Projects" von Tom DeMarco. Nachdem Sie diese beiden gelesen und verdaut haben, lesen Sie "Software Cost Estimation With COCOMO 2" von Barry Boehm.

Für das, was ich als nächstes zu sagen habe, wird es Ihnen eine Menge helfen, eine Wahrscheinlichkeits- und Statistikklasse belegt zu haben, selbst eine grundlegende Kochbuchklasse.

Keine Schätzung ist perfekt. Es gibt eine gewisse Wahrscheinlichkeit, dass Sie früh und eine gewisse Wahrscheinlichkeit, dass Sie spät eintreffen. Böhms ursprüngliches detailliertes COCOMO-Modell ergab Vorhersagen, die in 30% der Fälle besser waren als in 60% der Fälle. Das war viel besser als üblich, als er das Buch schrieb und veröffentlichte.

Wenn Sie Ihre besten Vermutungen anstellen (und das ist alles eine Schätzung), berücksichtigen Sie diese Wahrscheinlichkeiten. Wenn Sie die Schätzung berücksichtigen, erhöhen Sie die Wahrscheinlichkeit, dass Sie zu spät kommen. Wenn Sie die Schätzung erhöhen, erhöhen Sie die Wahrscheinlichkeit, dass Sie früh eintreffen oder pünktlich fertig werden. Wie viel Sie hineinziehen oder herauslassen, bestimmt, wie sich die Wahrscheinlichkeit ändert, und muss notwendigerweise von den Strafen abhängen, wenn Sie zu früh oder zu spät kommen. (Fügen Sie hier Horrorgeschichten ein - und es gab im Laufe der Jahre VIELE davon!)

DeMarco geht in gewissem Maße darauf ein. Er weist auch darauf hin, dass es eine "Unmöglichkeitsregion" gibt: Einige Zeitpläne sind einfach zu eng, egal welche Art von Heldentaten versucht werden.