Vorlage für das Framework zur Priorisierung technischer Schulden

TL; TR: Priorisierungskriterien

• Code-Kenntnis. Wie gut kennst du den Code?

• Schweregrad. Wie wirkt es sich auf die Funktionalität oder Performance der Software aus?

• Abhängigkeit und Umfang. Wie viele Komponenten hängen von diesem Teil des Codes ab? Der Umfang der betroffenen Software-Architektur.

• Kosten der Behebung. Wie viele Story Points würde es kosten, das Problem der technischen Schulden zu beheben?

Gesamtpunktzahl = (Kenntnis + Schweregrad + Abhängigkeit) – 3 * Kosten

Lies auch 5 Tipps zur Priorisierung technischer Schulden.

• TL; TR: Priorisierungskriterien
• Was sind technische Schulden?
• Beispiele für technische Schulden
• Das Problem technischer Schulden
• Kriterien zur Priorisierung technischer Schulden
  • Code-Kenntnis
  • Schweregrad
  • Abhängigkeit und Systemumfang
  • Kosten der Behebung
• Kriterienbeschreibungen anpassen
• Ungeeignete Kriterien für die Bewertung technischer Schulden
  • Nicht verwenden: Geschäftswert oder User Experience
  • Nicht verwenden: Auftreten
  • Nicht verwenden: Alter des Issues
• Berechnung der Prioritätspunktzahl für technische Schulden
• Issues für das Backlog technischer Schulden sammeln
  • Tipp 1. Erstelle einen dedizierten Bereich in deinem Task-Tracker
  • Tipp 2. Verwende ein einheitliches Format
  • Tipp 3. Gib eine klare Beschreibung an
  • Tipp 4: Verwende die Code-Änderungshäufigkeit zum Sammeln von aufgetretenen technischen Schulden
  • Tipp 5: Automatisches Scannen des Codes auf Langsamkeit und Schwachstellen
• Fazit

Was sind technische Schulden?

Technische Schulden sind ein metaphorischer Begriff in der Softwareentwicklung, der die zusätzliche Entwicklungsarbeit beschreibt, die entsteht, wenn Code gewählt wird, der kurzfristig einfach umzusetzen ist, anstelle robusterer oder skalierbarer Optionen, die länger dauern könnten. Er bezieht sich auf die Kosten von Abkürzungen oder Code, der nicht für langfristige Wartbarkeit, Erweiterbarkeit oder Zuverlässigkeit optimiert ist.

Beispiele für technische Schulden umfassen das Schreiben von Spaghetti-Code, der schwer zu lesen und zu verstehen ist, die Verwendung veralteter Bibliotheken oder Frameworks, die nicht mehr unterstützt werden, das Versäumnis, Code oder Tests zu dokumentieren, und das Vernachlässigen regelmäßiger Wartungs- oder Aktualisierungsarbeiten.

Beispiele für technische Schulden

Typische Issues technischer Schulden:

1. Verwendung veralteter oder veralteter Technologie: Die Nutzung alter oder nicht unterstützter Technologie kann zu Kompatibilitätsproblemen und Sicherheitslücken führen.

2. Schlechte Code-Qualität: Code, der schwer zu lesen, zu verstehen und zu warten ist, kann zu Bugs, verringerter Produktivität und erhöhtem Entwicklungsaufwand führen.

3. Fehlende Dokumentation: Das Versäumnis, Code, Prozesse und Anforderungen zu dokumentieren, kann es zukünftigen Entwicklern erschweren, die Software zu verstehen, was zu erhöhtem Entwicklungsaufwand und höheren Kosten führt.

4. Unzureichende Tests: Das Überspringen oder Verschieben von Tests kann zu unentdeckten Bugs, Sicherheitslücken und Unzufriedenheit der Nutzenden führen.

5. Mängel im Architekturdesign: Das Entwerfen von Software mit suboptimaler Architektur oder das Versäumnis, für Skalierbarkeit zu planen, kann zu technischen Schulden führen, da die Software im Laufe der Zeit komplexer und schwieriger zu warten wird.

Beispiele dafür, was NICHT als technische Schulden betrachtet wird:

1. Bewusstes Verschieben von Arbeit, die nicht kritisch für das Projekt ist oder später erledigt werden kann.

2. Informierte Entscheidungen, eine Abkürzung zu nehmen, um eine Deadline zu erfüllen oder schnell einen Prototyp zu liefern.

