Tracking zur einfachen Aufwandsschätzung

Veröffentlicht am 28.05.2007, letzte Änderung am 30.05.2007

Für eine zuverlässige Projektplanung müssen wir zuverlässige Schätzungen abgeben. Im Extreme Programming wollen wir uns dabei nicht nur auf unser Bauchgefühl verlassen, sondern Aufwände für zukünftige Aufgaben aus den Aufwänden für bereits erfüllte Aufgaben ableiten.

Warum überhaupt Tracking?

Im Tracking erfassen wir die geschätzten und tatsächlichen Aufwände für die Erfüllung von Aufgaben, und messen damit die Entwicklungsgeschwindigkeit. Sie ist sowohl für den Kunden als auch für die Entwicklung eine wichtige Information:

Das einfachste Tracking, das funktionieren könnte

Das einfachste Maß für die Entwicklungsgeschwindigkeit ist die Anzahl von Aufgaben, die pro Entwicklungszyklus realisiert werden. Für den Kunden ist dieses Maß ebenfalls geeignet, da es den für ihn sichtbaren Projektfortschritt abbildet.

Für den folgenden Entwicklungszyklus nehmen wir dann die gleiche Geschwindigkeit an, die wir im letzten Durchlauf erreicht haben. Das ist die ehrlichste Abschätzung, die wir bei diesem Maß machen können.

Im Extreme Programming hat sich dafür der Begriff Yesterday's Weather eingebürgert: Die Vorhersage, dass das Wetter heute genauso sein wird wie gestern, erreicht eine recht hohe Genauigkeit.

Verschiedene Aufgabengrößen

Variieren die Aufwände pro Aufgabe stark und lassen sich die Aufgaben partout nicht in annähernd gleichgroße, für den Kunden bedeutsame Teile zerschneiden, führen wir ein Maß für die Größe von Aufgaben ein. Wir geben zuerst einer kleinen Aufgabe 1 Punkt und schätzen dann größere Aufgaben im Vergleich damit ab: Schätzen wir eine andere Aufgabe doppelt so groß, bekommt sie 2 Punkte, schätzen wir eine andere wiederum doppelt so groß, geben wir ihr 4 Punkte.

Die Geschwindigkeit messen wir dann in Punkten pro Entwicklungszyklus. Für den folgenden Durchlauf nehmen wir die Geschwindigkeit des letzten Durchlaufs an.

Schätzungen und Realdaten

Der Anteil am tatsächlichen Aufwand einer Aufgabe am Gesamtaufwand eines Entwicklungsdurchlaufs kann stark von dem Punktanteil an der Gesamtpunktzahl abweichen. Zum Beispiel kann eine Aufgabe mit nur 10% der Punkte abgeschätzt worden sein, aber tatsächlich 30% der Zeit gekostet haben.

Treten solche Abweichungen häufig auf, wird das Tracking unzuverlässig. Um das Problem zu lösen, erfassen wir pro Aufgabe, wieviel Zeit tatsächlich darauf entfallen sind, und verteilen für zukünftige Vergleiche die geleisteten Punkte nach der tatsächlich verwendeten Zeit auf die Aufgaben.

Zur Vermeidung von Pseudogenauigkeiten wollen wir weiterhin mit vollen Punktzahlen arbeiten. Daher verwenden wir ein einfaches Verfahren, um die geleisteten Punkte auf die Aufgaben umzurechnen:

  1. Jede Aufgabe bekommt den ganzzahligen Anteil.
  2. Verbleibende Punkte werden den Aufgaben mit den höchsten Teilungsresten zugeschlagen.

Als Beispiel nehmen wir an, dass im letzten Entwicklungszyklus die Aufgaben A, B, C, D und E mit jeweils 2 Punkten geplant waren. Tatsächlich war noch etwas Zeit übrig, so dass die 1-Punkt-Aufgabe F ebenfalls erfüllt werden konnte. Insgesamt wurden also 11 Punkte geliefert. Mit den realen Aufwänden verteilen wir diese nun auf die Aufgaben: 

Aufgabe A: 11 Punkte * 23% = 2,53 Punkte
Aufgabe B: 11 Punkte * 16% = 1,76 Punkte
Aufgabe C: 11 Punkte * 25% = 2,75 Punkte
Aufgabe D: 11 Punkte * 16% = 1,76 Punkte
Aufgabe E: 11 Punkte *  5% = 0,55 Punkte
Aufgabe F: 11 Punkte * 15% = 1,65 Punkte

