agile review Leseprobe Erfolgreich agil! (2021/S) - Page 8

die rache von xp
Wir merken Verschlechterungen der Architektur nicht sofort . Es riecht nicht , obwohl es ( Code- ) Smell genannt wird . Jede einzelne Nachlässigkeit ist kaum spürbar und technische Schulden bauen sich nur langsam auf . Allerdings summieren sich Zins und Zinseszins ( zunehmender Aufwand bei der Feature- Implementierung ) und Tilgung ( Refactoring , d . h . Umbau der inneren Architektur ohne Funktionalität zu ändern ) meist gewaltig auf und erst dadurch , dass die Zinsen einem die Luft abschnüren merken wir : Es gibt Handlungsbedarf . Die Investitionsfähigkeit des Teams für neue Features wird immer schlechter , weil es für jede Story immer mehr Unannehmlichkeiten in Kauf nehmen muss : Der Code ist immer weniger verständlich , die Architektur lässt neue Features immer umständlicher zu . Wir können diese Trends erkennen , denn agile Methoden stellen Transparenz her . Z . B . ist die Velocity 1 ein Maß dafür . Ist die Velocity gering oder nimmt über die Zeit ab , so ist das ein Indikator dafür , dass zu viele technische Verschlechterungen und eine zu unflexible Architektur existieren . Das Team muss seine Maßnahmen darauf richten . Aber es ist ein inneres Maß , ein Maß für das Team . Wird das Maß von außen verwendet , entsteht Druck , der zu mehr Features führt . Diese können am leichtesten umgesetzt werden , wenn das Team den Dreiklang aufgibt und auf die Aufräumarbeiten verzichtet . Der Schuldenstrudel setzt ein .
Späte Rache ist süß
1
Bei der Velocity weise ich allen Storys Aufwandspunkte zu und messe für immer gleichlange Zeiträume , wie viel Aufwandspunkte vollständig fertig werden . Damit kann ich die Geschwindigkeit des Teams im zeitlichen Verlauf beobachten .
Agiles Vorgehen beruht im Kern auf kurzen Rückkopplungszyklen . Die Grundannahme ist , dass die Unsicherheit , genau das Kundenbedürfnis zu treffen , reduziert werden kann , indem kleine Schritte Erfahrungen liefern und das Team mit den Kunden zusammen stetig dazulernt . Als in den neunziger Jahren die agilen Methoden entstanden , war ein Vertreter besonders prominent : Extreme Programming ( XP ) [ Beck1999 ]. Es ging um allerlei ungewöhnliches Zeug . Wir sollten zu zweit an einem Stück Quelltext schreiben ( um gemeinsam über die Implementierung zu reflektieren ), wir sollten zuerst den automatisierten Test schreiben ( um alle Anforderungen regelmäßig ohne manuellen Mehraufwand prüfen lassen zu können ) und vieles weitere mehr . Insgesamt gibt es 13 Praktiken , die sich unter XP einreihen . Dann kamen weitere agile Methoden hinzu und XP wurde verdrängt . Es ging mehr um den Prozess und weniger um die handwerkliche Arbeit . Sinnvoll war das ebenso . Es ging niemandem um ein Entweder- Oder . Es sind sich ergänzende Aspekte . Die Fokussierung auf das Prozessmodell hat die Aufmerksamkeit von den XP-Praktiken genommen . Teams , Scrum Master , Manager kümmern sich vorwiegend um den Prozess und Softskills und vernachlässigen am Anfang die handwerklichen Fähigkeiten ( Hardskills ). Dummerweise merken wir gerade am Anfang nicht , was einem fehlt und welche Schulden dadurch angehäuft werden . Erst wenn über die Wochen die technischen Schulden ansteigen , die Fehler in Produktion zunehmen und die Architektur weniger wartbar , wird schnappt die Schuldenfalle zu . Das ist die Rache von XP . Das Team wird immer langsamer : Neue Features werden weniger , die Architektur ist schlechter änderbar , Tests brauchen länger , immer weniger wird das System verstanden .
agile rewiew Leseprobe Sonderausgabe 2021 8