Scrum und XP im harten Projektalltag

WIE WIR TESTEN | 99
Uns gefielen aber die zeitlich nicht beschränkbaren Release-Phasen nicht,
wohl hauptsächlich, weil das den Rhythmus unserer Sprints
durcheinander bringen würde.
So könnten wir nicht mehr einfach alle drei Wochen einen neuen Sprint
starten. Außerdem löst es unser Problem nicht vollständig, denn selbst mit
einer Release-Phase würden gelegentlich Bugs "außer der Reihe"
gemeldet werden, auf die wir reagieren müssen.
Methode 2: "Es ist in Ordnung, Neues anzufangen.
Priorität hat aber die Auslieferung fertiger
Funktionalität."
Dies ist unsere bevorzugte Methode - zumindest im Moment.
Einfach gesagt, wir beenden einen Sprint und beginnen den nächsten.
Allerdings reservieren wir etwas Zeit für die Behebung von Fehlern aus
dem letzten Sprint. Wird ein Sprint arg in Mitleidenschaft gezogen, weil
wir viel Zeit für die Behebung alter Fehler aufwenden, prüfen wir, warum
das passiert ist und wie wir die Qualität verbessern können. Außerdem
sorgen wir dafür, dass Sprints lang genug sind, einige Bugfixes aus dem
vorhergehenden Sprint aufzunehmen.
Schrittweise, über mehrere Monate hinweg, ist der Zeitanteil zur
Behebung solcher Fehler zurückgegangen. Zudem ist es gelungen, beim
Bugfixing immer weniger Personen zu involvieren, und nicht jedes Mal
das gesamte Team zu unterbrechen. Jetzt sind wir auf einem
annehmbareren Stand angelangt.
Um dem Aufwand für solches Bugfixing Rechnung zu tragen, setzen wir
bei der Sprint-Planung den Fokus-Faktor entsprechend niedrig. Mit der
Zeit sind die Teams mit ihrer Schätzung immer besser geworden. Die
Metrik "Entwicklungsgeschwindigkeit" (engl. Velocity) hilft dabei
übrigens sehr (siehe dazu auch den Abschnitt "Wie entscheidet das
Teams, welche Stories in dem Sprint enthalten sind?").
BUG!
BUG!