Warum sind Software-Zeitpläne so schwer zu definieren?

39

Meiner Erfahrung nach ist es so, als würde man Zähne ziehen, wenn man uns Ingenieure dazu bringt, die zu erledigenden Aufgaben genau abzuschätzen und zu bestimmen. Anstatt nur eine Swag-Schätzung von 2-3 Wochen oder 3-6 Monaten anzugeben ... Was ist der einfachste Weg, um Software-Zeitpläne zu definieren, deren Definition nicht so schmerzhaft ist? Zum Beispiel möchte Kunde A eine Funktion bis zum 01.02.2011. Wie können Sie Zeit für die Implementierung dieser Funktion einplanen, da Sie wissen, dass andere Fehlerkorrekturen erforderlich sein können, und zusätzliche Entwicklungszeit in Anspruch nehmen?

Brian
quelle
33
Ich habe einen wirklich wunderbaren Beweis gefunden, dass es unmöglich ist, alle komplexen Entwicklungsaufgaben genau zu schätzen oder diese Aufgaben perfekt zu planen, oder im Allgemeinen jeden Zeitplan, der auf Schätzungen basiert. Dieses Kommentarfeld ist zu klein, um es zu enthalten.
Dan McGrath
2
@ Dan McGrath: Warum postest du keinen Link, der den Beweis enthält? Warten Sie, versuchen Sie, wie Fermat und sein letzter Satz Beweis zu sein, der nie gefunden wurde:
Shamim Hafiz
9
Aus dem gleichen Grund, dass es schwierig ist, eine Reise zu planen, wenn der Navigator das Ziel nicht kennt, der Fahrer die Straßen nicht kennt und alle Passagiere Eis möchten.
Steven A. Lowe
1
Etwas, das Sie interessieren könnte, ist Evidence Based Scheduling.
Craige
2
Sie sind nicht schwer zu definieren. Einfach unmöglich zu halten.
Tony Hopkinson

Antworten:

57

Wenn Sie mit vertrauten Tools und einem vertrauten Team ein Projekt starten, das mit anderen Projekten fast identisch ist, und Sie feste schriftliche Anforderungen haben, sollte es möglich sein, eine gute Schätzung vorzunehmen.

Dies sind die Bedingungen, denen Maler, Teppichbauer, Landschaftsgestalter usw. regelmäßig ausgesetzt sind. Aber es passt nicht zu vielen (oder den meisten) Softwareprojekten.

Wir werden oft gebeten, Projekte einzuschätzen, die neue Tools, Technologien, sich ändernde Anforderungen usw. Verwenden. Dies ist mehr eine Extrapolation ins Unbekannte als eine Interpolation über unsere vergangenen Erfahrungen. Es ist daher selbstverständlich, dass die Schätzung schwieriger sein wird.

Rob Weir
quelle
20
Hervorragende Punkte. Es ist so, als würden Sie fragen, wie lange Sie brauchen, um irgendwohin zu fahren, wo Sie noch nie waren. Sie können eine Schätzung basierend auf der Entfernung abgeben, aber Sie können das Verkehrsaufkommen während der Hauptverkehrszeit nicht berücksichtigen.
JeffO
2
@ Jeff Das ist ein sehr guter Vergleich. Ich muss mich daran erinnern
Dave McClelland
1
@ Jeff ... aber man kann es bekannt Rushhour ist und diese Tatsache Ihre Schätzungen hinzufügen ... Sie noch aus sein könnte, aber nicht so viel
Pemdas
2
@Pemdas: Eigentlich können Sie nicht genug wissen, um alle Fakten zu Ihren Schätzungen hinzuzufügen . Sie können nicht wissen, ob die Feuerwehr auf einen Anruf reagiert. Sie können nicht wissen, ob ein Stromkabel heruntergefallen ist und die Straße blockiert. Es gibt unendlich viele Dinge, die Sie über die Zukunft nicht wissen können. Es ist die Zukunft. Es ist schwer vorherzusagen - per Definition.
S.Lott
1
@Pemdas - je komplexer die Aufgabe, desto mehr stören sich die Götter des Chaos. Natürlich passt das wahrscheinlich mehr zu Ihrem Standpunkt als zu einigen der Kommentare - bei vertrauten Aufgaben wissen Sie, wie interessiert diese lästigen Götter sind.
Steve314
35

