Berechnen Sie die Kosten für fehlerhaften Code

Ich suche nach Argumenten, um das Management davon zu überzeugen, Anstrengungen in das Refactoring zu investieren.

Wir protokollieren die Arbeit mit Jira und verknüpfen jedes SVN-Commit mit einem Jira-Aufruf.

Meine Idee ist Folgendes:

• Manuelles Erkennen eines Codebereichs, der extrem schlecht implementiert, aber häufig verwendet wird: sowohl von User-POV als auch von Developer-POV (Bugfixes)
• Holen Sie sich die SVN-Commits, die die JIRA-Issues enthalten
• filtern sie die probleme nach bestimmten kriterien (problemtyp, version, prio etc ...)
• Berechnen Sie die Zeit / den Aufwand für diese Fehler
• den Aufwand und die Risiken eines Refactorings abschätzen
• Präsentieren Sie die Zahlen und bitten Sie um Mühe, um es zu beheben.

Was denkst du über dies? Wäre eine solche Messung sinnvoll und / oder überzeugend? Was sind die Vor- und Nachteile?

Ich habe festgestellt, dass Manager eher handeln, wenn Sie gültige Zahlen angeben können. (Wenn sie die Logik und die Kosten / Nutzen verstehen können.)

IMHO, um einen überzeugenden Fall zu machen, müssten Sie Folgendes zeigen, wie schlimm es ist:

• Anzahl der für die Probleme protokollierten Supportvorfälle
• Zeitaufwand in Stunden, um fehlerhaften Code zu pflegen / zu helfen / Support-Korrekturen durchzuführen
• Zeitaufwand basierend auf dem Stundensatz der Personen, die die Wartung / Pflaster / Unterstützung durchführen
• eine Möglichkeit zu demonstrieren, wie wichtig diese Elemente für das Unternehmen sind

Und um das Refactoring zu vereinfachen, benötigen Sie:

• Zeitvoranschlag für die Umgestaltung und Implementierung der Top 3 dieser schlechten Dinge
• Kostenvoranschlag für die Implementierung (gleiche Stundensätze wie oben verwendet)

Mit diesen können Sie die Zeitersparnis begründen, wenn das Refactoring viel weniger Zeit in Anspruch nimmt als die Supportzeit für 3 Incidents für jedes dieser Top-3-Elemente. Sie können argumentieren, dass diese kürzere Zeit aufgewendet wird

• weniger als n mehr Support-Vorfälle
• Für diese Dinge wird es keine Zwischenfälle mehr geben (NOCH BESSER!)

Der schwierigste Teil dieses Verkaufs wird jedoch die Beantwortung der folgenden Frage sein, da viele Leute für die gesamte Unterstützung, die Sie leisten, keine Zeit in Zeitplänen einplanen:

Wie lange muss ich warten, bis das aktuelle Projekt Y abgeschlossen ist, während Sie mit X ????? (Trotz der aktuellen Support-Zeitsenken, die in Gantt-Diagrammen nicht vorhergesagt und geplant werden können)

Dies hängt stark davon ab, wie gut Sie mit den Entscheidungsträgern kommunizieren und wie sie die Situation verstehen.

Ich denke auf jeden Fall, dass es sich lohnt, dies zu tun, damit Sie die Praxis erlernen, den Fall mit den Metriken zu erstellen und sich Zeit zu sparen, auch wenn sie es nicht anstreben. Leider ist trotz der Daten nicht jeder leicht zu überzeugen. VIEL GLÜCK!

Denken Sie daran, dass das Refactoring auch Fehler enthält (die Sie bei Ihren Tests bemerken werden, die aber dennoch Fehler sind und die behoben werden müssen). Netscape nicht aus Versehen ziehen. Dies hängt von Ihrer persönlichen Definition von "Refactoring" ab. Für einige bedeutet dies "den gesamten Code umschreiben" für andere "einige Interna ändern". Wie kannst du sagen, welche Art du bist? Stellen Sie sich folgende Frage:

Ändere ich überhaupt die öffentliche Schnittstelle?

Wenn die Antwort "Ja" lautet, führen Sie eine Neugestaltung durch. Wenn die Antwort "Nein" lautet, führen Sie gerade ein Refactoring durch und können dies wahrscheinlich im Verlauf Ihrer täglichen Aktivitäten ohne besondere Genehmigung tun. Dies ist für Ihre Frage relevant, da ein Redesign viel mehr Fehler generiert, während ein Refactoring in der Regel einfacher durchzuführen ist (da Ihre Tests bereits die öffentliche Schnittstelle verwenden und selbst nicht geändert werden müssen).

Es ist ein schwieriger Fall, da niemand weiß, wie viel X mit oder ohne den Refaktor gekostet hätte, der vor einem Jahr durchgeführt wurde. Nach meiner Erfahrung schießen die pragmatischen Manager solche Dinge immer ab, weil:

1. Keine direkte Einnahmequelle ergibt sich aus dem Aufwand (finanzielle Kosten, nicht abrechenbar)
2. Hässlicher Arbeitscode funktioniert immer noch, Sie riskieren, Probleme zu verursachen, anstatt sie zu beheben (potenzielle Qualitätskosten)
3. Andere Projekte werden verzögert, während Sie umgestalten (Zeitaufwand)

Alle diese Zahlen sind auf Vermutungen basieren letztlich, in Ihrem Fall einen Vergleich der Betrag , den Sie es erraten kosten würde , nicht zu refactor vs. was Sie erraten es kosten würde , zu Refactoring. Das Beste, was Sie tun können, ist zu zeigen, dass Sie eine Art numerische, sachliche Grundlage für die Vermutungen haben, und Sie haben eine ziemlich gute.

Die Profis sind, dass es wahrscheinlich effektiv sein wird, sie davon zu überzeugen, sich umgestalten zu lassen, und es könnte gut gehen und die Anzahl von Fehlern reduzieren.

Die Nachteile sind, dass wenn die Zeit, die für das Beheben von Fehlern aufgewendet wird, nicht mindestens so viel sinkt wie die Zeit, die für das Refactoring aufgewendet wird, Sie wahrscheinlich nicht mehr refactern dürfen und Sie wahrscheinlich für die "verschwendete" Zeit verantwortlich gemacht werden .

Die Zeitersparnis beim Debuggen, die durch die Reduzierung der Komplexität des Gesamtprojekts oder durch die Vereinfachung des Hinzufügens von Funktionen erzielt wird, ist möglicherweise zu schwer zu messen, um Ihnen viel zu helfen. Sie können jedoch auch erwähnen, dass diese vorhanden sind.