**Extreme Programming** ist ein Ansatz, der in einem evolutionären Prozess in kleinen Schritten, sogenannten Releases, die Entwicklung vorantreibt.

Die wesentlichen Arbeitsschritte eines Projekts beschränken sich beim Extreme Programming auf die Planung einzelner Releases, Iterationen mit Programmierarbeiten sowie Abnahme-Tests für die einzelnen Releases. Das Entwicklerteam konzentriert sich ganz auf das eigentliche Programmieren, indem es auf umfassende Analysen verzichtet. Dahinter steckt das Ziel, einzelne Software-Releases möglichst schnell zu erzeugen. Typische Release-Intervalle betragen nur ein bis drei Monate. Hieraus soll ein zweifacher Nutzen für das Projekt erwachsen. Zum einen erhält der Auftraggeber bereits sehr früh ein Produkt, das seinen Verwendungszweck zumindest zum Teil erfüllt. Zum anderen erhalten die Anwender sehr
früh die Gelegenheit, den Entwicklern aufgrund erster Erfahrungen mit dem System Kommentare und Änderungswünsche mitzuteilen.

In diesem Punkt weist XP Analogien zur evolutionären Softwareentwicklung auf, die hier ins Extreme getrieben wird. Eine Charakterisierung des XP kann am besten durch die in XP eingesetzten Techniken erfolgen, die in der XP-Terminologie **Praktiken** heißen. Die Praktiken sind dabei nur in ihrer Gesamtheit sinnvoll. Das Weglassen einzelner Praktiken stellt das gesamte Vorgehen in Frage, weil sich die Praktiken gegenseitig unterstützen. Hier ein paar Aufzählungen von Praktiken:

![xp.jpg](https://files.peakd.com/file/peakd-hive/ozelot47/1eVrPI9j-xp.jpg)


**Abbildung: Modell zu Extreme Programming [3]**

* **Kleine Releases**
Wie bereits erwähnt, besteht eine erste Kernidee des XP darin, einzelne Software-Releases möglichst schnell zu erzeugen. Damit soll den sich ständig ändernden Anforderungen in einem Software-Projekt Rechnung getragen werden.

* **Tests**
Eine der zentralen Praktiken von XP ist das automatische Testen. Die Testfälle, die unbedingt vor der Implementierung der entsprechenden Features festgelegt werden müssen, repräsentieren neben den User Storys die einzige Festlegung der gewünschten Funktionalität.

* **Einfacher Entwurf**
Die Einfachheit der Lösungen wird als wichtiger Schritt auf dem Weg zu einer schnellen Lösung angesehen. Dem liegt auch die These zugrunde, dass ein Bemühen um technisch perfekte, allgemein wiederverwendbare, zukünftige Erweiterungen antizipierende Lösungen sinnlos ist, weil sich die Anforderungen bis dahin ohnehin geändert haben werden.

* **Dokumentation**
Im Hinblick auf die Dokumentation des Systems setzt XP auf Programmcode, der in hohem Maße selbsterklärend ist. Dazu ist auf eine entsprechende Programmstruktur und eine sinnvolle Namensgebung zu achten.

* **Programmieren in Zweierteams**
Die Programmierung geschieht bei XP immer in Zweierteams mit einer klaren Rollenverteilung. Der erste Partner kümmert sich um die aktuelle Kodierung, während der zweite Partner den Code auf Schreibfehler und logische Fehler überprüft und Strategien für weitere Implementierungen
entwickelt.

* **Gemeinsamer Code-Eigentum**
Der Entwickler bzw. das Paar, das einen bestimmten Programmcode erarbeitet hat, hat an diesem Code keine besonderen Rechte. Programmcode gehört in XP grundsätzlich allen Entwicklern gemeinsam. Das bedeutet, dass jedes Entwicklerpaar jederzeit überall Änderungen vornehmen darf (bspw. git).

* **Programmierrichtlinien**
Sowohl das Arbeiten in Paaren als auch das gemeinsame Code-Eigentum machen es erforderlich, dass Programmcode allgemein verständlich ist. Hierzu werden in XP feste Programmierrichtlinien verwendet, die von den Entwicklern untereinander vereinbart werden. Dadurch erhält man einheitlichen Code, der von allen Entwicklern verstanden und leicht modifiziert werden kann.

Wichtig ist dabei, die Voraussetzungen zu sehen, auf denen XP aufbaut:

1. Die Entwickler sollten alle über eine sehr gute und breite Qualifikation verfügen, da sie laufend in anderen Paaren und mit anderen Aufgaben eingesetzt werden.

2. XP ist für kleine Projekte mit 10 bis 15 Entwicklern gedacht und typischerweise in einem Umfeld mit sich rasch ändernden Anforderungen sinnvoll.

3. Die ganze Vorgehensweise im XP-Ansatz ist stark auf Kommunikation ausgerichtet und damit am besten umsetzbar, wenn die Entwickler an einem Ort konzentriert sind und die gleichen Arbeitszeiten haben.

4. Da die Tests sehr häufig ausgeführt werden müssen, sollten sie weder zu umfangreich noch zu laufzeitintensiv sein. Andererseits müssen sie aber die gesamte Funktionalität des gewünschten Systems abdecken.

**Quellen**
[1] Jeffries, Ron (Editor): XProgramming.com, 2001 (http://www.xprogramming.com/index.htm)
[2] Beck, Kent: Extreme Programming Explained – Embrace Change, Addison-Wesley, Reading, Mass., 1999
[3] expertiza.csc.ncsu.edu/images/5/5b/Extreme.jpg