Agiles Projektmanagement – XP, FDD und Agile Up

Teil 5: Beschreibung von XP, FDD und Agile Up

In den letzten beiden Teilen unserer RFC Blogreihe zum agilen Projektmanagement haben wir mit Scrum und Kanban zwei der bekanntesten agilen Methoden thematisiert. Aber natürlich gibt es noch weitere anerkannte Methoden, von denen wir in diesem Blog einige vorstellen möchten.

eXtreme Programming (XP)

Charakteristisch für eXtreme Programming (XP) ist das zyklische Vorgehen auf allen Arbeitsebenen: Von der Programmierung, über die tägliche Abstimmung im Entwicklerteam, bis hin zum gemeinsamen Anforderungsmanagement mit dem Kunden. Dabei ist es unerlässlich, dass alle Beteiligten die fünf zentralen Werte von XP miteinander teilen und beachten:



Abbildung 1: Die zentralen Werte von XP


Beteiligte in einem XP-Projekt sind im Wesentlichen die Entwickler, der Kunde und der Product Owner. Innerhalb des Entwicklerteams sollte es keine Rollentrennung geben. Jeder im Team wird unabhängig von seiner Aufgabe als Entwickler bezeichnet. Innerhalb des Teams gibt es einen Leiter, der die Kommunikation mit dem Kunden oder untereinander koordiniert. Es ist aber auch möglich, dass der Nutzer der zu entwickelnden Software das Team führt. Die finale Verantwortung trägt der Product Owner, der auch gleichzeitig der Kunde sein kann.

Um XP in seiner reinen Form durchzuführen sind bestimmte Haupt- und Nebenpraktiken anzuwenden:

XP Anwendungsbereich Hauptpraktiken Nebenpraktiken
Organisatorisch Ein Team Starke Kundeneinbeziehung
Ein Raum Konstantes Team
Informativer Arbeitsplatz Vermeidung von Überstunden
Technisch Paar-Programmierung Geteilter Code / gemeinsame Code Verantwortung
Testgetriebene Entwicklung Dokumentierung von Code und Test durch Entwickler
Inkrementelles Design Code Refactoring ist gelebte Praxis
Planung User Stories Ursachenanalyse
Wöchentliche Zyklen / Iteration Zahlung pro Nutzung nicht pro erstellter Version
Quartärliche Zyklen / Release verhandelbarer, vertraglicher Funktionsumfang
Einbau von Sicherheitspuffern (Slack) Daily Standups
Integration 10-Minuten-Build Zentrale Codebasis
Kontinuierliche Integration inkrementelles Deployment
Test-First Tägliches Deployment

Tabelle 1: Praktiken XP


Die folgende Grafik stellt die Methode sehr anschaulich dar und setzt die einzelnen zeitlichen Zyklen in Beziehung:


Abbildung 2: Methode XP


Im Einzelnen bedeutet dies:

  • Sekundentakt: Das Programmieren in Paaren (Pair-Programming) führt dazu, dass sich die Entwickler ständig gegenseitig kontrollieren und auf Fehler oder umständliches Design aufmerksam machen.
  • Minutentakt: In XP wird testgetrieben entwickelt, die UNIT-Tests werden also vor dem Code geschrieben, so dass eine permanente Überprüfung des Codes stattfindet. Es gilt die Regelung des sog. 10-Minuten Build. Das bedeutet, dass die Entwicklung und der Test einer Softwareänderung in 10 Minuten abgeschlossen sein sollen, um die Kosten für Erstellung und Test der Software zu minimieren.
  • Stundentakt: Neu entwickelte Komponenten werden mehrmals täglich (mindestens alle zwei Stunden) in das lauffähige Gesamtsystem integriert (Continuous Integration). So lassen sich Fehler schneller finden – denn je später Fehler entdeckt werden, um so aufwändiger sind sie zu beheben.
  • Tagestakt: In XP findet ein tägliches Treffen (Standup-Meeting) statt, auf dem das Entwicklungsteam kurz über den Projektfortschritt reflektiert und Fehlentwicklungen vermeidet.
  • Wochentakt: XP legt größten Wert auf kurze Iterationszyklen von wenigen Wochen. So erhält der Kunde immer wieder lauffähige Systemversionen, um diese zu testen und seine fachlichen Anforderungen auf den neuesten Stand zu bringen. Es werden also nicht die Anforderungen umgesetzt, die zu Projektbeginn einmal definiert wurden, sondern entwickelt wird immer genau das, was in der aktuellen Situation den größten Mehrwert für den Kunden erzielt. Deshalb werden in regelmäßigen Abständen die Anforderungen neu priorisiert.
  • Monatstakt: Anders als in klassischen Projekten, in denen es nur ein großes Release am Ende der Projektlaufzeit gibt, werden in XP-Projekten regelmäßig – am besten monatlich – neue Releases produktiv gestellt. Durch die kurzen Release Zyklen kann sehr früh ein (Teil-) Geschäftswert generiert werden. XP-Projekte können deshalb sehr viel früher als klassische Projekte selbstfinanzierend werden. In Abständen von wenigen Monaten werden daher aktuelle Releasepläne erstellt, in denen die nächsten Iterationen definiert werden

Feature Driven Development (FDD)

Wie der Name schon sagt, stellt die Methode FDD, dass Feature in den Mittelpunkt. Jedes Feature stellt einen Mehrwert für den Kunden dar. Mit FDD sollen die spezifischen Bedürfnisse eines großen Softwareentwicklungsprojektes erfüllt werden. FDD definiert ein Prozess- und ein Rollenmodell, die gut mit existierenden klassischen Projektstrukturen harmonieren. Daher fällt es vielen Unternehmen leichter, FDD als XP oder Scrum einzuführen. Außerdem ist FDD ganz im Sinne der agilen Methoden sehr kompakt. Es lässt sich auf 10 Seiten komplett beschreiben.

