- Konzept der technischen Schulden
- die impliziten Kosten künftiger Nacharbeit, die entstehen, wenn man statt eines besseren, aber zeitaufwendigeren Ansatzes eine einfache, jedoch eingeschränkte Lösung wählt
- die Kosten zusätzlicher Arbeit, die dadurch entstehen, dass man sich für die schnellste statt für die effektivste Lösung entscheidet
- Arten technischer Schulden nach der Unterscheidung des Softwareingenieurs Martin Fowler
- überlegte und bewusste technische Schulden (Prudent & Deliberate)
- Das Team weiß, dass es Schulden aufnimmt, und wägt ab, ob „der Nutzen einer schnelleren Veröffentlichung größer ist als die Kosten der Schuldentilgung“
- unüberlegte, aber bewusste technische Schulden (Reckless & Deliberate)
- das Ergebnis der Entscheidung, „schnell und schmutzig“ vorzugehen, obwohl man gute Designpraktiken kennt und umsetzen könnte, aber keine Zeit hat, sauberen Code zu schreiben
- überlegte, aber unbeabsichtigte technische Schulden (Prudent & Inadvertent)
- das Ergebnis, dass man gute Software entwickelt und auch sauberen Code geschrieben hat, aber erst mit der Zeit erkennt, „wie das Design hätte sein sollen“
- unüberlegte und unbeabsichtigte technische Schulden (Reckless & Inadvertent)
- ein Ergebnis, das aus mangelndem Wissen entsteht
- Wege zum Abbau technischer Schulden
- Verwaltung eines Verzeichnisses technischer Schulden
- im Projekt-Retrospektiven technische Schulden erfassen und als Liste aufbereiten und teilen
- jedes Mal, wenn technische Schulden entstehen, die zu ihrer Behebung nötigen Aufgaben zusammen mit dem erwarteten Aufwand und Zeitplan festhalten
- im Team besprechen, ob und wann die technischen Schulden behoben werden, und einen Lösungsplan erstellen
- gute und schlechte technische Schulden unterscheiden
- diese Unterscheidung hilft dabei, die größten Probleme zu priorisieren
- Refactoring
- notwendige Bereiche während der Arbeit aufräumen und schrittweise refaktorieren
- bei umfangreichem Refactoring das Team über die Situation informieren und auf Risiko und Kosten technischer Schulden hinweisen
- Testcode schreiben
- je komplexer der Code und je größer das Refactoring, desto schwieriger ist es, den Code auf einmal fehlerfrei zu ändern
- um Nebenwirkungen zu vermeiden, sollte Testcode geschrieben werden
- Qualitätsstandards festlegen und einhalten
- Qualitätsstandards festlegen, damit Entwickler keinen schlampigen Code deployen können
- keine plötzlichen Änderungen bei Vorgaben oder Zeitplänen
- wenn entwicklerbezogene Vorgaben ständig geändert und Deadlines verschoben werden, ist es schwer, technische Schulden zu vermeiden
- realistische Zeitpläne, Methoden und Arbeitsumfänge helfen dabei, technische Schulden zu managen
- Sind technische Schulden immer nur schlecht?
- In ihrem Buch 『Pflichtlektüre! Entwickler-Onboarding-Guide: Die Entstehung professioneller Entwickler, die nachhaltige Software und eine reibungslose Kultur der Zusammenarbeit verstehen』 schreiben Chris Riccomini und Dmitriy Ryaboy: „Wenn es sich um Schulden handelt, mit denen ein Team später umzugehen gelernt hat, kann man sie als ‚gute Schulden‘ bezeichnen.“
- But technische Schulden können sich negativ auf das Business auswirken und müssen daher behoben werden
- sie zeigen sich in Bugs und verschlechtern die User Experience
- wenn sich technische Schulden verschärfen, wird es für Entwickler schwieriger, innerhalb der bestehenden Codebasis zu arbeiten
- weil Zeit auf die Entwicklung neuer Funktionen und die Anpassung bestehender Funktionen aufgeteilt werden muss, verlangsamt sich der Softwareentwicklungslebenszyklus und der Markteinführungstermin verschiebt sich
Noch keine Kommentare.