Wer über was, aber ich spreche über Fehler.

Letztes Jahr habe ich Ihnen von den Bagels erzählt - einer Veranstaltung in unserem Unternehmen, bei der der Rückstand von Fehlern beseitigt wurde. Das Ereignis ist gut und nützlich, aber es löst das Fehlerproblem einmalig. Wir haben bereits sechs Bagodelen abgehalten, aber die Zahl der Teilnehmer ging allmählich zurück und es wurde offensichtlich, dass die Notwendigkeit für diese Veranstaltung allmählich verschwand. Der Hauptgrund war das Erscheinen der Zero Bug Policy. Es gibt nicht viele Quellen in russischer Sprache, in denen Sie lesen und eine bequeme Lösung für sich finden können. In diesem Artikel werde ich über unsere Herangehensweise an das Thema sprechen und in den Kommentaren gerne über Ihre Erfahrungen lesen.

Was ist das

Zero Bug Policy (ZBP) ist eine regelbasierte Fehlerbehandlungsrichtlinie:

"Wenn ein neuer Fehler auftritt, müssen Sie sofort entscheiden, ihn in naher Zukunft zu beheben, oder ihn als" Wird nicht behoben "schließen."

Gehen Sie in diesem Fall nicht bis zum Äußersten: Machen Sie überhaupt keine Fehler und bearbeiten Sie nicht alles hintereinander. Es ist wichtig, für sich selbst Qualitätskriterien für Funktionen zu entwickeln, die Sie den Benutzern geben können, und die Aufgabe als erledigt zu betrachten, nachdem alle wichtigen Fehler behoben wurden.

Versicherungsleistungen

• Jeder weiß, wie viele offene Fehler es gibt und diese Anzahl ist ziemlich begrenzt.
• Es ist weniger Zeit erforderlich, um die Aufgabe im Fehlerverfolgungssystem zu finden.
• Es gibt keine langen Besprechungen, um das Fehler-Backlog zu sortieren und neu zu priorisieren.
• Es kann für Sie psychologisch einfacher werden, wenn Sie nicht durch einen aufgeblähten Rückstand unter Druck gesetzt werden.
• Nach der Korrektur ist es nicht notwendig, sich an das zu erinnern, was „vor hundert Jahren“ da war, und erneut in den Kontext einzutauchen.

Klingt gut, aber Nebenwirkungen sind möglich.

• Verminderte Produktqualität.
• Verschlechterung des Testteam-Levels. (Warum Zeit damit verschwenden, nach kniffligen und komplexen Fehlern zu suchen, wenn sie immer noch nicht behoben werden?)
• Eine nützliche Informationsquelle (in Form eines offenen Rückstands) für neue Teammitglieder geht verloren.

Und es gibt immer einen Angstfaktor.

"Also werden wir den Fehler schließen und was ist, wenn eine glänzende Zukunft kommt, wenn Zeit ist, ihn zu beheben?"

Es ist sehr unwahrscheinlich, dass Sie zusätzliche Zeit haben. Es ist, als würde man alten Müll auf dem Balkon aufbewahren: Sie verlieren nicht die Hoffnung, eines dieser Dinge zu benutzen, aber höchstwahrscheinlich wird es nie passieren.

Hier schließen wir den Fehler und der Benutzer sieht ihn im Produkt.

Ein verärgerter Benutzer wird an den Support schreiben, der Sie wiederum informiert. Es wird notwendig sein, die Priorität dieses Fehlers zu überprüfen und erneut zu entscheiden, ob er behoben werden soll oder nicht.

Implementierung

Am schwierigsten ist es, loszulegen. Um dies zu tun, müssen Sie die Zeit, die Ressourcen und den Wunsch (unterstreichen erforderlich) finden, um den gesamten Rückstand an alten Fehlern zu schaufeln und eine radikale Entscheidung zu treffen, um zu korrigieren oder zu schließen.
Sammeln Sie dann Kraft und korrigieren Sie die "Überlebenden", nachdem Sie die Fehler beseitigt haben.
Und fange an, nach den neuen Regeln zu leben.

Teilen Sie Fehler in zwei Kategorien ein:

