Scrum und XP im harten Projektalltag

WIE WIR SCRUM MIT XP KOMBINIEREN| 87
Verbesserung der bestehenden Architektur. Nur selten stecken wir viel
Zeit in eine vorab durchspezifizierte, alles umfassende Gesamtarchitektur.
Manchmal vergeigen wir es natürlich und erlauben es windigen
Architekturen sich festzusetzen. Dann artet das Refactoring meist zu
einem größeren Projekt aus. Im Großen und Ganzen sind wir aber recht
zufrieden.
Die kontinuierliche Verbesserung des Designs ist ein beinahe schon
automatischer Nebeneffekt der testgetriebenen Entwicklung.
Fortlaufende Integration
Die meisten unserer Produkte haben eine recht ausgereifte
Laufzeitumgebung zur fortlaufenden Integration auf der Basis von Maven
und QuickBuild. Das ist außerordentlich nützlich und zeitsparend. Es ist
die ultimative Antwort auf den nur allzu bekannten Satz "Aber auf
meinem Rechner läuft es". Unser System zur fortlaufenden Integration
dient als eine Art Richter bzw. Referenzpunkt, von dem aus sich der
Gesundheitszustand all unserer Codebasen prüfen lässt. Wann immer
etwas ins Versionskontrollsystem eincheckt wird, erwacht es, baut auf
einem frei zugänglichen Server die Software von Grund auf neu und lässt
alle Tests ablaufen. Geht dabei etwas schief, sendet das System an das
Team eine Email mit der Nachricht, dass der Buildvorgang
fehlgeschlagen ist - inklusive Angaben, wessen Code-Änderung zu dem
Problem geführt hat und einem Link zu den Testresultaten.
Jede Nacht baut das System die Software neu und veröffentlicht in
unserem Informations-Portal Binär-Archive (ears, wars, etc),
Dokumentationen, Auswertungen zu Tests, Testabdeckung und Code-
Abhängigkeiten. Einige unserer Produkte werden sogar automatisch auf
einer Testumgebung installiert.
So aufwändig es auch war, dies alles zum Laufen zu bringen, hat sich
doch jede Minute ausgezahlt.
Gemeinsames Code- Eigentum
Wir ermutigen alle zu einer gemeinschaftlich verantworteten Codebasis -
also der Abkehr von den individuellen Modulen und Komponenten - aber
nicht alle Teams haben diese Praxis schon eingeführt. Wir haben
festgestellt, dass das Programmieren in Paaren mit häufig wechselnden
Partnern bereits in einem hohen Maß zu gemeinsamer Verantwortlichkeit
führt. Teams, die diese besonders gut etabliert haben, erweisen sich als
sehr robust. So müssen sie z.B. nur selten einen Sprint unterbrechen, weil
eine Schlüsselperson krank geworden ist.