In den ersten beiden Teilen dieser Serie standen die Grundlagen und Prinzipien von Extreme Programming (XP) sowie die Historie und die Verfahren zur Projektplanung im Vordergrund. Der abschließende dritte Teil dieser Einführung erläutert die Verfahren, die XP zur Softwareentwicklung einsetzt, stellt die besondere Verteilung der Rollen im Projekt vor und berichtet über Erfahrungen und die Bedeutung von XP.

Entwicklungszyklus

Der Arbeitszyklus der Entwicklung in Extreme Programming besteht aus vier Phasen: Zuhören, Testen, Codieren, Design.

• Zuhören findet während des gesamten Projekts statt, vor allem aber am Anfang beim Erstellen und Behandeln der Stories mit dem Kunden.
• Testen kommt vor dem Code. XP fordert automatische Tests, die vor jedem Codieren erstellt und während jeder Integration ausgeführt werden.
• Code wird nach dem Testcode, aber vor großen Designaktivitäten erstellt. Der Code wird so einfach wie irgend möglich erstellt und dann geändert, bis die Testfälle funktionieren.
• Design findet überwiegend nach dem Codieren durch Refactoring statt, oder durch Refactoring anderer Systemteile als Vorbereitung des neuen Codes. Wenn eine Klasse funktioniert, wird sie und auch der Rest des Systems solange geändert, bis die gesamte Funktionalität durch das verständlichste und einfachste denkbare Design erzielt wird.

Dieser Entwicklungszyklus unterscheidet sich von anderen Prozessen und ist auf Risikovermeidung und Feedback getrimmt. Vor allem fallen der späte Zeitpunkt und die ungewöhnliche Methode des Designs auf. Durch diesen späten Zeitpunkt wird das Projekt nicht durch komplexe Strukturen gebremst, die später vielleicht doch nicht benötigt werden. Andererseits wird das Design nicht übergangen, sondern hat seinen festen Platz und findet unter hohen Qualitätsmaßstäben statt. Letztlich mindert dieser Designprozess das Projektrisiko, da Funktionalität früh sichtbar und immer erweitert wird.

Projekte, die Design hauptsächlich durch Refactoring betreiben, vermeiden effizient eine frühe Paralyse durch Überdesign, müssen allerdings der Versuchung widerstehen, mit Fertigstellung der Funktionalität auch den Code für fertig zu erklären. Vielmehr muss der Code jetzt noch einem Design unterzogen werden, damit im Sinne eines aufgeräumten Arbeitsplatzes die Software bereit ist, die nächste Funktionalität aufzunehmen. Besonders umfangreiche Refactoring-Maßnahmen fließen als eigene Entwicklungsaufgaben in die Planung ein.

Auch in Extremen Projekten findet ein grobes Design vor der Implementierung statt, zum Beispiel in Diskussionsrunden oder CRC-Kartensitzungen. Die so entwickelten Designideen können als Leitlinien zur Implementierung dienen, müssen aber als spekulativ angesehen werden, solange bis der Code über ihre Gültigkeit entscheidet.

Entwicklungsverfahren

Im Gegensatz zu den Planungsverfahren von Extreme Programming, bei denen Kunden und Entwickler eng zusammenarbeiten, betreffen die Entwicklungsverfahren primär den täglichen Zyklus der Entwickler. Kunden können und müssen diesen allerdings an einigen Stellen unterstützen.

• Kunde vor Ort
  Ein Schlüsselelement von XP ist die Kommunikation zwischen Kunden und Entwickler. Dazu muss ein Kunde mit dem Team zusammensitzen, arbeiten, in denselben Meetings sein und jederzeit Rede und Antwort stehen können.
• Metapher
  Die Metapher ist eine kurze Beschreibung, was das System tun soll und wie. Sie wird als Schlagwort, Geschichte oder Sammlung der zentralen Klassen ausgedrückt, damit sie allen Teammitgliedern geläufig ist. Sie dient somit als stark zusammengefasste Systemarchitektur und prägt mittelbar jede Implementierungsentscheidung.
