Wie viele offene Fehler haben Sie in Ihrem Backlog? 100? 1000?
Wie lange liegen sie dort? Eine Woche? Monat? Jahre?
Warum passiert das? Es gibt keine Zeit? Müssen Sie vorrangigere Aufgaben erledigen? „Jetzt implementieren wir alle dringenden Features und dann haben wir bestimmt Zeit, die Fehler zu beheben“?

... Einige verwenden die Zero-Bug-Richtlinie, andere haben eine gut entwickelte Kultur der Arbeit mit Fehlern (sie aktualisieren den Rückstand zeitnah, überarbeiten Fehler, wenn sich die Funktionalität ändert usw.), und einige kultivieren Assistenten, die überhaupt ohne Fehler schreiben (unwahrscheinlich, aber vielleicht passiert das).

Heute erzähle ich Ihnen von unserer Lösung zur Bereinigung des Bug-Backlogs – dem Bagodelnya-Projekt.

Wie alles begann?

Wenn wir uns noch einmal den ständig wachsenden Rückstand an offenen Fehlern ansehen, sind wir am Siedepunkt angelangt. Es war unmöglich, länger so zu leben, sie beschlossen, es um jeden Preis abzuholzen. Die Idee liegt auf der Hand, aber wie geht das? Wir waren uns einig, dass der effektivste Weg eine Veranstaltung ähnlich einem Hackathon wäre: Nehmen Sie die Teams von alltäglichen Aufgaben ab und widmen Sie einen Arbeitstag nur der Bearbeitung von Fehlern.

Sie schrieben die Vorschriften auf, riefen und begannen zu warten. Es gab Befürchtungen, dass es nur wenige, sehr wenige Bewerber geben würde, aber das Ergebnis übertraf unsere Erwartungen – bis zu 8 Teams meldeten sich an (im letzten Moment schlossen sich jedoch 3 zusammen). Für die Veranstaltung haben wir am Freitag einen ganzen Arbeitstag eingeplant und einen großen Tagungsraum gebucht. Das Mittagessen wurde in der Bürokantine organisiert und als Snack kamen Kekse hinzu.

Implementierung

Am Morgen des Tages X versammelten sich alle in einem Besprechungsraum und hielten eine kurze Besprechung ab.

Grundregeln:

• ein Team besteht aus 2 bis 5 Personen, mindestens einer davon ist QA;
• Fehler müssen von einem Teammitglied gemäß allen internen Produktionsstandards geschlossen werden;
• Jedes Team muss mindestens einen geschlossenen Fehler haben, der Korrekturen im Code erfordert;
• Sie können nur alte Fehler beheben (Datum, an dem der Fehler erstellt wurde < Startdatum des Bug House – 1 Monat);
• Für behobene Fehler werden je nach Kritikalität Punkte (von 3 bis 10) vergeben (um Betrug zu vermeiden, kann die Kritikalität nach Bekanntgabe des Datums des Bug Days nicht mehr geändert werden).
• für die Behebung irrelevanter, nicht reproduzierbarer Fehler wird 1 Punkt vergeben;
• Die Einhaltung aller Regeln wird vom Audit-Team überwacht, das Punkte für wiederentdeckte Fehler annulliert.

Andere Details

• Wir haben niemanden bei der Wahl des Standorts eingeschränkt: Sie konnten an ihrem Arbeitsplatz bleiben oder mit allen in einem Meeting sitzen, wo die Jungs nicht abgelenkt waren und Leidenschaften spürbar waren.

• Um den Wettbewerbsgeist aufrechtzuerhalten, wurde eine Bewertungstabelle auf dem großen Bildschirm angezeigt und im Slack-Kanal wurde ständig eine Textübertragung des Kampfes ausgestrahlt. Zur Berechnung der Punkte haben wir eine Bestenliste verwendet, die über Webhooks aktualisiert wurde.

Bestenliste

• Die Einhaltung aller Regeln wurde durch das Audit-Team überwacht (erfahrungsgemäß reichen dafür 1-2 Personen).
• Eine Stunde nach dem Ende des Bagodelny wurden die erneut überprüften Ergebnisse bekannt gegeben.
  Die Gewinner erhielten einen Geschenkgutschein für die Bar und alle Teilnehmer erhielten ein Souvenir (Schlüsselanhänger mit „Käfer“).

Ergebnisse

In den letzten sechs Monaten haben wir bereits drei Armenhäuser veranstaltet. Was haben wir am Ende herausgefunden?

• Die durchschnittliche Anzahl der Teams beträgt 5.
• Die durchschnittliche Anzahl der verarbeiteten Fehler beträgt 103.
• Die durchschnittliche Anzahl irrelevanter/nicht reproduzierbarer Fehler beträgt 57 % (und dieser Müll war ständig ein Dorn im Auge und erschreckte wegen seiner Menge).

Moment der Bekanntgabe der Ergebnisse

Und nun die Antwort auf die kniffligste Frage, die jeder gerne stellt: „Wie viele neue Bugs haben Sie gefunden?“
Antwort: Nicht mehr als 2 % aller verarbeiteten Produkte.

Bewertungen

Nach dem Bagodelen sammelten wir Feedback der Teilnehmer. Hier die Antworten auf die Frage „Was hat Ihnen am Beteiligungsprozess am besten gefallen?“:

• Es ist sehr cool, mit so viel Motivation den Rückstand zu sortieren! Normalerweise ist dies ein sehr langweiliger Prozess, er muss regelmäßig durchgeführt werden.
• Aufregung, Kekse.
• Dies ist eine lang erwartete Gelegenheit, die kleinen Dinge zu korrigieren, die nicht kritisch sind, die Sie aber korrigieren möchten.
• Mir hat gefallen, dass man endlich alte, unangenehme Fehler außerhalb des Sprints beheben kann; dafür wird nie Zeit sein, weil es immer Aufgaben mit höherer Priorität geben wird. Es ist uns gelungen, alle notwendigen Personen an einem Ort zusammenzubringen (unser Team hatte zum Beispiel einen DBA) und gemeinsam die Relevanz der identifizierten Fehler und die technischen Möglichkeiten ihrer Behebung zu diskutieren.

Abschluss

Der Bugshop ist kein Allheilmittel, aber eine praktikable Möglichkeit, den Bug-Backlog (in verschiedenen Teams von 10 auf 50 %) in nur einem Tag zu reduzieren. Für uns ist diese Veranstaltung nur dank motivierter Leute erfolgreich, die das Produkt unterstützen und sich um die Zufriedenheit unserer Benutzer kümmern.

Alles Gute und weniger Fehler!

Source: habr.com