Bugs priorisieren

Bild: Pixabay / Jill Wellington - Lizenz

Meine Tätigkeit als Test-Manager ist mittlerweile schon einige Jahre her, in vieler Hinsicht profitiere ich aber bis heute davon. Speziell die Frage wie in einem agilen Entwicklungsumfeld Qualitätssicherung betrieben wird ist spannend und herausfordernd, von der Zero Bug-Policy bis zum "agilen Testkonzept" gibt es vieles was anders ist als im klassischen Vorgehen. Ein weiterer derartiger Fall, der um den es hier gehen soll, ist die Priorisierung von Bug-Tickets.

Beginnen wir mit der Ausgangslage: klassisch werden Bugs in Kritikalitätsklassen eingeteilt, z.B. gering, mittel, schwerwiegend und systemkritisch.¹ Worauf diese Einteilung zurückgeht ist von Unternehmen zu Unternehmen unterschiedlich (und nicht immer klar definiert) sie beruht aber in der Regel darauf wie viele Funktionalitäten betroffen sind, wie wichtig diese für das Funktionieren des Gesamtsystems sind und ob es einen Workaround gibt. Diese Kritikalität beeinflusst dann auch das weitere Vorgehen.

In der Theorie ist es so, dass systemkritische Bugs sofort repariert werden, schwerwiegende zeitnah, mittelschwere mittelfristig (z.B. in Stabilisierungsphasen) und gering wichtige irgendwann - oder nie.² Die Idee dahinter ist meistens, dass es oberste Priorität ist neue Features zu bauen um die gesetzten (und mit Belohnung versehenen) Ziele zu erreichen. Die Qualitätssicherung erfolgt dann später im Projekt, ggf. sogar nach Go Live (mehr dazu hier) gering wichtige Bug-Tickets bleiben z.T. für immer ungefixt.

In der Realität funktioniert dieses Vorgehen auch im klassischen Kontext eher selten. Bei vielen Bugs fällt erst während der Behebung auf wie schwerwiegend sie sind, andere gelten wegen vorhandener Workarounds als weniger schwerwiegend, allerdings blockiert deren Nutzung die Weiterentwicklung der so genutzten Komponenten. Nochmal andere sind wirklich eher klein, sie beeinträchtigen die Benutzungserfahrung aber so sehr, dass die Nutzer unzufrieden werden. etc.

In einem agilen Entwicklungskontext wird ein solches Vorgehen dann völlig unmöglich, schliesslich soll die Anwendung (inclusive ihrer neuesten Features) durchgehend "potentially shippable" sein, also ständig im notwendigen Zustand um sofort released werden zu können. Das erfordert das zeitnahe Erledigen aller Bugtickets, wodurch der ursprüngliche Grund der klassischen Priorisierung (die Entscheidung welche Reparaturen auf später verschoben werden können) weitgehend obsolet wird.

Soviel zur Analyse, aber wenn die klassische Bug-Priorisierung im agilen Umfeld problematisch ist, wie geht es besser? Ein einfacher Ansatz mit dem ich gute Erfahrungen gemacht habe ist der: Bugs der Prioritätsklasse I werden sofort erledigt, ggf. sogar um den Preis des Sprint-Abbruchs. Bugs der Prioritätsklasse II kommen in den nächsten Sprint (und zwar alle, selbst wenn dann kein Platz mehr für Features bleibt), Bugs der Prioritätsklasse III werden nicht repariert und geschlossen.

Was steckt dahinter? Klasse I ist Produktionsausfall, Datenleck oder Vergleichbares, also etwas das alles andere schlägt. Klasse II ist Teil eins der Zero Bug-Policy, also die Reparatur aller reparaturwürdigen Fehler zum nächstmöglichen Zeitpunkt (der keinen Sprint sprengt), Klasse III ist Teil zwei der Zero Bug-Policy, in dessen Rahmen alle noch verbleibenden Bugs als so irrelevant eingruppiert werden, dass ihre Behebung den Aufwand nicht wert wäre.³

Vor allem zwei Vorteile enstehen durch diese neue Art der Priorisierung: zum einen wird die (oft widersprüchliche) Parallelität von Wichtig und Dringend aufgehoben, zum anderen wird das Backlog ausgemistet, das vorher durch Tickets verstopft wurde von denen jeder wusste, dass sie nie in die Umsetzung gehen würden. In Summe gehen Diskussions- und Pflegeaufwand zurück und es bleibt mehr Zeit für wirklich wichtige Themen.

An dieser Stelle gibt es übrigens auch einen weiteren Brückenschlag zur Agilität. Teams und Organisationen die weniger Zeit für ihre Bug-Verwaltung aufwenden müssen haben mehr Zeit für andere Themen und werden mit denen schneller fertig. Ein Zustand ein eigentlich jeder anstreben sollte, auch ohne einen Testmanagement-Hintergrund.