Projektplanung und -überwachung mit dem Team Foundation Server, Teil 2: Schätzung des Arbeitsaufwands

Projektplanung und -überwachung mit dem Team Foundation Server, Teil 3: Ausbalancierung der Teamauslastung

TFS-Schätzungsparameter

Die Vorbereitung des Freigabeplans muss auf der vorherigen Erfahrung basieren sowie auf dem Verständnis der Entwicklungsgeschwindigkeit und der Komplexitätsschätzung.

Im TFS gibt es ein eigenes Feld für Aufwand – Effort  (Komplexität/Complexity) auf den Ebenen von User Story, Feature und Epic. Unter Berücksichtigung früherer Erfahrungen und Anforderungen kann das Team die Gesamtkomplexität der Implementierung spezifischer Funktionen analysieren. Die Ergebnisse der Schätzung einer User Story werden denen auf der Abbildung 1 ähnlich sein. Anhand dieses Beispiels können wir sehen, wie User Stories auf der Komplexitätsachse verteilt sind und dann in relevante Einheiten gruppiert werden, die von jedem Team unabhängig gewählt werden können.

Es ist wichtig zu beachten, dass Effort (Complexity) nur in Bezug auf andere User Stories geschätzt wird und nicht in der Arbeitszeit gemessen wird. Die Maßeinheiten sind in diesem Fall wirklich eine Frage der Präferenz und können alles, von den standardmäßigen Einheiten, wie “Story Points” bis hin zu den außergewöhnlichen, wie “Schlangen” oder “Lotterielosen”, bedeuten.

Abbildung 1: Relative Schätzung der User Story

Bei der Schätzung in den separaten User Stories können die Effort-Werte auf der Ebene der Features und der Epics gruppiert werden. Sobald die Teamgröße festgelegt ist, wird die Komplexitätsschätzung in Scrum nur durch den Zeitrahmen geregelt. Hier dient das Team als Träger der bisherigen Erfahrung mit seiner festen Entwicklungsgeschwindigkeit zur Orientierung. Bei der festen Entwicklungsgeschwindigkeit postulieren wir, dass das Team während eines Zyklus von einer bestimmten Dauer eine gewisse Anzahl von “Story Points” abschließen kann. Allerdings kann diese Annahme zu einem Engpass führen, wenn das Team neu zusammengestellt wird oder grundlegende Veränderungen vor dem Projektstart vorgenommen werden.

“Velocity” (Entwicklungsgeschwindigkeit) ist ein statistisch definierter, wenn auch etwas relativer Wert, der misst, wie schnell ein Team seine Arbeit abschließen kann. Im Gegensatz zu einigen vertretenen Meinungen ist Velocity weder die Lieferkurve noch das absolute Minimum. Die Bestimmung der Entwicklungsgeschwindigkeit hilft dabei, einen Freigabeplan mit Raum für Anpassungen und innerhalb einer bestimmten Erfolgswahrscheinlichkeit zu erstellen.

Auf der Abbildung 2 ist die Anzahl der Story Points zu sehen, die das Team innerhalb einer ca. neun Monate langen Projektlieferung abgeschlossen hat. Wenn wir die Menge der ausgelieferten Arbeit analysieren, können wir feststellen, dass das Team nach einer Anpassungsphase zu Beginn des Projektes nicht weniger als 110 Einheiten pro Sprint liefert. Trotzdem sollte man das absolute Minimum nicht bei 125 Einheiten ansetzen und erwarten, dass das Team diese liefert, indem man es mit dem “Ihr schafft das!” -Ansatz motiviert. Die Geschwindigkeit ist eher eine

Abbildung 2: Entwicklungsgeschwindigkeit – Lieferkurve

Schätzung desTeamarbeitsaufwands

In vielen praxisnahen Szenarien, wenn das Team neu ist und seine Mitglieder noch keine Erfahrung bei der Zusammenarbeit miteinander haben, ist es unmöglich, die Freigabe anhand der Entwicklungsgeschwindigkeit zu planen. In solchen Fällen sollte sich die Planung nach den Aktivitäten wie die Entwicklung, die Tests und die Dokumentation richten.

Jeder Teil der Anforderungen kann in Stunden für ihre Umsetzung geschätzt werden. Aus diesem Grund wird jede User Story in separate Aufgaben unterteilt. Siehe dazu das Beispiel in der Abbildung 3 unten.

Abbildung 3: Liste der Aufgaben im Feld User Story