3. Bewusste Wahl einer weniger als optimalen Lösung, die für die Projektziele dennoch akzeptabel ist.

4. Entscheidung für eine bestimmte Technologie oder ein Tool trotz potenzieller Einschränkungen, basierend auf Kompromissen mit anderen Faktoren wie Zeit, Kosten und Geschäftsanforderungen.

5. Durchführung routinemäßiger Wartungsaufgaben, die die Software nicht wesentlich verbessern.

Das Problem technischer Schulden

Das Hauptproblem technischer Schulden besteht darin, dass sie sich im Laufe der Zeit ansammeln können, wodurch es schwieriger wird, neue Features hinzuzufügen, Bugs zu beheben oder die Codebasis zu warten.

• Features brauchen länger in der Entwicklung

• Mehr Bugs

Es ist immer ein Kompromiss zwischen der Verbesserung deines Codes und dem Hinzufügen neuer Features.

Kriterien zur Priorisierung technischer Schulden

Unter Berücksichtigung dieser Kriterien kannst du ein Priorisierungssystem erstellen, das dir hilft, technische Schulden in deinen Task-Tracker-Issues zu identifizieren und anzugehen, um den Geschäftswert zu maximieren und Risiken zu minimieren.

Füge gerne Kriterien hinzu, ändere oder formuliere den Kriteriumnamen und die Beschreibung um, damit dein Team sie besser versteht.

Für jedes Kriterium verwenden wir die Fibonacci-Sequenz als Bewertungsskala, da sie sich am besten für Story Point-Schätzungen eignet.

hi.ducalis.io Board mit den Kriterien zur Priorisierung technischer Schulden

Code-Kenntnis

Es geht um das Verständnis und die Vertrautheit eines Entwicklungsteams mit der Codebasis, an der es arbeitet. Dazu gehört die Fähigkeit, den Code zu verstehen und darin zu navigieren, sowie das Verständnis der Code-Struktur, Design-Patterns und Best Practices, die im Projekt verwendet werden.

Code-Kenntnis ist entscheidend für ein Entwicklungsteam, da sie sich direkt auf die Fähigkeit auswirkt, effizienten und qualitativ hochwertigen Code zu schreiben und zu warten. Teams mit mehr Code-Kenntnis können schneller und präziser arbeiten.

Kurz gesagt, Code-Kenntnis ist eine entscheidende Komponente der Fähigkeiten eines Entwicklungsteams und wirkt sich direkt auf die Qualität und Effizienz ihrer Arbeit aus.

• 1: Autor. Ich habe diesen Code-Abschnitt geschrieben – kann ihn warten und erklären.

• 2: Maintainer. Ich habe mit diesem Code gearbeitet – keine Fragen dazu, wie er funktioniert.

• 3: Erreichbar. Ich kann ein Teammitglied fragen und die Dokumentation dazu lesen.

• 5: Dokumentiert. Ich habe nicht daran gearbeitet. Wir haben etwas Dokumentation darüber.

• 8: Verständlich. Ich habe nicht daran gearbeitet, aber ich habe ohne großen Aufwand gelernt, wie es funktioniert.

• 13: Herausfordernd. Benötige erhebliche Zeit, um herauszufinden, wie es funktioniert. Ich habe nicht an diesem Code gearbeitet, aber ich kann jemanden erreichen, der daran gearbeitet hat, oder Dokumentation finden.

• 21: Noch nie davon gehört. Niemand in deinem Team kennt diesen Code, oder sie werden bald gehen.

Schweregrad

Der Schweregrad der Auswirkung: Bestimme, wie stark das technische Schulden-Issue die Funktionalität oder Performance der Software beeinträchtigt. Der Schweregrad der Auswirkung kann hoch, mittel oder niedrig sein, und dies kann als Kriterium für die Priorisierung verwendet werden.

• 1: Keine Auswirkung.

• 2: Kosmetisch: Geringe Auswirkung auf einige lokale Komponenten. Kann in der Zukunft angegangen werden, wenn Ressourcen und Zeit verfügbar sind.

• 3: Gering: Es funktioniert gut, aber wir können es verbessern. Kann in der Zukunft angegangen werden, wenn Ressourcen und Zeit verfügbar sind.

• 5: Verlangsamend: Verlangsamt die Produktivität, macht Code weniger wartbar oder verhindert das Hinzufügen neuer Features. Kann später angegangen werden, wenn Ressourcen es erlauben.

