Agile Softwareentwicklung

Extreme Programming

30.08.2010
Extreme Programming (XP) wurde Mitte der 90er Jahre von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt. Es handelt sich um ein iteratives, inkrementelles Vorgehensmodell.

Extreme Programming setzt sich zusammen aus Werten, Prinzipien, Techniken und Rollen.

Die Werte des XP

Kommunikation: Permanente und intensive Kommunikation der Entwickler untereinander sowie mit den Kunden erlaubt schnellstmögliches Feedback sicherzustellen, unnötige Funktionalität zu verhindern, entstehende Probleme so schnell wie möglich zu lösen und das Problem der fehlenden Dokumentation zu mildern.

Einfachheit: Die Software soll so einfach wie möglich gestaltet werden, keine Vorbereitung möglicher zukünftiger Erweiterungen, keine redundante oder unnötige Funktionalität und keine redundanten Strukturen sind geduldet. Dadurch bleibt das System einfach und wartbar. Dies basiert auf der Annahme, dass es effizienter ist, heute etwas einfaches zu erstellen und morgen etwas mehr Aufwand zu investieren, um Änderungen einzubauen, als heute Komplexes zu entwickeln, das morgen nicht oder nicht in der antizipierten Form genutzt wird.

Mut: Die Umsetzung der Prinzipien und Werte erfordert Mut. Dazu gehört, die Wahrheit über den Projektfortschritt und Aufwände zu kommunizieren, nicht nach Entschuldigungen für Fehler zu suchen und Änderungen anzunehmen, wann immer sie auftreten.

Feedback: Viele heutige Projekte scheitern an Missverständnissen zwischen Entwickler und Anwendern. Evolutionäre Entwicklung des Systems in möglichst kleinen Releases und eine permanente Verfügbarkeit der Kunden erlaubt schnelles Feedback und dadurch eine flexible Steuerung des Projektfortschritts. Eine weitere wichtige Quelle des Feedbacks ist die Entwicklung von Tests auf verschiedenen Ebenen (Unit-Tests, Test-Stories), um zu prüfen, ob die realisierte Funktionalität korrekt und robust ist und gegebene Anforderungen erfüllt.

Respekt: Jeder gibt und empfängt den Respekt, den er als Teammitglied verdient. Jeder liefert seinen Beitrag zum Erfolg, auch wenn es nur Begeisterung ist. Entwickler respektieren die Expertise der Kunden und umgekehrt.

Die Prinzipien des XP

Die Prinzipien bilden die Brücke zwischen den abstrakten Werten und den konkret anwendbaren Praktiken. XP beschreibt folgende 13 Prinzipien:

Menschlichkeit: Software wird von Menschen entwickelt. Menschen bilden also den Faktor, dem laut XP besondere Aufmerksamkeit gilt. Durch Schaffung einer menschlichen Atmosphäre soll den Grundbedürfnissen der Entwickler (Sicherheit, Vollendung, Identifikation mit der Gruppe, Perspektive und Verständnis) entsprochen werden.

Der XP-Prozess (www.extremeprogramming.org)
Foto: BQI

Wirtschaftlichkeit und beiderseitiger Vorteil: Die erstellte Software, beziehungsweise eine einzelne Funktionalität, muss einerseits wirtschaftlich sein und dennoch einen echten Wert bringen. Andererseits muss sie für beide Seiten von Vorteil sein und alle Beteiligten (Entwicklungsteam und Kunde) zufriedenstellen.

Verbesserungen und Vielfältigkeit: Die Wiederverwendung bestehender Lösungen, wozu beispielsweise die zahlreichen unterschiedlichen Tests gehören, die stetig automatisiert durchlaufen werden, ist wichtig. Dabei ist jedem Beteiligten klar, dass erste Lösungen meist nicht optimal sind. Aus Feedback und selbst gewonnenen, neuen Erkenntnissen wird die Lösung ständig verbessert.

