2 Drei agile Methoden: eine kurze Einführung
Bevor wir uns den vertiefenden Themen widmen, werden in diesem Abschnitt exemplarisch drei ausgewählte agile Verfahren vorgestellt. Das ist nicht in aller Tiefe möglich, und hier auch nicht nötig, aber ein kleiner Überblick ist sinnvoll, um die nachfolgende Diskussion „griffiger“ zu machen.
2.1 Extreme Programming (XP)
Bei Extreme Programming liegt ein besonderes Augenmerk auf den gemeinsamen Werten und Prinzipien des Teams bei der Entwicklung von Software. Weiterhin liegt ein Schwerpunkt auf den Themen Implementierung und Test. XP beinhaltet die folgenden Elemente (vgl. Beck, 2005):
- Eine Philosophie zur Softwareentwicklung, die auf folgenden gemeinsamen Werten basiert: Kommunikation, Feedback, Einfachheit, Mut und Respekt.
- Ein Rahmenwerk von agilen Techniken, die sich bei der Verbesserung von Entwicklungsprozessen als besonders erfolgreich gezeigt haben. Sie ergänzen sich gegenseitig und können als konkrete Operationalisierung der XP-Werte verstanden werden.
- Einen Satz von Prinzipien, mit denen man die Werte in die Praxis überführen kann. Das ist hilfreich, wenn man keine Technik innerhalb von XP vorfindet, die das eigene spezielle Problem löst. Insofern ist XP keine geschlossene, fertige Methode.
- Eine Gemeinschaft von Entwicklern, die alle diese Werte in sich tragen und viele dieser Praktiken befolgen.
In Abbildung 2.1 ist beispielhaft ein Prozessbild dargestellt, um den Verlauf eines XP-Projekts zu visualisieren. Das entspricht so gar nicht dem Grundgedanken von XP, der ja gerade die Festlegung und kontinuierliche Verbesserung des Prozesses dem Team überlässt. Verstehen Sie also den dargestellten Ablauf nur als Beispiel, wie man es machen könnte, und als Erklärungsmittel, um Ihnen XP näher zu bringen. Die Empfehlung zum Einsatz von XP lautet folgendermaßen (vgl. Beck, 2003, S. 123):
- Man wählt das schlimmste Problem aus
- Man löst es unter Verwendung der XP-Konzepte
- Wenn es nicht mehr das schlimmste Problem ist, beginnt man wieder von vorn
Abbildung 2.1: Beispielhafter Ablauf eines XP-Projekts1
Denn das Team soll ja den Prozess gestalten. Insofern wurde hier mit einem Prozessbild nur eine Instanz von XP dargestellt, die aber keinen allgemeingültigen Anspruch haben kann. Dieser Gedanke ist Teil der Methode. Man wird überrascht sein, wenn man das Buch von Kent Beck liest, wie wenig ins Detail gegangen wird.
XP vertritt extreme Sichtweisen, wenn es zum Beispiel vorgibt, ganz ohne Dokumentation auszukommen. Die einzigen Artefakte sind ausführbarer Programmcode und die zugehörigen Testfälle. Anforderungen werden als User Stories erfasst, zum Beispiel handschriftlich auf kleinen Karteikärtchen. Kurz vor der Implementierung, oder auch währenddessen, werden die User Stories dann mit dem Kunden besprochen. User Stories werden gemeinsam im Team eingeplant. Das erfolgt häufig spielerisch, zum Beispiel mit Planning Poker. Dabei schätzen alle Teammitglieder die Komplexität der User Story verdeckt. Dann werden die Karten aufgedeckt, diejenigen mit der höchsten und mit der geringsten Schätzung müssen dann erläutern, wie sie zu ihren Schätzungen gekommen sind.
Das gemeinsame Planen endet damit, dass man die User Stories in priorisierter Reihenfolge abarbeitet. Dabei wird immer in Iterationen vorgegangen, die nicht länger als ein bis drei Wochen sind. Innerhalb dieser Iterationen werden die User Stories dann von den Entwicklern, häufig durch paarweise Programmierung, abgearbeitet, das heißt analysiert, entworfen, implementiert und getestet. Welche Aufgaben ein Entwickler übernimmt, entscheidet er selbst, er schätzt auch den tatsächlichen Aufwand. Am Ende der Iteration wird das Produkt allen Interessenträgern vorgeführt, um Feedback zu bekommen. Folgende primäre Techniken kommen bei XP zum Einsatz (vgl. Beck, 2005):
Individuen und Interaktionen und Zusammenarbeit mit dem Kunden |
Alle in einem Raum: Alle Personen sollen möglichst in einem Raum sitzen, damit sich die informelle Kommunikation verbessert. |
Funktionsübergreifendes Team: Es wird explizit gefordert, dass alle notwendigen Fähigkeiten im Team vorhanden sein sollen. |
Informatives Arbeitsumfeld: Durch Informationswände sollen zentrale Projektinformationen allen unmittelbar zugänglich gemacht werden. |
8-Stunden-Tag: Auf Überstunden soll zu Gunsten eines gesunden und leistungsfähigen Mitarbeiters verzichtet werden. |
Paarweise programmieren: Dabei werden speziell kritische Teile des Systems zu zweit programmiert. |
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen. |
Reagieren auf Veränderung |
User Stories: Anforderungen werden in Form von wenigen Sätzen auf Kärtchen erfasst. |
Wöchentliche Iteration: Jede Woche nimmt sich das Team seine Aufgaben vor und arbeitet sie bis zum Ende der Iteration ab. |
Vierteljährliche Iteration: Mit größerem Abstand erfolgt die übergeordnete Planung von größeren Releases und Aufgabenstellungen. |
10-Minuten-Build: Innerhalb von 10 Minuten sollen der gesamte Code kompilierbar und die automatisierten Testfälle durchführbar sein. |
Continuous Integration: Ein Integrationsserver soll kontinuierlich den Code kompilieren und durchtesten. |
Testgetriebene Entwicklung: Zuerst sollen die Tests geschrieben werden, und dann erst soll die Implementierung der eigentlichen Funktionalität erfolgen. |
Inkrementelles Design: Es wird gefordert, immer nur das aktuelle Problem mit dem dafür einfachsten Entwurf zu lösen. In Folgeiterationen wird der Entwurf dann erweitert. |
Tabelle 2.1: Techniken in XP
Die agilen Techniken in XP können auch einzeln eingeführt werden. Allerdings wird eine Kombination der vorgestellten Techniken empfohlen, da sie sich gegenseitig ergänzen. Ein Wegfallen von Dokumentation funktioniert beispielsweise am besten bei intensiver Einführung verschiedener Techniken wie User Stories, paarweiser Programmierung und testgetriebener Entwicklung. Neben den dargestellten primären Techniken führt XP weitere zwölf Techniken ein, sodass XP in der vollen Ausbaustufe aus vierundzwanzig Techniken besteht. Daran kann man erkennen, dass die Einführung von XP typischerweise nicht von heute auf morgen erfolgt, sondern eher nach und nach. Beginnen sollte man bei den primären Techniken.
kompakt: XP schlägt zwölf primäre und zwölf sekundäre agile Techniken vor, die sich gegenseitig ergänzen. Beginnen sollte man schrittweise mit der Einführung der primären Techniken. Viele Techniken betreffen die Arbeit des Teams aus technischer Sicht. Es werden aber auch Iterationen und Planungstechniken empfohlen.
2.2 Feature-driven Development (FDD)
Bei Feature-driven Development (FDD) handelt es sich um eine agile Methode, die von Jeff de Luca entwickelt wurde. Hier werden sechs Rollen definiert, von denen aber je nach Größe des Projekts nicht alle auf unterschiedlichen Personen verteilt sein müssen (Palmer und Felsing, 2002).
Rollen
Der Projektleiter ist für alle Fragen rund um Budget, Personal, Räumlichkeiten und sonstige Ausstattung verantwortlich. Er berichtet über den Status des Projekts nach außen und sorgt nach innen dafür, dass das Team ungestört arbeiten kann.
Der Development Manager ist für die Rahmenbedingungen des Teams zuständig und leitet die Entwicklungstätigkeit. Er löst auch Konflikte innerhalb des Teams, falls sie nicht eigenständig durch das Team gelöst werden können.
Der Chief Architect erstellt das Gesamtmodell des Systems und ist fachlich für die Entwicklungsarbeit verantwortlich. Er entscheidet auch zwischen unterschiedlichen Entwurfsalternativen, falls diese auf Architekturebene liegen.
Chief Programmer sind erfahrene Entwickler, die an der Analyse und am Entwurf des Systems mitwirken und zusammen mit einem Entwicklungsteam die Implementierung übernehmen.
Class Owner sind Entwickler, die jeweils für die Implementierung einzelner Klassen verantwortlich sind. Ein Entwickler kann Class Owner mehrerer Klassen sein. Zusammen mit dem Chief Architect arbeiten die Class Owner in kleinen Teams an der Umsetzung der Funktionen (Features).
Bei den Domain Experts...