Nach meiner persönlichen Erfahrung ist es genau das Gegenteil von dem, was Pemdas gesagt hat : Mit der Übung habe ich nur verstanden, dass es absolut unmöglich ist, abzuschätzen, wie viel Zeit eine Aufgabe benötigt. Zu Beginn meiner Karriere in der Softwareentwicklung gab ich oft Schätzungen wie "45 Tage", "fünf Wochen" usw. an und bemühte mich dann sehr, sie rechtzeitig abzuschließen. Einige Jahre später begann ich, weniger genaue Schätzungen wie "ungefähr einen Monat", "fünf bis sieben Wochen" usw. zu machen. Eigentlich versuche ich entweder, keine Schätzung abzugeben oder den Kunden zu bitten, seine eigene Schätzung abzugeben oder Frist oder ich gebe eine Schätzung so grob wie möglich.

Warum ist es so schwierig, eine Schätzung zu haben? Weil es fast unmöglich ist zu wissen, wie der gesamte Quellcode geschrieben wird, bevor er tatsächlich geschrieben wird, und weil Ihre Arbeit von zufälligen Dingen abhängt, wie sie von anderen Leuten ausgeführt werden, von Ihrer Motivation usw. Im Folgenden finden Sie eine detailliertere Liste der möglichen Gründe:

  1. Es ist nicht leicht zu wissen, was genau erforderlich ist, um ein Produkt zu produzieren, und insbesondere, wie es gemacht wird . Sehr oft habe ich einige Teile einer Anwendung gestartet, als ich nach Tagen der Arbeit begriff, dass mein erster Ansatz falsch war und dass es eine bessere und intelligentere Möglichkeit gibt, Dinge zu tun.

  2. Einige Probleme können auftreten . Wenn Sie beispielsweise auf Ihrem Computer einen ausgefallenen SQL-Server installieren müssen, die Installation fehlschlägt und der Support nicht vorhanden ist, können Sie dieses Problem wochenlang beheben.

  3. Anforderungen sind oft nicht klar genug , aber nachdem Sie sie zu Beginn gelesen haben, denken Sie, dass dies der Fall ist. Manchmal kann man verstehen, dass der Mittelwert 'A' ist, und wenn man mit der Implementierung begonnen hat, merkt man, dass sie möglicherweise 'B' bedeuten.

  4. Kunden mögen es, ihre Anforderungen genau dann zu ändern, wenn Sie das betreffende Teil gerade abgeschlossen haben , und sie verstehen wirklich nicht, warum Sie zwei weitere Wochen und 2000 USD für eine geringfügige Änderung verlangen , weil sie nicht sehen, dass diese geringfügige Änderung erforderlich ist andere Dinge ändern, die es erfordern, andere zu ändern, usw.

  5. Sie können Ihre Motivation nicht einschätzen . Es gibt Tage, an denen Sie stundenlang arbeiten und erfolgreich sein können. In einigen Wochen wechseln Sie nach dem Schreiben von zehn Codezeilen zu Programmers StackExchange und verbringen Stunden damit, Fragen zu lesen und zu beantworten.

  6. Dinge werden wirklich schlimm, wenn Ihre Schätzung von anderen Menschen abhängt . Zum Beispiel musste ich in einem zweimonatigen Projekt darauf warten, dass ein Designer seine Arbeit erledigte, um meine eigene fertigzustellen. Dieser Designer brauchte 3 Monate, bis er ein Stück unbrauchbaren Müll geliefert hatte. Natürlich war das Projekt zu spät.

  7. Ihre Schätzung hängt auch von Ihrem Kunden ab . Ich hatte Kunden, die Wochen damit verbracht haben, ihre E-Mails zu beantworten. Dies kann sich sehr auf Ihren Zeitplan auswirken, wenn Sie auf deren Antwort warten müssen (zum Beispiel, wenn Sie sie bitten, eine Anforderung zu präzisieren).

