Wie viele offene Bugs haben Sie in Ihrem Backlog? 100? 1000?
Und wie lange liegen sie schon dort? Eine Woche? Einen Monat? Jahre?
Warum passiert das? Keine Zeit? Wichtigeres zu erledigen? "Jetzt bringen wir alle dringenden Features zum Laufen, und danach haben wir definitiv Zeit, um die Bugs aufzuarbeiten"?

… Einige setzen eine Null-Bug-Politik um, andere haben eine ausgeprägte Kultur im Umgang mit Bugs (aktualisieren regelmäßig das Backlog, überprüfen Fehler bei Änderungen der Funktionalität usw.), und wieder andere züchten Magier, die überhaupt ohne Bugs programmieren (unwahrscheinlich, aber vielleicht kommt das tatsächlich vor).

Heute möchte ich Ihnen unser Konzept zur Bereinigung des Bug-Backlogs vorstellen – das Projekt „Bug-Klinik“.

Wie alles begann?

Bei der wiederholten Durchsicht des zunehmend umfangreichen Backlogs an offenen Bugs erreichten wir den Höhepunkt. So konnte es nicht weitergehen, wir beschlossen, ihn um jeden Preis zu reduzieren. Die Idee ist offensichtlich, aber wie setzt man das um? Wir waren uns einig, dass die effektivste Methode eine Art Hackathon sein würde: die Teams von den alltäglichen Aufgaben abzulenken und einen Arbeitstag ausschließlich für die Bearbeitung von Bugs zur Verfügung zu stellen.

Ein Regelwerk wurde erstellt, ein Aufruf ausgegeben und wir begannen zu warten. Es gab Bedenken, dass es nur wenige Teilnehmer geben würde, vielleicht sogar sehr wenige, aber das Ergebnis übertraf unsere Erwartungen — es haben sich insgesamt 8 Teams angemeldet (allerdings haben sich im letzten Moment 3 zurückgezogen). Für die Veranstaltung wurde ein ganzer Arbeitstag am Freitag eingeplant, und ein großer Besprechungsraum reserviert. Die Mittagessen wurden in der hauseigenen Kantine organisiert, und für Snacks wurden Kekse hinzugefügt.

Implementierung

Am Morgen des großen Tages haben wir alle Interessierten im Besprechungsraum versammelt und ein kurzes Briefing durchgeführt.

Die Hauptregeln:

• In einem Team kämpfen zwischen 2 und 5 Personen, mindestens eine davon ist QA;
• Bugs müssen von einem Teammitglied gemäß allen internen Produktionsstandards behoben werden;
• Jedes Team muss mindestens einen geschlossenen Bug haben, der Korrekturen im Code erfordert;
• Es dürfen nur alte Bugs behoben werden (Erstellungsdatum des Bugs < Datum des Bug-Hackathons — 1 Monat);
• Für behobene Bugs werden Punkte (von 3 bis 10) je nach Kritikalität vergeben (um Betrug zu verhindern, darf die Kritikalität nach der Ankündigung des Termins für den Bug-Hackathon nicht geändert werden);
• Für das Schließen von nicht mehr relevanten, nicht reproduzierbaren Bugs gibt es jeweils 1 Punkt.
• Das Audit-Team überwacht die Einhaltung aller Regeln und zieht Punkte für wiedergeöffnete Bugs ab.

Weitere Details

• Niemand wurde in der Standortwahl eingeschränkt: man konnte am Arbeitsplatz bleiben oder mit allen im Besprechungsraum sitzen, wo die Leute nicht abgelenkt wurden und die Spannung spürbar war.

• Um den Wettbewerbsgedanken zu fördern, wurde eine Rangliste auf der großen Leinwand angezeigt, und im Slack-Kanal fand ständig ein textuelles Live-Update des Kampfes statt. Für die Punktzahlen wurde ein Leaderboard genutzt, das über Webhooks aktualisiert wurde.

Leaderboard

• Die Einhaltung aller Regeln wurde von einem Audit-Team überwacht (erfahrungsgemäß sind dafür 1-2 Personen ausreichend).
• Eine Stunde nach dem Ende des Bug-Huntings wurden die überprüften Ergebnisse bekannt gegeben.
  Die Gewinner erhielten einen Geschenkgutschein für eine Bar, und alle Teilnehmer bekamen ein Andenken (Schlüsselanhänger mit „Bugs“).

Ergebnisse

In den letzten sechs Monaten haben wir bereits drei Bug-Hunts durchgeführt. Was haben wir letztendlich erreicht?

• Die durchschnittliche Anzahl der Teams beträgt 5.
• Die durchschnittliche Anzahl der bearbeiteten Bugs beträgt 103.
• Die durchschnittliche Anzahl irrelevanter/nicht reproduzierbarer Bugs liegt bei 57 % (und dieser Müll war ständig störend und beängstigend in seiner Anzahl).

Der Moment der Ergebnisauswertung

Und nun die Antwort auf die kniffligste Frage, die alle gerne stellen: "Wie viele neue Bugs habt ihr gefunden?"
Antwort: nicht mehr als 2 % von allen bearbeiteten.

Bewertungen

Nach der Durchführung von Bugdelena haben wir Feedback von den Teilnehmern gesammelt. Hier sind die Antworten auf die Frage: "Was hat Ihnen am meisten am Teilnahmeprozess gefallen?":

• Es ist echt großartig, das Backlog mit so viel Motivation zu durchgehen! Normalerweise ist das ein sehr langweiliger Prozess, man sollte das regelmäßig durchführen).
• Die Spannung, Kekse.
• Es ist eine lang ersehnte Möglichkeit, die Kleinigkeiten zu beheben, die nicht kritisch sind, aber behoben werden möchten.
• Ich fand es toll, dass man endlich alte, ärgerliche Bugs außerhalb des Sprints beheben kann, dafür hat man normalerweise nie Zeit, weil immer Aufgaben mit höherer Priorität anstehen. Es gelang uns, alle benötigten Personen an einem Ort zu versammeln (zum Beispiel hatten wir einen DBA in unserem Team), wir haben kollektiv die Relevanz der gemeldeten Bugs und die technische Möglichkeit, sie zu beheben, besprochen.

Fazit

Bug-Farmen sind keine Wundermittel, aber sie stellen eine effektive Möglichkeit dar, das Backlog an Fehlern (in verschiedenen Teams zwischen 10 und 50%) an nur einem Tag zu reduzieren. Dieses Event war bei uns nur dank der motivierten Kollegen, die sich für das Produkt einsetzen und das Wohl unserer Nutzer im Blick haben, erfolgreich.

Allen alles Gute und weniger Bugs!

Quelle: habr.com