• Programmieren in Paaren
  Der relevante Code wird in XP von zwei Programmierern entwickelt, die zusammen an einem Computer sitzen. Diese wechseln sich nach locker vorgegebenen Regeln am Steuer, also an der Tastatur, ab. Die Zusammensetzung der Paare erfolgt direkt von den Entwicklern. Die Paare werden immer wieder gewechselt und häufig aus Entwicklern unterschiedlicher Erfahrung zusammengesetzt. Die Zusammenarbeit und das Feedback ersetzt andere Maßnahmen wie zum Beispiel formale Code-Reviews.
• Zuerst testen
  Das Testen ist Voraussetzung für die Qualität des Codes und das Vertrauen der Entwickler wie des Kunden darin. Ein fehlschlagender Test hilft auch bei der Fokussierung auf die anstehende Aufgabe. Daher setzt XP den Test zeitlich noch vor den Code. Tests sind auch nötig für das Refactoring-Verfahren.
  Extreme Programming unterscheidet Funktionstests oder Akzeptanztests, die auf Basis der User Stories entstehen und parametrierbar sein sollten, und Unittests, die sich auf Klassen und Entwicklungsaufgaben beziehen. Alle Tests sind selbstprüfend, das heißt, dass nach Ablauf des Tests keine Ausgabelisten oder GUI-Reaktionen manuell mit einem Sollwert verglichen werden müssen. Die Tests prüfen selbst während ihres Ablaufs das tatsächliche gegen das erwartete Ergebnis und geben ein eindeutiges, digitales Ergebnis zurück. Zudem sind die Tests nicht interaktiv, sie können also ohne Bedienschritte vollständig automatisch ablaufen.
• Einfaches Design
  Das Design des Systems muss zu jedem Zeitpunkt so schlicht, einfach und verständlich wie möglich sein. Der Code muss die folgenden Kriterien in dieser Wertigkeit erfüllen:
  1. alle Tests bestehen;
  2. klar ausdrücken, was er macht;
  3. keine Verdopplung enthalten;
  4. mit einer minimalen Anzahl möglichst kleiner Klassen und Funktionen auskommen.
  XP verwendet plakative Merksätze, um das Streben nach einem einfachen Design in das tägliche Bewußtsein zu rücken:
  1. So einfach wie möglich, so kompliziert wie nötig;
  2. Einmal, und nur einmal;
  3. Du wirst es nicht brauchen.
• Bedingungsloses Refactoring
  Extreme Programming erfordert ein optimales Design, um auf Änderungen flexibel reagieren zu können. Refactoring (Fields et al., 1999) ist das Ändern der internen Codestruktur ohne Änderung des äußeren Verhaltens. Als wesentliches Designverfahren sorgt Refactoring für effiziente Entwicklung ohne vorauseilende Komplexität, und bewertet Funktionalität höher als brillante Konzepte.
  Für Projektmanager ist die Kenntnis wichtig, dass in XP Design oder Code nicht im klassischen Sinne "fertig" wird. Nach Einbau der Funktion kommt als erstes eine Änderung. Bis das System-Release erfolgt, kann es weiteren Änderungen unterliegen, wenn neue Stories ein geändertes einfaches Design erfordern.
• Ständige Integration
  Das System wird mehrfach täglich gebaut, integriert und getestet. Jeder Entwickler gleicht sich mehrfach täglich mit der stabilen Version des Systems ab. Fertiggestellte Entwicklungsaufgaben werden in diese stabile Version integriert und gelten nach Durchführung aller Tests und Refactoring auf das einfache Design als abgeschlossen.
• Gemeinsame Verantwortung
  Anstelle einer Zuordnung von Dateien oder Komponenten zu einzelnen Entwicklern führt Extreme Programming die gemeinsame Verantwortung ein. Jeder Entwickler darf jede Änderung jederzeit durchführen. Und jeder, der einen Fehler im Code entdeckt, oder eine mögliche Vereinfachung, ist zur Änderung im Rahmen der anderen XP-Verfahren verpflichtet.
   