Was kannst du tun?

  1. Geben Sie einen größeren Zeitplan . Wenn Sie glauben, dass Sie die Arbeit in zwei Wochen erledigen können, sagen Sie, dass Sie sie in einem Monat liefern werden.

  2. Sei klar . Wenn Sie sich auf einen Designer, einen anderen Entwickler usw. verlassen, sagen Sie es. Anstatt zu sagen "Ich werde das Produkt in drei Monaten liefern", sagen Sie "Ich werde das Produkt in zwei Monaten liefern, nachdem der Designer mir PSD-Dateien gegeben hat."

  3. Erklären Sie, dass das Projekt kaum rechtzeitig geliefert werden kann, wenn sich die Anforderungen täglich ändern.

  4. Schneiden Sie Ihren Zeitplan . Es ist einfacher, Teile eines großen Projekts rechtzeitig zu liefern.

  5. Geben Sie niemals eine Schätzung ab, wenn Sie ein Produkt verwenden, das Sie nicht genau kennen, oder wenn Sie an einem Quellcode einer anderen Person arbeiten: Sie können niemals vorhersagen, wie beschissen der Quellcode sein kann und wie viel Zeit Sie verbringen werden Verstehen Sie es und kopieren Sie es in The Daily WTF.

Arseni Mourzenko
quelle
1
@ Jeff O: Ich weiß es nicht. Ein Liefertermin bedeutet für mich eine Frist. Und eine Frist bedeutet, dass das Projekt nicht nachgeliefert werden kann. Auch psychologisch sind Kunden möglicherweise weniger verärgert, wenn Sie sagen, dass Sie etwas in einem Monat und vier Tage später ausliefern, als wenn Sie am 8. Januar 2011 sagen, dass Sie es am 8. Februar 2011 ausliefern und Sie Bring es am 12. Februar.
Arseni Mourzenko
10
@Pemdas: Es geht nicht um Faulheit. Sie können einfach depressiv sein, vorübergehend Konzentrationsschwierigkeiten haben, persönliche / familiäre Probleme haben oder von anderen Kunden oder was auch immer zu stark belastet werden.
Arseni Mourzenko
2
Zusätzlich zu den Punkten von MainMa gibt es Situationen, in denen jemand aus Freude oder Krankheit in Urlaub sein muss, wenn Sie in einem Team arbeiten.
Shamim Hafiz
5
@Pemdas Sie passieren zu einem gewissen Grad mit jedem Programmierer. Es ist nur so, dass es sich in einer Weise manifestiert, die nicht immer offensichtlich ist. Eine Woche, in der ein bestimmtes Problem bearbeitet wird, kann 3 Stunden dauern, da Sie sehr scharf und "in der Zone" sind. In der nächsten Woche sind es 3 Tage.
Matthew Frederick
7
@ 0A0D Wenn Sie das Projekt in seine detailliertesten Teilaufgaben aufteilen und genau herausfinden, wie jede von ihnen funktionieren wird, müssen Sie alles durcharbeiten, um sicherzustellen, dass Sie die Auswirkungen der Kombination dieser Teile verstehen, und alle neuen oder nicht aktuellen Aufgaben gründlich prüfen. Wenn es um In-Your-Mind-Technologien geht und Sie jedes Unbekannte aus dem Weg räumen, können Sie absolut eine verdammt genaue Schätzung abgeben. Natürlich haben Sie auch fast die gesamte Programmierung vorgenommen und nur den Codierungsteil belassen, und Sie können nicht im Voraus wissen, wie lange die gesamte Schätzung dauern wird. ;)
Matthew Frederick
15

