Verfolgen Sie die Ursache von Fehlern?

Die beste Lösung, die ich dafür gesehen habe, ist das Bug-Tracking auf Unternehmensebene. Sie versuchen, die Grundursache des Fehlers zu ermitteln und zu ermitteln. Nicht die Person, sondern die eigentliche Ursache . Beispiele hierfür könnten sein:

• Hat sich nicht an die Codierungskonventionen gehalten
• Schlechte Codierungslogik
• Fix für einen anderen Fehler hat diesen Fehler behoben
• Fehler in Bibliotheken von Drittanbietern
• usw.

Schuldzuweisungen sind nicht sinnvoll, und selbst wenn, haben wir nicht viel Wert darauf gelegt. Jeder macht Fehler. Es ist wichtiger zu sehen, welche Fehler wiederholt werden, damit wir sie beheben können. Für die oben aufgeführten Hauptursachen könnten die Lösungen (in der Reihenfolge) sein:

• Erstellen Sie eine Konvention, die den Fehler verhindert, und erzwingen Sie ihn über Codeüberprüfungen
• Korrigieren Sie die Logik
• Setzen Sie Unit-Tests ein, um Regressionen zu verhindern
• Tauschen Sie eine Bibliothek eines Drittanbieters gegen eine weniger fehlerhafte ein
• usw.

+1 an ashes999 für die Konzentration auf die Grundursache , aber Charakterisierungen wie:

• Hat sich nicht an die Codierungskonventionen gehalten
• Schlechte Codierungslogik
• Fix für einen anderen Fehler hat diesen Fehler behoben
• Fehler in Bibliotheken von Drittanbietern

Neigen Sie dazu, so spezifisch zu sein, dass Sie mit der Zeit zu viele Kategorien haben, um hilfreich zu sein. Bei einigen Projekten (aber nicht allen) habe ich Fehler nach Phase kategorisiert - eine Art loser Begriff, um zu versuchen zu erfassen, wann in Ihrem Projektlebenszyklus der Fehler injiziert wurde.

Ein Dropdown-Feld zu haben, in dem Sie zwischen Anforderungen , Design , Code und Integration auswählen können, ist alles, was ich je gebraucht habe. Wenn Sie wirklich Hardcore sind, können Sie dies in 2 Teile aufteilen: Phase Injected und Phase Detected . Die Grundidee hier ist die Eindämmung der Fehlerphase – es gibt einige gute Beweise dafür, dass die Behebung umso teurer ist, je länger Sie brauchen, um einen Fehler zu finden. Beispielsweise ist ein Anforderungsfehler während der Arbeit an Ihren Anforderungen kostengünstig zu beheben, kann aber nach der Veröffentlichung Ihres Produkts viel kosten.

Selbst wenn Sie nicht alle ausgefallenen CMMI-Analysen der Ebene 5 durchführen, ist es äußerst hilfreich zu wissen, in welcher Phase Sie Probleme injizieren. Wie bei jeder anderen Messung sollten Sie sie mit einem bestimmten Ziel erstellen – in dem Wissen, dass die meisten Ihrer Fehler letztendlich mit Anforderungen oder Design oder Codierung oder was auch immer Ihre Aufmerksamkeit darauf lenken, wo die Prozesskorrektur liegen sollte, zusammenhängen. Andernfalls könnten Sie versucht sein, immer mehr Tests hinzuzufügen. Dies ist möglicherweise der am wenigsten effiziente Weg, um das Problem anzugehen.

Siehe auch:

• Untersuchen von Metriken zur Fehlereindämmung in Agile

Ich stimme zu, dass Schuldzuweisungen vermieden werden sollten, wenn Sie ein offenes Arbeitsumfeld wünschen. Sie sollten sich darauf konzentrieren, in welchem ​​Bereich es passiert ist und in welchem ​​​​Teil des Lebenszyklus es eingeführt wurde:

Gibt es Bereiche im Code, die ständig Fehler bekommen? Sind sie aufgrund von Überkomplexität besonders empfindlich gegenüber Änderungen? Sollten diese Bereiche mehr Unit-Tests und/oder ein strengeres Release-Management (oder sogar eine Neufassung) haben?