• 8: Blockierend. Blockiert weitere Verbesserungen oder Updates einer Komponente der Software. Sollte bald angegangen werden, um erhebliche Probleme zu verhindern.

• 13: Größer. Blockiert und beeinträchtigt fast mehrere Software-Komponenten. Schafft zusätzliche Risiken oder Verzögerungen für das Projekt.

• 21: Zerstörend. Macht die Software unbrauchbar oder schafft hohes Risiko, wenn sie ungelöst bleibt.

Abhängigkeit und Systemumfang

Wie viele Komponenten hängen von diesem Teil des Codes ab? Der Umfang der betroffenen Software-Architektur:

• 1: Trivial. Kann ignoriert werden, da es jederzeit zurückgezahlt werden kann.

• 2: Gering lokal. Ist in sich geschlossen in einer einzelnen Methode, Klasse oder Funktion. Kann SOLID-Prinzipien verletzen – keine wesentliche Auswirkung auf die Gesamtqualität der Software.

• 3: Moderat lokal: Betrifft mehrere Methoden, Klassen oder Funktionen. Kann auch schwieriger zu modifizieren sein, ohne unbeabsichtigte Folgen zu verursachen.

• 5: Global. In sich geschlossen in einer einzelnen Anwendung oder einem Service, beinhaltet aber SOLID-Verletzungen über Subsysteme hinweg in einem größeren System, die sich auf scheinbar unabhängige Bereiche ausbreiten. Kann auch eine Diskrepanz zwischen Abstraktionsebenen, Probleme bei Integrationspunkten und harte Kopplung umfassen. Diese Schulden wirken sich nicht auf Nutzer der Anwendung oder des Service aus, werden aber beim Modifizieren des Service selbst spürbar.

• 8: Größer global. Größere und weitreichendere Auswirkung auf die Qualität der Software. Kann mehrere Subsysteme umfassen und die gesamte Anwendung oder den Service beeinflussen. Kann auch schwieriger zu modifizieren sein, ohne unbeabsichtigte Folgen zu verursachen.

• 13: Systemisch. Verteilt sich über mehrere Anwendungen, Infrastrukturen oder Teams. Beinhaltet zahlreiche Services, die einen Datenspeicher teilen, hohe Kopplung über verschiedene begrenzte Kontexte hinweg und eine deutliche Diskrepanz zwischen technischen Implementierungen und Geschäftslogik. Systemische Schulden sind langfristig nicht tragbar und erfordern sofortige Aufmerksamkeit.

• 21: Kritisch. Stellt ein erhebliches Risiko für die Gesamtqualität der Software dar und kann die Stabilität und Zuverlässigkeit des Systems beeinträchtigen.

Kosten der Behebung

Wie viele Story Points würde es kosten, das technische Schulden-Issue zu beheben?

• 1: Kein Aufwand

• 2: Niedrige Kosten: 10% der Sprint-Dauer.

• 3: Moderat: 20% der Sprint-Dauer.

• 5: Erheblich: Halber Sprint

• 8: Hoch: Ein Sprint

• 13: Sehr hoch: Mehr als ein Sprint, aber weniger als zwei Sprints. Empfohlen, in mehrere Issues aufzuteilen.

• 21: Unerschwinglich teuer. Keine Idee, wie es momentan zu handhaben ist. Zwei Sprints und mehr.

Kriterienbeschreibungen anpassen

Vergiss nicht, dass die besten Kriterienbeschreibungen für deine Teammitglieder leichter zu verstehen sind. Je spezifischer Kriterien und Skalenbeschreibungen du hast – desto besser für deinen Priorisierungsprozess. Spezifiziere Sprint-Dauern, Erklärungen von Abhängigkeiten, Definitionen von Blockern und die Bedeutung von Code-Kenntnis. Lies mehr über die Bearbeitung von Kriterienbeschreibungen.

Kriterienbeschreibungen anpassen

Ungeeignete Kriterien für die Bewertung technischer Schulden

Geschäftswert, Auftreten, Alter und Auswirkung auf die User Experience sind unzuverlässige Kriterien für die Bewertung technischer Schulden.

Nicht verwenden: Geschäftswert oder User Experience

Faktoren wie Code-Qualität, Dokumentation, Test-Abdeckung und Software-Architektur korrelieren selten direkt mit Geschäftskennzahlen wie Umsatz. Diese Faktoren beeinflussen die Fähigkeit des Entwicklungsteams, effizient Änderungen vorzunehmen, sowie die Gesamtqualität, Zuverlässigkeit und Skalierbarkeit der Software.