Eine sehr ähnliche Frage lautet: "Wie lange wird es dauern, bis dieses Kreuzworträtsel gelöst ist?"

Sie können das erst beantworten, wenn Sie sich die folgenden Dinge angesehen haben:

  • Ist es in einer vertrauten Sprache? (Spanisch gegen Englisch gegen Chinesisch)
  • Ist es ein Typ, den wir zuvor gelöst haben? (Einer aus einer Reihe, die in einer Zeitschrift läuft, zB)
  • Benötigen die Leads zusätzliches Wissen, bevor wir es überhaupt verstehen können?
  • Gibt es irgendwo im Puzzle Dinge, die nach Ihrer Kenntnis zusätzliche Arbeit erfordern?

Da ein Projekt in der Regel mehrere neue Elemente enthält (andernfalls handelt es sich nicht um ein Projekt), können Sie nicht sagen, wie lange die Lösung dauert, bis Sie sie sorgfältig überprüft haben. Vielleicht lösen Sie sogar mehr oder weniger, und dann sind Sie sich immer noch nicht sicher, ob es nicht die ein oder andere Überraschung gibt, an die Sie nicht gedacht haben.

Es besteht auch ein starker Druck, dies so billig wie möglich, also so schnell wie möglich, zu tun, und die Schuld für eine zu niedrige Schätzung liegt nicht beim Projektmanager, der Druck ausübt, sondern beim Entwickler, der die Schätzung abgibt. Es dauert nicht viele Iterationen, bis der Entwickler dies feststellt und lernt, SEHR müde zu sein, absolute Zahlen preiszugeben.

Jim G.
quelle
11

Der offensichtlichste Grund, warum Ihre Ingenieure Ihnen keine genauen Schätzungen geben können, ist, dass dies unmöglich ist .

Natürlich können Sie abschätzen, wie viel Zeit + -2 Minuten von zu Hause zur Arbeit benötigt werden. Sie wissen, wie man ein Auto fährt, Sie können den Verkehr und einige andere externe Faktoren bewerten.

Sagen Sie mir, wie lange Sie brauchen, um von London nach Barcelona zu fahren. Natürlich ohne fortgeschrittene GPS-Planungstools. Mit der guten alten Methode, wie wir sie immer noch in der Software-Schätzung anwenden. Empirische Schätzungen und Vorhersagen .

In der Software ist es schlimmer:

  1. Schätzungen werden oft zu einer Verpflichtung , daher wird unser Urteil geändert.
  2. Es kann große Unterschiede zwischen der Einschätzung von Bob und Karl für dieselbe Aufgabe geben.
  3. Unsicherheiten sind sehr verbreitet. Wie viele von uns stecken in einem dummen Fehler oder einem Festplattenabsturz fest und zerstören jede scheinbar gute Einschätzung.
  4. Wir vergessen normalerweise alle anderen Aufgaben als das Programmieren, einschließlich Besprechungen, Telefonanrufe, Hilfe für unsere Kollegen usw.
  5. Das menschliche Gehirn ist begrenzt . Es wurde nicht entwickelt, um lang laufende Aufgaben abzuschätzen.

Aus diesem Grund können Sie Ihrem Kunden nicht genau sagen, was Sie für den 01.02.2011 versenden können, und den 01.03.2011 vergessen.

Um all diese Probleme anzugehen, empfehle ich Ihnen fortgeschrittene Schätztechniken wie Planning Poker (Haftungsausschluss: Dies ist eine meiner Websites) und Iterative Development with Velocity- Berechnung.

  • Die ersten beiden Probleme werden mit Planning Poker behoben. Schätzungen sind kollektiv und das Team besitzt sie eher als Einzelpersonen.
  • Die letzten drei Punkte werden mit Velocity und Iterative Development behandelt. Wenn Sie Ihre Geschwindigkeit kennen (der Faktor, der für Ihre Schätzungen auf der Grundlage des Verlaufs gilt), können Sie Releases mit größerer Sicherheit planen. Wenn die iterative Entwicklung erfolgreich abgeschlossen wurde, werden die wichtigsten Funktionen in den Vordergrund gerückt und Sie können Ihren Benutzern frühzeitig einen Mehrwert bieten.

