"Don’t fix bugs later; fix them now." - Steve Maguire

Vorwort

Keine Software ist perfekt oder fehlerfrei. Das Auftreten von Bugs ist einfach ein Teil des Prozesses der Entwicklung neuer Software, der nicht vollständig eliminiert werden kann. Gute (Unit-, Integrations-, etc.) Tests und Softwareentwicklungstechniken wie Test-Driven-Development (TDD) können zwar dabei helfen, die Anzahl der auftretenden Bugs insgesamt zu reduzieren, aber wir können uns quasi nie sicher sein, dass unser Code fehlerfrei ist.
Was wir jedoch kontrollieren können, ist die Art und Weise, wie wir mit Bugs umgehen. Dadurch lässt sich die Entwicklungsgeschwindigkeit erhöhen und die Menge an Wartungsarbeiten reduzieren, die im Laufe der Zeit unweigerlich steigt. Genau darum geht es bei der Zero-Bug-Policy.

‍

Schlüsselerkenntnisse

• Es gibt praktisch keine fehlerfreie Software
• Gute Tests und Techniken können helfen, die Anzahl der (kritischen) Bugs zu reduzieren
• Die Zero-Bug-Policy hilft uns, mit Bugs besser umzugehen

Was gilt eigentlich als Bug?

Bevor wir uns kopfüber in das Thema stürzen, ist es wichtig, ein gemeinsames Verständnis für die Terminologie zu haben. Die Frage, was eigentlich ein Bug ist, kann in jedem Entwicklerteam etwas anders behandelt werden, daher hier unsere Definition:

"Ein Bug liegt vor, wenn ein Stück Funktionalität nicht die Aufgabe erfüllt, für die es entwickelt wurde.”

Schön und gut, aber wem immer noch nicht ganz klar ist, was eigentlich als Bug gilt, haben wir hier ist eine Liste von Dingen, dir wir als Bug einstufen deklariert:

🐞 Abweichung zwischen Anforderung und der eigentlichen Implementierung

🐞 UI-Probleme

🐞 UI Jank (Stottern bei der Anzeige)

🐞 Plötzliches (unerwartetes) Abfallen der Performance einer Applikation

🐞 Plötzliches (unerwartetes) Ansteigen des Speicherbedarfs

Es sei auch erwähnt, dass wir intern auch die folgenden Probleme als Bug einstufen:

🐞 Nicht-funktionierende Tests

🐞 Instabile Tests

🐞 Nicht-funktionierende CI/CD Pipeline

🐞 Nicht-funktionierende Tools

Um ein paar Beispiele dafür zu geben, was für uns nicht als Bug zählt: Fehlende Randfälle (edge cases), die nicht Teil einer User Story sind, gehören zum Beispiel nicht dazu. Ein weiteres Beispiel sind fehlende Fehlermeldungen, z.B. wenn es keine Internetverbindung gibt oder eine API-Anfrage fehlschlägt. Deshalb sollten User Stories nicht nur den "guten Pfad" enthalten, sondern auch den "schlechten Pfad", der Benutzerfehler und anderes Fehlverhalten behandelt. Für diese Art von fehlendem Verhalten muss ein neuer Feature Request erstellt werden.

Außerdem können Bug-Tickets bei uns nur von internen Teammitgliedern (Dev-Team, Product Owner, Designer, etc.) erstellt werden. Potenzielle Bugs, die extern gemeldet wurden, wie z.B. Kundenfeedback, müssen erst validiert werden.

Wie sieht der typische Bug-Lebenszyklus aus?

Wenn Du bereits mit den Standardprozessen in Softwareentwicklungsprojekten vertraut bist, die man häufig in der Unternehmenswelt findet, oder selbst an einem Softwareprojekt teilgenommen hast, hast Du vielleicht schon den folgenden Lebenszyklus eines Bugs gesehen:

Wann immer ein Bug entdeckt wird, wird ein neues Problem in einer Issue-Tracking Software wie Jira, Asana usw. erstellt und als Bug markiert. Hier beginnt die Reise.