Darüber hinaus gibt es im TFS ein Activity-Feld auf der Task-Ebene, in dem die Aufgaben auf die Gruppen innerhalb des Teams verteilt sind. So können wir bei der Schätzung des Teamaufwands die Anzahl der benötigten Ressourcen für das Frontend, das Backend und das Testen separat berücksichtigen. Das Aktivitätsfeld, genau wie viele andere TFS-Felder, ist ein benutzerdefiniertes Wörterbuch, in dem wir Werte hinzufügen oder abwählen können. Ein Beispiel für das Aktivitätsfeld in einem durchschnittlichen Projekt ist unten in der Abbildung 4 zu sehen.

Picture 4: Activity Dictionary at the Task level in TFS

In diesem Stadium der Aufwandsschätzung sind die Aufgaben und die Zeit, die für ihre Umsetzung erforderlich ist, bereits bekannt. Damit die Aufgaben mit der für das Team verfügbaren Zeit in Einklang gebracht werden können, gibt es im TFS die Option des Teamkapazitäts-Managements. Dieser Wert wird pro Sprint-Level geschätzt und stellt die ungefähre Anzahl der Stunden dar, die alle Teammitglieder brauchen, sowie die Kategorien der Aktivitäten, an denen sie beteiligt sind. Ein Mitarbeiter kann verschiedene Rollen ausführen, ein Teilzeit-Mitarbeiter sein oder Urlaub nehmen; alle diese Werte können im Teamkapazitäts-Management angegeben werden, damit sie bei der Planung berücksichtigt werden können.
Im nachfolgenden Beispiel wollen wir ein gängiges Beispiel für das Feld „Capacity“ zeigen und es ausfüllen. In der Abbildung 5 sind die Einstellungen für ein Team von 6 Personen zu sehen, es sind ein Analyst, ein Designer, ein Tester und drei Entwickler dabei. Wie wir feststellen können, arbeiten John Doe und Korben Dallas Teilzeit und sind nur drei Stunden pro Tag aktiv, während Samwise Gamgee der technische Leiter ist und neben dem regulären Entwicklungsjob Bewertungen durchführen muss. Der Rest des Teams arbeitet ganztägig. In der Regel wird pro einen 8-Stunden-Arbeitstag eine Stunde für die Meetings reserviert, die verbleibende Zeit ist für die laufenden Aufgaben gedacht.

Abbildung 5: Teamkapazität

Jetzt ist alles vorbereitet, um die User Stories unter den Sprints zu verteilen, wobei die relativen Komplexitätswerte durch die für bestimmte Aktivitäten erforderliche Zeit ersetzt werden.

Im TFS wird die Balance zwischen der verbleibenden Arbeit (die Stunden, die für alle Aufgaben innerhalb eines Sprints erforderlich sind) und der verfügbaren Kapazität automatisch bestimmt. Dieses Verhältnis wird immer auf der Hauptseite des Sprints angezeigt. Im Aufwandsabschnitt wird der Prozentsatz der für die regulären Aufgaben festgelegten Sprintzeit angezeigt.

Einige übliche Fälle sind in der Abbildung 6 unten dargestellt. Zum Beispiel wird zu Beginn des Sprints empfohlen, mindestens 10-15% der Zeit für die möglichen Änderungen und neue Anforderungen zu reservieren. Gleichzeitig können wir sehen, dass der Testaufwand den geplanten Rahmen sprengt. In diesem Fall kann das Team über verschiedene Optionen mit dem Kunden diskutieren, z. B. über die Reduktion des Aufwands oder die Verlängerung des Sprints, das Beenden der Qualitätssicherungsmaßnahme während des nächsten Sprints oder die Einbeziehung mehrerer Spezialisten beim Testen usw. Am wichtigsten ist, dass es einen offensichtlichen Indikator gibt, der die Notwendigkeit solcher Führungsentscheidungen signalisiert. Die Kapazität ist ausgeglichen, wenn jedes Teammitglied mit Grün markiert ist und etwas Zeit hat und sich die Summe der Aktivitätskategorien auch im grünen Bereich befindet. Diese Angaben sollten regelmäßig überwacht und überprüft werden.

Erwähnenswert ist außerdem, dass es einfach ist, User Stories zwischen den Sprints zu verschieben. Sie können User Stories auf jede Iteration oder zum Backlog mit allen begleitenden Daten verschieben und die Kapazitätsänderungen innerhalb des Sprints mit Hilfe des Rechtsklick-Menüs analysieren. Durch das Löschen von sperrigen User Stories und das Hinzufügen von kleineren können Sie die Sprintkapazität optimieren, während die Besonderheiten der einzelnen Teams berücksichtigt werden.

Abbildung 6: Analyse der Teamkapazität zu Beginn eines Sprints

Lesen Sie mehr über die Aufgabenzuweisung und – terminierung im dritten Teil der Reihe “Projektplanung und -berwachung mit dem Team Foundation Server”.