Schnell und einfach Bugs fixen

Das Fixen von Bugs war schon vor Scrum eine Herausforderung in der Softwareentwicklung. Die kurzen Iterationen in Agile machen es den Teams nicht unbedingt einfacher, zu entscheiden, welche Bugs gefixt werden müssen und welche noch warten können.

Die guten Nachrichten sind, dass ein Scrum Team normalerweise weitaus weniger Bugs hat als ein Team, das mit traditionelleren Entwicklungsframeworks arbeitet. Aber auch agile Teams finden hier und da den ein oder anderen Bug, besonders wenn ein Teil der Entwicklung aus der Zeit stammt, bevor das Team zu einem agilen Ansatz übergegangen ist. Und um diese Defekte zu priorisieren, benötigt das Team eine effektive Lösung.

Priorisierung von Bug Fixes: Was man nicht tun sollte

Früh in meiner Berufslaufbahn als Programmierer stellte mein Chef das gesamte Team eine Woche lang ab, um über alle bekannten Defects zu sprechen. Wir sprachen über mögliche Ursachen, darüber, wie schwerwiegend jeder einzelne Bug war, wie oft er auftrat, ob er reproduziert werden kann, wo im Code der Fehler liegen könnte und wer von uns dieses Problem beheben sollte.

Wir schätzten sogar ab, wie lange das für jeden Bug dauern würde. Diese Einschätzungen waren in den meisten Fällen nicht nur ziemlich nutzlos, es dauerte meist auch länger, die Einschätzung abzugeben, als einfach den Bug zu fixen.

Als ich nach diesen frühen Erfahrungen anfing, Teams zu führen, fing ich an, mit anderen leichtgewichtigeren Ansätzen zu experimentieren.

Heute möchte ich meine Lieblingsmethode für das Fixen von Bugs vorstellen.

Richtlinien für das Priorisieren von Bugs

Statt sich die Zeit zu nehmen, um über jeden einzelnen Bug nachzudenken, sollte man besser Richtlinien erstellen, die festlegen, wie schnell ein Bug gefixt werden sollte bzw. wie hoch der Defect, also das Problem beim Auftreten des Bugs ist.

Beispiel 1: Eine dieser Richtlinien könnte sein, dass jeder Bug, der alle Nutzer auf dramatische Weise beeinträchtigt, sofort behoben werden muss, d.h. dass die laufenden Arbeiten im Sprint unterbrochen werden. Eine andere Richtlinie könnte beispielsweise besagen, dass Bugs, die nur extrem selten auftreten und den Nutzer nicht davon abhalten, die wichtigsten Funktionen auszuführen, notiert werden und ohne Druck behoben werden, sobald Zeit dafür ist.

Richtlinien zu erstellen und zu nutzen, nennt man auch Priorisierung durch Richtlinien (prioritization by policy).

Beispiel 2: Ein etwas konkreteres Beispiel könnte wäre, wenn der Product Owner sich mit seinem Team einig ist, dass jeder Bug, der die Nutzer davon abhält, Bestellungen auf ihrer eCommerce-Seite zu tätigen, so schnell wie möglich behoben werden muss.

Weitere Richtlinien beziehen sich vielleicht auf Bugs, die lediglich am Ende des Tages oder am Ende der Woche oder sogar gar nicht gefixt werden sollten.

Defect-Richtlinien definieren

Hilfreich für die Formulierung von Bug-Fixing-Richtlinien sind folgende Überlegungen:

• Wahrscheinlichkeit eines Defects: Wie oft tritt das Problem auf?
• Schweregrad eines Defects: Wie schlimm ist es, wenn das Problem auftritt?

Stellen Sie sich vor, bei Amazon gibt es einen Bug, der bewirkt, dass Bestellungen mit einem Wert von 1 Million Dollar nicht getätigt werden können, da ein Entwickler davon ausgegangen ist, dass eine Bestellung nie über einem Wert von 999.999,99 Dollar liegen werden.

