Die fünf XP-Werte

XP ist nicht nur eine Sammlung von Praktiken – es ist ein Wertesystem. Die Praktiken ergeben nur im Kontext der Werte Sinn. Ohne die Werte erhält man Cargo-Kult-XP: Teams, die Bewegungen ausführen, ohne den Geist dahinter.

Die fünf XP-Werte sind: Kommunikation, Einfachheit, Feedback, Mut und Respekt.

Das sind keine Motivationsposter. Es sind Entscheidungswerkzeuge. Wenn Sie unsicher sind, was zu tun ist, fragen Sie sich, welche Wahl diese Werte am besten verkörpert.

Kommunikation ist der erste Wert, weil Softwareentwicklung grundsätzlich ein Kommunikationsproblem ist. Wir schreiben nicht nur Code – wir übersetzen menschliche Bedürfnisse in Maschinenanweisungen.

Missverständnisse sind die Grundursache der meisten Bugs. Der Kunde sagt „schnell", der Entwickler implementiert Caching, aber der Kunde meinte „weniger Klicks". Traditionelle Ansätze versuchen, dies mit Dokumentation zu lösen. XP löst es mit kontinuierlicher Kommunikation.

In XP bedeutet Kommunikation:

• Pair Programming (ständige technische Kommunikation)
• Kunde vor Ort (ständige Anforderungskommunikation)
• Daily Standups (ständige Teamkommunikation)
• Einfacher Code (Code, der seine Absicht kommuniziert)

Das Gegenteil von Kommunikation: annehmen, dass man weiß, was gebraucht wird, isoliert arbeiten, cleveren Code schreiben und Spezifikationen über die Mauer werfen.

Einfachheit bedeutet, das Einfachste zu tun, das möglicherweise funktionieren könnte. Nicht das Eleganteste, nicht das Erweiterbarste, nicht das Allgemeinste – das Einfachste.

Dies wird im XP-Mantra YAGNI: You Aren't Gonna Need It erfasst. Bauen Sie keine Frameworks. Fügen Sie keine Erweiterungspunkte hinzu. Verallgemeinern Sie nicht. Bauen Sie genau das, was heute gebraucht wird.

Warum? Weil:

• Einfacher Code weniger Bugs hat
• Einfacher Code leichter zu ändern ist
• Einfacher Code leichter zu verstehen ist
• Die Hälfte dessen, was Sie denken zu brauchen, werden Sie nicht brauchen

Das bedeutet nicht schlampig oder hacky. Einfacher Code ist oft schwerer zu schreiben als komplexer Code. Es erfordert tiefes Nachdenken darüber, was tatsächlich wesentlich ist.

Das Gegenteil von Einfachheit: für hypothetische zukünftige Anforderungen bauen, „nur für den Fall" Flexibilität hinzufügen, Abstraktionen erstellen, bevor man sie braucht.

Feedback ist, wie Sie lernen, ob Sie das Richtige tun. XP schafft Feedbackschleifen auf jeder Ebene:

• Sekunden: Unit-Tests sagen Ihnen, ob Ihr Code funktioniert
• Minuten: Pair-Partner fängt Fehler, während Sie tippen
• Stunden: Tägliche Integration offenbart Integrationsprobleme
• Tage: Wöchentliche Iterationen zeigen Kunden den Fortschritt
• Wochen: Release-Zyklen bestätigen, dass Sie das Richtige bauen

Je schneller das Feedback, desto günstiger die Behebung. Ein Bug, der in Sekunden gefangen wird, kostet nichts. Ein Bug, der in Produktion gefangen wird, kostet Zeit, Geld und Reputation.

XPs Praktiken sind darauf ausgelegt, schnelles, ehrliches Feedback zu erzeugen. Tests lügen nicht. Funktionierende Software lügt nicht. Produktionsmetriken lügen nicht.

Das Gegenteil von Feedback: wochenlang isoliert arbeiten, bis zum Ende warten, um zu testen, Kundenkontakt vermeiden, Produktionsmetriken ignorieren.

Mut bedeutet, das zu tun, was getan werden muss, auch wenn es unbequem ist. In XP zeigt sich Mut als:

• Rücksichtsloses Refactoring: Funktionierenden Code ändern, um ihn einfacher zu machen
• Code wegwerfen: Code löschen, der sein Gewicht nicht trägt
• Um Hilfe bitten: Zugeben, dass man etwas nicht weiß
• Sich zu Wort melden: Dem Kunden sagen, wenn Schätzungen falsch sind
• Neues ausprobieren: Experimentieren, auch wenn man scheitern könnte

Mut ist nicht Rücksichtslosigkeit. Er wird von den anderen Werten unterstützt. Sie können mit Mut refaktorieren, weil Sie Tests haben (Feedback). Sie können sich zu Wort melden, weil Sie Kundenbeziehungen haben (Kommunikation).

Das Gegenteil von Mut: kaputte Fenster zurücklassen, Schätzungen aufblähen, um „sicher" zu sein, schlechte Nachrichten verstecken, tun, was immer getan wurde.

Respekt wurde in der zweiten Auflage von Kent Becks Buch hinzugefügt und erkannte an, was immer implizit war: XP funktioniert nur, wenn Teammitglieder einander respektieren.

Respekt bedeutet:

• Der Kompetenz von Kollegen vertrauen (nicht mikromanagen)
• Den Beitrag aller wertschätzen (Entwickler, Tester, Kunden)
• Ehrliches Feedback freundlich geben (nicht den Geist zermalmen)
• Sich um die eigene Arbeit kümmern (keine Lasten für andere schaffen)

Beim Pair Programming bedeutet Respekt, den Ideen Ihres Partners zuzuhören. Bei der Planung bedeutet Respekt, ehrliche Schätzungen zu geben. Bei Code-Reviews bedeutet Respekt, Code zu kritisieren, nicht Menschen.

Das Gegenteil von Respekt: Ideen ohne Überlegung abtun, Schuld zuweisen, einige Rollen als weniger wichtig behandeln, sich mehr darum kümmern, recht zu haben, als effektiv zu sein.