Einer der häufigsten Gründe, technische Schulden nicht zu warten, ist deren Bewertung im potenziellen Umsatz.

Nicht verwenden: Auftreten

Berücksichtige die Wahrscheinlichkeit, dass das technische Schulden-Issue in der Zukunft erneut auftritt. Technische Schulden sind kein Bug, der erneut auftreten kann. Verschwende keine Zeit damit, die Zukunft vorherzusagen.

Nicht verwenden: Alter des Issues

Das mag wie eine offensichtliche und einfache Idee erscheinen, alte Bibliotheken früher zu refactoren. Aber warum solltest du Zeit darauf verwenden, wenn der Code gut funktioniert und nicht verlangsamt oder Schwachstellen schafft? Das Alter sollte nicht dein Priorisierungskriterium sein.

Berechnung der Prioritätspunktzahl für technische Schulden

Wie üblich müssen wir die Kriteriengewichte für die richtige Strategie zur Festlegung von Top-Priority-Issues für technische Schulden ausbalancieren. Standardmäßig haben wir Gewicht -2. Je weniger Entwicklungsressourcen du in deinem Team hast – desto negativer muss das Gewicht sein.

Setup des Gewichts für das Kriterium 'Kosten'

Die endgültige Formel ist ziemlich einfach:

Issues für das Backlog technischer Schulden sammeln

In „Essential Scrum: A Practical Guide to the Most Popular Agile Process" verwendet Autor Ken Ruben drei Kategorien zur Definition technischer Schulden: aufgetretene, bekannte und gezielte technische Schulden.

• Aufgetretene technische Schulden sind technische Schulden, von denen das Entwicklungsteam nicht wusste, dass sie existieren, bis sie während der routinemäßigen Produktnutzung oder Wartung aufgedeckt wurden. Zum Beispiel kann das Team beim Hinzufügen eines neuen Features zur Software einen Workaround entdecken, der vor Jahren zum Code hinzugefügt wurde und unverändert blieb, was zu unerwartetem Verhalten führt. Aufgetretene technische Schulden können auch durch „Bit Rot" verursacht werden, der auftritt, wenn Code im Laufe der Zeit verfällt und seine Funktion und Nutzbarkeit ändert.

• Auf der anderen Seite sind bekannte technische Schulden technische Schulden, über die das Entwicklungsteam bereits informiert ist und die es in der Software sehen kann. Beispiele für bekannte technische Schulden umfassen schlechte Code-Qualität, fehlende Dokumentation oder unzureichende Tests.

• Schließlich sind gezielte technische Schulden bekannte technische Schulden, die das Entwicklungsteam in einem bestimmten Sprint oder Release angehen möchte. Dies könnte die Überarbeitung von Code, die Verbesserung der Dokumentation oder die Erhöhung der Test-Abdeckung umfassen, um technische Schulden zu reduzieren und die Qualität der Software zu verbessern.

Durch das Verständnis der verschiedenen Arten technischer Schulden können Entwicklungsteams ihre Bemühungen priorisieren und daran arbeiten, technische Schulden anzugehen, um deren Auswirkungen auf die langfristige Wartbarkeit und Zuverlässigkeit der Software zu minimieren.

Tipp 1. Erstelle einen dedizierten Bereich in deinem Task-Tracker

Es ist wichtig, eine Eigenschaft zu haben, um technische Schulden-Issues von anderen Issues wie Bugs oder Features zu trennen. Verwende ein spezielles Tag/Label, Issue-Typ oder eine Komponente. Du solltest immer die Möglichkeit haben, das vollständige Backlog mit allen Issues anzusehen und es nach Typ zu filtern.

Tipp 2. Verwende ein einheitliches Format

Verwende ein einheitliches Format für die Protokollierung von technischen Schulden-Issues, wie eine User Story oder eine Aufgabe in deinem Backlog-Tool. Dies hilft dir, technische Schulden-Issues leicht zu identifizieren und zu priorisieren.

Tipp 3. Gib eine klare Beschreibung an

Gib eine klare Beschreibung des technischen Schulden-Issues an, einschließlich seiner Auswirkung auf die Codebasis, des geschätzten Aufwands zur Behebung und potenzieller Risiken oder Konsequenzen.

