8 Kennzahlen zur technischen Verschuldung: Wie misst man die technische Verschuldung?

Messung der Technologieverschuldung

Mithilfe von Kennzahlen können Teams die Auswirkungen technischer Schulden auf Softwarequalität, Produktivität und Wartungskosten im Laufe der Zeit verfolgen, sodass sie fundierte Entscheidungen über Ressourcenallokation und Schuldenmanagementstrategien treffen können.

Verfolgen Sie technische Schulden mit Kennzahlen

Den Überblick über die technischen Schulden zu behalten, ist für die Aufrechterhaltung der Gesundheit und Nachhaltigkeit eines Softwareprojekts unerlässlich. Wie kann man das effektiv machen?

Hier sind einige effektive Strategien und Praktiken zur Verfolgung und Verwaltung technischer Schulden:

Dokumentation und Aufbewahrung von Aufzeichnungen

• Dokumentieren Sie technische Schulden: Wenn technische Schulden entstanden sind, dokumentieren Sie diese. Dazu gehören die Gründe für die Verschuldung, die erwarteten Auswirkungen und etwaige Abwicklungspläne.
• Führen Sie ein technisches Schuldenregister: Erstellen Sie ein zentrales Dokument oder Tool, in dem alle Fälle technischer Schulden aufgezeichnet und verfolgt werden. Dies sollte Details wie die Art der Schuld, den zugehörigen Code oder die Module sowie etwaige Fristen für die Behebung enthalten.

Code-Reviews und Analysen:

• Regelmäßige Code-Reviews: Implementieren Sie einen Prozess, bei dem der Code regelmäßig von Kollegen überprüft wird. Dies hilft bei der frühzeitigen Identifizierung potenzieller technischer Schulden.
• Tools zur statischen Codeanalyse: Verwenden Sie Tools, die den Code automatisch auf potenzielle Probleme wie Codegerüche, Komplexität, Duplizierung und andere Indikatoren für technische Probleme analysieren.

Integration mit Problemverfolgungssystemen:

• Schulden mit Problemen verknüpfen: Wenn technische Schulden zu Bugs oder Problemen führen, verknüpfen Sie diese in Ihrem Problemverfolgungssystem. Dadurch wird ein klarer Zusammenhang zwischen der Verschuldung und ihren Folgen hergestellt.
• Priorisieren Sie Schuldenprobleme: Stellen Sie sicher, dass technische Schuldenprobleme neben anderen Arbeitselementen in Ihrem Backlog priorisiert werden.

Test- und Abdeckungsmetriken:

• Überwachen Sie die Testabdeckung: Überprüfen Sie regelmäßig die Testabdeckungsmetriken, um sicherzustellen, dass Ihre Codebasis angemessen getestet wurde. Eine niedrige Testabdeckung kann ein Indikator für technische Schulden sein.
• Automatisiertes Testen: Implementieren Sie automatisierte Tests, um den Zustand Ihrer Codebasis kontinuierlich zu überwachen und Probleme frühzeitig zu erkennen.

Regelmäßige Refactoring-Sitzungen:

• Dedizierte Refactoring-Zeit: Ordnen Sie regelmäßige Zeitfenster für das Refactoring und die Bearbeitung technischer Schulden zu. Dadurch wird sichergestellt, dass Schulden aktiv zurückgezahlt werden.
• Refactoring as you go: Ermutigen Sie Entwickler, Code im Rahmen ihres regulären Entwicklungsprozesses zu überarbeiten und zu verbessern, und zwar nicht nur in speziellen Sitzungen.

Metriken und Dashboards:

• Verwenden Sie Metriken: Verfolgen Sie wichtige Kennzahlen wie Codeabwanderung, Komplexität und Fehlerraten, um einen quantitativen Überblick über Ihre technischen Schulden zu erhalten.
• Dashboards: Erstellen Sie Dashboards, die technische Schuldenkennzahlen visualisieren. Dies hilft dabei, den Zustand des Projekts schnell einzuschätzen und Bereiche zu identifizieren, die Aufmerksamkeit erfordern.

1. Fehlerquote

Die Fehlerquote ist ein Maß für die Anzahl der Fehler in einem Softwaresystem im Verhältnis zur Größe der Software.

Relevanz für technische Schulden

• Höhere Fehlerquote: Weist auf eine größere Anzahl von Fehlern im Verhältnis zur Größe der Software hin. Dies kann ein Zeichen für eine schlechte Codequalität sein, die häufig auf angehäufte technische Schulden zurückzuführen ist.
• Überwachung im Laufe der Zeit: Wenn die Fehlerquote im Laufe der Zeit zunimmt, könnte dies darauf hindeuten, dass die technische Verschuldung steigt, was zu mehr Fehlern pro Softwaregröße führt.
• Qualität gegen Schulden: Während eine hohe Fehlerquote direkt auf Qualitätsprobleme hindeutet, deutet sie indirekt auf technische Schulden hin. So können beispielsweise überstürzte Funktionen, fehlende Tests oder schlechte Designentscheidungen sowohl zu mehr Fehlern als auch zu mehr Schulden führen.
• Umsetzbare Erkenntnisse: Die Kenntnis der Fehlerquote kann Teams helfen, Refactoring zu priorisieren, Teststrategien zu verbessern oder Entwicklungspraktiken zu überarbeiten, um sowohl Fehler als auch technische Schulden zu reduzieren.
• Indikator für Softwarequalität: Eine hohe Fehlerquote deutet auf eine geringere Qualität hin, was auf angehäufte technische Schulden aufgrund von Problemen wie überstürzter Entwicklung oder schlechtem Design zurückzuführen sein könnte.
• Wartungs- und Refactoring-Anforderungen: Eine im Laufe der Zeit zunehmende Fehlerquote kann darauf hindeuten, dass die Software immer schwieriger zu warten ist, was auf die Notwendigkeit einer Überarbeitung und Behebung technischer Probleme hindeutet.
• Gesundheitsbewertung des Projekts: Es bietet einen schnellen Überblick über den aktuellen Stand des Projekts und hilft dabei zu beurteilen, ob sich technische Schulden negativ auf die Software auswirken.