Die meisten modernen Teams arbeiten mit Frameworks wie Scrum oder Kanban und haben einen Produktmanager (PM) oder Product Owner (PO), der für die Priorisierung von neuen Funktionen und Bug-Fixes verantwortlich ist. Dies geschieht in der Regel in Zusammenarbeit mit dem Entwicklungsteam, das zunächst den Aufwand für die Fehlerbehebung oder Implementierung abschätzen wird. (Es muss an dieser Stelle erwähnt werden, dass nicht alle Scrum-Teams die Praxis der Bug-Abschätzung einsetzen).

Wenn man in Sprints arbeitet, wie typischerweise im Scrum Framework, wird der PO entscheiden, welche Aufgaben für den nächsten Sprint Priorität haben und welche nicht.

Von hier an gibt es grundsätzlich zwei Möglichkeiten, was mit dem Bug passiert. Entweder wird er als wichtig genug erachtet, um für den nächsten Sprint berücksichtigt zu werden und wird schließlich behoben, oder er wird als nicht wichtig erachtet und bleibt bis zum nächsten Sprint im Backlog. Dieser Prozess wiederholt sich im Grunde in jedem Sprint und unter Umständen bleibt der Bug auf unbestimmte Zeit im Backlog und wird nie behoben.

Schlüsselerkenntnisse

• Von der Entdeckung bis zur tatsächlichen Behebung von Fehlern kann es ein langer Weg sein.
• Wenn man Bugs die gleiche Priorität einräumt wie Features, dann werden sie möglicherweise nie als wichtig genug erachtet, um behoben zu werden.

Welche Probleme treten beim klassischen Ansatz auf?

Wenn Features und Bugs vom PM/POs gleichbehandelt werden – d.h. sie werden nach Priorität gestaffelt – dann wird die Behebung von Bugs vom Management oft als weniger wichtig angesehen, als das Entwickeln neuer Features. Dies führt zu einer Reihe von Problemen, mit denen so gut wie jeder Entwickler in der Vergangenheit schon einmal konfrontiert war.

Wertvolle Zeit wird mit der Priorisierung und Abschätzung von Bugs verschwendet

Es wird bereits viel Zeit in den Bugs investiert, bevor jemand an seiner Behebung arbeitet.

Der offensichtlichste Grund dafür sind die Bugs, die in den Augen des Product Owners eine sehr niedrige Priorität haben und auf unbestimmte Zeit im Backlog verbleiben. Der Bug verursacht also jedes Mal, wenn das Backlog sortiert wird, einen Overhead und Wartungsaufwand.

Außerdem - unabhängig von seiner Priorität wird er das Entwicklungsteam immer Zeit kosten, wenn es den Aufwand für seine Behebung abschätzt.

Kurz gesagt: Jedes Mal, wenn man einen Bug priorisiert oder abschätzt, vergeudet man Zeit.

Der Umgang mit sehr alten Bugs kann mühsam sein

Dieses Problem dürfte den meisten erfahrenen Entwickler wohl bekannt sein.

Wenn man sich mit alten Bugs befasst, kann es sehr schwer sein, sich daran zu erinnern, wo sich der zugehörige Code in der Codebase befindet. Taucht hingegen ein neuer Bug auf, wissen die Entwickler oft intuitiv, wie er zu beheben ist, da sie den Code erst kürzlich geschrieben haben. Dieser Vorteil geht bei alten Bugs völlig verloren.

In manchen Fällen kann es sogar passieren, dass der Bug schlecht dokumentiert wurde und man sich nicht mehr daran erinnern kann, worum es eigentlich ging.

Ein weiterer ärgerlicher Punkt ist, dass alte Bugs nicht immer reproduzierbar sind. Das Entwicklungsteam verbringt viel Zeit mit dem Versuch, das fehlerhafte Verhalten zu reproduzieren, nur um irgendwann festzustellen, dass das Problem nicht mehr existiert und bereits „aus Versehen“ behoben wurde.

Wenn neue Teammitglieder zum Entwicklungsteam stoßen, müssen sie sich zunächst mit dem Code vertraut machen, bevor sie an neuen Funktionen arbeiten können. Wenn die Codebase recht groß ist, müssen sie vielleicht nie einen Teil des alten Codes anfassen (oder gar lesen) – was gut ist, weil es Zeit spart. Den eigenen Code zu verstehen, den man vor langer Zeit geschrieben hat, kann schon zeitaufwendig sein, aber den Code eines anderen zu reparieren, ist noch anspruchsvoller. Idealerweise müssen sich neue Entwickler also nie mit alten Problemen befassen, sondern können sich auf die Entwicklung neuer Funktionen konzentrieren.

