Kapitel 10 Ablage für agile Herangehensweisen (PM-Methode 4)

Über dieses Kapitel

• Inhalt dieses Kapitels:Eine einfache Methode der Projektablage für agile Projekte wird vorgestellt.
• Zielgruppe dieses Kapitels: Alle, die in Projekten mit Unsicherheit arbeiten.
• Nötige Vorkenntnisse: Sie sollten Kapitel 6 über die verschiedenen Projektmanagement-Methoden gelesen haben.

Beispiel und Definition

Beispiel: Die Firma Agilomatik stellt Software her und hat 25 Mitarbeiter. Sie liefert ihre Produkte an größere Firmen, z. B. für die Automobilindustrie oder für Medienunternehmen. Frau Faber arbeitet im Vertrieb und hat einen neuen Auftrag für ein großes Medienhaus gewonnen. Mit ihrem Team von 6 Softwarespezialisten wird sie eine Anwendung für Smartphones und Tablet-Computer erstellen. Der Kunde von Frau Faber hat eine ungefähre Vision, was er mit der Anwendung erreichen will. Aber er kann keine konkreten Anforderungen liefern, weil er in diesem Bereich keine Erfahrung gemacht hat. Statt den Kunden vertraglich zu einem Pflichtenheft zu zwingen, schlägt Frau Faber vor, alle drei Wochen eine Zwischenversion zu liefern, bei der der Kunde seine wirklichen Anforderungen erkunden und testen kann. Erfahrungsgemäß dauert das Projekt zwischen 6 und 8 Monaten.

Bei einer solchen Ausgangslage ist eine agile Herangehensweise ein guter Weg. Häufig organisieren sich die Teams nach Scrum. Scrum ist ein Gestaltungsrahmen für Teams, der dabei hilft, komplexe Probleme zu lösen. Scrum ist nicht die einzige agile Herangehensweise, aber die am weitesten verbreitete. Andere Vertreter dieser Gattung sind Extreme Programming (XP), Feature Driven Development (FDD), Crystal oder DSDM Atern.

Scrum lässt sich schnell erklären. Wie jede der beschriebenen Herangehensweisen kennt auch Scrum feste Rollen. Neben dem Team, das die eigentliche Arbeit macht, gibt es einen Product Owner, der die Business-Entscheidungen trifft, und den sog. Scrum Master, der auf das Einhalten von Spielregeln achtet. Mehr Informationen zu Scrum gibt es im offiziellen Scrum Guide (siehe [Scrum Guide 2013]).

Die Iterationen (Sprints) als führendes Merkmal

Interessant für die Ablage ist die iterative Arbeitsweise von Scrum-Teams. Die Teams arbeiten in sehr kurzen Phasen, meist 1-4 Wochen. Sie liefern die Projektsalami scheibchenweise.

Diese kurzen Phasen werden Iterationen, bei Scrum „Sprints“, genannt. Jeder Sprint beginnt mit einer gemeinsamen Planungssitzung, in der das Arbeitspensum besprochen wird. Dabei ist der Product Owner dafür zuständig, die Anforderungen in einem bestimmten Format zu liefern. Alle Anforderungen werden im Sprintplanning in konkrete Aufgaben zerlegt. Das Team bearbeitet diese Aufgaben und stimmt sich täglich über den Fortschritt ab.

Am Ende eines Sprints stellt das Team seine Zwischenergebnisse dem Product Owner vor und bekommt sofort ein Feedback, ob die entwickelte Lösung dem Wunsch des Product Owners entspricht. Mit diesem Feedback und neuen Anforderungen geht es dann in die Planung für den nächsten Sprint, und der Zyklus beginnt von neuem. So wird Sprint für Sprint das Endergebnis komplettiert und verbessert. Speziell ausgebildete Scrum-Master achten darauf, dass die Scrum-Regeln eingehalten werden, damit das Team Ergebnisse liefern kann. Sehr wichtig ist das Einhalten der Sprint-Termine. Sprints sind fest getaktet, und auf das Ende eines Sprints folgt schon der Beginn des nächsten. Wenn ein Team sich einmal für eine Sprintlänge (z. B. drei Wochen) entschieden hat, wird dieser Rhythmus auch beibehalten. Diese feste zeitliche Taktung können wir gut für unsere Ablagestruktur verwenden.

Abbildung 10.1 zeigt ein Beispiel für eine Ablagestruktur. Wir sehen jeweils einen Ordner für jeden Sprint. Für jeden neuen Sprint wird ein neuer Ordner hinzugefügt. Zudem sehen wir jeweils einen Ordner für Ergebnisdokumente und für die Projektplanung (Steuerungsdokumente).

Abbildung 10.1: Ablagestruktur anhand einer zeitlichen Struktur

Im Kapitel über die Ad-Hoc-Projekte haben wir Meilensteine als Unterordner genommen. Wir nutzen hier das gleiche Prinzip, nur dass wir statt Meilensteine die Sprints als Unterordnerbezeichnungen verwenden. Wie vorher schon beschrieben, können wir abgeschlossene Sprints ebenfalls archivieren.