quelle
Wenn also jemand nach einem Liefertermin für ein Feature am 01.02.2011 fragt, lautet die beste Antwort: "Sobald ich daran arbeite, werde ich Ihnen mitteilen, wie lange es dauern wird." Ich bin mir sicher, dass das wie ein Bleiballon übergehen würde;)
Brian
0A0D: es kommt auf die situation an. Mit einem Team, das sich nicht kennt, würde ich auf KEINE Frist wetten. Wenn Sie jedoch Ihre Durchschnittsgeschwindigkeit kennen, kollektive Schätzungen verwenden und die iterative Entwicklung üben, können Sie einen Termin mit viel größerer Sicherheit festlegen.
@ 0A0D, in Europa bedeutet der 01.02.2011 den 2. Januar. Zumindest erleichtert es die Antwort, wenn am 8. Januar gefragt wird: D
6

Softwareentwicklung ist per definitionem ein Akt der Entdeckung und Erfindung. Es muss sich immer um etwas Unbekanntes handeln.

Alles, was mit der Softwareentwicklung zu tun hat, ist nur bekannt, wenn die Software vollständig ist.

Das einzige Mal, dass es keine unbekannte Technologie oder Geschäftsfunktion gibt, ist eine vollständige, gepackte Lösung, die zum Herunterladen bereitsteht.

Der Grund, warum wir neue Software schreiben, ist, dass wir eine neue Funktion oder eine neue Technologie oder beides haben. Neu bedeutet neu - unbekannt - unvorhersehbar.

Da die Softwareentwicklung mit Neuheiten verbunden sein muss, kann der Entwicklungsaufwand nicht vorhergesagt werden.

S.Lott
quelle
3

Ehrlich gesagt denke ich, dass es nur Übung braucht. Wenn Sie irgendwann genug Code schreiben, sollten Sie "ziemlich" genau sein. Mein erster Chef glaubte, dass diese Fertigkeit wichtig genug war, dass er mich aufforderte, dies bei jedem Feature / Projekt, das ich implementierte, informell zu üben. Nach jedem Projekt überprüften wir die Schätzungen und versuchten herauszufinden, wo ich falsch liege. Irgendwann kriegt man den Dreh raus.

Pemdas
quelle
Einverstanden mit dem Review, aber ich bin wirklich neugierig: @Pemdas, neigst du dazu, mit nur geringfügigen Änderungen an den gleichen Problemen für jedes Projekt zu arbeiten? Beziehen Sie sich auf einigermaßen einfache Dinge, vielleicht einen weiteren RESTful-Service, der im Grunde nur Datenbanktabellenzeilen zurückgibt, oder so? Nachdem ich mit vielen Dutzend Programmierern zusammengearbeitet und auch Dutzende eingestellt habe, muss ich noch jemanden finden, der genaue Schätzungen für Probleme voller Unbekannter abgeben kann.
Matthew Frederick
Ich arbeite am selben Produkt, aber die Probleme ändern sich mit jedem Release. Ich gebe zu, dass ich nie etwas abschätzen musste, das mehr als 6-8 Monate in Anspruch genommen hat.
Pemdas
Perndas, nur zum Spaß: Wie lange dauert es, Ihr Produkt in C # oder Java umzuschreiben? In der Google Cloud laufen? Um Daten in OpenGL live zu visualisieren? Möchten Sie einen Endbenutzer-Client auf einer Wii ausführen?
Vielleicht ist unsere Definition von Schätzungen falsch. Es ist auf jeden Fall eine gewisse Zeit der Recherche erforderlich, bevor Sie eine vernünftige Schätzung abgeben können. In der Regel schließe ich meine Zeit bis zur Lieferung nicht ein. Ich kann keine dieser Fragen vernünftig beantworten, ohne vorher ein paar Nachforschungen anzustellen. Ich würde niemals davon ausgehen, eine Schätzung abgeben zu können, ohne die Technologien zu verstehen.
Pemdas
2