Einschränkungen

• Nicht allumfassend: Die Fehlerquote allein erfasst nicht alle Aspekte technischer Schulden, wie z. B. architektonische Probleme oder Codekomplexität.
• Qualität der Fehlerberichterstattung: Die Genauigkeit der Kennzahl hängt von der Gründlichkeit und Konsistenz der Verfahren zur Meldung von Mängeln ab.
• Abhängig von einer genauen Messung: Die Effektivität dieser Metrik hängt davon ab, wie genau die Größe der Software und die Anzahl der Fehler gemessen werden.
• Erfasst nicht alle Aspekte technischer Schulden: Die Fehlerquote konzentriert sich auf Fehler und misst nicht direkt andere Aspekte technischer Schulden wie Codekomplexität oder Architekturprobleme.
• Variabilität des Schweregrads des Defekts: Nicht alle Fehler haben die gleichen Auswirkungen oder erfordern den gleichen Aufwand zur Behebung, was in diesem Verhältnis nicht berücksichtigt wird.

Wann sollte man es verwenden

• Regelmäßig während des gesamten Entwicklungsprozesses, insbesondere nach Hauptveröffentlichungen oder wenn Änderungen an der Codebasis vorgenommen werden.

Wie misst man

Zählen Sie die Gesamtzahl der Fehler (gemeldete Bugs oder Probleme) und dividieren Sie sie durch ein Maß für die Softwaregröße (wie Codezeilen, Funktionspunkte oder Module).

Fehlerquote = Größe der Software/Anzahl der Fehler

• Anzahl der Defekte ist die Gesamtzahl der in der Software gefundenen Fehler.
• Größe der Software könnte in verschiedenen Einheiten gemessen werden, z. B. in Codezeilen, Funktionspunkten oder der Anzahl der Module/Komponenten.

Wie es hilft

• Hilft dabei, die Qualität der Software im Laufe der Zeit zu verfolgen und zeigt an, ob technische Schulden zu einer Zunahme von Fehlern führen.
• Kann Entscheidungen darüber leiten, worauf die Entwicklungsbemühungen konzentriert werden sollten, insbesondere bei der Identifizierung von Bereichen der Codebasis, die möglicherweise überproportional zur Anzahl der Fehler beitragen.
• Hilft bei der Priorisierung technischer Strategien zur Schuldenreduzierung, insbesondere wenn sie mit anderen Metriken wie Codekomplexität oder Codeabwanderung korrelieren.

2. Codieren Sie Churn

Die Codeabwanderung bezieht sich auf den Prozentsatz des eigenen Codes eines Entwicklers, der nach dem Schreiben kürzlich bearbeitet (hinzugefügt, geändert, gelöscht) wurde.

Die Änderung des Codes kann auf Unentschlossenheit, mangelnde Klarheit oder Missverständnisse hinweisen — all dies trägt zur technischen Verschuldung bei. Eine hohe Codeabwanderung, insbesondere spät in einem Entwicklungszyklus, kann ein Warnsignal dafür sein, dass Code möglicherweise weniger zuverlässig oder schwieriger zu verwalten ist.

Relevanz für technische Schulden:

• Eine hohe Abwanderung kann auf instabile oder problematische Bereiche in der Codebasis hinweisen.
• Hilft bei der Identifizierung von Funktionen oder Modulen, die häufig geändert werden und zu einer Anhäufung von Schulden führen könnten.

Einschränkungen:

• Eine hohe Abwanderung ist nicht immer negativ; sie kann auf eine gesunde, iterative Entwicklung zurückzuführen sein.
• Misst die Codequalität nicht direkt.

Wann verwenden: Verwenden Sie diese Metrik während der Entwicklungsphase und nach der Veröffentlichung, um instabilen Code zu identifizieren.

So messen Sie: Berechnet den Prozentsatz der Codezeilen, die in einem bestimmten Zeitraum geändert, hinzugefügt oder gelöscht wurden.

Wie es hilft: Die Identifizierung von Bereichen mit häufigen Änderungen hilft dabei, instabilen Code zu lokalisieren und potenzielle zukünftige Probleme im Zusammenhang mit ständigen Änderungen zu verhindern.

Die Analyse der Codeabwanderung zusammen mit der Anzahl der Fehler kann Aufschluss darüber geben, ob die Abwanderung konstruktiv (Refaktorierung, Verbesserung des Codes) oder destruktiv (Einführung weiterer Fehler) ist.

Es hilft dabei, Bereiche für die Überarbeitung zu priorisieren und die Auswirkungen von Änderungen zu verstehen.

3. Technische Schuldenquote (TDR)

TDR ist ein Maß für die Kosten zur Behebung der technischen Schulden im Verhältnis zur Größe der Codebasis.

TDR bietet einen schnellen Überblick über die Qualität des produzierten Codes und hilft dabei, technische Schulden in wirtschaftlicher Hinsicht zu quantifizieren, sodass es einfacher ist, dem Management die Auswirkungen und die Notwendigkeit der Behebung technischer Schulden mitzuteilen.

