Agile / Projektmanagement / Software-Entwicklung

Scrum: Verbesserungen durch agile Praktiken 2/5

Die Reise zur bimodalen IT – Station 2: Scrum läuft, aber nicht optimal. Nicht verzweifeln! Das Projekt ist absolut nicht beim ersten Stolperstein schon zum Scheitern verurteilt. Es gilt jetzt richtig zu handeln. Agile Praktiken und agile Arbeitsmethoden unterstützen, ständig einen Überblick über das Projekt und den Status zu bewahren, ständig Feedback über die Qualität und den Entwicklungsstand zu haben. Nur so ist man imstande auch gezielte Entscheidungen zu treffen und den Erfolg zu messen. Ich möchte Ihnen einige dieser Praktiken und Methoden vorstellen.

Optimierung Scrum durch agile Praktiken

Was bisher geschah

Die erste Station der bimodalen Reise hat sich mit dem Einstieg in die Agilität beschäftigt. Die spannende Geschichte eines Scrum Teams hat begonnen. Die Einführung von Scrum war nach ein paar Hürden und viel Misstrauen am Anfang erfolgreich. Sie wählten eine Produktentwicklung als Pilotprojekt, die Mitarbeiter wurden bestens über die Komplexität der Methode geschult. Sie hatten einen externen Coach der Product Owner und Scrum Master unterstützte, aber inzwischen sind alle Aufgaben an die internen Mitarbeiter erfolgreich übergeben worden. Alle Vorurteile sind abgelegt und die Vorteile der agilen Methode sind besonders an der Produktivität des Teams spürbar. Die ersten Erfolge sind durch die bereits ausgelieferten Sprintergebnisse und der verbesserten Team Velocity messbar.

 

Erfolg und Misserfolg

Der Product Owner und das Team sind hoch motiviert, die letzten Sprints waren erfolgreich. Der Fortschritt wurde anhand der funktionierenden und ausgelieferten Software gemessen. Auch wenn es niemand zugibt, aber das erste Scrum Projekt ist immer etwas Besonderes. Der Erfolg oder Misserfolg dient als Entscheidungsgrundlage für die Fortsetzung der agilen Vorgehensweise. Motivation, das Gefühl etwas zu erreichen und der Druck von außen – ein Scrum Team nutzt diese Faktoren um zu beweisen wie sehr eine agile Methode die Produktivität steigert. Und tut sie dies, bringt der Product Owner weitere User Stories ein und das Team sieht keinen Grund diese nicht zu schaffen. Doch nach ein paar Sprints nimmt die Velocity ein wenig ab. Die Entwickler brauchen mehr Zeit um Erweiterungen zu implementieren, der Test findet immer mehr Fehler während der Sprints und so manche User Story wird nicht mehr erfolgreich abgeschlossen. Diese „Verlangsamung“ findet schleichend statt und fällt zuerst nicht wirklich auf. Dass eine User Story nicht fertig wurde, passierte in der Vergangenheit zwar selten, aber niemand sieht Grund zur Sorge, denn leichte Schwankungen der Velocity sind nicht unüblich.

 

Optimierung Scrum durch agile Praktiken

Ursachenforschung

Mit zunehmender Größe des Source-Codes erhöht sich der Aufwand um Qualitätsbereinigungen durchzuführen. Dieses Phänomen wird auch technische Schuld genannt. Ein gutes Scrum Team erkennt diesen Missstand und diskutiert die Situation in der Retrospektive. Wichtig ist, dass in diesem Moment nicht gleich Lösungen gesucht werden, um schneller zu werden (wie z.B. „Wo können wir einsparen?“), sondern nach den Ursachen.

Warum steigt der benötigte Aufwand der Entwicklung kontinuierlich? Antworten auf diese Frage sind mannigfaltig:

  • Die Code Basis ist gewachsen und wurde komplexer.
  • Durch die hohe Produktivität liegt der Fokus auf der Entwicklung neuer Features und dadurch wurde der Aspekt der Wartbarkeit der Software ignoriert.
  • Je mehr Code das Team entwickelt desto länger benötigt es den Code zu verstehen um ihn zu erweitern.

Liegt es nur an der Größe oder ist der Code unlesbar? Bis jetzt hat sich das Team nicht mit der Verständlichkeit und Clean Code beschäftigt, denn im Sog der Neuentwicklung wurde dieser Aspekt ignoriert. Also benötigt der Code ein Service bzw. ein Re-factoring um die bisher vernachlässigten Qualitätsaspekte mehr in den Mittelpunkt zu stellen. Wie viele Unit Tests haben wir um dieses Re-factoring durchzuführen? Auch hier wurde bisher gespart, die Unit Test Coverage ist sehr gering.

 

Maßnahmen

Welche Maßnahmen helfen dem Team in einer solchen Situation am meisten? Man muss das Rad nicht neu erfinden, eine gute Quelle sind agilen Praktiken und Arbeitstechniken. Allen voran sind für mich der Automatisierungsgrad von Tests und des Deployments die wichtigsten Aspekte (= Unit Testing, Test-Driven Development und Continuous Integration). Um die Qualität ausreichend zu sichern braucht das Team schnelles und zielgerichtetes Feedback. Weitere agile Praktiken um die Qualität der Softwareentwicklung zu verbessern, finden sich in der agilen Methode „Extreme Programming“.

 

XP Pratices

 

 Automatisierte Tests