Und als ob das nicht schon schlimm genug wäre, kann es noch schwieriger sein, den Bug zu beheben, nachdem die Codebasis viele Änderungen erfahren hat. Das sollte natürlich nicht passieren, kommt aber dennoch recht häufig vor. Ein Grund dafür ist, dass die zugrundeliegende Software-Architektur nicht richtig aufgebaut wurde (siehe Clean Architecture, Design Patterns, SOLID, etc.), aber viele neue Funktionen darauf aufgebaut wurden. Von Zeit zu Zeit können solche Fehler passieren, aber die Behebung des Bugs erweist sich jetzt als schwieriger, da viel mehr Code umhergeschoben werden muss. Im schlimmsten Fall wurden nicht einmal genügend Tests für die neuen Funktionen geschrieben, so dass man nicht einmal sicher sein kann, dass durch die Behebung des Bugs keine neuen entstanden sind.

Was mir in der Vergangenheit einmal passiert ist, war, dass viele unerfahrene Flutter-Entwickler an einem neuen Projekt arbeiteten und das so genannte BLoC-Pattern auf eine völlig falsche Weise anwandten. Dieser Code hätte es niemals durch den Code-Review schaffen dürfen, tat es aber trotzdem. Kurz darauf entdeckte einer der QA-Mitarbeiter einen Bug, der durch diesen Code verursacht wurde, aber das Management gab dem Bug eine niedrige Priorität, so dass er nicht sofort behoben wurde. Einige Wochen später, nachdem andere Funktionen, die auch mit dieser Codestelle interagierten, gebaut wurden, schaffte es das Bug-Ticket endlich in den nächsten Sprint. Als ich versuchte, den Bug zu beheben, stellte ich nicht nur fest, dass der zugrundeliegende Code schlecht geschrieben war, so dass ich ihn nicht nur neu schreiben musste, sondern das Beheben führte auch noch zu einem neuen kleinem Bug. Natürlich hätten die meisten dieser Probleme durch ordentliche Code-Reviews und bessere Tests beseitigt werden können. Doch wenn alles schiefläuft, führt die sofortige Behebung von Fehlern definitiv zu besseren Ergebnissen.

Bugs häufen sich an, was zu zahlreichen Problemen führt

Wenn man die Praxis befolgt, Bugs zu de-priorisieren, wird man früher oder später mit einem Backlog, das voll mit Bugs ist, enden. Wenn neue Funktionalität Vorrang vor der Behebung von Fehlern hat und jede neue Funktion im Durchschnitt > 1 neue Bugs mit sich bringt, aber das Team pro Sprint weniger Bugs fixed, als es Features entwickelt, so wird die Zahl der offenen Bugs mit der Zeit unweigerlich ansteigen. Bugs mit niedriger Priorität werden damit praktisch nie behoben, und bald hat man einen großen Haufen von Bugs. Das wiederum führt logischerweise zu einer Menge anderer Probleme.

Problematische Abhängigkeiten zwischen Teams

Wenn man Software entwickelt, die nicht nur von einem selbst, sondern auch von anderen Entwicklerteams benutzt werden (z.B. eine Bibliothek oder eine API), kann ein großer Haufen von Bugs zu Chaos und Frustration auf beiden Seiten führen.

In einem früheren Projekt hatten wir eine Abhängigkeit zu der Codebasis eines anderen unabhängigen Teams, an der sie aktiv arbeiteten. Sie brachten alle 3 Wochen eine neue Version heraus (Scrum-Inkrement) und wenn es keine "breaking-changes" gab, aktualisierten wir regelmäßig die Version des Moduls auf unserer Seite. Normalerweise lagen wir 1-2 Versionen hinter der neuesten Version zurück, was in Ordnung war. Das einzige Problem war, dass das Modul mit Bugs gespickt war, die das Management als „niedrige Priorität“ einstufte, die aber auf unserer Seite „hohe Priorität“ waren, weil sie uns behinderten. Dies führte zu einer Menge Frustration, Druck und Schuldzuweisungen auf beiden Seiten und hätte leicht vermieden werden können, wenn alle Bugs rechtzeitig behoben worden wären.

