Teil 5: Agile Methoden neben Scrum und Kanban. eXtreme Programming, Feature Driven Development und Agile Up

Geschätzte Lesezeit: 4 Minuten

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:

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 Projektes

Fazit:

Neben Scrum und Kanban gibt es viele weitere agile Methoden. Wir haben in diesem Blog eine weitere Methode 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.

_________________________________________________________________________________

Ihre Ansprechpartner
Steffen Hahn
Steffen Hahn
Hans Willhoeft
Hans Willhoeft
Torsten Lindlahr
Torsten Lindlahr
Nach oben scrollen