MSP: Iteration Manager / Tracker

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Einleitung

In Programmierprojekten kommt es immer wieder dazu, dass das Budget einzelner Mitglieder oder auch das gesamte Budget zu schnell aufgebraucht werden (vgl. das Bermuda-Dreieck der Softwareentwicklung). Oftmals kann der Teamleiter nicht die Übersicht über die einzelnen Iterationen sowie den Stand der gesamten Entwicklung behalten. Bei agilen Entwicklungsprozessen (z.B. "Extreme Programming") versucht man diesem Umstand vorzubeugen, indem man die Position eines Iteration Managers / Trackers besetzt. Der Iteration Manager unterstützt die Teammitglieder, in dem er Gespräche mit ihnen führt und sicher stellt, dass ihr Fokus immer auf den Aufgaben mit der höchsten Priorität liegt. Oftmals übernimmt der Iteration Manager auch die Rolle des Trackers, da die Aufgaben beider Rollen eng miteinander verbunden sind. Man sollte aber trotzdem zwischen den beiden Rollen unterscheiden: Während sich der Iteration Manager (im Gegensatz zum Teamleiter) nur mit den Bedürfnissen der Teammitglieder beschäftigt (Kommunikation untereinander und mit dem Kunden), konzentriert sich der Tracker (wie auch der Teamleiter) vor allem auf den Stand des gesamten Projekts.


Weitere Planspielrollen können im Planspiel-Artikel eingesehen werden. Die Planspielverwaltung findet man hier.

Was soll ein Iteration Manager / Tracker erreichen bzw. verhindern?

Wie schon weiter oben beschrieben kümmert sich der Iteration Manager vor allem darum, dass die Kommunikation im Team und mit dem Kunden funktioniert. Zu diesem Zweck schaltet er sich z.B. in Standup-Meetings ein und achtet dort darauf, dass jeder zu Wort kommt und alle "mit einem guten Gefühl" aus dem Meeting geht. So verhindert er, dass sich einzelne Teammitglieder überfordert fühlen, weil sie z.B. die Aufgabenstellung nicht richtig verstanden haben etc. Sollte der Iteration Manager bemerken, dass ein Teammitglied in einer Iterationsphase überbelastet wird, so kann er durchaus einschreiten und diesen Punkt mit dem Teamleiter diskutieren.

Der Tracker kümmert sich um die sogenannten Project Vital Signs. Er achtet unter anderem darauf, dass das Budget nicht zu schnell aufgebraucht wird. Dies gilt für das Budget einzelner Mitglieder (hier sieht man die Verbindung zwischen Iteration Manager und Tracker) sowie auch für das Gesamt-Budget. Überstunden sind in Extreme Programming - Projekten ein eindeutiges Zeichen dafür, dass etwas nicht stimmt (vgl. "Extreme Programming - das Manifest", Kent Beck). Der Tracker kann zwar nicht verhindern, dass es zu Überstunden kommt (außer, er hat auch die Rolle des Iteration Managers inne), aber er kann dies dem Teamleiter mitteilen, so dass dieser Maßnahmen ergreifen und gegensteuern kann. Auch liefert er dem Teamleiter Einblicke über den gesamten Projektverlauf, in dem er diesen in verschiedenen Statistiken visualisiert (Budget Burndown, Storycards, etc.). Die Statistiken über den Verbrauch des Budgets erstellt der Tracker anhand von Angaben der einzelnen Mitglieder. Diese Angaben müssen evtl. auf Plausibilität geprüft werden, dies wird jedoch in den meisten Fällen nicht vom Tracker allein, sondern in Zusammenarbeit mit dem Teamleiter erledigt. Des weiteren führt der Tracker eine Storycards Statistik. Meist durchlaufen alle Storys mehrere Phasen (todo, done, tested, bugs, etc.), der Tracker visualisiert den aktuellen Stand (Storycards sowie Meilensteine) und präsentiert diesen dem Teamleiter. So kann dieser die Statistiken (und damit den Stand des Projekts) in seine Entscheidungen einfließen lassen.

Welche Mittel stehen dem Iteration Manager / Tracker zur Verfügung?

Mittel / Befugnisse des Iteration Managers

Der Iteration Manager ist (meistens) von sämtlichen technischen Aufgaben entbunden. Natürlich benötigt er dennoch Erfahrung in diesem Gebiet um Belastungen einschätzen zu können. Er hat in sämtlichen Meetings das Recht, einzuschreiten um Überbelastungen zu verhindern. Außerdem kann er jederzeit Gespräche zwischen Teammitgliedern oder mit dem Kunden forcieren.

Mittel / Befugnisse des Trackers

Auch der Tracker ist (meistens) von sämtlichen technischen Aufgaben entbunden. Er führt ständig Statistiken über alle Project Vital Signs und präsentiert diese dem Teamleiter. Genau diese Statistiken sind die Mittel, die dem Tracker zur Verfügung stehen, um aufzuzeigen, dass das Projekt evtl. vom Kurs abkommt oder der geplante Kurs nicht einzuhalten ist. Er ist also in der Lage, dem Teamleiter beratend zur Seite zu stehen. Er darf und muss ihn auf evtl. Missstände aufmerksam machen.

Beispiel-Statistiken

Budget Burndown

Budget Burndown.png

StoryCards

Storycards.png

Übersicht über das Budget von Teammitgliedern

Budget Verbrauch W9.png

Weitere XP Rollen

XP Coach

Der XP-Trainer (Coach) unterstützt bei der Einführung und dem Erlernen von XP. Er achtet nach der Einführung auf die kontinuierliche Einhaltung des Prozesses. Als XP Coach kann entsprechend nur fungieren, wer schon Erfahrungen in der Anwendung von XP gesammelt hat. Der XP Prozess wird in Projekten Stück für Stück eingeführt, wenn das Team ihn vorher noch nicht angewendet hat.

Testing Engineer

Hauptaufgabe des Testing Engineers ist die Überprüfung der Software auf Fehler. Außerdem gehört die Integration in die CI-Umgebung zu seinen Aufgaben. Der Testing Engineer ist stets darum bemüht, seine Aufgaben zu automatisieren. Ermittelte Fehler und Schwachstellen werden an die Entwickler weitergeleitet.

Kunde

Der Kunde wird meist durch einen Mitarbeiter der Geschäftsseite repräsentiert. Er ist der Ansprechpartner für sämtliche Mitglieder des Teams und gehört selbst zum Team. Er sollte also von seinen Alltagsaufgaben im Geschäftsablauf (zumindest größtenteils) entbunden werden, so dass er sich auf das Projekt konzentrieren kann.

Entwickler

Die Entwickler in einem XP Projekt haben die Befugnis technische Entscheidungen zu treffen ("Wie wird etwas gemacht?"). In Abgrenzung dazu trifft der Kunde die Entscheidungen, für die man Einblick in den Geschäftsablauf benötigt ("Was wird (wann) gemacht?"). Er legt die Reihenfolge fest, in der die von ihm erstellten Storycards abgearbeitet werden.

Teamleiter

Der Teamleiter kümmert sich nicht um das Tagesgeschäft der Entwickler. Er muss das Projekt als ganzes im Auge behalten und sich um die Verwaltung von Ressourcen (Budget in Form von Zeit und Geld, etc.), Einhaltung von Terminen und generell alles Organisatorische kümmern.

Literatur

Extreme Programming - Das Manifest, Kent Beck, 2. Auflage, Addison-Wesley

The Thoughtworks Anthology - Essays on Software Technology and Innovation, Martin Fowler et. al, Pragmatic Bookshelf

--Philippi-SPh 09:16, 2. Feb. 2009 (UTC)