Agil - Aufgabenaufschlüsselungen - zu schätzen oder nicht?

Während unserer Iterationsplanung befinden wir uns häufig in der gleichen Position wie dieser Kerl - How to estimate a programming task if you have no experience in it

Ich stimme definitiv dem Prototyping zu, bevor Sie eine vernünftige Schätzung abgeben können. Aber das gleiche gilt für alles, was ein bisschen Architektur und Design braucht - aber ich bin nicht so bequem, all dies aerthatonur im Rahmen eines Sprints zu tun.

Die Grundidee ist, dass Sie so viele Aufgaben wie möglich identifizieren, von denen Sie sicher sind, und diese als normal einschätzen. Für die Bereiche, von denen Sie sich nicht sicher sind, sollten zwei "Arten" von Aufgaben identifiziert werden: Untersuchung & Implementierung.

Untersuchungsaufgaben sind kurze Beschreibungen der Arbeit, von denen Sie sich nur nicht sicher sind, z. B. "Untersuchen, wie Control X an Daten gebunden werden kann". Für diese wird eine Schätzung vorgelegt.

Die Implementierungsaufgabe ist eine traditionelle grobe Vermutung, die wahrscheinlich auf den zugewiesenen Story-Punkten basiert, wie lange Sie denken, dass es dauern würde, um das Feature zu implementieren.

Während des Sprints, wenn die Ermittlungsaufgaben abgeschlossen sind, sollte sich der Entwickler dann in einer Phase befinden, in der er eine viel bessere Vorstellung davon hat, was vor sich geht. "Richtige" Aufgaben können dann identifiziert werden, die an die Stelle des Implementierungsplatzhalters treten. Darüber hinaus können in dieser Phase weitere Untersuchungsaufgaben identifiziert werden, und der Zyklus wird fortgesetzt.

Im obigen Beispiel beginnen wir mit einer Untersuchungsaufgabe bei 7 Stunden und einer Implementierungsaufgabe, die auf 14 Stunden geschätzt wird. Sobald die erste Untersuchung abgeschlossen ist, werden die Aufgaben 1, 2 und 3 mit einiger Sicherheit ermittelt und geschätzt, wobei Aufgabe 3 eine weitere Untersuchungsaufgabe ist, aus der Zuhause stellungsprüfung 4 und 5 zu einem späteren Zeitpunkt festgelegt werden. Wie Sie sehen können, hatte die erste Implementierung Schätzung Lieferung der Funktion innerhalb von 14 Stunden - aber die Realität ist es dauerte mindestens 4 + 7 + 3 + 4 + 2 = 20. Ein Drittel mehr als die ursprüngliche Schätzung.

alt text http://www.duncangunn.me.uk/myweb/images/estimate.png

Alle Gedanken sind willkommen - mein Bauchgefühl ist, dass das fliegen wird - bin ich recht oder bin ich der falsche Bruder?

Jubel!

Antwort auf "Agil - Aufgabenaufschlüsselungen - zu schätzen oder nicht? " 3 von antworten

Schätzung Funktion ist in der Regel komplexe Aufgabe. Nach einiger Zeit wird Ihre Einschätzung besser. Aber ein guter Ansatz kann sein, dass Sie Features mit den Story-Punkten schätzen. Story-Punkt ist abstrakter Wert (d. h. im Team vereinbart), der die Komplexität des Problems ausdrückt. Sie sollten den Features der ähnlichen Komplexität dieselbe Komplexität (gleiche Anzahl von Storypunkten) zuweisen. Später reicht es dann aus, nur kleinere Features zu schätzen (oder sich die historischen Daten anzusehen) und Sie sollten in der Lage sein, abzuschätzen, wie viel Zeit Sie benötigen.

Features mit ähnlicher Komplexität erfordern einen ähnlichen Zeitaufwand für die Implementierung.

Eigentlich dauerte die Implementierung der Funktion 27 Stunden - Sie haben die erste Untersuchung von 7 Stunden vergessen, so dass in Wirklichkeit die tatsächliche Umsetzung fast doppelt so lange dauerte wie die Schätzung.

Es gibt zwei Möglichkeiten, wie Sie auf diese Weise gehen können:

  1. Machen Sie einfach die Schätzung so gut Sie können und möglicherweise erleben Sie einen Blowout in Ihrem Sprint und eine verringerte Projektgeschwindigkeit (Sie sollten dies nur tun, wenn die Funktion sowohl dringend als auch kritisch ist); oder
  2. Planen Sie die Untersuchung für diesen Sprint und lassen Sie die Umsetzung für einen weiteren Sprint - ohne eine Ahnung, wie lange die Aufgabe dauern wird, hat der Produktbesitzer nicht genügend Informationen, um eine Entscheidung darüber zu treffen, in welchem Sprint er geplant werden soll oder ob er es überhaupt tun soll. Nur aufgaben, die geschätzt wurden, sollten in Den Sprint einbezogen werden.

Die erste Wahl bedeutet, dass Ihre Sprint- und Projektschätzungen etwas willkürlich sind. Die zweite Wahl gibt viel mehr Vorhersehbarkeit für Ihre Sprints.

In Ihrem Beispiel kann die erste Untersuchung für Sprint 1 geplant werden, aber ohne zu wissen, wie lange die Aufgabe dauert, kann der Produktbesitzer nicht entscheiden, wie er sie plant. Wenn Sie mit einer Schätzung von 200 Stunden zurückkamen, kann der Produktbesitzer entscheiden, diese Funktion überhaupt nicht zu tun oder sie bis Release 2 des Produkts zu verzögern. Die Schätzung kommt herein und der Produktbesitzer plant Aufgabe 1, Aufgabe 2 und die Untersuchung von Aufgabe 3 für Sprint 2. Nach der Schätzung von Aufgabe 3 können die Aufgaben 4 und 5 in Sprint 3 oder höher geplant werden.

Was wir tun.

Einige Funktionen beinhalten neue Technologie. Wir können sie nicht genau abschätzen. Zeitraum.

Wir machen eine Zahl aus. Basierend auf ein paar Dingen. Wie schwer "fühlt es sich" an? Können wir mit einer Art "teilweiser" oder "geradezu" Implementierung auskommen?

  • Wenn es schwer ist, dann ist es schwer. Es wird teuer.

  • Wenn es viele Teile gibt, mit einem Kern von Güte und etwas Bonus-Material, das aufgelegt ist, haben wir die Möglichkeit, nur den Kernel in eine Veröffentlichung zu stecken und andere Sachen für später beiseite zu legen. Einige wenige Dinge sind "alles oder nichts", wo eine Teilfreigabe nicht möglich ist. In diesem Fall müssen wir genug Zeit für "alle" zur Verfügung stellen, und das wird teuer.

Unser Standardansatz ist es, Dinge zu bekommen, die funktionieren, und die Dinge möglicherweise auf einen späteren Sprint zu verschieben, wenn uns die Zeit aufgrund unerwarteter Komplexitäten ausgeht.

Was Sie "Untersuchung" nennen, nennen wir technische Spike-Sprints. Für Dinge, die neu sind, erstellen wir eine Geschätzte Anzahl, um Manager zu besänftigen, die es für notwendig halten, Dinge zu überplanen. Dann treiben wir die Technologie in die Höhe. Sobald es gespickt ist, können wir die Schätzungen auf der Grundlage dessen, was wir jetzt wissen, überarbeiten.