Es ist niemals einfach. Du versuchst nur besser zu werden.

Ein Vorteil des Aufteilens Ihres zu liefernden Codes in kleinere Teile besteht darin, dass die Kunden verstehen, was zu erwarten ist und wann es zu erwarten ist. Jetzt haben Sie eine Basislinie, die Sie als Referenz verwenden können.

Wenn sie eine genaue Definition eines Features haben, das sie zu einem definierten Zeitpunkt benötigen, müssen sie wissen, dass dieser Anforderung zusätzliche Ressourcen zugewiesen werden müssen. Sie gehen ein Risiko in Bezug auf die Schwere der auftretenden Fehler ein und wie lange sie andauern können, ohne dass sie behoben werden. Wenn etwas Wichtiges auftaucht, kehren Sie zum Kunden zurück und zwingen ihn zu einer Entscheidung. Behebe ich den Fehler oder stelle ich die Frist für die neue Funktion fest? Geben Sie ihnen genügend Informationen, um eine fundierte Entscheidung zu treffen.

Hoffentlich haben Sie genug Erfahrung in der Zusammenarbeit und haben sich genug etabliert, um vertrauenswürdig zu sein. Sie können nicht erwarten, dass sie den Entwicklungsprozess vollständig verstehen, aber Sie können ihnen das Gefühl geben, dass Sie sich ehrlich anstrengen und ihren Wissensmangel nicht ausnutzen.

JeffO
quelle
Ich habe nicht einmal über inkrementelle Releases nachgedacht. Dies ist ein großartiges Werkzeug, um dem Kunden einen sinnvollen Fortschritt zu verschaffen. Obwohl ich nicht mit "externen" Kunden zusammenarbeite, ist dies eine großartige Möglichkeit, Pipeline-Tests mit der Entwicklung durchzuführen.
Pemdas
2

Weil wir den Zeitplan zu früh machen. Siehe Construx des Artikels auf eine vorläufige grobe man tut, dann besser ein später. Auch wenn Sie nicht nachvollziehen können, wie Sie es bei früheren Schätzungen getan haben, ist es schwierig, besser zu werden. FogBugz macht das [ein Kunde von ihrem freien, kein anderer Interessenkonflikt].

Brian Carlton
quelle
2

Ich habe viel aus diesem Buch gelernt:

Software-Schätzung: Entmystifizierung der schwarzen Kunst

Kurz gesagt, um bessere Schätzergebnisse zu erhalten, machen wir Folgendes:

  1. alle bis auf triviale aufgaben werden von mehr als einer person geschätzt (in unserem fall zwei)
  2. wir teilen die aufgabe in kleinere aufgaben auf. Je mehr Aufgaben Sie haben, desto wahrscheinlicher wird Ihre Einschätzung gut sein - Gesetz großer Zahlen, wenn ich mich richtig an das Buch erinnere
  3. Wir schätzen das schlechteste, beste und wahrscheinlichste Szenario. Manchmal schätzt jeder von uns diese Baumszenarien ganz anders. Das heißt, wir müssen reden und es stellt sich normalerweise heraus, dass einer von uns die Aufgabe nicht verstanden hat. Hätte diese eine Person die Aufgabe alleine eingeschätzt, wäre dies falsch eingeschätzt worden.
  4. Wir setzen 3 Zahlen von oben in die Gleichung ein und erhalten die Schätzung (excell) k

Nachdem die Arbeit beendet ist und unsere Einschätzung falsch war, versuchen wir, Gründe dafür zu finden. Und dieses Wissen fließen wir in den nächsten Schätzprozess ein. Bisher ist dies das beste Verfahren, mit dem ich größere Aufgaben geschätzt habe. Wenn ich Aufgabe sage, meine ich Jobs, die von ungefähr 50-500 Stunden dauern.

