eXtreme Programming: Ein Überblick

Extreme Programming (XP) [1-1] ist ein alternativer Ansatz zu den meisten gängigen Software Entwicklungsmethoden. Der erste Versuch wurde vor zehn Jahren in Firmen wie der Bayerischen Landesbank, Credit Swiss Life, Daimler Chrysler, First Union National Bank, Ford Motor Company oder UBS vorgenommen, um Softwareentwicklungskosten zu senken.

XP sticht aus der Masse der verschiedenen Möglichkeiten deshalb heraus, weil es sich vorwiegend an den Bedürfnissen der Kunden orientiert. Sowohl die Methoden als auch die Werkzeuge wurden so konzipiert, dass in der Entwicklung immer auf den Kunden eingegangen wird und Änderungen (sowohl vom Kunden aus, als auch vom Erzeuger) auch in einer späten Phase für die Programmierer keine große Umstellung bedeuten. Daraus leitet sich auch ein wichtiges Motto in XP ab:

Der Kunde bekommt das, was er braucht, und dann, wenn er es braucht.

Nachdrücklich wird vor allem Teamwork gefordert. Alle Mitarbeiter werden in den Produktionsprozess miteinbezogen. So gehören neben den Softwareentwicklern, auch die Manager und die Kunden zum Entwicklungsteam.

Jedes XP Projekt sollte grundsätzlich aus vier Teilen bestehen: Kommunikation, Einfachheit, Feedback und Courage. Programmierer kommunizieren mit den Kunden und Kollegen. Sie halten das Design und die Schnittstellen einfach und sauber. Feedback bekommen die Programmierer durch Testen, und zwar schon vom ersten Tag an. Dem Kunden wird so früh wie möglich eine lauffähige (beschränkt einsatzfähige) Version geliefert, die dann nach spezifischen Wünschen weiterentwickelt wird.

 [1-1]   What is Extreme Programming?

Die Erfinder

In den 90er entwickelte Kent Beck[1-2] mit Ward Cunningham[1-3] einen neuen Ansatz für Softwareentwicklung, der sowohl einfach umzusetzen als auch effizient sein sollte. Sie nahmen dafür erfolgreiche, existierende Konzepte und analysierten deren Schwächen und Stärken. Aus diesen Erkenntnissen wurde XP geboren, das von den Beiden in einem Projekt von Daimler Chrysler getestet wurde.

 [1-2]   Kent Beck

 [1-3]   Ward Cunningham

Theorie von XP

Die Vorgänger von XP setzten mehr auf schrittweise Annäherung (Iteration) als vollständige Planung - XP ist im Grunde ein beschleunigtes Spiralmodell. Es besteht aus einer Folge von Ansätzen, die jeder für sich allein betrachtet keinen Effekt auf das gesamte Projekt haben. Erst alle Komponenten zusammen ergeben eine völlig neue Methode in der Softwareentwicklung.

XP hat gegenüber anderen Methoden der Softwareentwicklung einige entscheidende Vorteile:

• Es ist, durch die einfachere Programmierweise möglich die Programmierkosten drastisch zu senken.
• Alle Tests werden, bevor Methoden programmiert werden, automatisiert und können während einer ganzen Projektzeit durchgeführt werden, d.h. schon bevor der erste Code geschrieben wird, während der Implementierung und danach, beziehungsweise auf neue Anforderungen mit neuen Tests reagiert wird, kann eine hohe Qualität garantiert werden.
• Änderungen der Spezifikation bedeuten in XP kein Problem.

Es gibt in XP einige Grundregeln, die sehr allgemein gehalten werden. Die wichtigsten sind:

• Mache das Einfachste, das funktionieren kann.
• Entwickeln ist eine komplizierte Tätigkeit, die Kommunikation benötigt.
• Zusammenarbeit sollte Spaß machen.

Der erste Teil wird Extreme Planning genannt. Dabei wird auf Karteikarten eine "Story" [1-4] geschrieben, und so den Entwicklern Aufgaben zugeteilt. Die Aufgaben werden mit Prioritäten und Schwierigkeitsgraden versehen. Der Sinn dabei ist, dass jedem Einzelnen seine eigene Zuständigkeit und die der Anderen genau bekannt ist, und niemand sich überfordert fühlt.

Als nächstes wird die Dauer der Entwicklung geschätzt. Die Stories können natürlich jederzeit geändert werden. [1-5]

Programmiert wird dann zu zweit, da so die Effizienz sehr gesteigert werden kann. Fehler werden viel eher erkannt, die Implementierung wird durch Diskussionen besser und die Aufmerksamkeit ist größer. Es sollten jedoch nicht immer die Selben zusammenarbeiten, sondern jeden Tag neue Gruppen entstehen. 40 Stunden sind die Grenze der Arbeitszeit pro Woche, da Erholung wichtig ist.

Falls eine Aufgabe früher als erwartet zu Ende ist, sollte man besser früher den Arbeitstag beenden, als noch am selben Tag eine neue Aufgabe zu beginnen.

Dokumentation ist zu jeder Zeit notwendig. Es wird dabei zwischen Design, Code, Reporting und Requirement Dokumentation unterschieden.

 [1-4]   Story-Card

 [1-5]   Planning XP

XP in der Praxis

User-Stories

Für jedes Projekt wird als erstes ein Pflichtenheft mit den abzuliefernden Features erstellt. Danach ist es die Aufgabe der Design-Gruppe, was zu welcher Zeit implementiert wird.

Bei XP werden keine Anforderungen formuliert, sondern Probleme, genannt `User Stories´, die das Produkt lösen soll, geschildert. Diese Form der Beschreibung ist auch in der Unified Modeling Language (UML) gebräuchlich, dort heißt sie `Use Case´.

Zum Beispiel soll eine neue Software einen Parkplatz verwalten. Das bedeutet Schranken steuern, Geld kassieren und für Belüftung sorgen. Kassenabschlüsse und regelmäßige Bilanzen müssen auch möglich sein. Daher wartet eine unübersehbare Vielzahl an Aufgaben auf das zuständige Projektteam.

Zunächst beschreibt der Kunde einfach alle `Vorfälle´, die den Betrieb des Parkplatzes ermöglichen, zum Beispiel die Steuerung der Einfahrtschranke:

Die User-Story beginnt als erstes mit dem Einfahren eines Autos auf dem Parkplatz. Der Fahrer bleibt vor der geschlossenen Einfahrtschranke stehen und fordert per Knopfdruck einen Parkschein an. Nachdem er ihn entnommen hat, öffnet sich die Einfahrtsschranke. Der Fahrer passiert diese, die sich dann gleich wieder schließt. Damit endet die Story.

Der aufmerksame Beobachter wird hier eine ganze Menge vermissen. zB: Was passiert, wenn der Parkplatz schon voll ist, oder wenn der Vorrat an Parkscheinen erschöpft ist? Was soll bei Versagen der Schranke oder einem Stromausfall passieren? Der Grundgedanke der User-Story ist nicht, in dem Pflichenheft nicht alles zu beschreiben, was passieren kann, sondern immer nur einen Teil. Erst die Gesamtheit aller Stories ergibt den vollständigen Verlauf. Falls später jemandem noch etwas Neues einfällt, kommt einfach eine weitere User-Story dazu.

Das ist auch schon die erste Besonderheit von XP: Die Mitarbeit des Kunden beschränkt sich nicht nur auf das Pflichtenheft und die Abnahmetest, sondern er ist während der ganzen Entwicklung mitten im Geschehen dabei. Günstigstenfalls sitzt ein Mitarbeiter des Kunden beim Entwicklerteam und sorgt damit für kurze Kommunikationsstrecken. In der Praxis wird der Kunde nur ungern einen seiner Mitarbeiter, der im Unternehmen auch andere Aufgaben hat, beim Lieferanten abstellen.

Design der kleinen Schritte

Wenn die meisten User Stories bekannt sind, beginnt das große Verhandeln. Der Kunde, das Management und die Entwickler einigen sich, welche User-Stories zu Beginn zur Umsetzung kommen sollen und bis wann die einzelnen Module vorliegen müssen. Dabei sind technische und kommerzielle Aspekte sehr wichtig. Daher müssen Entwickler und Manager gemeinsam verhandeln.

Nur die Entwickler geben Terminabschätzungen ab, denn die Kaufleute neigen in solchen Bereichen bekanntlich zu übertriebenem Optimismus. Nur wer für die Arbeit zuständig ist, kann verlässliche Zeiten abschätzen - entsprechende Erfahrung beim Einzelnen vorausgesetzt.

Am Ende jeder Phase beschreibt ein Release Plan für jedes einzelne Ziel des Projekts,

• ob es gleich zum Projektanfang fertig werden muss oder sich auch später realisieren lässt,

• wie lange es dauert, dieses Ziel zu erarbeiten,

• wie dessen erfolgreiche Umsetzung vom Gelingen anderer Stories abhängt und

• was die Umsetzung kostet.

Der Kunde bekommt entsprechend dieser Planung häufig Zwischenversionen des Projektes. Die Funktionalität nimmt dabei stetig zu und so kann der Abnehmer den Projektfortschritt beurteilen.

Die Stunde der Entwickler

Ab dieser Phase wird Code generiert. Durch die Priorisierung der einzelnen User-Stories weiß jedes Team, was zuerst funktionieren muss. Es teilt die User Stories in kleinere Subprojekte auf, deren Bearbeitung immer ungefähr zwei Arbeitstage dauert. Das hat jedoch den Nachteil, dass schwieregere Aufgaben schnell in abstrakte und kleine Module zerfallen. Jedes Module darf keine Zeile mehr als unbedingt nötig ist enthalten, weil niemand weiß, ob dieses Stück Code nach der nächsten Anforderungsänderung noch zu verwenden ist.

Zuerst wird immer eine Testfunktion für jedes Modules geschrieben, und zwar genauso sorgfältig wie die Funktionen der eigentlichen Anwendung. Diese Testmodule entwickeln sich genauso wie das gesamte Programm über die gesamte Projektzeit weiter. Erst danach beginnt das Ausprogrammieren des einzelnen Modules. Zunächst werden nur grundsätzliche Funktionen implementiert - aber der Anfang ist gemacht.

Wenn der erste Iterationsschritt fertig ist, integriert man die Module auch gleich in das Gesamtprogramm. Das bedeutet aber nicht, alle Module einfach zusammenzubinden. Wenn dann nichts funktioniert, kennt man die Ursache nicht und muss nach ihr mittels Debugging erst umfangreich gesucht werden. Stattdessen integriert man jedes Modul einzeln: Treten dann Fehler auf, ist klar, woher die kommen.

Weil die Teile schon bald sehr stark zusammenwachsen, erscheinen Mängel im Konzept zu einer Zeit, wo die Verbesserung noch wenig Mühe macht. Andererseits hat das Softwareteam noch nichts geschaffen, was einer User Story entspricht.

Ein Fachwerkhaus besteht zuerst auch nur aus einem hölzernen Gerüst. Die Form des Hauses ist aber schon zu erkennen, und jetzt ist ein Fehler noch durch Austausch eines Teiles zu beheben.

Der Aufwand für die häufigen Integrationen ist allerdings eher hoch und erfordert einen eigenen hauptberuflichen Integrator, der dann nicht fürs Programmieren zur Verfügung steht.

Annäherungen

In XP gilt die Regel: Tu nie mehr, als du tun musst! Wozu den Release Plan übererfüllen, wenn durch spätere Änderungen des Pflichenheftes diese Mehrarbeit womöglich wieder komplett nutzlos gemacht wurde?

Die entwickelte Software nähert sich schrittweise an das fertige Produkt an. Dadurch werfen Änderungen nicht gleich die ganze Planung über den Haufen und der Entwicklungsprozess bleibt wesentlich besser steuerbar. Niemand wird versuchen, auf Anhieb eine Gesamtlösung zu erzeugen: Wer weiß, wo noch Schwierigkeiten auftauchen können und ob der Kunde nicht seine Wünsche noch einmal ändert? Damit diese Annäherung auch funktioniert, muss man den Iterationsplan ständig neu verhandeln - einmal die Woche sehen, wie weit man gekommen ist, sich fragen, ob die Schätzungen noch stimmen, und eingreifen, wenn nicht.

Wurde früher die Frage `Wie weit seid ihr?´ gestellt, kam meist als Antwort etwas in diese Richtung: `Das Design ist fast fertig.´ In XP gibt es greifbare Zahlen zur Beantwortung dieser Frage: `Die User Story 'Kassieren'haben wir im Kasten´ oder `Es sind noch 17 von 47 User-Stories zu implementieren´.

Viele kleine Schritte

Durch die häufigen Integrationsschritte entstehen viele neue, getestete Versionen des Produkts, auf die sich der kundenseitige Abnahmetest anwenden lässt. Jedes Mal bei Erfolg bekommt der Kunde eine neue `Release´. Damit hat der Auftraggeber immer den Eindruck dass etwas weitergeht.

Außerdem kann der Abnehmer jede neue Release ausgiebig bei sich testen. Je länger jede neue Release für den Weg bis zum Kunden braucht, desto später kann dieser reagieren und Fehler und neue Anforderungen zurückmelden, und umso weniger Zeit bleibt, darauf zu reagieren.

Aus Fehlern lernen

Beim Planen der nächensten Release oder auch zum Zeitpunkt, wenn eine Story programmiert wird, gibt es oft Probleme, deren Lösung noch völlig unklar ist. Etwa in einer frühen Phase des Parkplatz-Projekts weiss wohl noch niemand so genau, wie man eigentlich die dortigen Schranken ansteuern muss.

Da dieses Detail aber von grosser Wichtigkeit für das Gelingen des gesamten Projektes ist, wird ein Sub-Team eine Prinziplösung suchen, um die verdeckten Probleme in dieser Spezialaufgabe zu finden. Diese Lösung lässt sich zwar im Projekt nicht weiter verwenden, zeigt aber einen möglichen Weg auf und ist somit keine vertane Mühe.

Je später wirkliche ernste Probleme zu Tage treten, desto teurer kommen sie sowohl der Softwarefirma als auch dem Kunden zu stehen. Die Verringerung derartiger Risiken ist ein Hauptanliegen von XP.

