Was ist die akzeptable Fehlerquote bei der Schätzung einer Projektdauer?

Das Unternehmen, in dem ich arbeite, strebt eine maximale Fehlerquote von 10% an. Sie erwarten, dass Analysten die Schätzung nicht um mehr oder weniger als 10% verfehlen.

Ich weiß nicht, was ich davon halten soll, da ich nichts zu vergleichen habe.

Was könnte eine gute Basis sein, um zu messen, wenn wir mehr oder weniger zu falsch einschätzen? Wie viel (in%) ist es Ihrer Meinung nach in Ordnung , etwas zu verpassen?

+/- 10% sind lächerlich optimistisch, es sei denn, Sie schätzen etwas sehr Ähnliches wie Sie und Ihre Kollegen. Ihr Management hat entweder nicht viel Erfahrung mit Software, oder es sind keine großen Grenzen für die Softwareschätzung bekannt . Das Papier enthält einige unterstützende Materialien , und es gibt viele Experten .

Betrachten wir ein weitaus einfacheres System als ein typisches Softwareprojekt: Rubik's Cube. Sie können jede Position in 20 Zügen lösen , max. Da Sie jedoch schätzen, können Sie einen bestimmten Würfel nur einige Minuten lang betrachten, bevor Sie die Lösung angeben. Können Sie eine gute Schätzung abgeben? Nein, manchmal dauert das Abschätzen eines Prozesses länger als das Ausführen des Prozesses.

Ein weiteres einfaches System: Pinocchio. Als hölzerner Automat wächst sein Nasenstück, wenn er lügt. Was passiert, wenn Pinocchio ruht und dann sagt "Meine Nase wächst"? Einige Systeme sind nicht vorhersehbar, sie sind unentscheidbar.

Diese beiden Probleme sind in den meisten Softwaresystemen enthalten. Aus diesem Grund erhalten Sie niemals Schätzungen in der Nähe von +/- 10%.

Mein Rat ist, eine stark gepolsterte Schätzung abzugeben, wie ein Sklave zu arbeiten, um das Projekt so schnell wie möglich zu erledigen, und dann beschäftigt zu sein, bis Sie innerhalb von 10% unter oder über sind. Kündigen Sie an diesem Punkt einen spektakulären Erfolg an.

Ich würde jede Art von "Zielfehlermarge" sehr zögern, da dies wirklich vom Projekt abhängt. Wenn Sie abschätzen möchten, wie lange es dauern wird, ein neues CRM-System zu installieren, zu konfigurieren und anzupassen, bei dem niemand genau weiß, welche Arten von Anpassungen erforderlich sind und welche Änderungen an Geschäftsprozessen erforderlich sind Das Unternehmen hat in der Vergangenheit keine vergleichbaren großen Projekte. Ihre Fehlerquote sollte ziemlich hoch sein (dh Sie können davon ausgehen, dass es 18 Monate +/- 50% dauern und 9-27 Monate dauern wird). Im weiteren Verlauf des Projekts werden die Spezifikationen klarer, Entscheidungen über Geschäftsprozesse werden getroffen, Ihre Entwickler fühlen sich wohler usw. Diese Fehlergrenzen sollten enger werden. Wenn Sie abschätzen möchten, wie lange es dauert, bis die 101. grundlegende E-Commerce-Website erstellt wird, wenn Sie Wenn Sie von den ersten 100 eine gute Historie erhalten haben, sollten Sie in der Lage sein, eine viel genauere Schätzung abzugeben. Die meisten Projekte werden jedoch irgendwo in die Mitte fallen.

Wenn Sie nun eine einzelne Zahl anstelle eines Bereichs angeben, besteht die Antwort wahrscheinlich darin, den Bereich anzugeben, damit die Person, die die Schätzung vornimmt, angeben kann, wie genau sie ihre Schätzung erwartet.

Eine gute Basis wäre eine, die auf den von Ihnen gesammelten realen Daten basiert .

Der erste Schritt dazu ist das Aufzeichnen aller Schätzungen . Der zweite Schritt ist das Aufzeichnen der tatsächlichen Ergebnisse . Seien Sie ehrlich, lassen Sie sich nicht dazu verleiten, das Tatsächliche selbst anzupassen. Sammeln Sie genug dieser Informationen und Sie haben einige statistische Daten, um festzustellen, wie gut Ihre Schätzungen sind. Beachten Sie, dass dies je nachdem, wer die Schätzung vorgenommen hat und wer die Arbeit geleistet hat, stark variieren kann / wird. Nur wenn Sie dies tun, können Sie vernünftigerweise erwarten, dass Sie eine "Fehlerquote" erhalten, die alles andere als reiner Müll ist.

Auch hier hört es nicht auf; Durch die Analyse der Ursachen für die Abweichung der Schätzungen können Sie die Genauigkeit Ihrer zukünftigen Schätzungen verbessern. Hinweis: Es handelt sich weiterhin um Schätzungen und somit nur um Schätzungen .

Die Schätzung endet auch nicht nach der ersten Schätzung. Dies kann im Verlauf des Projekts angepasst werden, wenn mehr Wissen gesammelt wird. Dadurch wird die mögliche Fehlerquote verringert. Je offener Sie mit der Kommunikation sind, desto früher werden Überraschungen besprochen - was dazu führt, dass die Leute weniger überrascht sind und mehr Zeit haben, um Anpassungen an den Projekt- oder Kundenerwartungen vorzunehmen.

Zweitens besteht ein besserer Weg, die Fehlerquote zu handhaben, darin, die internen Vertrauensbereiche zu bestimmen und nicht nur die Fehlerquote in Prozent. Sie haben das geschätzte Lieferdatum nicht auf einem einzelnen Datum, sondern auf einem Konfidenzintervall basiert.

PERT ist ein Beispiel für ein Framework, mit dem Schätzungen basierend auf statistischen Überlegungen durchgeführt werden können. Beispielsweise:

"Basierend auf dem, was ich jetzt weiß, haben wir ein Konfidenzniveau von 90%, das wir in 8 Monaten liefern können. 95% Konfidenz in 10 Monaten, 99% Konfidenz in 2 Jahren usw."

Beachten Sie hier: Je sicherer Sie gewünscht werden, desto höher ist die Schätzung. Abhängig von der Komplexität (auch bekannt als mögliche Genauigkeit) kann es sich um einen kleinen Unterschied zwischen 80% und 90% handeln oder um einen großen Unterschied!

Lastly - Good luck;) Wenn Sie jemals eine "maximale Fehlerquote" bei der Softwareschätzung lösen, bei der Sie so etwas wie "Alle unsere Schätzungen betragen +/- 10%" angeben können, sollten Sie für den Rest des Jahres einen Kinofilm in Auftrag geben uns in der Software-Branche. Ich denke so etwas wie eine Kreuzung zwischen Office Space und The Matrix: D

Tatsächlich hängt es stark von der Größe und Komplexität des Projekts ab.

Wenn Ihre Projektschätzung 1 Woche beträgt, sind 10% angemessen. Es bedeutet +/- 1/2 Tag.
Wenn es 1 Monat ist, sind 10% wackelig - aus meiner Erfahrung ist es unmöglich vorherzusagen, was Sie in 1 Monat entdecken werden.

Mehr als einen Monat - alle Wetten sind ungültig :).

Diese sind pro Entwickler - also für 4 Entwicklerteams 1 Woche == 1 Monat.

Für ein 4-Entwickler-Team ist es meistens gut, eine Liste von Funktionen zu erstellen, die in einem Monat ausgeführt werden können, und für diese Funktionen innerhalb von 10% zu liegen. Schätzen Sie dann für den nächsten Monat neu.

Ich habe hier einige naive Annahmen getroffen

1. Alle Entwickler können parallel arbeiten.
2. Habe nicht als Tester angesehen - sie sollten etwas Zeit zum Testen haben
3. Alle Entwickler sind gleich - Frontend, Backend, Designer etc ...

Man muss diese einkalkulieren, aber das ist die allgemeine Idee.

Es gibt viele Variablen:

1. Wie lange dauert das Projekt?

2. Wie wird das Projekt verwaltet? Wasserfall? Agil? GEDRÄNGE?

Ich würde von der Frage Wasserfall ausgehen. Wenn dies der Fall ist, wird bei der Anforderung einer Spanne mit einem gewissen Prozentsatz von einem Scheitern gerechnet.

Wenn die Antwort eine agile Methodik ist, insbesondere so etwas wie SCRUM. Es spielt keine Rolle, wie hoch der Prozentsatz der Gewinnspanne ist. Eine 50% ige Fehlerquote bei einem 2-wöchigen Sprint beträgt 1 Woche, bei einem 1-wöchigen Sprint 2,5 Tage, beides extrem schlimmste Szenarien. Dies liegt daran, dass der Liefertermin bei jedem Sprint neu geschätzt wird und im Laufe der Zeit immer genauer wird, anstatt immer weniger.

Mit Waterfall sind 50% der Fehler nicht unbekannt, aber bei einem 12-monatigen Projekt, das 6 Monate dauert, wird es nicht wirklich entdeckt / zugegeben, dass es bis 10 Monate nach dem 12 so schlimm ist.

Damals, als ich Softwareteams ungefähr um die Kreide- / Tertiärgrenze herum leitete, kamen wir der Schätzung von +/- 10% sogar nahe. Es war ungefähr +/- 15%, wenn mein sehr zwielichtiges Gedächtnis dient. Dies war jedoch darauf zurückzuführen, dass wir eine Schätzung für bereits erledigte Aufgaben vorgenommen hatten : relativ einfache Echtzeit-Kommunikationsfirmware, die Bytes von A in einer von uns entworfenen Echtzeitumgebung in einer uns vertrauten Sprache nach B verschob im gespräch mit hardware, die von jungs ein paar büros weiter im haus entwickelt wurde. Viele kleine Varianten zum obigen Thema, buchstäblich seit Jahren .

Offen gesagt ist es lächerlich, zu erwarten, dass diese Art von Fehlerrate bei der normalen Schätzung von Softwareprojekten erreicht wird . Wenn man sieht, dass es anscheinend erreicht wurde, liegt es daran, dass entweder die Leute überbewertet und aufgefüllt sind (zusätzliche Dinge und Haustierprojekte, um das Budget aufzubrauchen), oder dass sie unterbewertet und wie Hunde am Abend und am Wochenende gearbeitet haben, um die Zeit wieder gut zu machen.

Sie haben wahrscheinlich die 300% Sache richtig gehört?

Ich benutze es tatsächlich. Vollständig basierend auf dem, was ich seit Jahren gesehen habe. Wenn ich ein oder zwei Tage höre, ist das eine Woche oder länger, die wirklich getan werden muss . Und getestet. In allen Umgebungen. Dokumentation aktualisiert. Usability getestet. Leistung getestet. Last getestet. Ein paar Stunden sind eher ein Tag.

Ich denke, wir schätzen sehr schlecht, weil:

• Anderen helfen
• Immer unterbrochen
• Neue Leute ausbilden
• Andere Sachen kommen auf
• Krank oder unwohl werden
• Menschen abdecken, die gehen
• Urlaub oder Freizeit brauchen
• Von anderen abgelenkt werden
• Von anderen Gruppen aufgehalten werden
• Übermäßig optimistisch gegenüber realistisch
• Keine Zeit für die Bearbeitung von zeitweiligen Testfehlern
• Einfaches Ausschließen von Testzeiten, insbesondere Schreiben automatisierter Tests

Auf höchster Ebene streben wir also bei Geschäftsleuten, die Schätzungen von mehr als 300% benötigen, nach einigermaßen guten Schätzungen, aber zu dem Preis, dass sie höher und allgemeiner sind. "Wir werden eine Benutzerbearbeitungsfunktion haben", auch wenn Version 1 nur für 1 Benutzergruppe zum Ändern von 1 Feld bedeutet.

Wenn es um "Was ist die akzeptable Fehlerquote bei der Schätzung einer Projektdauer?" Ich stelle fest, dass dieser Ansatz, der in vielen agilen Umgebungen verwendet wird, dazu beiträgt, die Frage auf die Mindestfunktionalität zu ändern, um eine Alpha- oder Betaversion live zu bekommen und sie dann zu wiederholen.