Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Während viele Projektmanager meinen, der Prozess zur Software-Entwicklung sei nicht detailliert genug beschrieben oder kontrolliert, vertritt Extreme Programming eine andere Meinung.

Traditionelles Software-Engineering ist durch einen vorhersagbaren Prozess charakterisiert. Dieser Prozess ist aus anderen Ingenieurswissenschaften entlehnt, und Software-Entwicklung wird oft durch Analogien zu Maschinenbau, Elektrotechnik oder Architektur beschrieben. Ihrer Meinung nach sollen Software-Kunden einmal eindeutig erklären, was sie erwarten. Das System wird dann mit allen Features entwickelt, getestet und ausgeliefert, und alle sind zufrieden.

So vorhersagbar ist die Welt nur leider nicht. Kunden ändern ihre Meinung, und Entwickler irren sich. Ausgetüftelte Strategien, mit solchen Unwägbarkeiten klarzukommen, wurden entwickelt - und berühren kaum das Kernproblem. Anstatt noch mehr vorherzusehen und zu berücksichtigen, müssen viele Projekte Änderungen als normal begreifen und mit den dadurch entstehenden Kosten umzugehen lernen. Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren.

Diese ausführliche Einführung umfaßt drei Teile. Der erste Teil klärt die Frage, was Extreme Programming eigentlich ist, erläutert die wichtigsten Grundlagen und geht auf die Prinzipien hinter XP ein. Zwei weitere Teile beschäftigen sich mit der Historie von XP, den Einsatzgebieten und Zielen, den Verfahren zur Projektplanung und Entwicklung und mit den spezifischen Rollen in einem extremen Projekt.

Was ist Extreme Programming?

Extreme Programming ist ein leichtgewichtiger, durch Risikomanagement und Software-Struktur gesteuerter Prozess zur Softwareentwicklung (Siehe Kent Beck: Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999). XP verzichtet auf Analogien zu anderen Ingenieursdisziplinen und bezieht sich ausschließlich auf Software.

Dabei setzt XP bekannte Prinzipien und Verfahren, die einzeln erprobt sind, in neuer Sichtweise zu einem Ganzen zusammen. Alles Gute wird betont, alles Unnötige weggelassen. Kent Beck, einer der Erfinder, versieht XP mit den Attributen "leicht, effizient, risikoarm, flexibel, vorhersagbar, menschlich und spaßig".

XP verlangt Disziplin und Verantwortungsbewusstsein

XP ist interessant, weil es Qualität und Effizienz in den Vordergrund der Entwicklung rückt und periphere Aufgaben zu vermeiden sucht. Wer gewohnt ist, mit schwergewichtigen Prozessen wie dem Capability Maturity Model (CMM) umzugehen, mag XP als Hacken empfinden. Das ist es nicht - XP verlangt viel Disziplin und Übernahme von Verantwortung. Allerdings kann XP nicht aus einem Lehrbuch abgeschrieben oder als Software-Lösung gekauft werden, sondern muss im jeweiligen Projekt von den beteiligten Personen zum Leben erweckt werden.

Grundlagen

Nach gängiger Lehrmeinung sind Fehler in der Anforderungsphase, bzw. nachträgliche Änderungen, um ein Vielfaches teurer als solche in der Analysephase, diese wiederum teurer als solche in der Designphase, und so weiter.

Wachsen die Kosten für Änderungen in einem Software-Projekt wirklich exponentiell mit dem Projektfortschritt? Geht man von einer langsameren Kostensteigerung aus, verändert sich damit die Sicht, welcher Prozess zur Software-Entwicklung der effektivste ist. XP bietet Mechanismen, diese Kostenkurve nahezu linear zu gestalten. Dementsprechend sieht XP erheblich weniger Vorausplanung vor und verschiebt auch wichtige Entscheidungen für ein Projekt nach hinten: Auf einen Zeitpunkt, zu dem man mehr Information hat und eine effiziente und produktive Wahl treffen kann.

Diese Sicht von Änderungskosten ist das technische Leitmotiv von Extreme Programming.

Software ist Software