Technische Schuld, Teil 2
16.07.2018, 00:00 Uhr
Dem Problem ein Preisschild geben
Die technische Schuld ist schwer zu schätzen, das Verfahren lässt sich trotzdem gut anwenden.
Der Code für ein Softwareprojekt ist schnell geschrieben und die von Kunden gewünschten Funktionalitäten sind mit minimalem Aufwand in sehr kurzer Zeit umgesetzt. Wird dabei jedoch die Qualität des Erzeugten außer Acht gelassen, entsteht im Lauf des Projekts eine Abweichung der Ist-Situation vom eigentlich zu erreichenden Soll-Zustand. Diese Abweichung wird technische Schuld (Technical Debt) genannt.
Der erste Artikel zu diesem Thema [1] hat die Grundlagen gelegt und gezeigt, was genau die absolute und die relative technische Schuld ist, und dazu noch zahlreiche mögliche Einsatzszenarien beschrieben. Diese sind ungemein hilfreich, wenn es um qualitative Entwicklung eines Softwareprojekts geht. Dieser zweite Teil von Davids Deep Dive zu diesem Thema wird nun etwas genauer darauf eingehen, wie sich diese technische Schuld messen lässt, oder besser gesagt schätzen lässt.
Jetzt 1 Monat kostenlos testen!
Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
- + Digitales Kundenkonto,
- + Zugriff auf das digitale Heft,
- + Zugang zum digitalen Heftarchiv,
- + Auf Wunsch: Weekly Newsletter,
- + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar
