Geschwindigkeit und Genauigkeit der Softwareschätzung

Question

Nehmen wir an, Sie haben ein Projekt, das zwei Webanwendungen umfasst (die DAL/DAO/BO-Assemblys und einige OSS-Bibliotheken gemeinsam nutzen):

• Eine halbkomplexe Verwaltungsanwendung, die Windows Live ID zur Authentifizierung verwendet und auch mit verschiedenen Benachrichtigungsdiensten (E-Mail, SMS, Twitter usw.) kommunizieren kann, wobei gezielte Benachrichtigungen etwa 10 % der Funktionalität ausmachen
• Eine einfache bis halbkomplexe Benutzeranwendung mit weniger Funktionalität, aber höherer Robustheit, die auch Windows Live ID zur Authentifizierung verwendet

Wir sind zu zweit mit mittlerem Schätzvermögen und würden es nicht in zwei Tagen schaffen, selbst wenn wir wollten/müssen.Zumindest wäre es ein weit weg schätzen.

Fragen

1. Wie lange würde/brauchen Sie normalerweise, um eine zuverlässige/wertvolle Schätzung zu erstellen?
2. Was würden Sie vorschlagen, um die Schätzung zu beschleunigen, ohne die Genauigkeit zu beeinträchtigen?
3. Wie viel Spielraum (in Bezug auf Kosten/Zeit) würden Sie abhängig von der Schätzgeschwindigkeit hinzufügen (wenn Sie sagen würden: Ich könnte es etwas genauer einschätzen, weil ich denke, dass es immer noch ziemlich daneben liegt)

Answer 1

Interessante Frage. Ich fürchte, die Antwort ist „es hängt wirklich!“ Ich weiß, dass nicht sehr nützlich ist (obwohl es wahr ist), so sind hier einige Faktoren:

1) Qualität und Vollständigkeit der Anforderungen und ihre Spezifikation. Dies ist für mich, am häufigsten der Projekt-Schätzung Killer. Wenn Sie keine Qualitätsanforderungen haben, haben Sie keine ausreichende Grundlage für eine Schätzung. Wir verwenden einen „RUP-lite“ Stil der Produktentwicklung hier, also als Manager Engineering ich nichts geben, aber die gröbsten Korn Schätzung, bis wir unsere „Ausarbeitung“ -Phase und bekamen Sign-off aus dem Produktmanagement abgeschlossen haben, dass der Kern 80% der Produkteigenschaften sind in der Tat genau abgedeckt.

2) Der Umfang und Art des Produkts. Bigger / teurer / mehr kompliziert = wesentlich länger zu schätzen. Ich habe Jahre damit verbracht, in Telco-Carrier-Land arbeiten die Bereitstellung von Lösungen, die die normalen robusten Träger Anforderungen ( „5 9s“ von uptime durch SLA erforderlich meinen Sie wirklich einen guten Job Lösungsdesign und Fehlerbehebungs tun müssen!). In dieser Art von Umgebung mit allen beweglichen Teilen über Funktionsbereiche des Unternehmens, ist die Schätzung der Arbeit auf immer das ganze Bild Scharnier gehen ... speziell, funktionsübergreifende Abhängigkeiten und externe Abhängigkeiten können hier ein echter Killer sein. Das heißt, ich habe auch eine Menge eingeschweißten und Enterprise-Software auch gebaut. In diesen Umgebungen ist es viel einfacher, da der Umfang der Regel wesentlich kleiner, so somit leichter zu schätzen ist.

3) Wie "neu" ist dieses Projekt? Wie „neu“ ist das Team zu diesem Produkt oder eine Technologie-Set? Die neuere das Produkt oder das Team, desto länger und Puffer sollten Sie zuweisen.

4) Wie spezifisch brauchen wir sein? Wenn dies eine „grobe Schätzung“ ist, dann werde ich Anlehnen meiner Technik führt eine konservative Schätzung zu schaffen, dann werde ich Pad, dass. Wenn wir eine „echte“ Schätzung (zB eines, das von meinem Chef verwendet wird und die ich für das Schlagen verantwortlich sein werde) benötigen, würde ich die Eingabe von einer Anzahl verschiedenen Manager und Teammitgliedern muß, die Zeit benötigen, um analysieren die Anforderungen und confer untereinander.

