Extreme Programming (XP)

Extreme Programming (XP) ist ein pragmatischer Ansatz zur Entwicklung von Software, der das Lösen einer Programmieraufgabe betont. Die in der Codeentwicklung häufig zugrunde gelegte formale Vorgehensweise rückt bei diesem Konzept in den Hintergrund.

Konkret folgt XP einem inkrementellen, iterativen Ansatz, der sich den Kundenanforderungen in kleinen Schritten nähert: Der Ansatz beginnt mit einem simplen Prototype, den der Entwickler testet, ändert und bis zum Endprodukt weiterentwickeln.

Das XP-Konzept wurde von Kent Beck, Autor des Buchs Extreme Programming Explained: Embrace Change, entwickelt. In dem Buch präsentiert er seine Grundidee, einfach zu starten, sofort etwas Reales zu bauen, das in einer begrenzten Art und Weise gut funktioniert, und dieses weiterzuentwickeln.

Laut Beck kommt in XP der Code immer zuerst. Allerdings betont Beck, dass man vor dem Schreiben von Code zuerst immer einen Test schreiben sollte, so dass man weiß, wenn der Code erfolgreich ist. Beck führt auch die relativ neue Idee ein, dass Code paarweise von Programmierern geschrieben werden sollte. Der Hintergedanke ist, dass der Hauptprogrammierer den Code dem anderen Programmierer beschreiben muss, und so weitere Ideen entstehen können.

Der theoretische Hintergrund von XP ist folgender: XP geht davon aus, dass der Kunde die Anforderungen an die zu erstellende Software zu Projektbeginn noch nicht komplett kennt und nicht hinreichend strukturieren kann. Zudem verfügt das Entwicklerteam oft nicht über alle Informationen, um ein Softwareprojekt verlässlich anzugehen. Im Laufe eines Projektes ändern sich nicht selten die Prioritäten. Zu Beginn geforderte Funktionen der Software werden möglicherweise in einer anderen Form benötigt oder im Laufe der Zeit sogar komplett hinfällig.

Beck nennt Extreme Programming eine „leichte Methodik“, die dazu führt, dass man die Software schon beim ersten Mal ziemlich gut hinbekommt - was auf lange Sicht der wirtschaftlichste Ansatz für das Programmieren sei. Das Modell betont Teamarbeit, Offenheit und Kommunikation. Anstatt sich zu spezialisieren, schreiben alle Teammitglieder Code, testen, analysieren, entwerfen und integrieren den Code kontinuierlich, während sich das Projekt entwickelt. Da vieles über Face-to-Face-Kommunikation abläuft, wird der Bedarf für Dokumentation minimiert.