Verfälschte Feature-Velocity

Eine weitere häufige Folge ist die Tatsache, dass die Feature-Velocity über verschiedene Zeiträume hinweg stark schwankt. Langfristig kann sie sogar abnehmen, wenn man die anderen genannten Probleme berücksichtigt. Die Feature-Velocity ist die Geschwindigkeit, mit der das technische Team in der Lage ist, der Software neue Features hinzuzufügen. Diese Metrik ist an sich schon sehr schwer zu messen, aber wenn man mit Story Points arbeitet, gibt es einige gute Techniken, um eine grobe Schätzung zu erhalten. Je besser der Näherungswert ist, desto besser kann das Management die Zukunft vorhersagen und desto besser kann das Team messen, ob es hinter oder vor dem Zeitplan liegt.

Um ein Beispiel aus der Arbeit mit dem Scrum-Prozess zu geben: Ein Grund, warum die Feature-Velocity bei der Depriorisierung von Bugs an Glaubwürdigkeit verliert, ist, dass jeder Sprint oft eine völlig andere Anzahl von Bugs umfasst, die in ihm behoben werden müssen. Am Anfang mag die Relevanz von Bugs gering sein, aber später kann sie plötzlich zur obersten Priorität werden.

Nehmen wir an, dass die Frist für den App Launch näher rückt und der Schwerpunkt der nächsten Sprints plötzlich auf der Behebung von Bugs liegt. Die Feature-Velocity für diesen Zeitraum wird sehr niedrig sein und ist schwieriger einzuschätzen. Wenn das Management vorher mit der Feature-Velocity gearbeitet hat und davon überrascht wurde, wie viele Bugs vor dem App Launch noch behoben werden müssen, dann liegt das Projekt jetzt weit hinter dem Zeitplan zurück. Features, von denen man annahm, dass sie Teil des App Launches sein würden, müssen nun fallengelassen werden. Die Metrik war einfach falsch, weil die Behebung von Bugs während der Arbeit an der Funktionalität fast nie ein Teil davon war, bis sie plötzlich wichtig genug wurde.

Nehmen wir außerdem an, dass das Entwicklungsteam die (schlechte) Praxis der Bug-Abschätzung anwendet und dass viele der Bugs schon vor langer Zeit abgeschätzt wurden. Wie wir bereits gesehen haben, sind alte Bugs oft schwieriger zu beheben und die Schätzungen aus der Vergangenheit sind jetzt wahrscheinlich völlig unbrauchbar. Es kann also sein, dass nicht einmal alle Bugs bis zum Launch behoben werden, und im Grunde verliert das Management die Kontrolle.

Ein weiterer negativer Nebeneffekt dieser auf Bug-Beseitigung ausgerichteten Sprints ist, dass Stakeholder, die nicht zum Scrum-Team gehören, beim Sprint-Review enttäuscht sein werden, wenn sie feststellen, dass fast keine sichtbaren Fortschritte erzielt wurden (außer der Behebung von Bugs).

Schlechte Teammoral

Das größte Problem ist meiner Meinung nach jedoch die negative Auswirkung, die all dies auf die Stimmung des gesamten Teams hat. Ganz gleich, wie gut die Teammitglieder ihre Arbeit machen, am Ende des Tages kann ein wirklich hervorragendes Produkt nur dann entstehen, wenn jeder Spaß daran hat und zufrieden mit der Arbeit ist.

Wenn sich die Bugs häufen, sind das Management und die Stakeholder unzufrieden und stellen möglicherweise die Fähigkeit des Teams in Frage, gute Software zu liefern, weil scheinbar „die Sachen einfach nie funktionieren“. Bereits das kann eine Menge Druck auf alle Beteiligten erzeugen.

Natürlich möchte jeder im Team die bestmögliche Softwarequalität produzieren. Zum einen können Entwickler sehr frustriert sein, wenn ihre Software von minderer Qualität ist, sie aber „keine Zeit“ haben, fehlerhaften Code zu korrigieren. Dies kann sehr leicht in ein Gefühl der Überforderung umschlagen, weil man ständig an neuen Funktionen arbeiten muss, während man nicht in der Lage ist, alte Funktionen zu reparieren (oder richtig fertigzustellen). Außerdem macht es ja viel mehr Spaß, tolle neue Funktionen zu entwickeln, als wochenlang einen Bug nach dem anderen zu beheben. Softwareentwicklung ist wie der Bau eines Wolkenkratzers. Man will sich hocharbeiten und über das Ergebnis staunen, anstatt immer wieder am Boden festzustecken und das Fundament reparieren zu müssen.