Der erste Schritt zur Testautomatisierung beginnt mit der Implementierung von Unit Tests. Das Aufschreiben dieses Ziels ist sehr wichtig. Damit die Entwicklung von Unit Tests zu einem verbindlichen Kriterium wird, beschließt unser Scrum Team als erste Maßnahme die Implementierung von Unit Tests in die Definition of Done aufzunehmen. Somit kann ein Feature erst dann für fertig erklärt werden, wenn der Unit Test implementiert wurde. Eine zusätzliche Vereinbarung könnte lauten, das zuerst der Unit Test geschrieben werden muss, und erst dann der funktionale Code.

Das Implementieren alleine reicht noch nicht aus. Zusätzlich müssen automatisierte Tests regelmäßig ausgeführt werden. Das Team definiert als Regel, dass alle Unit Tests vor jedem Commit durchgeführt werden müssen und keine Fehler auftreten dürfen. Diese Regel muss auch im automatischen Build und im Continous Integration (CI) Server unterstützt werden. Die Ergebnisse sollten unbedingt gemessen und überwacht werden. Der CI Server Jenkins stellt dazu verschiedene Plug-Ins zur Verfügung. Dabei bewährt sich eine agile Vorgehensweise und keine Überforderung durch unnötige Statistiken: einfache Metriken zuerst und ein hohes Maß an Transparenz!

 

Metriken

Als einfache Metriken empfehle ich am Anfang die Anzahl der erfolgreichen und der fehlerhaften Tests. Falls die Tests zu oft scheitern, sollte das Verhältnis und die Anzahl der Tage, an denen Fehler bzw. keine Fehler auftraten überwacht werden. Im Fehlerfall muss das Team bzw. der Entwickler, welcher die Änderung frei gab, per E-Mail informiert werden. Ein scheiternder Unit Test ist genau so gravierend wie ein Code, der nicht kompiliert. Wenn der Build bricht und rot ist, bedeutet das eine sofortige Korrektur des Fehlers.

 

Jenkins JUnit Plugin

Jenkins JUnit Plugin

 

Das Ziel ist jetzt messbar und kann automatisch überprüft werden. Durch den CI Server ist die Erfassung der Daten und das Reporting effizient gelöst. Der CI Server schafft Transparenz für das ganze Team. Um den Effekt zu verstärken installiert man einen Monitor, der von allen Team-Mitgliedern beobachtet werden kann.

 

Code Coverage

Eine verlässlichere und detailliertere Metrik als die Anzahl der Tests ist die Code Coverage. Die Code Coverage beschreibt wie viel Code durch automatisierte Tests abgedeckt wird bzw. welcher Code noch nicht getestet wird. Reife Teams mit erfahrenen Entwicklern erreichen eine Code Coverage von 80%. Allerdings sagen beide Metriken nichts über die Qualität der entwickelten Tests aus. Es besteht die Gefahr des Missbrauchs, besonders dann, wenn die vorgegebenen Ziele unrealistisch sind (How to Misuse Code Coverage).

 

Zieldefinitionen

Die Größe von Zielen muss sehr sorgfältig gewählt werden und sollte im Laufe des Projekts adaptiert werden. Eine mögliche Größe ist z.B. 1.000 zusätzliche Unit Tests im nächsten Monat. Die Gefahr ist allerdings Missbrauch in Form von nutzlosen oder sogar sinnlosen Tests und anderseits, dass die Ziele nur deswegen erreicht werden, weil es jemand fordert. In einem Scrum Team ist meine Erfahrung, dass diese Ziele vom Team gemeinsam definiert werden und nicht von außen gefordert werden dürfen. Dadurch ist die Identifikation, Motivation und Akzeptanz der Ziele gegeben. Von außen sollen zusätzliche Anreize geschaffen werden z.B. als Belohnung ein Abendessen für ein erfolgreiches Team.

 

Conclusio

Gerade am Anfang neigen Scrum Teams dazu, die erreichte Produktivität zu genießen und andere Aspekte in der Softwareentwicklung zu ignorieren. Sehr häufig scheitern Projekte mit Scrum, weil die technische Schuld schnell aufgebaut wird und die Wartbarkeit der Software zunehmend leidet. Scrum definiert keine Vorgaben in Bezug auf die agilen Praktiken, denken sie von Anfang an daran oder spätestens, wenn sie die Zeichen von schlechter Qualität mit ihrem Team in den Retrospektiven erkennen.

Investieren Sie in Scrum Master, die diese Situation mit ihrer Erfahrung bewältigen können oder suchen sie sich externe Hilfe zur Analyse. Die wichtigsten Praktiken unterstützen das Team um ständig Feedback über die Qualität und den Entwicklungsstand zu erlangen. Die Unit Test Metriken und ihre Reports unterstützen ihre Mitarbeiter! Was könnten sie übersehen haben? Welche blinden Flecken existieren auf der Unit Test Landkarte? Die Entscheidung über die Relevanz und die Verantwortung darüber wie und ob die Code Coverage erhöht werden kann, liegt in den Händen der Entwickler. Mit Hilfe von Metriken kann das Team Entscheidungen treffen und den Erfolg messen. Ich bin überzeugt, dass diese Metriken eine wichtige Ergänzung sind.

 

Bleiben sie dabei auf der bimodalen Reise und lesen sie nächste Woche über die Auswirkungen der Agilität an den Schnittstellen des Entwicklungsteams im 3. Teil der Blogreihe.

 

 

Blogreihe „Die Reise zur bimodalen IT“:

Passende Artikel

Kommentare gesperrt.