Immer bessere Lösungen zu erkennen, gelingt nur durch stetige Reflexion und kontinuierliches Hinterfragen der jeweiligen Vorgehensweisen im Team. Die Produktivität dieses Verfahrens steigt proportional zur Uneinheitlichkeit des aus Personen mit unterschiedlichen Fähigkeiten und Charakteren bestehenden Teams. Verschiedene Meinungen werden nicht nur geduldet sondern sogar gefördert. Dazu muss ein Konfliktmanagement etabliert werden.

Fluss, Fehlschläge hinnehmen und Gelegenheiten wahrnehmen: Die Lauffähigkeit der Software muss zu jedem Zeitpunkt garantiert sein. Obwohl kurze Iterationen mit permanentem Feedback dabei helfen das Projekt in einem Fluss zu halten, müssen Fehlschläge dennoch miteinkalkuliert werden. Dabei ist es durchaus üblich und wird akzeptiert, eine Umsetzung durchzuführen, die zunächst nicht optimal oder sogar fehlerhaft sein kann. Diese Schwierigkeiten müssen als Gelegenheit und Chance begriffen werden, das Produkt und das Team noch weiter reifen zu lassen.

Ein offener, konstruktiver Umgang mit den Herausforderungen der Softwareentwicklung gelingt umso besser, je mehr alle Beteiligten bereit sind, ihre Verantwortung zu akzeptieren. Einem Entwickler eine Aktivität und Verantwortung nur disziplinarisch aufzutragen reicht nicht aus, da er die Verantwortung aktiv annehmen und auch leben muss.

Qualität: Ein weiterer wichtiger Punkt ist die hohe Qualität, die gemäß XP im Gegensatz zu anderen Faktoren wie Ressourcen, Funktionsumfang oder Endtermin nicht zur Diskussion steht. Diese Grundeinstellung unterscheidet sich von vielen anderen Methoden der Softwareerstellung, bei denen Software zu einem bestimmten Zeitpunkt und in einem definierten Funktionsumfang fertiggestellt werden soll, worunter fast immer die Softwarequalität leidet. Gerade die Qualität ist allerdings wichtig, um das Produkt einsatzfähig, fehlerfrei und erweiterbar zu halten. Software mit gutem Design und hoher Qualität ist mittelfristig kostengünstiger, erweiterbarer und weniger fehlerbehaftet, als schnell erstellte, sogenannte "Quick-and-dirty"-Software.

Redundanzen vermeiden: Zu guter Qualität gehört auch die Vermeidung von Redundanzen. Hierzu zählen unnötig mehrfach oder wiederholt ausgeführte oder auch manuell ausgeführte automatisierbare Schritte.

Kleine Schritte: Durch schnelle, kleine Schritte bleibt das Team flexibel und kann sich schnell neuen Rahmenbedingungen anpassen und auf Feedback eingehen. Die negativen Folgen eines einzelnen kleinen, nicht erfolgreichen Schrittes können wesentlich schneller durch einen neuen Schritt kompensiert werden, als dies bei einem einzelnen größeren Schritt der Fall wäre.

Die Techniken des XP

Folgende Techniken finden in XP Verwendung:

Planungsspiel: Im Planungsspiel werden die verfügbaren Entwicklerressourcen mit den Kundenwünschen in Einklang gebracht. Hier wird entschieden, welche Funktionalität als nächstes umgesetzt wird. Funktionen sind dabei als "User Story" beschrieben und werden priorisiert. Die Entwickler schätzen den Aufwand für die User Stories. Auf dieser Basis wird entschieden, welche Funktionen neu umzusetzen sind.

Kleine Releases: Beginne mit dem kleinsten sinnvollen Funktionsumfang. Liefere früh und häufig aus und ergänze jedes Mal neue Funktionen.

Ablauf innerhalb einer Iteration in XP. Eine Aktion innerhalb einer Iteration ist dabei die Entwicklung.
Foto: BQI