Designer sind frustriert oder fühlen sich sogar herabgesetzt, wenn der Product Owner UI-Fehler als weniger wichtig einstuft.

Und wenn ein QA-Team involviert ist, wird ihre Arbeit noch schwieriger, wenn sie den Überblick über eine lange Liste von Bugs behalten müssen. Auch das habe ich schon erlebt, und es ist unnötig zu sagen, dass ihre Stimmung verständlicherweise sehr schlecht war und auf das ganze Team überschlug.

Logischerweise sind auch die Endbenutzer über ein Produkt verärgert, das mit Bugs gespickt ist. Das führt zu einer Menge negativer Rückmeldungen, die sich wiederum auch auf die Moral des Teams auswirken.

Natürlich wirken sich alle in den obigen Abschnitten beschriebenen Probleme auch negativ auf die Motivation des Teams aus. Zum Beispiel …

• Probleme mit teamübergreifenden Abhängigkeiten können Frustration aufbauen oder sogar zu Schuldzuweisungen führen, wenn der Zeitplan davon betroffen ist
• Ständige Krisensitzungen sind lästig und stören die Konzentration
• Die Abschätzung von Bugs kann sehr lästig sein, vor allem, wenn es manchmal schneller ist, sie „einfach zu beheben“, als sie abzuschätzen
• das Team könnte an seinen eigenen Fähigkeiten zweifeln, etwas zu liefern, weil die Feature-Velocity verfälscht ist

Zusammenfassend lässt sich sagen, dass durch die Anhäufung von Bugs niemand gewinnt und alle verlieren. Nicht die Bugs selbst sind die Wurzel allen Übels, sondern die schlechte Angewohnheit, sie nicht sofort zu beheben.

Schlüsselerkenntnisse

• Bugs mit niedriger Priorität verursachen Reibungsverluste, erfordern ständige Wartung und sind im Grunde genommen für alle eine Zeitverschwendung
• Alte Bugs sind oft schwieriger zu beheben und daher zeitaufwändiger
• Die Feature-Velocity der Entwicklung wird unvorhersehbar und das Management verliert die Kontrolle
• Das Anhäufen von Bugs führt zu ineffektivem Management, verärgerten Endbenutzern und schlechter Stimmung im Team

Was also ist die Zero-Bug-Policy und wie hilft sie uns?

Wenn Du aufmerksam bis hierhin gefolgt bist, ahnst Du vielleicht schon, worauf das ganze hinausläuft.

Die Zero-Bug-Policy ist ein sehr einfaches Verfahren für den Umgang mit Bugs. Es gibt nur eine einzige Regel, die man beachten muss, bevor man an einem neuem Feature arbeitet: „Gibt es offene Bugs? Wenn ja, dann behebe erst die Bugs, bevor Du an etwas anderem arbeitest.“

Natürlich bedeutet die Zero-Bug-Policy nicht, dass wir niemals Bugs produzieren werden, aber sie bedeutet, dass Bugs eine höhere Priorität haben als alle Features und User Stories. Man will immer sicherstellen, dass das Backlog keine Bugs enthält, bevor man mit der Arbeit fortfährt und dass schnell und proaktiv auf neue Bugs reagiert. Einfach ausgedrückt: Entwickler dürfen erst dann an neuem Code arbeiten, wenn alle offenen Bugs behoben sind. Wenn ein Bug im Moment nicht behoben werden kann (z. B. wegen externer Abhängigkeiten), ist es natürlich in Ordnung, den Status auf „blockiert“ zu setzen und ihn zu einem späteren Zeitpunkt zu beheben.

Damit dies funktioniert, ist es auch wichtig, Fehler entsprechend unserer Definition eines Bugs zu identifizieren (siehe Abschnitt „Was zählt als Bug?“). Jeder „Fehler“, der nicht in diese Kategorie fällt, ist potentiell ein Feature Request und sollte auch als solcher behandelt werden. Ein Beispiel hierfür wäre ein fehlender Randfall wie eine Benutzer-Passwort-Eingabevalidierung, bei der nicht in der User Story festgehalten wurde, dass das Passwort mindestens ein Sonderzeichen enthalten muss.