Abbildung 10.2: Abgeschlossene Sprints werden sofort archiviert

Wie die Sprintordner weiter unterteilt werden, ist Angelegenheit der Teams. Wichtig sind folgende Punkte:

• Es gibt einen Klammerordner für das aktuelle Sprint-Backlog, in dem die Anforderungen für den aktuellen Sprint festgehalten werden.
• Es gibt einen Klammerordner, in dem Anmerkungen, Zeichnungen, Designvorgaben etc. zu den einzelnen Anforderungen gespeichert werden.
• Es gibt einen Ordner für Testprotokolle o. ä., die für einen Review aufbewahrt werden müssen.
• Alle E-Mails werden gemäß den vereinbarten Regeln im Sprintordner aufbewahrt.

Klare Verantwortung für die Ablage

In agilen Projekten gibt es immer einen Prozessverantwortlichen. Bei Scrum wird diese Rolle vom Scrum Master wahrgenommen. Er oder sie hat damit auch dafür zu sorgen, dass es einen Verantwortlichen für die Ablage gibt. Gemäß einem agilen Prinzip, dass sich das Team selbst organisiert, wird er diese Aufgabe mit dem Team besprechen.

Der oder diejenige, die die Verantwortung übernimmt, ist auch für das Anlegen und Archivieren von Sprint-Ordnern zuständig. Wenn der nächste Sprint beginnt, kopiert der Ablageverantwortliche alle Dokumente, die aufgehoben werden müssen, in den entsprechenden Klammerordner oder den Ordner für den nächsten Sprint. Der Ordner des abgeschlossenen Sprints wird archiviert.

Häufige Probleme bei agilen Teams

Was wir in agilen Projekten häufig vorfinden, ist eine Vielzahl von Sekundärsystemen, die zur Verwaltung eingesetzt werden. Hier ein typisches Beispiel:

• Die Liste mit Aufgaben und die Details werden in der Webanwendung JIRA verwaltet. Zusätzlich gibt es ein physikalisches Bord im Teamraum, auf dem man die laufenden Aufgaben sehen kann. Zum Teil werden elektronische Dokumente an einzelne Stories in JIRA angehängt.
• Die Quelltexte für die erstellte Software werden in Versionskontrollsystemen wie Subversion oder Git gespeichert.
• Fehler werden in Bugzilla verwaltet und per E-Mail kommuniziert.
• Sog. Build-Systeme automatisieren den Zusammenbau der einzelnen Softwareteile. Dabei laufen auch verschiedene Tests, die ihre Ergebnisse per E-Mail verkünden.
• Für Programmierrichtlinien, vereinbarte Standards, Systemdokumentation und Hilfetexte wird ein Wiki benutzt, über das sich jeder informieren kann.
• Hauptkommunikationsmittel ist das E-Mail-System.

Wegen dieser Vielfalt der Systeme rückt die eigentliche Ablage im Dateisystem in den Hintergrund. Sie wird nicht unbedingt als aktives Steuerungsinstrument wahrgenommen. Das ist zum einen verständlich, weil man wegen der Vielfalt nicht noch ein weiteres System benutzen will. Zum anderen sei an dieser Stelle darauf zur Wiederholung hingewiesen, dass die gemeinsame Ablage sich viel besser eignet, den Austausch der Dokumente im Team zu steuern.

Ohne gemeinsame Ablage ist das Team gezwungen, in allen vorhandenen Systemen nach Informationen zu suchen. Fehlende Dokumente werden wieder per E-Mail angefragt und verschickt. Jede Anfrage nach einem Dokument verursacht Wartezeiten und weitere Fehler.

Der Scrum Master ist daher gut beraten, Ablage zum Thema im Team zu machen. Das Team sollte sich klare Regeln geben:

• Es muss für alle Beteiligten klar sein, in welchem System welche Informationen gespeichert werden.
• Das Team sollte sich selbst verpflichten, keine Dokumente per E-Mail zu verschicken, wenn jeder im Team Zugriff auf die gemeinsame Ablage hat.
• E-Mails gehören in die gemeinsame Ablage.
• Das Team sollte sich Metriken geben, mit denen es selbst seinen Umgang mit E-Mails und elektronischen Dokumenten messen kann, um im Rahmen der kontinuierlichen Verbesserung rechtzeitig etwas gegen E-Mail-Flut und Co. zu unternehmen.

Die Vielzahl von Systemen erhöht die Ausfallwahrscheinlichkeit der gesamten Systemkette. Daher lohnt es sich, die gemeinsame Dateiablage als einen sicheren Ort zu nutzen, an dem man die Bauanleitungen für alle anderen verwendeten Systeme findet und zu dem man die Daten aus den anderen Systemen sichert.

Wo Sie weiterlesen können:

Falls Sie es mit komplexen Projekten zu tun haben, in denen verschiedene Teile integriert werden, sollten Sie einen Blick auf das folgende Kapitel werden.