Die Testphase

Erst wird programmiert, dann wird getestet. So wird immer schon Software entwickelt. Wenn man nun diese Reihenfolge umdreht, also zuerst einen Test für ein noch zu entwickelndes Modul ausprogrammiert, erleichtert das die Arbeit ganz wesentlich, denn

• der Test beschreibt die Modulfunktion aus anderer Sicht;

• beim Entwickeln des Tests treten neue Gesichtspunkte der Aufgabenstellung zu Tage und das Modul lässt sich schneller entwickeln;

• wenn bisher vom Test unerkannte Fehler auftreten, kann man die Prüfsoftware erweitern, sodass sie nun auch die `neuen Fehler´ meldet;

• auch wenn sich die Implementation der Module radikal ändert, bleibt der Test der gleiche und erleichtert die Verifikation.

In der Praxis wird erst ein einfacher Test entstehen, dann ein einfaches Stück Code. Anschließend wird der Test erweitert und dann wieder das Programm hinzugefügt - so wächst der Test nebenbei mit. Das funktioniert aber nur, solange der Druck auf die Programmierer nicht so groß wird, dass die nur noch `hacken´ können und der Test in Vergessenheit gerät.

Probleme

Damit XP funktioniert, müssen alle Beteiligten bereit sein, mitzumachen. Bei großen Projekten, aber vor allem bei Mitarbeitern die mit alteingesessenen Strukturen arbeiten, ist dies schwierig. Es ist auch darauf zu achten, dass Gespräche und Feedback regelmäßig geführt werden, und nicht mit der Zeit vernachlässigt werden.

Die meiste Kritik ruft das Pair Programming hervor. Wenn zwei Leute aufeinander treffen, die absolut nicht miteinander auskommen, wird die Arbeit für dieses Paar zur Qual. Dann bilden sich Untergrüppchen im Mitarbeiterpool, und der Kommunikationsfluss kommt zum Erliegen. Obendrein funktioniert das Konzept bei weniger als fünf Mitarbeitern nicht, weil zu wenig `Abwechslung´ möglich ist. Bei Gruppen über zehn Entwicklern gibt es noch gar keine Erfahrung.

Der wichtige Aspekt, durch viele kleine Iterationen schnell auf Störungen und geänderte Randbedingungen zu reagieren, widerspricht in den meisten Unternehmen den dort praktizierten Projektabläufen. Ein XP-Team muss sich also ständig gegen Althergebrachtes wehren.

Der Kunde ist bei XP zur intensiven Zusammenarbeit aufgefordert. Geht er darauf ein, bekommt er auch etwas dafür: den besseren Überblick über den aktuellen Projektstatus und viele kleine Vorablieferungen. Nur - wenn der Auftraggeber nicht von XP überzeugt ist, dann will er alles wie gewohnt und spielt nicht mit bei den vielen Iterationszyklen.

Abschliessende Worte

XP gibt es seit 1995. Seitdem sind ein paar Projekte damit realisiert worden, aber weite Verbreitung hat XP nicht gefunden. Viele Ideen lassen sich in der Praxis nicht vernünftig umsetzen.

Bibliothek

• Dr. Andreas Elting, Dr. Walter Huber, Immer im Plan?, c't 2/2002, S. 184ff
• K. Beck, Extreme Programming explained, Addison-Wesley Longman, 2000
• Dr. Andreas Elting, Dr. Walter Huber, Schnellverfahren, c't 3/2001, S186ff

Links

• http://ootips.org/xp.html
• http://www.armaties.com/extreme.htm
• http://www.xprogramming.com/

Verweise auf Arbeiten anderer Gruppen

 SpiralModel

Das Spiralmodell kommt auch bei XP zur Anwendung.

Requirements Engineering

Beide Strömungen wollen Kundenwünsche herausfinden und die Machbarkeit überprüfen.

Modellierung

Hier ist ein Beispiel, das die Motivation der Entwickler von XP verdeutlicht. Die Softwareerzeugung soll kein maschineller Vorgang sein. Also weg von der Automatisierung.

Expertensysteme

Auch ein Grund warum XP gescheitert ist, sind die neuen Anwendungsgebiete und Anforderungen, wie beispielsweise Expertensysteme.