Tipp 4: Verwende die Code-Änderungshäufigkeit zum Sammeln von aufgetretenen technischen Schulden

Die Code-Änderungshäufigkeit gibt an, wie oft Änderungen an der Codebasis eines Softwaresystems vorgenommen werden.

Sie kann verwendet werden, um die Gesundheit und Qualität eines Softwareprojekts zu bewerten und potenzielle Probleme und Risiken zu identifizieren. Sie ermöglicht die Bewertung von Auswirkungen, die Identifizierung von Hochrisikobereichen und fundierte Entscheidungen über Änderungen an der Codebasis.

• Die hohe Häufigkeit kann auf häufige Updates, Verbesserungen, Instabilität oder Fehler hinweisen.

• Die niedrige Häufigkeit kann auf einen Mangel an Wartung oder Weiterentwicklung hinweisen, was zu technischen Schulden und anderen Problemen führt.

Sehr empfehlenswert ist es, Adam Tornhills Vortrag über diese Idee anzusehen: „

".

Tipp 5: Automatisches Scannen des Codes auf Langsamkeit und Schwachstellen

Es gibt viele Tools für Code-Analysen. Probiere sie aus und übertrage gefundene Issues in das Backlog deines Task-Trackers.

1. Code Scene — Ein Tool zur Visualisierung, zum Verständnis und zur Verbesserung deiner Software hinsichtlich Code, Wissen und den Menschen dahinter. Nimm Verbesserungen auf der Grundlage automatisierter, priorisierter und umsetzbarer Empfehlungen vor.

2. SonarQube: Ein beliebtes Tool, das Sicherheitslücken, Code Smells und andere Probleme in deinem Code erkennen kann. Es unterstützt verschiedene Programmiersprachen und integriert sich mit verschiedenen CI/CD-Tools.

3. OWASP ZAP: Ein Open-Source-Webanwendungs-Sicherheitsscanner, der Schwachstellen wie SQL-Injection, Cross-Site-Scripting und andere Sicherheitsprobleme erkennen kann.

4. CodeClimate: Eine Cloud-basierte Plattform, die deinen Code analysiert und Einblicke in dessen Qualität, Wartbarkeit und Sicherheit bietet. Sie unterstützt verschiedene Programmiersprachen und integriert sich mit GitHub, Bitbucket und anderen Tools.

5. Snyk: Ein Cloud-basiertes Tool, das deinen Code und Abhängigkeiten auf Sicherheitslücken scannt und Ratschläge zur Behebung bietet. Es unterstützt verschiedene Programmiersprachen und integriert sich mit verschiedenen CI/CD-Tools.

6. AppDynamics: Ein Tool, das Echtzeit-Einblicke in die Performance deiner Anwendungen bietet, einschließlich Antwortzeit, Fehlerrate und anderen Metriken. Es hilft dir, Performance-Engpässe zu identifizieren und deinen Code zu optimieren.

7. Qodana. Bewerte die Integrität des Codes, den du besitzt, vertraglich vereinbart oder kaufst. Bereichere deine CI/CD-Pipelines mit all den intelligenten Features, die du von JetBrains IDEs liebst.

Fazit

Technische Schulden sind in der Softwareentwicklung unvermeidlich, können aber auch ein erhebliches Hindernis für Fortschritt und Innovation darstellen. Durch die Entwicklung eines Systems zur Priorisierung technischer Schulden, das für dein Team funktioniert, kannst du deren Auswirkungen minimieren und die Qualität und Zuverlässigkeit deiner Software im Laufe der Zeit aufrechterhalten.

Denke daran, dass technische Schulden nicht nur ein Entwicklerproblem sind; sie betreffen die gesamte Organisation. Durch die Integration des Managements technischer Schulden in deine Projektmanagement-Prozesse kannst du sicherstellen, dass alle über deren Auswirkungen informiert sind und gemeinsam daran arbeiten, sie anzugehen.

Schließlich ist es wichtig zu bedenken, dass das Angehen technischer Schulden kein einmaliges Ereignis ist; es erfordert kontinuierliche Aufmerksamkeit und Bemühung. Durch regelmäßiges Überprüfen und Aktualisieren deines Backlogs technischer Schulden kannst du potenzielle Probleme im Blick behalten und sicherstellen, dass deine Software langfristig gesund und zuverlässig bleibt.

Lies weiter: 5 Tipps zur Priorisierung technischer Schulden