Randbemerkung

Wenn Du bereits mit ZBP vertraut sind, hast Du vielleicht bemerkt, dass sich unser Ansatz ein wenig von der klassischen Version unterscheidet. In der Standardversion würden man sich fragen, ob die Behebung des Bugs einen Mehrwert für den Endbenutzer darstellt, und wenn die Antwort nein lautet, würden Sie den Bug einfach schließen. Unserer Meinung nach kann dieser Schritt übersprungen werden, wenn es eine ganz klare Definition gibt, was tatsächlich als Bug zählt und wer Bug-Tickets erstellen darf. In diesem Fall ist jeder identifizierte Bug ein Merkmal für schlechte Qualität, das wir einfach nicht akzeptieren.

Ein großartiger Nebeneffekt von ZBP ist, dass jeder im Team automatisch eine gewisse Einstellung zur Qualität des Produkts entwickelt. Die Entwickler werden nach besserer Software streben, weil gute Qualität nun Teil des Prozesses ist und sie wissen, dass jeder Bug, den sie produzieren, sofort behoben werden muss.

Welche Vorteile bietet die ZBP und wie löst sie alle oben beschriebenen Probleme?

Schauen wir uns die zuvor besprochenen Probleme nochmal an, die entstehen, wenn Bugs nicht sofort behoben werden, und betrachten dabei, wie die meisten von ihnen durch die Anwendung der Zero-Bug-Policy im Grunde von selbst verschwinden.

Es kann mehr Zeit auf wichtige Aufgaben verwendet werden, anstatt Prioritäten zu verteilen und Bugs abzuschätzen.

Ein großes Problem bestand darin, dass Bugs, die nie eine hohe Priorität erhielten und daher auf unbestimmte Zeit im Backlog standen, Reibungsverluste verursachten, ständige Wartung erforderten und im Grunde eine Zeitverschwendung für alle waren.

In ZBP stellt sich die Frage nicht, ob man einen Bug aufschieben oder im nächsten Sprint beheben soll. Wenn ein Problem auftaucht, das als Bug eingestuft wird, wird es sofort behoben. Es gibt keinen Raum für Diskussionen darüber, ob der Bug im Moment Priorität hat. Auch die unnötige Arbeit der Bug-Abschätzung entfällt.

Die meisten Bugs sind leichter zu beheben, weil es viel weniger „alte“ Bugs gibt.

Wir haben auch gelernt, dass ältere Bugs unangenehmer zu behandeln und oft zeitaufwändiger sind. Einige Gründe dafür sind, dass man sich an den betreffenden Code weniger gut erinnert oder er sich bereits drastisch verändert hat. Außerdem weiß man oft sofort, wie man einen Bug in einer Funktion, die man gerade erst geschrieben hat, beheben kann – ein Vorteil, der bei alten Bugs verloren geht.

Wenn neue Bugs entdeckt werden, stehen sie meist auch in Zusammenhang mit einer neuen Funktionalität. Daher ist es weniger wahrscheinlich, dass sich der Bug auf alten Code bezieht, und somit ist er leichter zu beheben.

Abhängige Teams werden es zu schätzen wissen, wenn Bugs schnell behoben werden

Ein offensichtlicher Vorteil ist, dass die Zusammenarbeit mit anderen Entwicklungsteams, die von Ihrem Code abhängen, viel reibungsloser verläuft. Es gibt kein lästiges Hin und Her und keine unangenehmen Fragen, wann bestimmte Bugs endlich behoben sind. Auf diese Weise kann die Zusammenarbeit viel mehr Spaß machen.

Jeder ist vom ersten Tag an mit der hervorragenden Produktqualität zufrieden

Da hohe Qualität für das Team oberste Priorität hat, wird die Anwendung von allen, die mit ihr in Berührung kommen, immer als einwandfrei empfunden. Dies kann Stakeholder betreffen, die immer darauf erpicht sind, die neuesten Entwicklungen auszuprobieren, oder Endnutzer, die sehr zufrieden sind, dass die Anwendung so wenige Fehler aufweist und wenn es welche gibt, diese zeitnah behoben werden. Das allein kann die User Experience schon um einiges verbessern.

