Wie viele offene Bugs haben Sie in Ihrem Backlog? 100? 1000?
Wie lange liegen sie schon dort? Eine Woche? Einen Monat? Jahre?
Warum passiert das? Keine Zeit? Wir müssen priorisierte Aufgaben erledigen? "Jetzt setzen wir alle dringenden Features um, und dann haben wir definitiv Zeit, die Bugs zu beheben"?

… Einige verwenden eine Zero Bug Policy, bei manchen ist die Fehlerkultur gut ausgeprägt (aktuelles Backlog zeitnah aktualisieren, Fehler bei Änderungen der Funktionalität überprüfen usw.), und manche züchten Zauberer, die ganz ohne Bugs schreiben (wenig wahrscheinlich, aber vielleicht kommt das vor).

Heute werde ich Ihnen unsere Lösung zur Bereinigung des Bug-Backlogs vorstellen — das Projekt „Bug-Fabrik“.

Wie alles begann?

Beim erneuten Durchsehen des immer größer werdenden Backlogs an offenen Bugs erreichten wir den Siedepunkt. So konnten wir nicht weitermachen, und wir beschlossen, ihn um jeden Preis zu reduzieren. Die Idee ist offensichtlich, aber wie umsetzen? Wir einigten uns darauf, dass die effektivste Methode ein Event ähnlich einem Hackathon sein würde: die Teams von ihren alltäglichen Aufgaben abzuhalten und einen Arbeitstag nur für die Bearbeitung von Bugs zu reservieren.

Wir schrieben die Richtlinien auf, riefen alle dazu auf und warteten. Es gab Bedenken, dass sich nur wenige melden würden, sehr wenige, aber das Ergebnis übertraf unsere Erwartungen — ganze 8 Teams meldeten sich an (allerdings zogen sich kurzfristig 3 zurück). Für die Veranstaltung wurde ein ganzer Arbeitstag am Freitag reserviert, und wir buchten einen großen Konferenzraum. Mittagessen organisierten wir über die Bürokanteine, für Snacks fügten wir Kekse hinzu.

Implementierung

Am Morgen des Tages X versammelten wir alle Interessierten im Konferenzraum und hielten eine kurze Einweisung.

Die wichtigsten Regeln:

• In einem Team kämpfen 2 bis 5 Personen, mindestens einer von ihnen muss QA sein;
• Bugs müssen von einem Teammitglied gemäß allen internen Produktionsstandards geschlossen werden;
• Jedes Team muss mindestens einen geschlossenen Bug haben, der Änderungen im Code erfordert;
• Es dürfen nur alte Bugs behoben werden (Erstellungsdatum des Bugs < Datum des Beginns der Bug-Fabrik - 1 Monat);
• Für behobene Bugs gibt es Punkte (von 3 bis 10), abhängig von der Kritikalität (um Cheating zu vermeiden, darf die Kritikalität nach der Bekanntgabe des Datums der Bug-Fabrik nicht geändert werden);
• Für das Schließen von nicht mehr aktuellen, nicht reproduzierbaren Bugs gibt es jeweils 1 Punkt;
• Das Audit-Team überwacht die Einhaltung aller Regeln und annulliert Punkte für wiedereröffnete Bugs.

Weitere Details

• Wir haben niemanden in der Wahl des Standorts eingeschränkt: man konnte am Arbeitsplatz bleiben oder mit allen im Besprechungsraum sitzen, in dem die Jungs nicht abgelenkt wurden und die Stimmung spürbar angespannt war.

• Um den Wettbewerbsgeist zu unterstützen, wurde eine Rangliste auf dem großen Bildschirm angezeigt, und im Slack-Kanal lief ständig ein textuelles Live-Update des Kampfes. Zur Punktezählung wurde ein Leaderboard verwendet, das über Webhooks aktualisiert wurde.

Leaderboard

• Ein Team von Auditoren überwachte die Einhaltung aller Regeln (erfahrungsgemäß sind dafür 1-2 Personen ausreichend).
• Eine Stunde nach dem Ende der Bug-Duell wurden die überprüften Ergebnisse bekannt gegeben.
  Die Gewinner erhielten einen Geschenkgutschein für eine Bar, und alle Teilnehmer erhielten ein Andenken (Schlüsselanhänger mit "Bugs").

Ergebnisse

In den letzten sechs Monaten haben wir bereits drei Bug-Duelle 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 der irrelevanten / nicht reproduzierbaren Bugs liegt bei 57 % (und dieser Müll fiel ständig ins Auge und machte sich durch seine Menge bemerkbar).

Moment der Ergebniskündung

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

Feedback

Nach den Bug-Duellen haben wir Feedback von den Teilnehmern gesammelt. Hier sind die Antworten auf die Frage "Was hat Ihnen am meisten am Teilnahmeprozess gefallen?":

• Es ist sehr cool, das Backlog mit so viel Motivation zu bearbeiten! Normalerweise ist das ein sehr langweiliger Prozess, so etwas sollte man regelmäßig machen).
• Einsatz, Kekse.
• Es ist die lang ersehnte Möglichkeit, die kleinen Dinge zu verbessern, die nicht kritisch sind, aber geändert werden möchten.
• Es hat mir gefallen, dass ich endlich alte, unangenehme Bugs außerhalb der Sprints beheben konnte, da für solche immer keine Zeit sein wird, weil es immer Aufgaben mit höherer Priorität geben wird. Es gelang, alle notwendigen Personen an einem Ort zu versammeln (in unserem Team war z.B. ein DBA), wir haben gemeinsam die Relevanz der genannten Bugs und die technische Möglichkeit ihrer Behebung diskutiert.

Fazit

Die Bug-Factory ist kein Allheilmittel, aber eine durchaus realisierbare Option zur Reduzierung des Bug-Backlogs (in verschiedenen Teams zwischen 10 und 50 %) an nur einem Tag. Bei uns hat diese Veranstaltung nur dank der motivierten Leute funktioniert, die für das Produkt brennen und sich um das Wohl unserer Nutzer kümmern.

Allen alles Gute und weniger Bugs!

Quelle: habr.com