Application Kata “Comparative Estimation”
Absolute Schätzung
Eine beliebte Methode, um den voraussichtlichen Aufwand zur Umsetzung einer Anforderung abzuschätzen, ist die Verwendung von Story Points (SP). Anstatt die Echtzeit in Stunden oder Tagen zu schätzen, wird eine abstrakte Metrik verwendet. Ob ein auf 5 SP geschätzter Bedarf 5 Stunden oder 5 Tage oder 10 Tage dauert, ist nicht bekannt und nicht wichtig. Wichtig ist, dass 5 SP mehr als 3 SP und weniger als 10 SP sind.
Das ist zumindest die Theorie. In der Praxis wird jedoch derjenige, der bald eine Schätzung benötigt, damit beginnen, SP-Schätzungen in Zeitdauern umzuwandeln. Der Grund dafür ist: „Wenn das Team beim letzten Mal für die Implementierung von 85 SP 10 Tage gebraucht hat, werden sie das nächste Mal wieder 10 Tage brauchen. Jeden Tag ist das Team in der Lage, 8,5 SP zu liefern.“
Diese Argumentation ist verständlich – aber absolut kontraproduktiv. Es übt Druck auf die Entwicklung aus, sobald eine Schätzung in eine Frist umgewandelt wird: „Oh, Sie schätzen das also auf 110 SP? Das bedeutet, dass Sie es in 13 Tagen fertig haben.“
Obwohl die SP-Schätzung vielleicht nie auf diese Weise verwendet werden sollte, ist sie es sicherlich oft.
Ähnlich verhält es sich, wenn Schätzungen auf T-Shirt-Größen basieren, z.B. S, M, L, XL.
Das Kernproblem liegt in der absoluten Metrik: Ein bestimmter Wert (z. B. 8 oder M) wird verwendet, um die Höhe eines benötigten Budgets auszudrücken.
Vergleichende Schätzung
Um die Abbildung abstrakter Schätzungen auf absolute Zeit- und Geldwerte zu überwinden, können relative Schätzungen verwendet werden. Anstatt einer Anforderung eine Nummer zuzuweisen, wird sie nur mit einer anderen Anforderung verglichen. Das Ergebnis des Vergleichs ist eine Bestellung.
Absolute Schätzung: Anforderungen A, B, C werden auf A=5, B=8, C=3 geschätzt.
Relative Schätzung: Anforderungen A, B, C werden mit B>A>C geschätzt.
Wenn dann A+B+C 10 Tage zur Umsetzung braucht, kann nichts auf die nächste Schätzung von X, Y, Z übertragen werden! Und das ist ein Feature, kein Fehler.
Relative Schätzung oder vergleichende Schätzung funktioniert, indem Alternativen paarweise verglichen werden. Bei den Anforderungen A, B, C, D sind diese Paare zu vergleichen: A:B, A:C, A:D, B:C, B:D, C:D. Das sind 3+2+1=6 Vergleiche für 4 Alternativen. Allgemeiner ist für n Alternativen (n-1)((n-1)+1)/2 = n(n-1)/2 Vergleiche.
Für jedes Paar muss entschieden werden, welche Alternative als „größer“, „schwerer“, „wertvoller“, „aufwendiger“ eingestuft wird… Beispiel:
Die resultierende Reihenfolge: D,B,A,C
Die Vergleiche 4. und 6. sind mit * gekennzeichnet, da ein anderes Ergebnis eine Inkonsistenz verursachen würde. Sie hätten nicht einmal geschaffen werden müssen.
Da B>A (1.) und A>C (2.) ist, muss B wegen der Transitivität auch > als C (4.) geschätzt werden.
Vielleicht sollten dann die Vergleiche 4. und 6. gar nicht angeboten werden. Auf der anderen Seite wäre es vielleicht lohnenswert, Inkonsistenzen auftreten zu lassen, weil sie bisher versteckte Verwirrung oder Missverständnisse anzeigen, die gelöst werden müssen, bevor eine vernünftige Schätzung abgegeben werden kann.
Wenn mehr als eine Person eine relative Schätzung von Alternativen vornimmt, kann das Gesamtergebnis durch Zählen von Rängen berechnet werden, z.B.
Die relative Schätzung kann verwendet werden, um den voraussichtlichen Aufwand für die Umsetzung von Anforderungen abzuschätzen. Eine Möglichkeit, das obige Beispielergebnis zu interpretieren, könnte sein: D wird länger dauern als B, was länger dauert als A, was länger dauert als C, um implementiert zu werden.
Es ist jedoch weder bekannt, wie lange D oder B brauchen, noch wie viel länger D als B brauchen wird.
Oder eine solche Schätzung kann verwendet werden, um den Wert zu schätzen, den eine Anforderung für einen Kunden (oder eine Vertriebsabteilung) haben könnte. Dann könnte das obige Ergebnis so interpretiert werden: D wird mehr Wert liefern als B, was noch mehr Wert liefert als A, das wertvoller wäre als C.
Wie viel absoluten Wert eine Anforderung hat, ist jedoch nicht bekannt.
Auch dies ist ein Feature, kein Fehler dieses Ansatzes!
Absolute Schätzungen sind schwierig, vielleicht sogar unmöglich innerhalb angemessener Fehlerspannen. Dies gilt sogar für die Zuordnung abstrakter Zahlen zu Anforderungen. D mit 13 und B mit 8 gleichzusetzen ist schon ziemlich genau, auch wenn SPs nur relative Werte ausdrücken sollen.
Aber bei rein vergleichender paarweiser Einschätzung reicht ein Bauchgefühl. Das ist ehrlich. Denn Entwickler haben beim Schätzen nicht mehr als ein Bauchgefühl. (Und selbst das könnte falsch sein.)
Die Entscheidung für B>A in Schritt 1. oben steht nicht für mehr als „Mein Bauchgefühl ist, dass B länger dauert als A. Aber um wie viel…? Ich weiß nicht.” oder „Mein Bauchgefühl ist B ist wertvoller als A. Aber um wie viel? Ich weiß nicht.”
Vielleicht könnte ein Vergleich mit einem Faktor wie „B dauert etwas länger“ oder „B dauert viel länger“ versehen werden. Aber mehr als 2 oder 3 Faktoren (z.B. „mehr“ (>), „viel mehr“ (>>), „enorm mehr“ (>>>)) machen keinen Sinn. Präziser kann ein Bauchgefühl nicht sein.
Ein solcher Faktor würde dann natürlich den Gesamtrang beeinflussen. Dies könnte durch größere Abstände (>=1, >>=3, >>>=10) zwischen Alternativen erleichtert werden. Anstatt ihnen zusammenhängende Ränge zuzuweisen, könnte die Rangfolge spärlich sein. Beispiel: D>B>>A>>>C könnte übersetzt werden in
Funktionale Anforderungen
Schreibe ein Programm, um die vergleichende Schätzung in einem Team zu unterstützen.
Jede Schätzung beginnt mit der Eingabe eines optionalen Titels für das Schätzungsprojekt (z. B. „Sprint 12“) und die zu vergleichenden Items (User Stories). Die Anzahl der Artikel muss nicht begrenzt werden. Sind aber alle Items eingetragen, wird die max. Anzahl der Vergleiche angezeigt werden.
Das Schätzprojekt wird dann an die Teammitglieder verteilt (z. B. indem es ihnen seine ID mitteilt oder ihnen eine URL sendet), damit sie ihren Vergleich durchführen.
Die Teammitglieder vergleichen die Projektelemente paarweise. Dies kann so einfach sein, wie einfach nur auszuwählen, welcher Gegenstand eines Paares als größer/wertvoller angesehen wird. Oder es kann auch ein Faktor angegeben werden, z.B. „viel größer“ oder „viel, viel wertvoller“.
Der Gesamtrang der Artikel kann jederzeit eingesehen werden. Es wird jedes Mal aktualisiert, wenn ein Teammitglied seine/ihre Vergleiche einreicht. (Die mehrfache Übermittlung von Vergleichen für dasselbe Projekt überschreibt vorherige Vergleiche.)
Der Benutzer identifiziert sich einfach durch die Eingabe seiner E-Mail-Adresse. Es ist keine weitere Authentifizierung/Autorisierung erforderlich.
Nicht-funktionale Anforderungen
Das Programm sollte in einem Intranet laufen. Mehrere Teammitglieder können an ihren Computern gleichzeitig an ihren Vergleichen arbeiten. Eine Auswertung ist jederzeit möglich.
Die Anzahl der Teammitglieder ist gering (1..10). Die Anzahl der Elemente pro Projekt ist gering (2..10).
Die Anzahl der Schätzprojekte pro Team liegt im Bereich von 4 bis 100 pro Jahr.
Eine echte Verteilung der Teammitglieder über das Internet zu ermöglichen wäre schön, ist aber nicht notwendig.
Projekte werden durch eine automatisch generierte ID identifiziert. Diese ID ist an den Ersteller des Projekts gebunden. Projektlisten zeigen nur Projekte, die dem aktuellen Benutzer gehören. Bei einer vergleichenden Schätzung kann jedoch jede gültige Projekt-ID eingegeben werden. Keine Autorisierung ist notwendig. Wer zufällig eine Projekt-ID kennt, gilt als ausreichend durch dieses Wissen autorisiert, um Beiträge zu leisten.
Benutzeroberflächenskizze der Konsole
Variation: Aufwändigere Benutzeroberfläche
Eine Web-UI oder eine Desktop-GUI ist natürlich willkommen.
German 
English