Natürlich sind auch das Management und die Entwickler zufriedener, wenn sie wissen, dass das Produkt, das sie entwickeln, hervorragend ist.

Qualität und Quantität – Man erhält das Beste aus beiden Welten

Wenn man ZBP als das Äquivalent zu „Qualität vor Quantität“ betrachtet, könnte man meinen, dass der klassische Ansatz ohne ZBP „Quantität vor Qualität“ lautet. Man könnte auch zu dem Schluss kommen, dass es für das Team länger dauert, Software zu schreiben. Diese Annahme ist jedoch falsch. Wie wir bereits gesehen haben, wird die Arbeit für das Team mühsamer, wenn Zeit für Abschätzungen und die Behebung alter Bugs verschwendet wird und die Motivation des Teams gering ist.

Wir erhalten also nicht nur ein besseres Produkt in Bezug auf die Qualität, sondern gewinnen auch noch an Geschwindikeit. Eine perfekte Win-Win-Situation.

Das Management wird sich über die Möglichkeit freuen, die Zukunft besser vorhersagen zu können.

Die meisten dieser Vorteile liegen auf der Hand. Aber Du fragst dich vielleicht, wie genau ZBP eine konstantere und verlässlichere Feature-Velocity sicherstellt, die vom PO für die Erstellung einer groben zukünftigen Roadmap oder von Meilensteinen verwendet werden kann.

Unter der Annahme, dass die Anzahl der Bugs, die pro neuem Feature produziert werden, relativ gleichmäßig verteilt ist, wird auch die Anzahl der Bugs, die pro Sprint behoben werden, in jedem Sprint ähnlich sein.

Wenn es also eine vergleichbare Anzahl von Funktionen und Bugs gibt, die in jedem Zeitraum behoben werden können, dann sollte theoretisch die Feature-Velocity im Schnitt sehr konstant bleiben (außer in Sprint 1).

Außerdem wird es nie eine Notwendigkeit von Bugfixing-orientierten Sprints geben, da wir durch die Anwendung der Zero-Bug-Policy keine Bugs anhäufen.

Weniger lästige Meetings

Die Fähigkeit des Managements, besser zu planen, führt auch zu weniger Krisensitzungen, die sehr anstrengend und ermüdend sein können, vor allem, wenn Deadlines näher rücken. Mit weniger Komplikationen können sich alle auf die Entwicklung der nächsten großartigen Features konzentrieren.

Die Stimmung des Teams ist besser

Und nicht zuletzt ist der größte Vorteil von ZBP die enorme Wirkung, die all dies auf die Stimmung des Teams hat. Motivation ist der Schlüssel, um etwas Außergewöhnliches zu schaffen.

Denk an all die negativen Auswirkungen, die der große Berg von Bugs auf das Team hatte:

• Immenser Druck, weil die Fristen falsch gesetzt wurden
• Monotone Wochen der Fehlerbehebung
• Entwicklerteams, die auf ihr Produkt nicht mehr stolz waren
• Ständiges negatives Feedback von Stakeholdern und Endbenutzern
• und so viele weitere Probleme …

All das ist nun vorbei.

Stell Dir stattdessen eine Welt vor, in der sich jeder auf das konzentrieren kann, was er am liebsten tut:

• Tolle neue Funktionen entwickeln, die die Kunden lieben
• Eine positive Feedback-Schleife zu bekommen, in der einem jeder sagt, wie gut und stabil die App läuft
• Eine gute Balance zwischen Entwicklung und Fehlerbehebung zu haben
• Konzentriert und hochfokussiert arbeiten zu können
• Deadlines immer mit Leichtigkeit einhalten zu können
• In der Lage zu sein, Meilensteine richtig zu planen
• …

Auch wenn die Teammitglieder gut ausgebildet sind, kann ein großartiges Produkt nur dann realisiert werden, wenn alle mit ihrer Arbeit zufrieden sind.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass die Zero-Bug-Policy den Prozess beschreibt, bei dem Bugs Vorrang vor allem anderen haben. Die Anwendung dieses Prinzips führt zu einigen ziemlich interessanten Effekten wie einer konstanteren und sogar höheren Feature-Velocity, mehr Teamzufriedenheit und zufriedeneren Kunden.