Relevanz für technische Schulden:

• Bietet eine monetäre Perspektive auf die Auswirkungen technischer Schulden.
• Hilft bei der Priorisierung des Schuldenabbaus auf der Grundlage der Kosten.
• Ein höheres Verhältnis deutet darauf hin, dass ein erheblicher Teil der Entwicklungsanstrengungen in die Bekämpfung der technischen Schulden fließt.
• Kann verwendet werden, um Investitionen in den Abbau technischer Schulden zu rechtfertigen.

Einschränkungen:

• Die Schätzung der Kosten für die Behebung von Problemen kann subjektiv sein.
• Erfasst keine Aspekte technischer Schulden, die nichts mit dem Programmieren zu tun haben (z. B. architektonische Probleme).
• Spiegelt möglicherweise nicht die Auswirkungen nicht quantifizierbarer Schuldenaspekte wider.

Wann verwenden: Verwenden Sie TDR, um den allgemeinen Zustand der Codebasis zu bewerten und sowohl technischen als auch nichttechnischen Stakeholdern mitzuteilen.

So messen Sie: TDR = (Kosten für die Schuldenbehebung/Entwicklungskosten) * 100%.

Wie es hilft: Es bietet einen allgemeinen Überblick über die Codequalität und hilft dabei, Refactoring-Maßnahmen zu priorisieren, indem kritische Schuldenbereiche identifiziert werden.

Die regelmäßige Überwachung von TDR ermöglicht es den Teams, Trends zu beobachten und zu verstehen, ob sich ihre Codequalität und ihre technischen Schulden im Laufe der Zeit verbessern oder verschlechtern.

Es hilft bei der Entscheidungsfindung in Bezug auf die Zuweisung von Ressourcen für die Behebung von Problemen im Vergleich zu Neuentwicklungen.

Technische Messung der Schuldenquote — Fallstudie

Lassen Sie uns am Beispiel einer Fintech-App analysieren, wie die technische Schuldenquote gemessen wird.

In einer Fintech-App, in der Zuverlässigkeit, Sicherheit und Compliance von größter Bedeutung sind, ist die Messung und Verwaltung der technischen Schulden entscheidend für die Aufrechterhaltung des Vertrauens und der betrieblichen Integrität. Die technische Schuldenquote ist ein quantifizierbares Maß, um den Wartungsaufwand und die Ressourcenzuweisung zu steuern und sicherzustellen, dass die App robust, sicher und effizient bleibt.

Schritt 1: Identifizierung der Komponenten der Fintech-App

• Komponenten: Zahlungsabwicklungsmodul, Anlageportfoliomanager, persönliches Finanz-Dashboard, Benutzerauthentifizierung und Berichterstattung zur Einhaltung gesetzlicher Vorschriften.
• Geltungsbereich: Entscheiden Sie, welche Teile des Antrags auf technische Schulden geprüft werden sollen.

Schritt 2: Codeanalyse

• Werkzeuge: Verwenden Sie statische Codeanalysetools, die für die in der Fintech-App verwendeten Programmiersprachen und Frameworks geeignet sind (z. B. ESLint für JavaScript, SonarQube für eine Reihe von Sprachen).
• Beispielergebnisse: Im Anlageportfoliomanager gibt es möglicherweise komplexe Codesegmente mit schlechter Fehlerbehandlung und veralteten Bibliotheken, die aktualisiert werden müssen.

Schritt 3. Berechnung der Sanierungskosten

• Methode: Schätzen Sie die Zeit ab, die zur Behebung der identifizierten Codeprobleme erforderlich ist. Bedenken Sie die Komplexität der Fintech-Umgebung, für die möglicherweise spezielle Fähigkeiten erforderlich sind.
• Stundensatz: Gehen Sie von durchschnittlichen Kosten pro Entwicklerstunde aus, die für Fintech-Entwicklungskompetenz spezifisch sind (z. B. 80 USD/Stunde).
• Berechnung: Wenn es 15 Stunden dauert, den komplexen Code zu überarbeiten und die Bibliotheken im Anlageportfoliomanager zu aktualisieren, betragen die Kosten 15 Stunden * 80 $/Stunde = 1.200$.

Schritt 4. Berechnung der Entwicklungskosten

• Methode: Schätzen Sie die Gesamtkosten für die Entwicklung der App oder ihrer spezifischen Module, einschließlich Design, Programmierung, Testen, Bereitstellung und aller anderen Ausgaben.
• Beispiel: Die Entwicklungskosten des Anlageportfoliomanagers könnten 30.000 USD betragen.

Schritt 5: Berechnung der technischen Schuldenquote

• Formel: Technischer Schuldenstand = (Sanierungskosten/ Entwicklungskosten) * 100
• Berechnung: Für den Anlageportfoliomanager beträgt das Verhältnis (1.200 $/ 30.000 USD) * 100 = 4%.

Schritt 6. Interpretation und Aktion

• Interpretation: Eine technische Schuldenquote von 4% deutet auf einen moderaten Schuldenstand hin. Aufgrund der kritischen Natur von Finanzdaten und Transaktionen ist es wichtig, dies umgehend in einer Fintech-App zu beheben.
• Aktion: Priorisieren Sie die Behebung kritischer Probleme, insbesondere solcher im Zusammenhang mit Sicherheit, Datenintegrität und Einhaltung gesetzlicher Vorschriften.

4. Code-Duplikation

Diese Metrik gibt den Prozentsatz an dupliziertem Code in der Codebasis an.