Es ist schlecht, wenn dieser Fall eintritt (hoher Schweregrad), aber ich denke, dass Amazon nicht besonders viele Bestellungen bekommt, die über 1 Million Dollar liegen (geringe Wahrscheinlichkeit).

Erstellung der Defect-Richtlinien-Matrix zum Priorisieren von Bugs

Die beiden Dimensionen – Schweregrad und Priorität – können kombiniert werden, um die Prioritätenrichtlinie für einen Defect festzulegen. Dabei kann eine solche Matrix helfen:

Es gibt viele Möglichkeiten, um Wahrscheinlichkeit und Schweregrad von Bugs einzuordnen. Bei dem Beispiel mit der eCommerce-Seite wird die Wahrscheinlichkeit beispielsweise mit dem Prozentsatz der beeinträchtigten Transaktionen ausgedrückt. Alles, was 10% oder mehr an Transaktionen beeinflusst, ist eine ziemlich große Sache, also habe ich die gesamte Spalte auf hohe oder sehr hohe Priorität gesetzt.

Zur Bemessung des Schweregrades eines Defects kann man überlegen, ob es eine Ausweichlösung gibt und ob sie offensichtlich ist oder eher schwer zu finden. Auf einer eCommerce-Seite gibt es unter Umständen z.B. zwei “Jetzt kaufen”-Buttons aber nur einer davon funktioniert.

Die Zellen der Matrix zeigen, welche Richtlinie für Defects mit einer bestimmten Wahrscheinlichkeit und einem bestimmten Schweregrad gelten. In diesem Beispiel habe ich fünf verschiedene Prioriätenstufen gewählt – von sehr niedrig bis sehr hoch. In manchen Fällen reichen unter Umständen drei Abstufungen. Ich würde davon abraten, mehr als fünf zu nehmen, aber auch das habe ich schon gesehen.

So verwende ich die fünf Prioritätenstufen:

• Sehr hoch: Wird sofort in die laufende Iteration aufgenommen, auch wenn das bedeutet, dass andere Arbeiten liegen bleiben. Erfordert womöglich mehr als ein Teammitglied, evtl. sogar das gesamte Team.

• Hoch: Wird sofort in die laufende Iteration aufgenommen, auch wenn das bedeutet, dass andere Arbeiten liegen bleiben. Das Team entscheidet, wer das Problem am besten lösen kann.

• Mittel: Kann nach Ermessen des Product Owners in die laufende Iteration aufgenommen werden.

• Niedrig: Wird dokumentiert und im nächsten Planning Meeting nach Ermessen des Product Owners besprochen.

• Sehr niedrig: Wird in Liste bekannter Probleme dokumentiert. Wird nur wieder thematisiert, wenn sich Wahrscheinlichkeit bzw. Schweregrad ändern oder nach Ermessen des Product Owners.

Vorteile der Priorisierung durch Richtlinien

Der Hauptvorteil dieses Ansatzes ist, dass man wesentlich weniger Zeit damit verbringt, darüber zu diskutieren, was mit jedem einzelnen Defect gemacht werden soll. Diese Art der Priorisierung von Bugs ist anfänglich mit etwas Aufwand für das Erstellen der Richtlinien verbunden. Sobald diese Richtlinien jedoch erst einmal erstellt sind, wird das Priorisieren von neuen Defects zum Kinderspiel.

Das Ziel dieses Ansatzes ist es, dass das Priorisieren von Defects eine eher objektive statt subjektive Angelegenheit wird. Natürlich wird jemand entscheiden müssen, wie häufig ein Problem wohl auftreten wird, aber abgesehen davon wird die Priorisierung selbst nicht mehr Zeit in Anspruch nehmen, als sich die Priorisierungsmatrix anzuschauen.

Dieser Beitrag stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.

Product Owner Seminar

=> Werde zertifizierter Product Owner und besuche eins unserer CSPO Trainings

Nichtfunktionale Anforderungen

=> Finde heraus, wie du nichtfunktionale Anwendungen in User Stories überführst.

Product Scorecard

=> Finde heraus, ob dein Produkt auf die Unternehmensstrategie einzahlt und benutze die Product Scorecard.