Piotr Perak
quelle
1

Hinweis: Dies gilt wirklich nur für Projekte, bei denen Sie eine stundenweise Abrechnung gegen eine feste Pauschale vornehmen.

Normalerweise versuche ich, meinen Zeitplan so zu planen, dass er im Wesentlichen aus einer Reihe von SCRUM-Sprints besteht (unabhängig davon, ob ich SCRUM verwende oder nicht). Wenn ich den Zeitplan erstelle, bestimme ich die Länge jedes Sprints und die Funktionen für das Projekt. In der Regel müssen einige Funktionen zuerst ausgeführt werden, daher versuche ich, eine bestmögliche Schätzung (nicht zu verwechseln mit optimistisch) für diese Funktionen anzugeben, und für alle Funktionen, die gegen Ende des Projekts verfügbar sein werden, werden allgemeine Schätzungen erstellt. Nachdem ich die Features Sprints zugeordnet habe, versuche ich, 1 bis 2 Sprints am hinteren Ende des Projekts hinzuzufügen, um Features zu berücksichtigen, die nach rechts verschoben werden, und um Features zu berücksichtigen, die in der ursprünglichen Anforderungserfassung übersehen wurden.

Der Schlüssel dazu ist, dass ich das alles für den Kunden von vornherein transparent mache, damit er versteht, warum die letzten beiden Sprints leer oder dünn besetzt sind. Zumindest bis zu diesem Punkt hat es den Kunden gefallen, mit denen ich gearbeitet habe, da sie wissen, dass der Zeitplan / die Finanzdaten einen gewissen Puffer aufweisen, da die meisten von ihnen wissen, dass die SW-Schätzungen tendenziell weniger als konkret sind. Sie sind sich auch bewusst, dass wenn wir nicht den letzten Sprint oder so brauchen, dies Stunden sind, die wir nicht in Rechnung stellen. Mit der Transparenz, wie der Zeitplan erstellt wird, und dem regelmäßigen Feedback, wie der Fortschritt während der Ausführung des Projekts verläuft, war jeder Kunde, mit dem ich dies getan habe, äußerst zufrieden.

Ken Henderson
quelle
1

Neben all den genannten Dingen sehe ich diese beiden als eines der größten Probleme. Zuerst schätzen Sie das Enddatum, basierend darauf, dass jeder Entwickler an 5 Tagen in der Woche 8 Stunden am Tag zur Verfügung steht. Dies ist falsch und garantiert praktisch zu 100%, dass das Enddatum für ein nicht triviales Projekt nicht eingehalten wird. Die Mitarbeiter nehmen sich frei, nehmen an firmeninternen (oder nicht projektbezogenen) Besprechungen teil, streiten sich mit der Personalabteilung um Krankenversicherungsansprüche, machen Pausen usw. Nehmen Sie niemals eine Verfügbarkeit von mehr als 6 Stunden pro Entwickler und Tag an.

Die nächsten Entwickler vergessen notorisch, alle nicht entwicklungsbezogenen Aufgaben wie Besprechungen und E-Mails zu schätzen, die sich auf das Projekt, die Bereitstellung, den QS-Support, den UAT-Support, das Schreiben von Komponententests, die Recherche, die Dokumentation usw. beziehen Schätzungen wurden viel besser.

HLGEM
quelle
Ich würde das Schreiben von Unit-Tests nicht als Entwicklungsaufgabe bezeichnen;) Und unsere Chefs zählen uns 6 Stunden am Tag. Wenn ich 60 Stunden sage, sagen sie 10 Tage.
Piotr Perak
@Peri, Zugegeben, ich würde es auch nicht wirklich tun, aber viele Leute vergessen, Zeit für das Schreiben von Tests hinzuzufügen und denken nur an das Hauptproblem. Gut für deine Chefs, es wundert mich, wie viele es nicht tun.
HLGEM
1

