Es ist ein bekannter Stil, den viele Softwareentwicklungsteams an den Tag legen: Die Zero-Bug Policy. Ziel dieser Philosophie ist es, ein komplett bug-freies Produkt zu haben. Dabei werden Bugs oft prioritär behandelt und landen in agilen Entwicklungsmethodiken wie Scrum gerne einmal im bereits laufenden Sprint. Der Anspruch, bug-freie Software zu betreiben ist damit erfüllt, doch das ein oder andere Mal leidet darunter der erreichte Fortschritt im Sprint.
Wie kann man mit diesen Problemen umgehen?
Hierzu sollte man einmal in die Definition des "Bugs" eintauchen. Wikipedia definiert einen Bug als "Softwarefehler […], mit denen für Software-Systemkomponenten Abweichungen zu einem geforderten oder gewünschten Sollzustand bezeichnet werden." In dieser Definition befindet sich viel Auslegungsspielraum, denn wer fordert oder wünscht sich den Sollzustand? Der Endnutzer? Das Entwicklungsteam? Der Product Owner? Oder andere Stakeholder?
Aus dem täglichen Umgang mit der Hereingabe von "vermeintlichen" Bugs hat sich bei uns eine Klassifizierung ergeben, welche eine Hilfestellung in der Priorisierung darstellt. Tatsächliche Fehler (z.B. verfälschte Ergebnisse oder Bruch der Prozesskette) Dinge, die besser umgesetzt sein könnten (z.B. etwas ist nicht so intuitiv gelöst) Für die tatsächlichen Fehler gilt die Zero-Bug Policy. Das heißt Fehler werden zeitnah bearbeitet und dabei anderen Sprintinhalten überpriorisiert. Die zweite Kategorie wiederum durchläuft den normalen Prozess über das Backlog Refinement bis zur Sprintplanung. Die Tickets werden dabei in andere Inhalte, wie bspw. Neue Features, mit hereinpriorisiert.
Diese Klassifizierung hat uns im Team stark geholfen, den Fokus im Sprint zu wahren. Denn wenn man Software betreibt, die von vielen Nutzern genutzt wird, dann ist es ein Fluch und Segen zugleich: Je mehr Menschen die Software benutzen, desto mehr Fehler kommen auf. Und so verfolgen wir unsere ganz eigene Zero-Bug Policy.