Systemmetapher: Unter der Systemmetapher wird die Grundarchitektur des Systems verstanden. Gemeint ist das Gesamtbild, das alle Entwickler vor Augen haben. Alle Entwickler kennen nicht nur den Teilbereich oder das Subsystem, an dem sie selbst arbeiten, sondern auch das Gesamtziel und die Grundarchitektur, die das System bestimmen.

Einfaches Design: Es wird immer das einfachst mögliche Design, das die aktuellen Anforderungen abdeckt, gewählt. Die Anforderungen ändern sich täglich, darum sollte man heute nichts machen, was man vielleicht morgen benötigen könnte.

Pair-Programming: Zwei Entwickler arbeiten zusammen an einem Rechner. Dabei ist der eine der "Driver", also derjenige, der entwickelt, und der andere der "Follower", der seine Überlegungen mit einfließen lässt. Diese Rollen werden ständig getauscht. Dadurch findet parallel zur Entwicklung ein Review des Codes statt.

Refactoring: Durch ein Refactoring wird die interne Struktur des Programms verbessert, ohne sein Verhalten oder die Funktionalität zu ändern.

Ständiges Testen: Bevor ein Entwickler eine neue Funktion implementiert schreibt er zunächst einen Test dafür ("Test first"). Typischerweise handelt es sich dabei um Unittests. Diese Unittests werden zu Test-Suiten zusammengefasst, die nach jeder Integration automatisch ablaufen.

Collective Code-Ownership: Der Sourcecode gehört dem ganzen Team. Jeder Entwickler sollte jederzeit jede Stelle des Codes bearbeiten können.

Vor-Ort-Kunde:

Das Entwicklungsteam arbeitet beim Kunden vor Ort. Dadurch ist eine intensive Zusammenarbeit und Kommunikation möglich. Ebenso erhalten die Entwickler schnell Feedback zu den bereitgestellten Releases.

Programmierrichtlinien: Die vorgegebenen Programmierrichtlinien (zum Beispiel Namenskonventionen) müssen von allen eingehalten werden. Dadurch wird der Sourcecode einheitlicher, was es einfacher macht, dass alle Entwickler überall arbeiten können.

40 Stunden Woche:

Überstunden verringern auf Dauer die Motivation und die Leistungsfähigkeit der Entwickler. In Ausnahmesituationen sind Überstunden erlaubt. Handelt es sich allerdings um einen Dauerzustand, ist mit dem Prozess etwas nicht in Ordnung.

Ständige Integration:

Alle Änderungen werden mindestens einmal täglich in die Codebasis eingespielt. Die Tests müssen sowohl vor als auch nach der Integration vollständig und fehlerfrei laufen.

Die Rollen des XP

In einem Projekt nach XP gibt es folgende Rollen:

Kunde: Der Kunde entscheidet, was ihm einen Mehrwert bringt, priorisiert diese Punkte und wählt aus was umzusetzen und was zurückzustellen ist. Darüber hinaus definiert er die Tests, welche die Funktionalität des Systems prüfen (Akzeptanztests).

Entwickler: Der Entwickler schätzt die Aufwände und die Komplexität der User Stories und steuert die Geschwindigkeit, mit der die Funktionalität entwickelt und ausgeliefert wird.

Manager: Der Manager bringt die Kunden und Entwickler zusammen und hilft ihnen, zu einem schlagkräftigen Team zusammenzuwachsen.

Bewertung BQI Research

Foto: BQI

Extreme Programming (XP) deckt unter den Disziplinen des Software Engineering die Implementierung (IMP) und den Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Qualitäts-Management (QM) und Requirements-Management (RM). Mittlere Abdeckung erfährt das Systemdesign/technische Konzeption (SD) sowie die Integration/Einführung (INT), während Wartung (W) und Projekt-Management (PM) nur schwach ausgeprägt sind. Der Betrieb (B) ist nicht abgebildet.