• Programmierstandards
  Das Team sucht sich Standards aus und hält sich daran. Ziel dieses Standards ist Klarheit, Übersichtlichkeit und Einfachheit des Codes. Der Code soll so sprechend sein, dass er sich ohne lange Kommentare oder Dokumente anderen Teammitgliedern erschließt.

Rollen in einem Extremen Projekt

In vielen Softwareprojekten ist nicht ein ausgetüftelter Prozess ein Wettbewerbsvorteil, sondern ein zielorientiertes effizientes Vorgehen und kompetente Mitarbeiter. Entsprechend ist die Austauschbarkeit von Personen kein Ziel für Extreme Programming. XP setzt aber von allen Beteiligten ein hohes Maß an Selbstbewußtsein und Rollenverständnis voraus. Die im folgenden definierten Rollen werden im Projekt Personen zugeordnet, wobei einzelne Mitarbeiter auch mehrere Rollen übernehmen können.

Kunde

Der Kunde ist der Auftraggeber für das Projekt. Er schreibt, priorisiert und erklärt die User Stories, bestimmt den Inhalt von Releases und spezifiziert die Abnahmetests.

Rechte des Kunden und Managers

(Siehe hierzu auch Ron Jeffries, in: Yahoo Groups, 18.01.2000.)

Kunden und Manager haben das Recht darauf,

1. einen Übersichtsplan zu erhalten, um zu wissen, was erreichbar ist, wann und zu welchen Kosten;
2. den größtmöglichen Gewinn aus jeder Entwicklerwoche zu ziehen;
3. in einem arbeitenden System Fortschritte zu sehen, deren Funktionalität durch Tests nachgewiesen werden, die der Kunde vorgibt;
4. neue Ideen einzubringen, Funktionalität zu ändern oder zu streichen und Prioritäten zu ändern, ohne dafür einen exorbitanten Preis zu bezahlen;
5. über Änderungen im Zeitplan rechtzeitig informiert zu werden, um Maßnahmen zu definieren, wie das Streichen von Funktionalität, zum Einhalten des Endtermins. Das Projekt kann jederzeit abgebrochen werden, mit dem Ergebnis eines laufenden Systems, das die getätigten Investitionen widerspiegelt.

Entwickler

Der Entwickler schätzt die Aufwände für User Stories, leitet aus den Stories Programmiertätigkeiten ab, und implementiert Stories und Unit-Tests.

Rechte des Entwicklers

(Siehe hierzu auch Ron Jeffries, in: Yahoo Groups, 18.01.2000.)

Entwickler haben das Recht darauf [Jeffries00],

• zu wissen was benötigt wird und mit welcher Priorität;
• immer mit hoher Qualität zu arbeiten;
• nach Hilfe zu fragen und sie zu erhalten, von Kollegen, Vorgesetzten und Kunden;
• eigene Aufwandsschätzungen zu machen und zu ändern;
• Verantwortungen zu akzeptieren, statt sie zugewiesen zu bekommen.

Coach

Der Coach beobachtet die anderen Projektmitglieder und wacht über die disziplinierte Einhaltung der XP-Verfahren.

Tester

Der Tester implementiert Abnahmetests, führt sie durch und veröffentlicht die Ergebnisse.

Tracker

Der Tracker geht alle paar Tage zu jedem Entwickler, schaut auf den Projektfortschritt und achtet auf eventuelle Schwierigkeiten. Bei Problemen kann er Gegenmaßnahmen initiieren, wie beispielsweise Hilfestellungen von Kollegen oder ein zusätzliches Treffen mit dem Kunden.

Projektmanager

Der Projektmanager bringt Kunden und Entwickler zusammen, plant die nötigen Meetings, kontrolliert die Ergebnisse und kümmert sich um Personal und den Geldgeber. Seine wichtigste Aufgabe ist das Beseitigen von Hindernissen, die andere Leute von ihrer Arbeit abhalten. Insbesondere ist der Manager für das Klima im Projekt verantwortlich, das durch Angstfreiheit geprägt sein muss und Fehler als Lernen akzeptiert.

