Extreme Programming

Als ich 2000 das erste Mal von Extreme Programming (oder kurz XP) hörte, gab es das Agile Manifest noch nicht. Ich war CTO der Business Media AG und meine Aufgabe war es, einen Marktplatz für Wertvolle Inhalte im Web zu schaffen. Hierfür suchte ich Entwickler. Ich war geprägt von den Gewaltmärschen der New Economy und wollte in meinem eigenen Team eine gesunde, nachhaltige Produktivität ohne Ausbrennen oder überbordende Bürokratie. Da sprach mich Extreme Programming mit seinem Satz einfacher Regeln sehr an. Kent Beck hat seinen Prozess in einigen, nicht zu dicken Büchern gut dokumentiert:

• Extreme Programming Explained: Embrace Change (1999)
• Planning Extreme Programming (2000, zusammen mit Martin Fowler)

Daneben gibt es in der XP-Serie eine Reihe weiterer Bücher.

Aber auch im Web gibt es hervorragende Ressourcen zu XP. Die Wichtigste ist wohl Extreme Programming: A gentle introduction von Don Wells. Auf dieser Website findet man die Regeln (29 Regeln in den Kategorien Planung, Management, Software Design, Programmieren und Testen) von XP und die Werte, auf denen es basiert. Don betont, dass die Werte, nicht die Regeln der Ausgangspunkt seien. In einem betrieblichen Umfeld gibt es immer ein Zusammenspiel aus persönlichen und betrieblichen Werten. Zusätzlich zu den Werten und Regeln werden 12 Praktiken definiert.

Werte

Hier sind die Werte, auf denen Extreme Programming basiert. Um diese Werte an die eigenen Werte anzugleichen, müssen möglicherweise auch die weiter unten aufgelisteten Regeln angepasst oder erweitert werden.

Einfachheit. Das tun wonach gefragt wurde, aber nicht mehr. In kleine Schritten zum Ziel. Fehler gleich beheben, wenn sie auftreten. Etwas bauen, worauf man Stolz ist und es für vernünftige Kosten pflegen.

Kommunikation. Alles sind Teil des Teams und kommunizieren täglich. Alle arbeiten gemeinsam an den Anforderungen und am Code. Alle erschaffen die beste Problemlösung gemeinsam.

Feedback. Die eingegangene Verpflichtung einer Iteration wird ernst genommen; ihr Ergebnis ist funktionsfähige Software. Die Software wird früh und oft demonstriert. Sich aus den Rückmeldungen ergebende, erforderliche Änderungen werden eingearbeitet. Auch der Prozess ist Gegenstand von Gesprächen und kann an das Projekt angepasst werden, nicht anders herum.

Respect. Jedes Team-Mitglied gibt und schätzt den verdienten Respekt. Jeder steuert etwas bei, selbst wenn es nur Begeisterung ist. Entwickler schätzen die Expertise der Kunden und umgekehrt. Das Management schätzt die übernommene Verantwortung und ermächtigt das Team, für die eigene Arbeit verantwortlich zu sein.

Mut. Fortschritt und Schätzungen werden offengelegt. Entschuldigungen für Fehlschläge werden nicht dokumentiert; der Plan ist es, erfolgreich zu sein. Es gibt auch keinen Grund für Angst, da niemand allein arbeitet. Auf Änderungen wird eingegangen, wann immer sie passieren.

Regeln

Hier sind die 29 Regeln.

Planung

• User Stories werden geschrieben.
• Der Zeitplan für Releases wird in Release Planning festgelegt.
• Mache häufige, kleine Releases.
• Das Projekt ist in Iterationen aufgeteilt.
• Eine Iterationsplanung steht am Beginn geder Iteration.

Management

• Gib dem Team einen dedizierten Arbeitsbereich.
• Setze ein einhaltbares Tempo fest.
• Ein Stand-up Meeting steht am Beginn eines jeden Tages.
• Die Projektgeschwindigkeit wird gemessen.
• Verschiede Team-Mitglieder.
• Repariere XP, wenn es zerbricht.

Software Design

• Einfachheit.
• Wähle eine System-Metaphor.
• Nutze CRC (Class, Responsibilities, and Collaboration) Cards für Entwurfssitzungen.
• Entwickle Durchstiche zur Reduzierung von Risiken.
• Keine Funktionalität wird überfrüht eingeführt.
• Refactoriere wannimmer möglich.

Programmieren

• Der Kunde ist immer verfügbar.
• Code wird nach verabredeten Standards geschrieben.
• Codiere zuerst den Unit Test.
• Aller Code in Produktion ist in Pair Programming entstanden.
• Nur ein einziges Entwicklerpaar integriert
• Integriere oft.
• Nutze einen dedizierten Integrationsrechner.
• Nutze gemeinsame Eigentümerschaft über den Code.

Testen

• Aller Code muss Unit Tests besitzen.
• Aller Code muss alle Unit Tests bestehen bevor er releast werden kann.
• Wenn ein Fehler gefunden wird, werden Tests angelegt.
• Akzeptanztests werden oft durchgeführt und das Ergebnis wird publiziert.

Praktiken

Extreme Programming setzt 12 Praktiken, die sich in vier Bereiche gruppieren lassen.

Enge Zusammenarbeit

• Pair Programming
• Planing Game
• Testgetriebene Entwicklung
• Ganzheitliches Team

Fortlaufender Prozess

• Continuous Integration
• Kontinuierliche Verbesserungen am Entwurf
• Kleine Releases

Gemeinsames Verständnis

• Coding Standards
• Gemeinsamer Besitz des Codes
• Einfacher Entwurf
• System-Metaphor

Wohlergehen der Team-Mitglieder

• Einhaltbares Tempo