In einem feature-gesteuerten Entwicklungsprojekt gibt es sechs Rollen. Dabei können einzelne Personen mehrere Rollen ausfüllen:

  • Projektmanager
  • Hauptarchitekt
  • Entwicklungsleiter
  • Chefprogrammierer
  • Klassenverantwortlicher (Class Owner)
  • Domänenexperte

Feature-gesteuerte Entwicklungsprojekte durchlaufen 5 Prozesse oder Vorgänge, die iterativ durchgeführt werden:

Prozess #1: Entwickle ein Gesamtmodell (Rollen: alle Projektbeteiligte)

Prozess #2: Erstelle eine Feature-Liste (Rollen: in der Regel nur die Chefprogrammierer)

Prozess #3: Planung je Feature (Rollen: Projektleiter, Entwicklungsleiter, Chefprogrammierer)

Prozess #4: Design je Feature (Rollen: Chefprogrammierer, Entwickler)

Prozess #5: Entwicklung je Feature (Rollen: Entwickler)

Abbildung 3 veranschaulicht den Projektlebenszyklus und die Wechselbeziehungen der 5 Prozesse untereinander. Die Entwicklung eines Features sollte nicht länger als zwei Wochen dauern.



Abbildung 3: Projektlebenszyklus eines Feature-gesteuerten Projektes


Agile Unified Process (AgileUP)

Der AgileUP definiert vier Projektphasen und sieben Workflows. Jede Projektphase wird pro Projekt einmal durchlaufen, die Workflows dagegen mehrfach iterativ pro Phase. Bestimmte Workflows werden dabei in bestimmten Phasen mehr oder weniger intensiv durchgeführt.

Die vier Phasen sind wie folgt definiert:

  1. Inception (Beginn): Das Team bestimmt den (initialen) Umfang des Projektes, eine mögliche Architektur und sichert sich die Finanzierung sowie die Akzeptanz der Stakeholder.
  2. Elaboration (Ausarbeitung): Die Machbarkeit wird sichergestellt und die Architektur endgültig definiert.
  3. Construction (Entwicklung): Die Software wird, basierend auf den Prioritäten des/der Stakeholder, inkrementell entwickelt.
  4. Transition (Übergang): Die Software wird vom Team validiert und in der Produktionsumgebung eingesetzt.

Die Workflows legen die Aktivitäten fest, die das Entwicklerteam in jeder Phase durchführen muss, um laufende Software zu bauen, zu validieren und zu liefern:

  • Model (Verstehen)
  • Implementation (Implementierung)
  • Test (Testen)
  • Deployment (Einsatz)
  • Configuration Management (Konfigurationsmanagement)
  • Project Management (Projektmanagement)
  • Environment (Umgebung)

Am Ende einer jeden Iteration wird ein Stück ausgeliefert und in einem Development-Release in eine Testumgebung (Vor-Produktionsumgebung) released. Wichtig dabei ist, dass das Development-Release qualitätsmäßig auch in eine Produktionsumgebung released werden könnte. In der Testumgebung wird dann die finale Qualitätssicherung durchgeführt, bevor dann aus mehreren Development-Releasen ein Produktions-Release erstellt und eingeführt wird.



Abbildung 4: Timeline eines AgileUP Projekte


Fazit:

Neben Scrum und Kanban gibt es viele weitere agile Methoden. Wir haben in diesem Blog weitere Methoden vorgestellt. Das Vorgehen ist jeweils unterschiedlich, das iterative Vorgehen, die Kundenorientierung, die Konzentration auf das Wesentliche und das Akzeptieren von Veränderungen ist aber bei allen Methoden gleich. Es ist und bleibt immens wichtig, dass das Mindset der Mitarbeiter und Manager auf die agilen Prinzipien ausgerichtet ist, um agile Methoden erfolgreich ausführen zu können.

Ausblick:

Im nächsten Teil unserer Blogreihe beschäftigen wir uns mit agilem Testen.

_________________________________________________________________________________

Übersicht aller Blogs unserer RFC Blogreihe Agiles Projektmanagement

Blog 1: VUCA und die Folgen für Unternehmen – Warum „Agiles Projektmanagement“?

Blog 2: Systematik des agilen Projektmanagements. Werte, Prinzipien, Techniken und Methoden – Was ist „Agiles Projektmanagement“?

Blog 3: Scrum ist eine der bekanntesten agilen Methoden – Was ist „Scrum“?

Blog 4: Kanban ist eine agile Methode für evolutionäres Change-Management – Wie funktioniert Kanban?

Blog 5: Beschreibung von XP, FDD und Agile Up

Blog 6: Testen im agilen Umfeld – Was bedeutet das?

Blog 7: Beschreibung von skalierten Methoden Teil 1: / SoS, LeSS und ES

Blog 8: Beschreibung von skalierten Methoden Teil 2 / SAFe und DA

Blog 9: Entscheidungsfindung – die Ermittlung der passenden Vorgehensweise

Blog 10: Hybrides Projektmanagement: Das Beste aus beiden Welten?

Blog 11: Agile Transition: Der Change-Management-Prozess in der Organisation

Blog 12: Menschen im agilen Umfeld / Herausforderungen und Lösungen für Veränderungsprozesse.

Gefällt Ihnen unsere Blogreihe, haben Sie Anmerkungen oder neue Ideen? Dann freuen wir uns, wenn Sie uns kontaktieren.

Steffen Hahn

Steffen
Hahn

Torsten Lindlahr

Torsten
Lindlahr

Hans Willhoeft

Hans
Willhöft