Einige Rollen sind gegen eine klassische Rollenverteilung etwas verschoben. In Extreme Programming sagt der Manager nicht, was wer bis wann tun soll, und überwacht das auch nicht. Diese Verantwortungen werden ihm durch die Planungsverfahren (siehe Teil 2) abgenommen, in denen Kunden meist direkt mit Entwicklern kommunizieren, beziehungsweise werden vom Tracker erledigt. Anstatt sich als Bote und mit mechanischen Tätigkeiten zu verschleißen, können sich Manager in der XP-Rollenverteilung ganz auf die Arbeit in der Außenwelt und an den "weichen Faktoren" im Inneren konzentrieren, um so das Projekt sicher zu manövrieren.

Entwickler sind in dieser Rollendefinition in höherem Maße für die Qualität ihrer Arbeit verantwortlich. Die Rolle des Coaches ist spezifisch für XP und nötig geworden, da fehlende Disziplin und eine Abweichung von einzelnen Verfahren den Erfolg des gesamten Prozesses und Projekts gefährden kann.

Erfahrungen

Extreme Programming ist zur Zeit eine Modeerscheinung; der Aufmerksamkeit steht noch wenig Substanz gegenüber. Unter den Protagonisten und frühen Anwendern gibt es allerdings einen regen Erfahrungsaustausch. Neben stark frequentiertenMailinglisten (XP-Forum) gibt es mittlerweile eine Newsgroup (XP-News) und die ersten lokalen Benutzergruppen; in Deutschland sind es Hamburg, München und Berlin.

XP bietet interessante Perspektiven

Da XP der Erfahrungswelt vieler Software-Ingenieure entspricht und für viele Projekte interessante Perspektiven bietet, finden sich immer mehr Projekte und Manager, die XP ausprobieren und deren Prinzipien und Verfahren anwenden. Einige folgen Extreme Programming mit dem Anspruch, die Gesamtheit der Verfahren anzuwenden, da XP sich als minimal versteht. Die Projekte, die sich offen zu XP bekennen, sind im Wiki zu finden.

Daneben gibt es auch einen eher opportunistischen Ansatz. Viele Projekte, die bereits ähnliche Prinzipien wie die von Extreme Programming verfolgt haben, führen die Verfahren einzeln ein. Dies erfolgt in dem Moment, in dem sie eine höhere Effizienz oder Qualität versprechen als die bis dahin praktizierten.

Extreme Programming verändert die Zuständigkeiten und Rollen im Vergleich zu anderen Vorgehensmodellen und stößt damit in seiner Vollausprägung noch auf Skepsis. Oft wird XP dann nur von Entwicklerseite verfolgt. Dieser Ansatz erzeugt leider gelegentlich mehr Konflikte als er löst, da die wichtige Kommunikation und Rückkopplungsschleife zum Kunden nicht nur offen bleiben, sondern durch gegenseitiges Unverständnis noch zusätzlich behindert werden kann.

Ein Coach verhindert das Chaos

Eine der wichtigsten Erfahrungen aus frühen XP-Projekten ist die Notwendigkeit eines Coaches. Da die Verfahren sich gegenseitig stützen, läuft XP Gefahr, zu einem chaotischen Prozess zu werden, wenn einzelne Säulen fehlen. Die Disziplin zum Einhalten aller Verfahren kommt bislang nur zustande, wenn ein Coach benannt wird, der zur Einhaltung motiviert. In diesem Sinne ist XP ein noch instabiler Prozess, der sich nicht selbst trägt. Extreme Programming hat außer dem Coach keine Mechanismen, um einen individuellen Mangel an Disziplin aufzufangen.

Zudem verlangt XP eine Selbstlosigkeit, die nicht viele Menschen mitbringen. Die geforderte strikte Disziplin kann als totalitäres Regime empfunden werden, und der persönliche Einsatz eines Coaches bevormundend wirken. Hier liegen derzeit Grenzen von XP, die den Einsatz in einer Organisation verhindern können - beziehungsweise eine eigene, gelassenere Ausprägung des Prozesses erfordern. Andere leichtgewichtige Entwicklungsprozesse, die mehr individuellen Freiraum erlauben, kommen aber eventuell in Frage, wie zum Beispiel Crystal Clear (Cockburn, 2000).