• ein Fehler beim Testen einer neuen Funktion gefunden;
• Ein Fehler bei Prod / mit Regression.

Wenn Sie beim Testen einer neuen Funktion einen Fehler finden, müssen Sie sofort eine Entscheidung treffen:

• Beheben Sie den Fehler, bevor die Entwicklung / das Testen der Funktion abgeschlossen ist.
• einen Fehler neu klassifizieren (vielleicht ist dies tatsächlich eine Verbesserung);
• Vielleicht müssen Sie überhaupt keinen Fehler bekommen, wenn Sie ihn nicht bearbeiten möchten.
  In der Einlaufphase des Prozesses ist es besser, solche Fehler mit der Auflösung „Won't Fix“ zu starten und zu schließen, die den Grund für das Schließen beschreibt. Basierend auf diesen Daten können Sie Fehler analysieren und Qualitätskriterien in Ihrem Team korrekt entwickeln.

Und wenn es einen Fehler auf dem Produkt / mit Regression gibt, müssen Sie entscheiden, was zu tun ist.

• Beheben Sie den Fehler und halten Sie die Frist ein, abhängig von der Priorität des Fehlers. Die Fixzeit reicht von "jetzt" bis zu zwei Sprints. Wenn der Fehler in zwei Sprints nicht behoben wurde, sollte er geschlossen werden.
• Ändern Sie den Aufgabentyp von "Fehler" in "Verbesserung".
• Schließen Sie den Fehler mit der Auflösung "Wird nicht behoben" mit einer Beschreibung des Grundes für das Schließen.

Um die Priorität des Fehlers zu bestimmen, verwenden wir eine Matrix, die die Kritikalität des Fehlers innerhalb eines bestimmten Befehls und die Häufigkeit des Auftretens kombiniert.

Weitere Details

Der Gewinn aus diesem Ansatz ist wahrscheinlich unbedeutend, wenn Sie die Prozesse und Ansätze in Entwicklung und Test nicht zusätzlich ändern.

Was reduziert die Anzahl der Fehler bei der Entwicklung einer neuen Funktion?

1. Verwenden Sie eine breite Palette technischer und organisatorischer Praktiken (z. B. Implementierung von Quality Gates, Auswirkungsanalyse, agiles Testen).
2. Beseitigen Sie fehlererzeugende Speicherorte, indem Sie alten Code umgestalten.
3. Korrigieren Sie Fehler schnell, um ihre Auswirkungen in Zukunft zu verringern.
4. Schreiben Sie Autotests, um Problembereiche schneller und schneller zu erkennen
   verhindern Sie die Wiederholung von Fehlern.

Metriken

Um keine Rückschlüsse auf unsere Gefühle zu ziehen, folgen wir den ZBP-Metriken (ich mag Tableau sehr und verwende es zum Erstellen von Berichten). Auf diese Weise können Sie den Fortschritt in der Dynamik verfolgen und aufkommende Probleme hervorheben.

Ergebnisse

Was sind die Ergebnisse der Arbeit an ZBP mit uns?

Wir leben in der realen Welt und in ihrer reinsten Form war es nicht möglich, Politik zu benutzen.
Jemand stieß auf ein Legacy-Problem und die Unfähigkeit, einige Fehler für eine begrenzte Zeit zu beheben. Jemand hatte im Laufe der Jahre einen Rückstand angesammelt, es war nur beängstigend, sich ihm zu nähern, und sie hatten es nicht eilig, diesen Prozess zu beginnen.

Im Allgemeinen gelang es vielen Teams jedoch, ihre Rückstände zu analysieren und die Anzahl der offenen Fehler auf eine bestimmte Messlatte zu setzen. Die Teams begannen, Fehler besser zu bewerten und schnellere Entscheidungen über die Notwendigkeit einer Korrektur zu treffen.

Schlussfolgerungen

• Es ist sehr aufwändig, Ihren Ansatz zur Arbeit mit Fehlern zu ändern.
• Damit der Prozess funktioniert, muss er Teil der Ingenieurkultur des Unternehmens werden.
• Das Team muss ein Gleichgewicht zwischen Fehlerkorrektur und Sprintentwicklung finden.

Alles gut und weniger Fehler!