Werden am Ende des Projekts immer wieder Fehler eingeführt? Dies kann ein Indikator für zu viele späte Anforderungsänderungen sein. Fehlern, die gleichmäßig über die Hauptentwicklungsphase verteilt sind, kann geholfen werden, indem Peer-Code-Reviews durchgeführt werden.

Selbst wenn Probleme aufgrund einer Person auftreten, können Sie Probleme abmildern, ohne persönliche Probleme zu verursachen, indem Sie sich darauf konzentrieren, Gegenmaßnahmen zu dem hinzuzufügen, woran sie gerade arbeitet .

Ich glaube, dass die Verfolgung der Grundursache von Fehlern sehr wichtig ist, umso mehr, wenn sich herausstellt, dass die Grundursache etwas Systematisches wie ein Teil Ihres Entwicklungsprozesses ist.

Die Analyse zeigt beispielsweise, dass der Code, der sich mit der Integration einer Leistung eines ausgelagerten Unternehmens befasst, ständig fehlerhaft ist und die Hauptursache darin besteht, dass die Anforderungsspezifikationen nicht gut verstanden und kontrolliert wurden. Dies ist ein systematisches Problem und muss angegangen werden, damit zukünftige Auswirkungen minimiert werden.

Wir neigen dazu, die Grundursachen des Fehlers und den Bereich, in dem die Lösungen angewendet werden, zu verfolgen.

Denken Sie definitiv nicht, dass dies eine Übung zur Schuldzuweisung ist, sondern ein Prozess, der ein besseres Verständnis dafür ermöglicht, was die Hauptursachen für Probleme innerhalb des Projekts waren. Es ist Sache des Projektmanagers, innerhalb der Projektgrenzen eine Kultur der Nicht-Schuldzuweisung aufrechtzuerhalten.

Oder vielleicht ist dies nur eine vergebliche Übung in Statistik

Die Statistik wird die wesentlichen Problemfelder belegen. Dies hilft bei den Überprüfungen nach der Implementierung und zeigt auf, welche Lehren für zukünftige Projekte gezogen werden können oder sogar anderen derzeit laufenden Projekten zugute kommen.

Die Fehlerursache ist eine sehr wichtige Metrik. Ich nenne es im Allgemeinen als "Gelöst als" mit Werten: Code Fix, Environment Issue, External Entity, Bad Data, Design Gap etc.

Hier gibt es kein Schuldzuweisungsspiel, da nur der Teamleiter es kategorisieren darf. QA und Entwickler sollten nicht die Ursache festlegen.

Am Ende des Tages ist es nützlich zu wissen, dass die Umgebung 60 % der Probleme verursacht hat und dass fehlerhafte Daten in der Datenbank weitere 20 % verursachen, während nur 10 % mit Code zusammenhängen. Dadurch wissen wir, dass wir uns bei unserem nächsten Projekt mehr auf die Umgebung und den Einsatz konzentrieren müssen. Hinter den Kulissen kann es auch dabei helfen, den KPI genau zu messen.

Natürlich sollte "Schuld" nichts damit zu tun haben. Wir sind alle in ein äußerst komplexes menschliches Unterfangen verwickelt, und niemand sollte jemals „beschuldigt“ werden. Wir müssen uns weiterhin auf den Prozess konzentrieren, nicht auf die Menschen, die daran beteiligt sind. Das einzige Ziel sollte sein, zu lernen, wie man es besser macht – und das ist eigentlich ein sehr „situatives“ Ziel, kein allgemeines.

Es ist sehr nützlich, nachzuverfolgen, was unserer Meinung nach die Grundursache war und wo genau es im Prozess passiert sein könnte. (Siehe die „Eindämmung“-Antwort oben.) War es wirklich so, dass „jemand einen Fehler gemacht hat“, oder ist es tatsächlich ein Zeichen für etwas anderes? Es ist vielleicht kein 'ein Fehler!'