Wachsende Zahl von Frameworks erleichtert die Erstellung von Tests

Für die Unit-Tests gibt es für viele Sprachen inzwischen Frameworks, die die Erstellung eigener Tests erleichtern. Im Bereich Funktionstest gibt es bislang leider nur wenig Hilfestellung. Als hilfreich hat sich in manchen Projekten die Verwendung einer interpretierten Computersprache erwiesen. Programmieren in einer Sprache, die compiliert und gelinkt werden muss, verlängert die Feedbackschleife zwischen Test und Code erheblich. Was in Smalltalk Sekunden oder Minuten dauert, kann in C++ Stunden beanspruchen.

Der Großteil der Verfahren ist einzeln wenig umstritten, und auch mit der Kombination verschiedener Verfahren gibt es viele Erfahrungen. Oft setzen Entwickler einzelne Verfahren schon lange regelmäßig ein - je nach Anspruch der Entwicklung sind diese Ideen der letzte Strohhalm, der das Projekt gerade über den Meilenstein rettet, oder Bestandteil eines eingespielten aber inoffiziellen Prozesses, der das Einhalten eines offiziellen Prozesses durch zusätzliche Papiererzeugung vorspiegelt (Parnas; Clements, 1986). Letztere Projekte können vielleicht am meisten von Extreme Programming profitieren, da ihnen der Qualitätsanspruch geläufig ist, ihr effizienter und pragmatischer Umgang mit Richtlinien jetzt aber eine Chance zum "Outing" bekommt.

Bedeutung und Potential

Extreme Programming ist nicht der einzige leichtgewichtige Prozess, aber der derzeit populärste. XP hat die breite Diskussion über leichtgewichtige Prozesse angestoßen und diese salonfähig gemacht. Auch nach Abflauen der derzeitigen Euphorie werden viele der Prinzipien von XP und die Betonung der menschlichen und kommunikativen Aspekte Bestand haben. In vielen Branchen gilt es jetzt, die Qualitäten und Ziele von XP mit einem z.B. durch ISO zertifizierten Prozess zu kombinieren.

Da Extreme Programming konsequent auf Maßnahmen zur Qualitätserhaltung setzt, bei ständig wachsendem Funktionsumfang und größtmöglicher dauerhafter Effizienz, ist es ein wichtiger Schritt in Richtung eines Ingenieursdenkens in der Software-Entwicklung. Ingenieure aller Disziplinen haben einen Kanon an Verantwortung und Maßnahmen, die sie aus Berufsethos und schließlich auch aus rechtlichen Gründen einhalten - und der weitgehend unumstritten ist. In XP sind Entwickler, genau wie Ingenieure in anderen Disziplinen, primär für die Qualität ihrer Arbeit verantwortlich und nicht für den Umfang. Zu dieser Qualität in der Software gehören insbesondere Tests, Programmieren in Paaren, Refactoring und die ständige Integration.

Trotz aller Einschränkungen: von XP kann jedes Software-Projekt und seine Beteiligten eine Menge lernen. Und Projekte bestehen ja aus ständigem Lernen und Verbessern.

Literatur

• Beck, Kent: Extreme Programming Explained. Embrace Change, Addison-Wesley, 1999a
• Beck, Kent: Embracing Change with Extreme Programming, in: Computer (Institute of Electrical and Electronics Engineers), Vol. 32, Nr. 10, 1999b, p. 70-77
• Beck, Kent; Fowler, Martin: Planning Extreme Programming, Addison-Wesley, 2000
• Cockburn, Alistair: Writing Effective Use Cases, Addison-Wesley, 2000
• De Marco, Tom; Lister, Timothy: Peopleware. Productive Projects and Teams, Kindle Edition, 2010
• Fields, Jay et al.: Refactoring. Ruby Edition, Addison-Wesley Longman, 2009 (Siehe auch http://refactoring.com
• Parnas, David; Clements, Paul: A Rational Design Process: How and Why to Fake it, in: IEEE Transactions on Software Engineering, Feb. 1986, p. 251-257