Ist es möglich, die Ursache von Fehlern zu verfolgen oder zu messen, oder verlangt dies nur nach unbeabsichtigten Konsequenzen?

Question

Gibt es eine Methode zum Verfolgen oder Messen der Ursache von Fehlern, die nicht zu unbeabsichtigten Konsequenzen von Mitgliedern des Entwicklungsteams führt?Wir haben kürzlich die Möglichkeit hinzugefügt, die Ursache eines Fehlers in unserem Tracking-System zuzuordnen.Beispiele für Ursachen sind:schlechter Code, fehlender Code, unvollständige Anforderungen, fehlende Anforderungen, unvollständige Tests usw.Ich war kein Befürworter davon, da ich sehen konnte, dass dies zu unbeabsichtigtem Verhalten des Entwicklerteams führte.Bisher wurde dieses Feld vor Teammitgliedern verborgen und nicht aktiv genutzt.

Jetzt sind wir mitten in einem Projekt, in dem wir eine überdurchschnittlich hohe Anzahl von Fehlern haben und diese Art von Informationen wäre gut, um besser zu verstehen, wo wir Fehler gemacht haben und wo wir in Zukunft Verbesserungen vornehmen können (oder Anpassungen jetzt).Um gute Daten über die Ursache der Fehler zu erhalten, müssten wir dieses Feld für die Eingabe durch Entwickler- und QA-Teammitglieder öffnen, und ich mache mir Sorgen, dass dies zu schlechtem Verhalten führen wird.Zum Beispiel möchten Menschen möglicherweise einen Defekt, den sie nicht verursacht haben, nicht beheben, weil sie das Gefühl haben, dass er sich schlecht auf ihre Leistung auswirkt, oder Menschen könnten aus ähnlichen Gründen Zeit damit verschwenden, über die Klassifizierung eines Defekts zu streiten.

Hat jemand einen Mechanismus gefunden, um diese Art der Verfolgung durchzuführen, ohne schlechtes Verhalten zu verursachen?Ist es möglich, nützliche Daten von Teammitgliedern zu erwarten, wenn wir dem Team die Gründe für die Daten erklären (nicht um individuelle Leistungskennzahlen, sondern Projekterfolgskennzahlen zu ermitteln)?Gibt es einen anderen, besseren Weg, um so etwas zu tun (vielleicht eine Ad-hoc-Obduktion oder eine offene Diskussion über die Themen)?

Answer 1

Viele Versionskontrollpakete haben Dinge wie svn blame.Dies ist keine direkte Metrik zum Nachverfolgen eines Fehlers, aber sie kann Ihnen sagen, wer Änderungen an einer Version eingecheckt hat, die einen größeren Fehler enthält.

Es gibt auch Programme wie http://www.bugzilla.org/ das hilft, Dinge im Laufe der Zeit zu verfolgen.

Aber soweit es wirklich darum geht, herauszufinden, warum Fehler existieren, ja, es lohnt sich auf jeden Fall, einen Blick darauf zu werfen, obwohl ich keine Standardmetrik für das Sammeln dieser Informationen angeben kann.Es gibt eine Reihe von Gründen, warum ein System sehr fehlerhaft sein kann:

• Schlecht geschriebene Spezifikationen
• Überstürzte Zeitpläne
• Programmierung mit geringen Kenntnissen
• Schlechte Moral
• Fehlende Beta- oder QA-Tests
• Fehlende Vorbereitung der Software, so dass es überhaupt möglich ist, Beta- oder QA-Tests durchzuführen
• Schlechtes Verhältnis von Zeitaufwand für das Bereinigen von Fehlern zu Zeitaufwand für das Herausholen neuer Funktionen
• Schlechtes Verhältnis von Zeitaufwand für fehlerfreie Verbesserungen zu Funktionalität
• Ein überaus komplexes System, das leicht zu knacken ist
• Eine sich ändernde Umgebung, die außerhalb der Codebasis liegt, z. B. die Maschinenverwaltung
• Schuld für Fehler, die sich auf die Vergütung oder Beförderung von Programmierern auswirken

Das ist nur um ein paar zu nennen...Wenn zu viele Fehler ein großes Problem darstellen, müssen sich Management und leitende Programmierer sowie alle anderen Beteiligten am gesamten Prozess zusammensetzen und das Problem diskutieren.

Answer 2

Hohe Bugraten können ein Symptom für einen Zeitplan sein, der zu stürzt oder unflexibel ist.Umschalten auf einen Null-Defektansatz kann helfen.Beheben Sie alle Fehler, bevor Sie an einem neuen Code arbeiten.

Zuordnung von Gründen ist eine gute Technik, um zu sehen, ob Sie einen Problembereich haben.Typische Metriken, die ich gesehen und begegnet bin, ist ein sogar Split zwischen:

• Spezifikationsfehler (fehlt, standardmäßig usw.)
• Anwendungsfehler (Inccorrect-Code, fehlender Code, schlechte Daten usw.)
• Falsche Tests / kein Fehler (im Allgemeinen falsche Erwartungen oder Spezifikationen noch nicht implementiert)

Reviewing und Überprüfung der Fehlerursachen können nützlich sein.