Das kann so wenig wie ein paar Tage dauern, oder weeks..it hängt alles von der Größe. „Zwei oder drei Tage“ sind, ehrlich gesagt, nicht lange genug, um etwas Schlichte aber die banalsten von Projekten.

Das Beste, was Sie tun können, um die Qualität Ihrer Schätzungen zu verbessern, um die Qualität Ihrer Anforderungen zu verbessern, und seine rücksichtslos in verborgene Abhängigkeiten zu identifizieren.

Eine letzte Sache. FWIW, ich habe dies seit '81 getan und ich betrachte die Schätzung genau eine Dauer / Kosten, wie die einzelne schwierigsten / voller Gefahren Teil des Engineering Management des Projekts

Answer 2

Da wir Agile Methoden (Scrum, speziell) dauert es uns ungefähr eine Stunde länger, als es die Nutzer nimmt zu priorisieren.

Mehr Zeit nicht zu mehr Genauigkeit führen.

Der harte Teil, dann wird immer die Benutzer zu priorisieren. Wir hören diese Diskussion die ganze Zeit „wenn die ganze Sache nicht rechtzeitig abgeschlossen ist, es ist alles wertlos.“ „Mit Ausnahme der XYZZY Komponente, die einen gewissen Wert hat.“ Dieses Argument kann stundenlang weitergehen, bis es gelöst ist, dass XYZZY sollte zuerst sein.

Generell versuchen wir, 4-wöchige Sprint zu erstellen. Die ersten sind kompliziert, weil es immer etwas Neues. Nachdem die ersten beiden (oder drei) scheinen wir einen stetigen Tempo zu setzen.

Jeder Anwendungsfall hat eine relativ einfache, subjektive Bewertung, wie sich die Mühe wird es dauern, es zu beenden. Alles, was über einen vollen Sprint Dauer hat zerlegt werden. Die meiste Zeit einige Anwendungsfälle sind in einem einzigen Sprint gebündelt.

Das sind formale Möglichkeiten der Bewertung aller Anwendungsfall besser in den Griff, die Kosten und den Zeitplan Fragen. Wir benutzen sie nicht, weil der zusätzliche Aufwand nicht hilft.

Nach den ersten beiden Sprinten,

1. Es gibt neue und andere Funktionalität,

2. Die Prioritäten haben alle geändert,

3. Die Details der einzelnen Anwendungsfall drastisch überarbeitet.

Was bedeutet „Genauigkeit“ bedeuten, wenn das Ding Sie versuchen, Änderungen am Ende eines jeden Sprints zu schätzen?

---

Eine Lektion gelernt. Teile meiner Firma ein verbringen lang Zeit vollständig definiert, genau , was geliefert wird, und dann messen, dass sie liefern genau das, was sie wollen.

Kunden bemerken dies, und man sagte, dass wir „eine Menge Zeit damit verbringen, das liefern, was der Vertrag sagt, aber es ist nicht das, was wir brauchten.“

Das Problem mit festen Upfront-Schätzungen ist, dass sie auf einem Eigenleben nehmen. Je mehr Sie „investieren“ in der Schätzung, desto mehr werden die Schätzungen scheinen eine nützliche lieferbar zu sein. Sie sind nicht geeignet, da sie in der Regel völlig falsch sind. Sie basieren auf Upfront-Annahmen, die völlig falsch sind.

Es ist eine schlechte Politik zu investieren mehr Zeit bei der Schätzung. Die „genaue“ Antworten sind nicht mehr genau, aber sie sind mehr von jeder Schicht des Managements geschätzt. Wie Sie und der Kunde erfahren, ungültig machen Sie zahlreiche Annahmen und müssen Sie unbedingt immer wieder neu schätzen.

Tun Sie es nicht nach vorne. Wenn Ihr Vertrag erfordert, dass Sie es tun vorne, dann stellen Sie sicher, haben Sie eine Steuerrückstellung ändern und den Kunden sagen, dass Sie absolut wird Änderungen vornehmen, wie Sie vorwärts gehen. Als beide Sie und der Kunde erfahren, Sie beide muss Änderungen vornehmen.

Answer 3