Codeduplizierung führt häufig zu Wartungsproblemen. Wenn in einem duplizierten Code ein Fehler gefunden wird, muss er in allen Fällen behoben werden. Dies erhöht die Wahrscheinlichkeit übersehener Fehler und zukünftiger Probleme.

Relevanz für technische Schulden:

• Eine hohe Duplizierung weist auf eine schlechte Codequalität und höhere Wartungskosten hin.
• Verweist auf potenzielle Bereiche für die Wiederverwendung und Refaktorierung von Code.

Einschränkungen:

• Eine gewisse Vervielfältigung könnte notwendig oder beabsichtigt sein.
• Misst keine anderen Qualitätsaspekte wie die Codekomplexität.

Wann verwenden: Benutze es kontinuierlich, um sicherzustellen, dass die Codebasis TROCKEN bleibt (Don't Repeat Yourself).

So messen Sie: Analysieren Sie die Codebasis mithilfe statischer Codeanalysetools, um doppelte Codeblöcke zu identifizieren und zu quantifizieren.

Wie es hilft: Die Reduzierung der Codeduplizierung verbessert die Wartbarkeit und verringert die Wahrscheinlichkeit, dass bei Aktualisierungen Inkonsistenzen auftreten.

Durch die Verfolgung von Code-Duplikation im Laufe der Zeit und projektübergreifend können systemische Probleme in der Entwicklungspraxis aufgezeigt werden, die möglicherweise angegangen werden müssen.

5. Zyklomatische Komplexität

Es misst die Anzahl der linear unabhängigen Pfade durch den Quellcode eines Programms und gibt so die Komplexität des Codes an.

Eine hohe zyklomatische Komplexität deutet darauf hin, dass der Code möglicherweise schwieriger gründlich zu testen ist und anfälliger für Fehler ist. Er kann auch schwieriger zu lesen und zu verstehen sein, was die Wahrscheinlichkeit erhöht, dass bei zukünftigen Änderungen Fehler auftreten.

Relevanz für technische Schulden:

• Eine höhere Komplexität deutet oft auf schwieriger zu wartenden Code hin, was zu technischen Schulden führt.
• Kann Bereiche identifizieren, die überarbeitet werden müssen.
• Hilft bei der Abschätzung des für Tests und Wartung erforderlichen Aufwands.

Einschränkungen:

• Misst die Lesbarkeit oder Wartbarkeit von Code nicht direkt.
• Kann für bestimmte Codestrukturen irreführend sein.
• Ein gewisses Maß an Doppelarbeit kann in bestimmten Fällen unvermeidlich oder sogar vorzuziehen sein.
• Weist nicht auf andere Aspekte der Codequalität hin.

Wann verwenden:

‍Verwenden Sie diese Metrik, um komplexen Code zu identifizieren, der möglicherweise schwieriger zu verwalten und anfälliger für Fehler ist.

So messen Sie:

‍Verwenden Sie statische Analysetools, um die Anzahl der unabhängigen Pfade durch den Code zu berechnen.

Wie es hilft:

‍Das Management der Komplexität stellt sicher, dass der Code wartbar bleibt, und reduziert das Risiko, dass bei Änderungen Fehler auftreten.

Die Analyse der zyklomatischen Komplexität auf Methoden-, Klassen- und Modulebene kann helfen, bestimmte Bereiche zu identifizieren, die am meisten vom Refactoring profitieren könnten.

Die Metrik hilft Entwicklern, komplexen Code zu vereinfachen und so den zukünftigen Wartungsaufwand zu reduzieren.

6. Technischer Schuldenquadrant

Der Quadrant unterteilt technische Schulden in vier Typen: Rücksichtslos oder umsichtig und überlegt oder versehentlich.

Das Verständnis der Art und Herkunft technischer Schulden hilft den Teams, Strategien zu entwickeln, um sie zu bekämpfen und ähnliche Schulden in Zukunft möglicherweise zu verhindern. Es hilft auch dabei, fundierte Entscheidungen darüber zu treffen, wann vorsätzlich Schulden aufgenommen werden sollten.

Relevanz für technische Schulden:

• Hilft dabei, die Natur der technischen Schulden und die dahinter stehenden Gründe zu verstehen.
• Hilft bei der Entscheidung, wie mit verschiedenen Arten von technischen Schulden umgegangen werden soll.

Einschränkungen:

• Eher ein konzeptionelles Instrument; bietet keine quantitativen Maßnahmen.
• Erfordert ein subjektives Urteilsvermögen, um Schulden zu kategorisieren.

Wann verwenden: Verwenden Sie diese Kennzahl bei Projektrückblicken und bei der Planung, um die Art der technischen Schulden zu verstehen und zu kommunizieren.

So messen Sie: Ordnen Sie bestehende technische Verbindlichkeiten anhand von Rückblicken und Teamdiskussionen in die vier Quadranten ein.

Wie es hilft: Es hilft beim Verständnis der Herkunft von Schulden und informiert über Strategien zur Vorbeugung und Rückzahlung.

Eine regelmäßige Überprüfung und Neubewertung des technischen Schuldenquadranten trägt dazu bei, sicherzustellen, dass vorsätzliche und umsichtige Schuldverschreibungen im Laufe der Zeit nicht versehentlich leichtsinnig oder unbeabsichtigt werden.

Messung des technischen Schuldenquadranten — Beispiel

Rücksichtslos und überlegt (Quadrant I)

1. Beispiel: Das Entwicklungsteam beschließt, die Verschlüsselung von Daten bei der Übertragung zu umgehen, um die Bereitstellung einer neuen Online-Zahlungsfunktion zu beschleunigen.
2. Messung: Bewerten Sie die Anzahl und den Schweregrad potenzieller Sicherheitsverletzungen aufgrund unverschlüsselter Daten. Dies kann eine Risikobewertung beinhalten, um die potenziellen finanziellen Verluste und die Schädigung des Kundenvertrauens zu quantifizieren. Tools für Sicherheitstests können verwendet werden, um unverschlüsselte Datenübertragungen zu erkennen.

Rücksichtslos und unbeabsichtigt (Quadrant II)

1. Beispiel: Unerfahrene Entwickler implementieren eine Funktion für Kreditanträge, ohne dass sie SQL richtig verstehen, was zu ineffizienten Datenbankabfragen führt.
2. Messung: Führen Sie einen Code-Review durch, der sich auf Datenbankinteraktionen konzentriert. Verwenden Sie Tools zur Erstellung von Datenbankprofilen, um langsam ausgeführte Abfragen zu identifizieren und deren Auswirkungen auf die Gesamtsystemleistung zu messen. Ermitteln Sie die zusätzlichen Serverressourcen, die für die Bearbeitung dieser ineffizienten Abfragen erforderlich sind, sowie die Auswirkungen auf die Benutzererfahrung, z. B. langsame Antwortzeiten bei Aktualisierungen des Kreditstatus.

Umsichtig und überlegt (Quadrant III)

1. Beispiel: Wir haben ein älteres Framework für das Benutzerauthentifizierungssystem gewählt, weil das Team damit besser vertraut ist, auch wenn es möglicherweise an neueren Sicherheitsfunktionen mangelt.
2. Messung: Vergleichen Sie das aktuelle Framework mit neueren Alternativen in Bezug auf Funktionen und Sicherheitsverbesserungen. Schätzen Sie den Zeit- und Kostenaufwand für die Schulung des Teams in einem neuen Framework und den Aufwand ab, der für die zukünftige Migration des Authentifizierungssystems erforderlich ist. Wägen Sie dies gegen die unmittelbaren Produktivitätsgewinne ab, die sich aus der Verwendung eines vertrauten Frameworks ergeben.

Umsichtig und unbeabsichtigt (Quadrant IV)

1. Beispiel: Gestaltung der Seite mit dem Verlauf der Kundentransaktionen ohne Berücksichtigung des hohen Datenvolumens, das sich im Laufe der Jahre ansammeln würde und zu langsamen Seitenladezeiten führen würde.
2. Messung: Überwachen Sie die Seitenladezeiten und die Leistung der Datenbankabfragen, wenn das Datenvolumen wächst. Verwenden Sie Analysetools, um die Nutzerinteraktion und die Abbruchraten auf der Seite mit dem Transaktionsverlauf zu verfolgen. Schätzen Sie den Aufwand und die Kosten ab, die für das Refactoring der Seite erforderlich sind, um eine effiziente Datenverarbeitung und schnellere Ladezeiten zu gewährleisten.

Für jeden Quadranten besteht der Schlüssel darin, die unmittelbaren Bedürfnisse des Projekts mit langfristiger Nachhaltigkeit und Effizienz in Einklang zu bringen. Dazu gehören regelmäßige Code-Reviews, Leistungsüberwachung, Sicherheitsaudits und die Analyse des Benutzerfeedbacks. Durch die Quantifizierung der Auswirkungen technischer Schulden in diesen spezifischen Bereichen kann das Team fundierte Entscheidungen über die Priorisierung und Behandlung dieser Probleme im Zusammenhang mit dem Online-Banking-System treffen.

7. Öffnen Sie Bug Count and Age

Diese Metrik verfolgt die Anzahl der offenen Bugs und wie lange sie schon geöffnet sind.

Eine wachsende Zahl offener Bugs oder Bugs, die schon lange offen sind, kann darauf hindeuten, dass technische Schulden vernachlässigt werden. Dies kann zu einer Verschlechterung der Codebasis und der Benutzererfahrung führen.

Relevanz für technische Schulden:

• Eine hohe Anzahl oder seit langem bestehende Fehler können auf grundlegende Qualitätsprobleme hinweisen, die zur technischen Verschuldung beitragen.
• Nützlich für die Priorisierung von Bugfixes.
• Hilft bei der Priorisierung von Bugfixes und der Identifizierung verbesserungsbedürftiger Bereiche.

Einschränkungen:

• Der Schweregrad und die Auswirkungen von Bugs variieren; nicht alle Bugs tragen gleichermaßen zur technischen Verschuldung bei.
• Die Anzahl der Fehler allein gibt kein vollständiges Bild vom Zustand der Software.

Wann verwenden: Verwenden Sie diese Metrik kontinuierlich, um die Gesamtqualität und den Zustand der Anwendung zu überwachen.

So messen Sie: Verwenden Sie Tools zur Problemverfolgung, um die Anzahl der offenen Bugs zu zählen und deren Alter zu berechnen.

Wie es hilft: Wenn sichergestellt wird, dass Fehler rechtzeitig behoben werden, wird die Anhäufung defektbedingter technischer Schulden verhindert.

Die Analyse der Anzahl und des Alters von Fehlern zusammen mit Codeabwanderung und TDR kann einen umfassenderen Überblick über den Zustand der Codebasis und die Auswirkungen technischer Schulden bieten.

8. Testabdeckung

Die Testabdeckung gibt den Prozentsatz Ihrer Codebasis an, der durch automatisierte Tests getestet wurde.

Eine hohe Testabdeckung ist zwar keine Garantie für die Codequalität, eine unzureichende Testabdeckung kann jedoch bedeuten, dass die Codebasis nicht gut vor Regressionen geschützt ist, was es riskanter macht, technische Schulden durch Refactoring zu beheben.

Relevanz für technische Schulden:

• Eine hohe Testabdeckung kann die Wahrscheinlichkeit von Fehlern und technischen Schulden verringern.
• Zeigt die Robustheit der Testpraktiken an.
• Eine geringe Testabdeckung kann zu unentdeckten Fehlern führen und die technische Verschuldung erhöhen.
• Eine hohe Abdeckung trägt dazu bei, dass Codeänderungen nicht zu neuen Problemen führen.

Einschränkungen:

• Eine hohe Abdeckung garantiert keine qualitativ hochwertigen Tests oder Codes.
• Kann zu einem falschen Sicherheitsgefühl führen, wenn die Tests nicht gut konzipiert sind.

Wann verwenden: Verwenden Sie diese Metrik kontinuierlich, um sicherzustellen, dass die Codebasis angemessen getestet wird.

So messen Sie: Verwenden Sie Testtools und Frameworks, um den Prozentsatz des während des Tests ausgeführten Codes zu berechnen.

Wie es hilft: Die Aufrechterhaltung einer angemessenen Testabdeckung stellt sicher, dass die Codebasis robust ist, und ermöglicht eine sicherere Refaktorierung und Funktionsentwicklung.

Die Beobachtung der Testabdeckung zusammen mit den Bug-Discovery-Raten kann Teams dabei helfen, zu verstehen, ob ihre Tests wirksam sind und wo zusätzliche Tests von Vorteil sein können.

9. Zeit bis zur Markteinführung (TTM)

TTM ist die Zeit, die für die Entwicklung und Bereitstellung einer Funktion oder eines Produkts von der Konzeption bis zum Kunden benötigt wird.

Wenn TTM steigt, könnte das darauf hindeuten, dass technische Schulden die Feature-Entwicklung verlangsamen. Dies kann die Fähigkeit des Unternehmens beeinträchtigen, im Wettbewerb zu bestehen und auf Marktanforderungen zu reagieren.

Interpretation und Relevanz für technische Schulden:

• Eine längere Markteinführungszeit kann auf Ineffizienzen und potenzielle technische Schulden hindeuten.
• Das Streben nach einer kürzeren Markteinführungszeit kann manchmal dazu führen, dass mehr technische Schulden entstehen.

Einschränkungen:

• Die Markteinführungszeit wird von vielen Faktoren beeinflusst, nicht nur von technischen Schulden.
• Eine kurze Markteinführungszeit ist nicht immer positiv, insbesondere wenn sie zu einer geringeren Qualität führt.

Wann verwenden: Verwenden Sie diese Metrik, um die Auswirkungen technischer Schulden auf die Geschwindigkeit der Feature-Entwicklung zu beurteilen.

So messen Sie: Messen Sie die Dauer zwischen dem Zeitpunkt, an dem eine Funktion geplant ist, bis zu dem Zeitpunkt, an dem sie Benutzern zur Verfügung steht.

Wie es hilft: Die Überwachung von TTM hilft zu verstehen, wie sich technische Schulden auf die Fähigkeit des Teams auswirken, Funktionen zeitnah bereitzustellen.

Die Analyse von TTM zusammen mit anderen Metriken wie Codeabwanderung und Anzahl offener Fehler kann Aufschluss darüber geben, ob der Anstieg des TTM auf technische Schulden oder andere Faktoren zurückzuführen ist.

10. Vorlaufzeit

Misst die Zeit von der Konzeption einer neuen Funktion oder eines neuen Produkts bis zu seiner Fertigstellung.

Interpretation und Relevanz für technische Schulden:

• Längere Lieferzeiten können ein Symptom für eine hohe technische Verschuldung sein, da bestehende Probleme die Neuentwicklung verlangsamen.
• Hilft bei der Identifizierung von Engpässen im Entwicklungsprozess.

Einschränkungen:

• Beeinflusst von vielen Faktoren, die über die technische Verschuldung hinausgehen, wie Teamgröße und Ressourcenzuweisung.
• Nicht alle Verzögerungen sind auf technische Schulden zurückzuführen.

Wann sollte man es verwenden: Zur Prozessverbesserung und Identifizierung von Bereichen, in denen technische Schulden den Fortschritt behindern.

Wie misst man: Erfassung der Zeit von der ersten Idee oder Anfrage bis zur endgültigen Lieferung des Produkts oder der Funktion.

Wie es hilft: Zeigt Bereiche auf, in denen der Abbau technischer Schulden die Entwicklung beschleunigen könnte.

11. Schuldenindex

Eine zusammengesetzte Kennzahl, die verschiedene Indikatoren für technische Schulden in einem einzigen Index kombiniert.

Interpretation und Relevanz für technische Schulden:

• Bietet einen ganzheitlichen Überblick über die technischen Schulden im Projekt.
• Kann verwendet werden, um Änderungen der technischen Schulden im Laufe der Zeit zu verfolgen.

Einschränkungen:

• Die Konstruktion des Index kann subjektiv sein, je nachdem, welche Metriken enthalten sind.
• Kann komplexe Aspekte der technischen Verschuldung zu stark vereinfachen.

Wann sollte man es verwenden: Zur allgemeinen Bewertung und Verfolgung der technischen Schuldenentwicklung.

Wie misst man: Kombination verschiedener technischer Schuldenkennzahlen (wie Codekomplexität, Anzahl von Fehlern usw.) in einem einzigen Index.

Wie es hilft: Bietet einen allgemeinen Überblick über technische Schulden, der für das Management und die Kommunikation mit Stakeholdern nützlich ist.

12. Veränderte Ausfallrate

Misst den Prozentsatz der Änderungen (z. B. Bereitstellungen oder Code-Commits), die fehlschlagen und eine sofortige Korrektur erfordern (z. B. ein Hotfix oder Rollback).

Interpretation und Relevanz für technische Schulden:

• Eine hohe Änderungsfehlerrate kann auf eine schlechte Codequalität oder unzureichende Tests hinweisen, was zu technischen Schulden führt.
• Hilft dabei, die Stabilität und Zuverlässigkeit der Entwicklungs- und Bereitstellungsprozesse zu ermitteln.

Einschränkungen:

• Einige Ausfälle sind normal und deuten nicht auf technische Schulden hin.
• Erfasst nicht die zugrunde liegenden Ursachen der Ausfälle.

Wann sollte man es verwenden: Um die Zuverlässigkeit der Entwicklungs- und Bereitstellungspipeline zu bewerten.

Wie misst man: Verfolgung der Erfolgs- und Ausfallraten von Bereitstellungen und Codeänderungen.

Wie es hilft: Weist auf Bereiche hin, in denen Verbesserungen der Codequalität und des Testens die technische Verschuldung reduzieren können.

13. Anzahl der fehlgeschlagenen CI/CD-Ereignisse

Zählt, wie oft Continuous Integration (CI) oder Continuous Deployment (CD) -Prozesse fehlschlagen.

Interpretation und Relevanz für technische Schulden:

• Häufige CI/CD-Fehler können auf grundlegende Probleme bei der Codequalität, beim Testen oder beim Build-Prozess hinweisen, was zu technischen Schulden führt.
• Hilft bei der Identifizierung der Zuverlässigkeit und Effizienz automatisierter Prozesse.

Einschränkungen:

• Einige Ausfälle könnten auf externe Faktoren zurückzuführen sein, die nichts mit technischen Schulden zu tun haben.
• Bietet keine Einblicke in die Art der Probleme, die die Ausfälle verursacht haben.

Wann sollte man es verwenden: Zur Überwachung und Verbesserung der Effektivität von CI/CD-Pipelines.

Wie misst man: Verfolgung der Häufigkeit und der Ursachen von Fehlern in CI/CD-Prozessen.

14. Neue Bugs im Vergleich zu geschlossenen Bugs

Diese Metrik erfasst die Anzahl der gemeldeten neuen Bugs im Vergleich zur Anzahl der Bugs, die in einem bestimmten Zeitraum behoben oder geschlossen wurden.

Interpretation und Relevanz für technische Schulden

1. Balance zwischen Bug-Erstellung und -Behebung: Eine hohe Anzahl neuer Bugs im Vergleich zu geschlossenen Bugs könnte auf eine zunehmende technische Verschuldung hindeuten, da dies darauf hindeutet, dass Probleme schneller eingeführt als behoben werden.
2. Stabilität der Software: Ein plötzlicher Anstieg neuer Bugs könnte auf Probleme hinweisen, die in den letzten Updates eingeführt wurden. Dies ist auf die Auswirkungen überstürzter Entwicklung oder unzureichender Tests zurückzuführen, die beide zu technischen Schulden führen können.

3. Gesundheitsüberwachung des Projekts: Der regelmäßige Vergleich neuer und geschlossener Bugs kann helfen, den Zustand und den Fortschritt eines Projekts zu beurteilen. Ein Projekt mit sinkender technischer Verschuldung sollte idealerweise einen Trend zur Abnahme neuer Bugs oder zu einer steigenden Rate an Bugschließungen aufweisen.
4. Priorisierung und Ressourcenzuweisung: Diese Kennzahl kann dazu beitragen, die Behebung von Fehlern zu priorisieren und Ressourcen effektiv zuzuweisen, was für die Verwaltung und Reduzierung der technischen Schulden von entscheidender Bedeutung ist.

Einschränkungen

1. Nicht alle Bugs sind gleich: Diese Metrik berücksichtigt nicht den Schweregrad oder die Komplexität der Fehler. Daher könnten die Rohzahlen ohne den Kontext der Auswirkungen des Fehlers irreführend sein.
2. Qualität der Fehlerberichterstattung: Die Zuverlässigkeit dieser Metrik hängt von der Konsistenz und Qualität der Verfahren zur Fehlerberichterstattung ab. Eine inkonsistente Berichterstattung kann die Daten verzerren.
3. Spiegelt nicht die zugrunde liegenden Ursachen wider: Diese Kennzahl kann zwar potenzielle Probleme signalisieren, weist jedoch nicht direkt auf die Ursachen technischer Schulden hin.

Wann sollte man es verwenden

• Verwenden Sie diese Metrik regelmäßig als Teil des Softwareentwicklungszyklus, um die Häufigkeit des Auftretens und der Behebung von Fehlern zu überwachen. Dies kann ein indirekter Indikator für die Qualität des Codes und die potenzielle Anhäufung technischer Schulden sein.

Wie misst man

• Verfolgen Sie in regelmäßigen Abständen (z. B. wöchentlich, monatlich) die Anzahl der gemeldeten und geschlossenen Bugs in Ihrer Issue-Tracking- oder Projektmanagement-Software.

Wie es hilft

• Hilft beim Verständnis der Dynamik des Auftretens und der Behebung von Fehlern in einem Projekt.
• Kann signalisieren, wann technische Schulden zunehmen könnten, was die Aufmerksamkeit auf Bereiche der Codebasis erfordert, die neue Fehler generieren.
• Hilft bei der Ressourcenplanung für Fehlerbehebungen und technische Schuldenreduzierung.

Wie man eine Reihe von technischen Schuldenkennzahlen zusammenstellt

Schauen wir uns einige Beispiele an, die zeigen, auf welche Faktoren Sie bei der Erstellung einer Reihe von Kennzahlen für technische Schulden für einen bestimmten Fall achten sollten:

Ein Startup in der Frühphase baut ein MVP (Minimum Viable Product) auf

1. Kennzahlen, auf die Sie sich konzentrieren sollten: Codeabwanderung, Testabdeckung, Markteinführungszeit (TTM).
2. Argumentation: Startups müssen schnell handeln und Produkte schnell liefern. Eine hohe Code-Abwanderung könnte auf eine schnelle Iteration hindeuten, was bei Startups üblich ist. Die Testabdeckung ist wichtig, um die Qualität ohne umfangreiche manuelle Tests aufrechtzuerhalten. TTM ist entscheidend, um zu verstehen, wie schnell sich das Produkt weiterentwickelt.

Etabliertes Fintech-Unternehmen mit komplexer Software

1. Kennzahlen, auf die Sie sich konzentrieren sollten: Technischer Schuldenstand, zyklomatische Komplexität, Anzahl offener Fehler und Alter.
2. Argumentation: Für eine komplexe und etablierte Codebasis ist es wichtig, die technische Schuldenquote zu überwachen, um die finanziellen Auswirkungen zu verstehen. Cyclomatic Complexity hilft bei der Verwaltung der Wartbarkeit und Testbarkeit von Code, was bei Fintechs für Sicherheit und Zuverlässigkeit von entscheidender Bedeutung ist. Die Erfassung der Anzahl und des Alters offener Fehler ist entscheidend, um sicherzustellen, dass die Software zuverlässig und vertrauenswürdig bleibt.

<span class="colorbox1" fs-test-element="box1"><p>Benötigen Sie Hilfe bei der Bewertung und Rückzahlung Ihrer technischen Schulden? Schau dir das an Ranking der besten Fintech-Softwareentwicklungsunternehmen, die Erfahrung im Umgang mit technischen Schulden und Herausforderungen bei der Modernisierung von Altsystemen haben.</p></span>

Software für das Gesundheitswesen, die eine hohe Konformität erfordert

1. Kennzahlen, auf die Sie sich konzentrieren sollten: Codeduplizierung, Testabdeckung, Quadrant für technische Schulden.
2. Argumentation: Software für das Gesundheitswesen erfordert eine hohe Genauigkeit und Zuverlässigkeit. Die Codeduplizierung muss gering sein, um Fehler und Inkonsistenzen zu reduzieren. Eine hohe Testabdeckung ist entscheidend, um sicherzustellen, dass alle Funktionen getestet werden und den Gesundheitsvorschriften entsprechen. Das Verständnis des Quadranten für technische Schulden hilft dabei, fundierte Entscheidungen zur Bewältigung technischer Schulden zu treffen und gleichzeitig die Vorschriften einzuhalten.

E-Commerce-Plattform

1. Metriken: Codeabwanderung, technische Schuldenquote, Anzahl offener Bugs und Alter.
2. Begründung: E-Commerce-Plattformen erfordern eine schnelle, iterative Entwicklung (daher Code Churn), müssen die finanziellen Auswirkungen technischer Schulden bewältigen (Technical Debt Ratio) und eine hohe Verfügbarkeit und Zuverlässigkeit gewährleisten (Open Bug Count and Age).

Gaming-Entwicklungsunternehmen

1. Metriken: Zyklomatische Komplexität, Testabdeckung, Markteinführungszeit.
2. Begründung: Die Spieleentwicklung beinhaltet komplexe Logik und Grafiken (Cyclomatic Complexity), erfordert gründliche Tests für eine reibungslose Benutzererfahrung (Test Coverage) und muss die Marktfristen (Time to Market) einhalten.

Software für Bildungstechnologie (EdTech)

1. Metriken: Codeduplizierung, Quadrant für technische Schulden, Testabdeckung.
2. Begründung: EdTech-Software skaliert oft schnell und erfordert wartbaren Code mit minimaler Duplizierung (Code Duplication), einen strategischen Ansatz zur Bewältigung technischer Schulden (Technical Debt Quadrant) und die Sicherstellung der Funktionalität durch gründliche Tests (Test Coverage).

ERP-Software (Enterprise Resource Planning)

1. Metriken: Technischer Schuldenstand, Codeduplikation, Technischer Schuldenquadrant.
2. Begründung: ERP-Systeme sind groß und komplex, und die finanziellen Auswirkungen der technischen Schulden sind erheblich (technische Schuldenquote). Die Reduzierung der Codeduplizierung verbessert die Effizienz und Wartbarkeit (Codeduplizierung). Das Verständnis der Art der technischen Schulden mithilfe des Quadranten für technische Schulden hilft dabei, diese effektiv zu verwalten, ohne die vielfältigen Funktionen der ERP-Software zu beeinträchtigen.

Fangen Sie an, technische Schulden zu messen

Jede dieser Kennzahlen bietet eine andere Perspektive, um technische Schulden zu betrachten. Zusammen bieten sie einen umfassenden Überblick über den Zustand der Codebasis und die Auswirkungen der technischen Schulden auf das Team und das Produkt. Es ist wichtig, diese Kennzahlen ganzheitlich und im Kontext miteinander zu analysieren, um effektive Strategien für den Umgang mit technischen Schulden zu entwickeln.