Jede Aufgabe bekommt die ganzzahligen Punkte, das sind insgesamt 7 Punkte. Die restlichen 4 Punkte bekommen die Aufgaben mit den höchsten Teilungsresten, also B, C, D und F: 

Aufgabe A: 2 + 0 Punkte = 2 Punkte
Aufgabe B: 1 + 1 Punkt  = 2 Punkte
Aufgabe C: 2 + 1 Punkt  = 3 Punkte
Aufgabe D: 1 + 1 Punkt  = 2 Punkte
Aufgabe E: 0 + 0 Punkte = 0 Punkte
Aufgabe F: 1 + 1 Punkt  = 2 Punkte

Stellen wir die geschätzten Punkte den nach realen Aufwänden verteilten gegenüber, sehen wir, wie gut unsere Schätzungen im Einzelnen waren. Hier waren die Schätzungen für A, B und D recht gut, C und F haben wir unterschätzt und E völlig überbewertet.

Das hier verwendete Vorgehen, um Prozentwerte auf eine feste Anzahl von Punkten zu verteilen, nennt sich Hare-Niemeyer-Verfahren und wird bei Parlamentswahlen dazu verwendet, Sitze auf Parteien zu verteilen.

Einfache Ausnahmebehandlung

Zahlreiche geplante und ungeplante Ereignisse können die pro Durchlauf verfügbare Zeit verändern (Krankheit, Urlaub, neue Teammitglieder, …). Natürlich könnten wir diese Daten verwenden, um zu versuchen, die zukünftige Geschwindigkeit genauer einzuschätzen.

Viel einfacher ist aber, einfach einen Entwicklungsdurchlauf zu warten und damit festzustellen, ob sich die Geschwindigkeit tatsächlich ändert.

Analog gehen wir mit Aufwänden um, die wir nicht direkt den bearbeiteten Aufgaben zuweisen können. Sagen wir mal, wir haben 10 Punkte geschätzt, eine der letzten Lieferungen war aber fehlerhaft und 20% der Zeit sind in ungeplante Fehlerkorrekturen geflossen. Außerdem haben wir 10% der Zeit in Meetings verbracht. Tatsächlich haben wir 7 Punkte geschafft. Natürlich können wir nun zusätzliche 'Aufgaben' für die Fehlerkorrekturen (2 Punkte) und die Meetings (1 Punkt) erfassen und damit unsere tatsächliche Geschwindigkeit auf die geschätzten 10 Punkte bringen.

Tatsächlich ist so eine Vorgehensweise fatal: Wer sagt uns, dass wir im nächsten Durchlauf nicht wieder 20% der Zeit für ungeplante Fehlerkorrekturen brauchen? Und wer sagt uns, dass wir mit weniger Meetings nicht noch weniger Punkte geschafft hätten, da zu wenig Abstimmung vorlag?

Wir erfassen unsere Geschwindigkeit also mit ehrlichen 7 Punkten. Die Zeiten für nicht aufgabenrelevante Aufwände schlagen wir einfach den Aufgaben zu, von denen uns die Aufwände abgehalten haben.

Anpassung der Planung

Natürlich eignet sich die Ausnahmebehandlung nur für Ausnahmefälle. Haben wir ständig wiederkehrende Aufwände für ungeplante Aufwände (zum Beipiel Serveradministration und Support), bietet es sich an, diese Aufgaben entweder aus der Entwicklung herauszulösen, oder sie explizit einzuplanen.

Geschwindigkeitsänderungen

Bei der Geschwindigkeit sollte keine Konstante erwartet werden, kleine Schwankungen sind völlig normal. Bei starken Geschwindigkeitsänderungen sollten wir versuchen, den Ursachen auf den Grund zu gehen. Zum Beispiel mag eine plötzliche Geschwindigkeitssteigerung aus Kundensicht schön aussehen, sie kann aber ebensogut bedeuten, dass zu viel Druck auf das Team ausgeübt wurde, und dass darunter die strukturelle Qualität des Systems und die Testabdeckung gelitten haben.

Lieber wenig als überhaupt nicht

Sicher, das hier vorgestellte Tracking ist bewusst einfach und ungenau. Andererseits können komplexere Lösungen leicht zu bürokratischen Monstern ausarten, die vom Team nicht akzeptiert werden und daran scheitern.

Meine Empfehlung ist daher: Starten Sie lieber mit dem einfachsten Tracking, das funktionieren könnte. Erweitern Sie es dann, wenn es tatsächlich nötig ist. Und prüfen Sie, ob sie es später nicht wieder vereinfachen können.