Vor inzwischen mehr als 5 Jahren bin ich über ein Buch gestolpert, das ich inzwischen wieder vergessen hatte. Nach langer Zeit habe ich mal wieder meine leanpub Bibliothek durchstöbert. Und hier war es: https://leanpub.com/fixitnowordeleteit
Vereinfacht beschreibt diese kurze Buch die Idee, Bugs entweder sofort zu löschen, oder sie zu löschen.
In der Realität sieht es meistens anders aus. Hier stehen Features und Bugs in einem ständigen Konflikt. Es gibt Stakeholder, die gerne Fortschritte sehen möchten, es gibt Anwender, die mit Problemen und Bugs zu kämpfen haben und dann gibt es das Entwicklungsteam, dass sozusagen zwischen beiden Stühlen steht.
Das Problem mit dem Priorisieren
Viele Teams beginnen dann damit, die „Bugs“ zu priorisieren. Ist dieser Bug ein „Blocker“, „Critical“, „Major“, „Minor“, „Trivial“, …
Stundenlange Diskussionen und Abstimmungen folgen, um zu definieren, wie zu entscheiden ist, wann welche Prio zu vergeben ist und im ungünstigsten Fall steigt die Zahl der „Blocker“ Bugs, weil jeder, der einen Bug erstellt, der Meinung ist, dieser spezielle Bug müsse besonders dringend gelöst werden.
Besonders perfide wird es, meiner Meinung nach, wenn festgelegt wird, in welchem Zeitraum ein Bug zu lösen ist. Beispielsweise ist ein „Blocker“ innerhalb von 4h zu lösen, ein „Minor“ innerhalb von 14 Tagen und ein Trivial hat kein Zeitlimit.
Die Wahrscheinlichkeit ist dann sehr hoch, dass ein Bug, der nicht „Blocker“ ist, im Backlog nach und nach immer weiter nach unten wandert und dabei heimlich, still und leise vor sich hin gammelt. Monate später ist das Backlog so groß geworden, dass ein „Backlog-Grooming“ fällig wird und sich keiner mehr erinnert, worum es eigentlich genau ging und keiner weiß, ob der Bug überhaupt noch relevant ist.
Fix it (NOW!)
Viel einfacher ist es, wenn wir direkt beim ersten Auftreten des Bugs klären, ob wir den Bug überhaupt beheben müssen. Diese Entscheidung ist viel leichter zu treffen (ja/nein) als zu kategorisieren.
Nach der Entscheidung sollte dann die sofortige Umsetzung kommen. Sonst laufen wir wieder Gefahr, dass der Bug im Backlog nach unten wandert und aus dem Fokus gerät.
„Aber es sind zu viele Bugs, wir müssen prorisieren“
Auch diese Begründung habe ich selbst erlebt. Hier ist es schnell passiert, dass man dem Team den vorwirft, sie würden schlampig programmieren oder noch schlimmer, inkompetent sein.
Meine Erfahrung ist, dass häufig das ominöse „Management“ die falschen Signale setzt (Features vor Bugfixing) oder gar mit Druck auf „Fehler“ reagiert. Ich habe in einem anderen Blogpost über die Aussage berichtet „Bisher wurde Code-Qualität nicht wertgeschätzt“. Es liegt also an uns Führungskräften, dafür zu sorgen, dass unser Team die richtigen Werte kennt und diese auch leben kann.
Zurück zum Thema. Es gibt verschiedene Möglichkeiten, das Problem der vielen Bugs anzugehen.
Feature-Freeze (z.B: 4 Wochen) und reiner Fokus auf „Bugfixing“.
Diese Methode adressiert die Problematik der „vielen Bugs“ vor allem in Richtung Management.
Vorteile:
- Viele Bugs können in kurzer Zeit behoben werden
- Die Dringlichkeit des Bugfixing wird sichtbar
- Das Team bekommt auch wirklich den Freiraum, die Probleme anzugehen und zu lösen
Nachteile:
- Es entsteht der (vielleicht berechtigte) Eindruck (vor allem beim Management), dass die Qualität der Software so schlecht ist, dass ein Freeze der einzige Ausweg ist
- Nach dem Feature-Freeze ist vor dem Feature-Freeze. Kaum ist der eine Freeze vorbei, stauen sich die nächsten Bugs auf und der nächste Freeze muss geplant werden.
Fix One Bug a Day
Das Team entscheidet sich jeden Tag (alternativ auch ein längerer Zeitraum) für einen Bug aus der langen Liste und behebt (nur) diesen.
Vorteile:
- Die Stakeholder haben nicht das Gefühl, dass es nicht voran geht, da die Features weiterhin entwickelt werden
Nachteile:
- Die offenen Bugs werden nur sehr langsam weniger
- Es besteht die Möglichkeit, dass die Liste größer wird, weil mehr Bugs gemeldet, als behoben werden.
Backlog-Grooming (mit Fokus auf Bugs)
Gerade, wenn es viele Bugs im Backlog gibt, ist die Wahrscheinlichkeit hoch, dass einige davon nicht mehr relevant sind.
Vorteile:
- Das Backlog wird um die obsoleten Themen bereinigt und damit kürzer
- Die relevanten Bugs werden (wieder) sichtbarer
Nachteile:
- Backlog-Grooming ist zeitaufwändig, anstrengend und oft frustrierend
Bug-Retro
Im Scrum-Umfeld ist es üblich, regelmäßig Retros zu veranstalten, um zu diskutieren, was gut gelaufen ist und was nicht, und um einzelne Maßnahmen zu vereinbaren, die zur Verbesserung beitragen können.
Insbesondere wenn es viele Bugs gibt, kann eine auf dieses Thema spezialisierte Bug-Retro hilfreich sein, um herauszufinden, welche Kategorien von Bugs es gibt und was getan werden kann, um das Auftreten von Bugs zu reduzieren.
Wenn z.B. festgestellt wird, dass ein großer Teil der Bugs „Nullpointer-Exceptions“ sind, kann eine Maßnahme darin bestehen, einen Workshop zum Thema Nullpointer zu organisieren, um bewährte Verfahren zur Vermeidung von Nullpointer-Exceptions zu vermitteln.
Fazit
Zero-Bugs ist eine „Policy“, die ich als Führungskraft immer wieder kommunizieren muss. Gleichzeitig muss ich dem Team den Freiraum dafür geben und es ggf. auch gegen höhere Ebenen schützen.
Zero-Bugs verbessert nicht die Qualität meiner Software. Zero-Bugs funktioniert nur, wenn die Software-Qualität bereits hoch ist und das Team nicht von der „Bug“-Welle überrollt wird.