Um eine verlässliche Schätzung machen Sie wirklich eine Liste von Aufgaben erledigt werden müssen, erstellen. Brechen sie in Geschichten / Aufgaben (auch wenn Sie nicht agil verwenden) und werten sie aus. Dies kann schon eine Menge Zeit in Anspruch nehmen - vor allem die Menge an Forschung (zu suchen Bibliotheken diese Notifier Sachen zu tun, um die Kosten zu reduzieren). Ich würde mindestens 3 Tage in Anspruch nehmen - aber 1-2 Woche (n) Sound für mich mehr zumutbar ist. Dies scheint nicht ein kleines Projekt zu sein.

Ich würde nicht auf Speed-up der Schätzungsprozess wagen, wenn Sie wan't etwas vernünftige Ergebnisse zu haben. Tendenzen sind nie genau, und Sie werden nur noch schlimmer machen.

Eine Option wäre eine ganz grobe Schätzung innerhalb weniger Stunden zu machen und dann zu Arbeit daran beginnt bereits (für eine Woche oder so). Am Ende der Woche könnten Sie in der Lage sein, eine bessere Einschätzung zu geben, basierend auf dem aktuellen Stand. Allerdings ist es wichtig, einen guten Prototyp zu erstellen (das sieht aus wie Mist, aber ein wenig Code in allen Regionen hat).

Answer 4

Ein gängiges Zitat lautet: „Der Preis wird zwischen 50 % und 400 % unserer ursprünglichen Schätzungen liegen.“Der Grund dafür, dass dieses Zitat so groß geworden ist, liegt darin, dass es wahr ist.Die Genauigkeit der Schätzung hängt weitgehend von Ihren Fachkenntnissen ab.Wenn dies das 100. Mal ist, dass Sie einen bestimmten Blog-Engine-Typ verkauft haben, sind Sie sich bei den Schätzungen ziemlich sicher.In den meisten Fällen verfügen Sie jedoch nicht über umfassende Kenntnisse der Domäne (Wenn die App bereits vorhanden ist, warum sollten Sie dann eine neue erstellen?).

Agile Entwicklung ist populär geworden, weil die Menschen weitgehend erkennen, dass die traditionelle „Wasserfall“-Denkweise für die meisten realen Projekte einfach nicht funktioniert.Sie sollten bei Ihren Schätzungen die gleiche Denkweise anwenden.Natürlich brauchen Sie ein Verkaufsargument, aber sagen Sie Ihren Kunden unbedingt, dass diese Informationen sehr vage sind (und dass ihre Schätzungen, egal was ein Wettbewerber ihnen sagen wird, ebenfalls vage sind).

Sie müssen Iterationen verkaufen und daher auch Iterationen schätzen.Ich bin mir sicher, dass irgendein Marketing-Typ in jedem Unternehmen weiß, wie man mit dem Papierkram und den rechtlichen Angelegenheiten dafür umgeht, also sollte es keine so große Sache sein.

Betrachten Sie ein Projekt mit 5 Iterationen:

• Beginnen Sie damit, Meilensteine ​​festzulegen.Diese können sich ändern, liefern aber Ihre ersten Schätzungen für das Endprodukt.
• Planen Sie Iteration Nr. 1.
• Schätzeniteration Nr. 1, Gesamtschätzungen entsprechend anpassen.
• Führen Sie Iteration Nr. 1 durch
• Spülen/wiederholen bis Iteration Nr. 5
• Du bist fertig :)
• Denken Sie über Ihr Projekt nach.Wie haben sich Ihre Schätzungen entwickelt?Gründe dafür?Lerne beim machen :)

Die meisten Kunden hätten lieber Teilschätzungen und Teillieferungen als ein unrealistisches Ziel, das ihnen irgendein Anzug verkauft :)

Answer 5

etwas von Ihrer ursprünglichen Frage streunen, aber es ist auch wichtig, von den Schätzungen zu erfahren, dass Sie in der Vergangenheit produziert haben, indem sie Informationen zu halten, wie es lange tatsächlich nahm die Dinge zu tun, dass Sie geschätzt.

Wir 5 Tage geschätzt, diese Seiten zu produzieren, es dauerte tatsächlich 10 Tage, etc.

Auf lange Sicht Informationen wie diese (hoffentlich!) Ermöglicht es Ihnen, genauere Schätzungen zu produzieren.