Was ist ein gesundes Verhältnis von [für Fehler aufgewendete Zeit]/[für das Projekt aufgewendete Gesamtzeit]?

Als Maß für die Softwarequalität haben wir das Verhältnis im Titel berechnet.

Der Wert dieses KPI sollte folgende Bedeutung haben:

  • 0 (0%) = keine Arbeit am Fehler, das bedeutet, dass die gesamte Zeit, die für das Projekt aufgewendet wurde, für neue Funktionen verwendet wurde, großartig!
  • 1 (100%) = nur an Fehlern arbeiten, dies könnte ein altes Projekt sein, in dem es keine neuen Funktionen gibt, sodass die gesamte Zeit, die für dieses Projekt aufgewendet wird, der Fehlerbehebung dient&testen;
  • 0,5 (50 %) = die Hälfte der Zeit wird für die Fehlerbehebung und das Testen aufgewendet, dies könnte in einem normalen Projekt ein Problem darstellen.

Die Frage ist also: Was könnte in einem normalen Projekt (nicht Legacy) ein gesunder Wert dieses KPI sein?

Jemand hat mir 33% gesagt, aber ich kann keine Literatur über diesen Wert finden.

Kontext abhängig. Hängt auch von automatisierten Tests und BDD ab. Meinen Sie entgangene Fehler in der Produktion oder meinen Sie Fehler vor der Veröffentlichung?
Ihre Metrik geht davon aus, dass Zeit, die nicht für Fehler aufgewendet wird, bedeutet, dass es keine Fehler gibt. Dies ist auf der Oberfläche fehlerhaft.
@Venture2099 beides, aber hauptsächlich Vorabversionen.
@CodeGnome, warum denkst du, dass es fehlerhaft ist? Ich weiß, es ist fast unmöglich, es ist nur ein Beispiel.
Ich denke, dies als KPI zu verwenden, wäre kontraproduktiv. Um in eine Position zu kommen, in der Bugs und schlechter Code Sie nicht zurückhalten, müssen Sie sie direkt angehen. Als KPI kann dies auf ein Problem hinweisen, aber es verhindert auch, dass es gelöst wird.
Spannende Frage. Die Antwort hängt auch von der Lebenszyklusphase und der Philosophie des Projekts ab. Werden neue Funktionen schrittweise hinzugefügt (wie bei Agile) oder handelt es sich um einen Wasserfall von Anforderungen? Ich stelle es mir so vor: In den ersten Tagen wird das Verhältnis 0,0 sein, keine Fehler; und wenn V&V beginnt, beginnt das Verhältnis zu steigen, vielleicht bis auf 1,0, und dann bleibt das Verhältnis dort, solange es keine neuen Änderungen oder Funktionsanfragen auf höherer Ebene gibt.
@greenkey: Ich kann die 0-Zeit-Metrik erreichen, indem ich einfach alle eingehenden Fehler ignoriere. Auf diese Weise bedeutet keine Zeit, die für die Behebung von Fehlern aufgewendet wird, nicht, dass es keine gibt. Nur dass niemand daran gearbeitet hat.

Antworten (1)

Dies hängt wirklich von der von Ihnen verwendeten Methodik, dem Fachwissen, der Erfahrung und der Strenge der Menschen ab, mit denen Sie zusammenarbeiten. Auch die Zeit, die Sie für die Entwicklung einplanen, spielt eine Rolle. Ich habe mit Leuten zusammengearbeitet, die dazu neigen, pünktlich zu liefern, auch wenn es nicht zu 100 % abgeschlossen ist.

Abgesehen davon kann ich mich auf diesen KPI beziehen, und basierend auf den wenigen Hundert kleinen Softwareentwicklungsprojekten, an denen ich beteiligt war, scheint diese 33-%-Metrik ziemlich hoch, aber plausibel zu sein. Wir versuchen, 15 % bis 20 % in meinem Team anzustreben, aber das ist erforderlich, um die Eigenverantwortung des Entwicklungsteams für ihre Projekte durchzusetzen.

Danke für die Antwort. Es scheint, dass es keine offiziellen Dokumente in der Literatur gibt, es ist eher etwas, das Sie überwachen und versuchen zu verringern.
Nun ... technisch nein. Ich möchte eine automatisierte Testabdeckung, um mehr Fehler vor der Produktion zu identifizieren. Das zeigt an, dass es funktioniert.
Was ist ein gesundes Verhältnis von [für Fehler aufgewendete Zeit]/[für das Projekt aufgewendete Gesamtzeit]?
AntwortenHierDatenschutz-Bestimmungen1y, 0v