Wie schon oft gesagt ( 1 , 2 , 3 ):
„Fehler/Defekte nicht einschätzen“.
Ich weiß, dass wir in Scrum versuchen, die Fehlerrate zu minimieren, aber es passiert hin und wieder. Das Beheben solcher nicht geschätzter Aufgaben kann große Auswirkungen auf die tatsächliche Geschwindigkeit des Teams haben. Ich frage mich, ob es eine Art Verfahren oder Formel gibt, um dies für das Team und andere sichtbar zu machen?
Oder ist eine Erhöhung der Fehlerrate (= Abfall der Geschwindigkeit) nur ein Zeichen dafür, dass wir unserer QA mehr Aufmerksamkeit schenken sollten?
Da wir Bugs nicht schätzen, ist diese Frage kein Duplikat dieser Frage: Verfolgen von Punkten, die während des Sprints für Bugs ausgegeben werden
Wenn Sie ein länger laufendes Projekt mit Geschwindigkeit messen, um eine Vorstellung davon zu bekommen, wann Features oder Meilensteine erreicht werden, ist es eine gute Idee, Fehler nicht zu schätzen. Mängel sind Arbeiten, die an anderen Stellen bereits in der Vergangenheit hätten erledigt werden müssen. Wenn Sie jetzt viele Fehler haben, werden Sie wahrscheinlich in Zukunft die gleiche Menge haben, was Ihr gesamtes Projekt verlangsamt. Es würde ein falsches Gefühl von Geschwindigkeit vermitteln, wenn Sie nicht wertvolle Story-Points für die Arbeit angeben. Die Geschwindigkeit sinkt, wenn Sie Defekte oder technische Schulden haben .
Eine Zunahme von Fehlern oder eine Abnahme der Geschwindigkeit sollte während einer Retrospektive immer zu einer guten Ursachenanalyse führen , um Wege zu finden, ähnliche Fehler zu verhindern oder den Prozess zu verbessern. Ob die Ursache wirklich in Ihrem QS-Prozess liegt, müssen Sie herausfinden, da dies stark von der Situation abhängt.
Einige Metriken, die ich gerne verwende, um Probleme zu signalisieren:
Diese sollten je nach Metrik ziemlich stabil sein oder nach unten/oben gehen.
Erfahrungsgemäß ist die Hauptursache der meisten Fehler meistens nicht das Fehlen eines QA-Prozesses, sondern eine Architektur oder ein Design, das viele gekoppelte Abhängigkeiten aufweist, was es schwierig macht, die Codebasis zu warten und zu erweitern. Oft ist es schwierig, eine Testautomatisierung dafür zu erstellen, und daher ist es schwierig, sie zu refaktorisieren und zu bereinigen. Ich empfehle immer, sich die erste Folge von Clean Code anzusehen , um sich ein Bild von häufigen Problemen mit Code zu machen.
pasler