Zero Bug-Policy (II)
 |
| Bild: Pexels / Picas Joe - Lizenz |
Zu den am häufigsten missverstandenen (und aus diesem Grund immer wieder kontrovers diskutierten) Begriffen der Software-Entwicklung gehört die Zero Bug Policy, sinngemäss übersetzt die Regel keine Fehler in der Software mehr zu haben. Da die sich daraus ergebenden Debatten intensiv und zeitfressend sein können lohnt es sich, einen näheren Blick darauf zu werfen - um was geht es hier eigentlich und wo findet das Missverständnis statt?
Um mit dem Letzten zu beginnen: das Missverständnis besteht darin, dass oft angenommen wird, eine Zero Bug-Policy hätte zum Inhalt, dass keine Bugs mehr entstehen dürften. Dass das zwar wünschenswert aber nicht umsetzbar ist dürfte jedem klar sein, der sich schon einmal mit Softwareentwicklung beschäftigt hat. Die Komplexität und Vernetztheit von Anforderungen und Systemen ist zu gross um Fehler auszuschliessen, auch bei grösster Mühe.
Was tatsächlich hinter dem Begriff steckt ist die Regel, entdeckte Bugs schnellstmöglich zu beheben und das nicht auf einen späteren Zeitpunkt zu verschieben. Man kann sich Zero Bugs in diesem Kontext als die Kurzform von "Zero Bugs left behind" vorstellen, das macht den Begriff plastischer. Und schnellstmöglich bedeutet (vereinfacht gesagt), dass man zwar natürlich erst die laufenden Arbeitspakete abschliessen kann, aber keine neuen bearbeitet so lange noch Bugs gefixt werden können.
Mit dieser Erklärung erscheint die Reglung zwar nicht mehr undurchführbar, kontrovers bleibt sie aber. Ein häufiger Einwand ist z.B., dass es nicht vermittelbar ist, neue Features (mit denen Geld verdient und Kunden gewonnen werden können) aufzuschieben, nur um kleinere Bugs zu beheben, von denen nur wenige Anwender betroffen sind, die nur selten auftreten oder für die es einen Workaround gibt. Und isoliert betrachtet stimmt das sogar.
In der Realität treten derartige Bugs allerdings meistens nicht mit einer derartigen, von Beginn an klar erkennbaren nachrangigen Wichtigkeit auf. Zu Beginn ist fast immer eine Analyse nötig, die dann auch bereits den Grossteil des nötigen Aufwandes ausmacht. Die eigentliche Behebung kann im Anschluss daran eher schnell stattfinden, was ausserdem den Nebeneffekt mit sich bringt, dass die Analyse nicht mehr dokumentiert werden muss um zum Behebungszeitpunkt präsent zu sein.
Selbst im Fall einer von Beginn an klar erkennbar nachrangigen Wichtigkeit gibt es aber ein Argument gegen das Aufschieben. Bereits nach erstaunlich kurzer Zeit führt dieses Vorgehen nämlich zum Entstehen von Bug-Backlogs, die die Tendenz haben aus sich heraus ständig Bürokratie zu erzeugen: sind diese Tickes noch relevant? Sind sie noch aktuell? Sind sie richtig priorisiert? Sind sie bereits redundant? Alleine das zu überprüfen und zu dokumentieren kann einen irrsinnigen Verwaltungsaufwand bedeuten.
Die wirtschaftlichste Art damit umzugehen ist tatsächlich die No Bug Policy. Alle auftretenden Fehler müssen behoben werden, und zwar so bald wie möglich. Im Einzelfall könnte man zwar fast immer argumentieren, dass gerade dieses spezielle Ticket in Relation zu anderen unwichtig ist, im Durchschnitt spart die sofortige Behebung aber Zeit, Aufwand und Nerven. Und jedem der das nicht sofort einsehen will kann man gerne die Verantwortung für Analyse, Dokumentation, Aktualisierung, Priorisierung und Triage von Bugs übertragen.1 Schnelle Lerneffekte sind dann garantiert.