Wenn es um die Zeitschätzung für Aufgaben geht, die länger als ein paar Stunden dauern können, versuche ich nach besten Kräften, diese Regeln anzuwenden:

  1. Versuchen Sie niemals vorherzusagen, wann andere Menschen ihre Arbeit beenden werden, wenn Sie davon abhängig sind. Sprich nur für dich.
  2. Analysieren Sie zuerst die Aufgabe und schätzen Sie dann ab. Mit Analyse meine ich, zumindest eine Liste von Teilaufgaben mit Schätzungen für jede von ihnen aufzuschreiben (und nicht zu versuchen, alles im Kopf zu behalten!).
  3. Wenn eine Aufgabe komplex genug ist, schätzen Sie die Zeit für eine solche Analyse selbst. Die Schätzung sei ein separater Prozess. Sie können auch sicherstellen, dass Ihr Chef darüber Bescheid weiß.
  4. Schätzen Sie nicht unter Druck. Machen Sie deutlich, dass es einige Zeit dauert, eine vernünftige Schätzung vorzunehmen, und sagen Sie ihnen einfach etwas wie "Ich werde morgen um 11:00 Uhr einen Termin benennen, wenn ich mit der Analyse der Aufgabe fertig bin". Ich weiß, dass einige Kunden / Manager hart drücken können, aber sie werden nicht passen. Legen Sie Ihr geschäftiges Gesicht auf und beanspruchen Sie Ihre Zeit!
  5. Bitten Sie um etwas mehr Zeit als Sie denken , weil Sie wahrscheinlich vergessen haben, eine Kaffeepausenzeit (und andere Umstände) in Ihrer Schätzung hinzuzufügen.
  6. Für große Aufgaben noch mehr verlangen - es wird wahrscheinlich mehr als eine Kaffeepause geben.
  7. Wenn Sie wirklich nicht einschätzen können (die Aufgabe ist zu schwierig / ungewohnt) oder sich nicht sicher sind, fragen Sie jemanden, der Ihnen bei Ihrer Analyse helfen kann.

Es gibt wahrscheinlich mehr Regeln als das, aber ich habe tatsächlich kein Poster mit diesen Regeln an meiner Wand. Ich habe sie jetzt nur formuliert, aber sie stammen aus meiner Erfahrung (daher funktioniert es möglicherweise nicht für Sie).

Die einzige verlässliche Methode, um die Softwareentwicklung zu planen, die mir einfällt (ich habe sie jedoch noch nicht ausprobiert), ist die evidenzbasierte Planung. Dabei handelt es sich im Wesentlichen um die Monte-Carlo-Methode, mit der die Wahrscheinlichkeit eines Versanddatums anhand historischer Aufzeichnungen über von Ihnen ausgeführte Aufgaben ermittelt wird. schon mal geschafft. Es fühlt sich gut an, weil keine anderen Metriken als die geschätzte und die tatsächliche Zeit verwendet werden. Es erfordert jedoch viel Erfahrung, große Aufgaben zuvor in kleinere aufzuteilen, und Sie müssen über einen großen Satz historischer Daten verfügen, damit sie präzise genug funktionieren.

scriptin
quelle
1

Es gibt "bekannte Unbekannte" und "unbekannte Unbekannte". :-)

  1. Schätzungen werden oft zu Fristen.

    • Niemand möchte eine Deadline verpassen und Schlagzeile werden!
  2. Anforderungen ändern sich (oft rational) und der Programmierer kann kein Veto einlegen.

  3. Programmierer haben möglicherweise keine Kontrolle über Faktoren wie

    • Verfügbarkeit von Code, von dem sie abhängig ist
    • Codequalität, von der sie abhängig ist
    • Gesamtarchitektur und Design des Systems
    • APIs für den Zugriff auf andere Teile des Systems
Arun Saha
quelle