Artikel

Debt Factor - jenseits der technischen Verschuldung

Andrey Cunha

Aktualisiert Oktober 10, 2025

7 Minuten

Technische Schulden sind bei der Anwendung einer agilen Methodik in einer sich verändernden Umgebung unvermeidlich, da ständig neue Verfahren und Techniken eingeführt werden. Dieser Artikel definiert technische Schulden, betrachtet die Einflussfaktoren und geht über den Schuldenhorizont hinaus.

Definition technischer Schulden

Das Wort wurde erstmals 2007 von Ward Cunningham verwendet, der es erfand, indem er "technische" Schulden mit "finanziellen" Schulden verknüpfte. Finanzielle Schulden sind akzeptabel, solange Sie daran denken, sie zurückzuzahlen. Bei technischen Schulden ist die gleiche Methode wirksam.

Von finanziell bis technisch

In der modernen Welt können Sie ein Unternehmen nur mit Hilfe von Technologie führen.

Unternehmen müssen ihre Arbeitsabläufe und die Zufriedenheit der Verbraucher mithilfe von sozialen Medien und Kundennetzwerken überprüfen.

Die Produktverantwortlichen verwalten die Kundenwünsche und entscheiden, welche Versionen sie herausgeben, je nachdem, wie viel Mehrwert sie bringen oder wie sie sich auf die Vorschriften auswirken.

Technische Schulden sind unvermeidlich und aufgrund der bereits erwähnten Dinge, des Bedarfs des Marktes an schnelleren Veröffentlichungen und der Entwicklung neuer Technologien in Ordnung.

Ein Team kann (technische) Schulden haben, solange es sie zurückzahlt.

Vom V-Modell zu agil

Als Teams die Wasserfallmethode anwandten, war es einfacher, einige Gateways einzurichten, um im Projekt weiterzukommen.

Ein gutes Beispiel dafür ist, dass Microsoft nach jeder Produktveröffentlichung neue Produkte herausbrachte und dann Service Packs zur Verfügung stellte, um das zu beheben, was den Verbrauchern entgangen war oder was sie beachten mussten.

Das Bereitstellungsmodell hat sich geändert, und die meiste Infrastruktur wird jetzt in die Cloud ausgelagert. Diese Auslagerung bedeutet, dass es nicht mehr nötig ist, Dinge in internen Rechenzentren zu speichern.

Unternehmen müssen mehr Veränderungen vornehmen, wenn sie die Erwartungen ihrer Kunden erfüllen und den Überblick darüber behalten wollen, wie gut sie funktionieren.

Was ist jenseits der technischen Schulden

Man kann argumentieren, dass Teams immer verschuldet sein werden (siehe folgende Tabelle). Es gibt vier Hauptarten von Schulden: Kreisdiagramm Xita Transparent

Menschen
Business
Technisch
Prozess

Auf dem Weg zu einer Ontologie von Begriffen zu technischen Schulden, lassen'in jede der Kategorien eintauchen:

Architektur: Sie bezieht sich auf die Ineffizienz des technischen Rahmens (z.B. Software oder Infrastruktur).
Anforderung: "Es ist die Annahme der Entwickler, die in die Produktion geht" - Alberto Brandolini. Sie beschreibt die Aufgaben des Entwicklungsteams, um die Anforderungen des Unternehmens zu erfüllen. Die Schuld kann absichtlich (z.B. Bereitstellung kleiner Pakete auf der Grundlage von Funktionen) oder versehentlich (z.B. menschliche Voreingenommenheit) sein.
Infrastruktur: Umgebung zum Entwickeln, Testen und Bereitstellen für die Produktion sowie zur Integration verschiedener Architekturkomponenten.
Erstellen: Bezieht sich auf die Erstellung der Artefakte, die an die folgende Umgebung geliefert werden sollen. (z.B. hohe Abhängigkeiten).
Code: Es handelt sich um einen Mangel an Richtlinien für die Entwicklung von Softwarecode und verursacht gelegentlich Refactors. (z.B. duplizierter Code, langsame Algorithmen)
Defekt: Der Fehler ist bekannt und wird nach Absprache mit der Abnahme in zukünftigen Versionen behoben.
Design: Das Entwerfen von Lösungen, ohne gute Prinzipien für die Entwicklung anzuwenden, führt zu stark gekoppelten Systemen. (z.B. starke Kopplung, duplizierter Code).
Dokumentation: Die häufigste Schuld ist, dass die Dokumentation immer unvollständig oder veraltet ist. Allerdings ist es am einfachsten, sie zu bezahlen.
Fertigkeiten: Diese Schuld ist auch eines der häufigsten Probleme in Teams und Projekten. Dabei geht es nicht um die Anzahl der Personen, sondern auch um die mangelnden Fähigkeiten einiger Mitglieder. (z.B. Personalmangel).
Sozial: Da die Menschen ständig auf die Interaktion mit Maschinen angewiesen sind, suchen sie die Lösung für das Problem bei sich selbst. Wenn jedoch eine Zusammenarbeit in einem dynamischen Umfeld erforderlich ist, ist der Austausch von Ideen und unterschiedlichen Perspektiven auf das Problem und/oder die Lösung erforderlich.
Prozess: Dies bezieht sich auf die ineffizienten oder nicht vorhandenen Prozesse zur Unterstützung der Teams. (z.B. Verfahren zur Definition des LCM).
Dienst: Erstellen und/oder Ändern eines Dienstes oder einer API, um eine bestimmte Funktion freizugeben, die einen von der Gegenseite geforderten Wert liefert. (z.B. Auswahl/Ersatz von APIs oder Webservices).
Testautomatisierung: Die Entwicklung von Automatisierungen für entwickelte Testartefakte, die die kontinuierliche Integration unterstützen.
Testen: Die Anzahl der auszuführenden Testaktivitäten oder die Anzahl der von den Testszenarien abgedeckten Funktionalitäten. (z.B. geringe Abdeckung)

Angleichung der verschiedenen Schulden

Es ist nicht nur die Aufgabe des Product Owners und des Domain-Teams, sondern das Unternehmen muss auch das strategische Wachstum jedes Mitarbeiters in den Vordergrund stellen.

Der Drei-Horizonte-Ansatz von McKinsey kann dazu beitragen, dass Lernen und Entwicklung kurz-, mittel- und langfristig stattfinden. Und er kann auch dabei helfen herauszufinden, welche Fähigkeiten die Markteinführung beschleunigen werden.

Beim Wachstumsmodell kann das Unternehmen finanzielle Mittel für das Team und die Mitarbeiterentwicklung bereitstellen.

Grafik 1: Drei-Horizonte-Modell Liniendiagramm Xita Transparant

Horizont 1: Konzentrieren Sie sich auf Verbesserungen oder Erweiterungen dessen, was die Organisation bereits hat;

Horizont 2: Konzentrieren Sie sich auf die Anpassung oder Veränderung von Geschäftsmodellen, die in anderen Branchen gut funktionieren;

Horizont 3: Disruptiver Architektur-/Modellwechsel für B2B-Märkte durch den inkrementellen Prozess;

Die dunkle Seite des Mondes

Die dunkle Schuld bezieht sich auf die Folgen, die durch die Kombination von neuen Ereignissen oder Faktoren entstehen, die zu "bösen" Problemen führen können. Dieses Thema beruht auf Metamodellen und menschlichen Vorurteilen und würde vom Thema dieses Artikels abweichen.

Der Begriff "dunkle Schuld" bezieht sich auf die Kosten, die entstehen, wenn neue Ereignisse oder Ursachen zusammenkommen, die zu "bösen" Schwierigkeiten führen.

Das passt nicht zum Thema dieses Artikels, denn es geht um Metamodelle und die dem Menschen innewohnenden Vorurteile.

Dunkle Schulden sind eine Form von technischen Schulden, die erst sichtbar werden, wenn sie zum Scheitern führen. Anders als technische Schulden sind dunkle Schulden nicht auf Code beschränkt. Sie können überall auftreten und sich in jedem komplexen System abspielen.

Dunkle Schulden erscheinen als Anomalien, im Gegensatz zu technischen Schulden, die überarbeitet werden können.

Dark Debt verursacht unerwartete Systemausfälle und Anomalien. Sie können Dark Debt aufspüren, indem Sie testen, wie gut das System mit Ausfällen umgehen kann und dabei noch akzeptable Service-Levels bietet. Sie können Ihre Dark Debt frühzeitig erkennen, indem Sie dem System gefährliche Dinge zumuten, z. B. einen Ausfall.

Antizipieren Sie, wann die Schulden problematisch werden könnten, und ergreifen Sie Maßnahmen, um sie abzubauen. Eine der besten Möglichkeiten, die schädlichen Auswirkungen technischer Schulden zu vermeiden, besteht darin, auf Anzeichen zu achten, die darauf hindeuten, dass ein angemessenes Maß an Schulden in den Bereich der Verantwortungslosigkeit abgleitet.

Wenn Sie in Ihrem Code Abkürzungen nehmen, um Ihr Produkt schneller auf den Markt zu bringen, ist das ein Beispiel für technische Schulden.

Technische Schulden können auch das digitale Wachstum bremsen, da eine hohe finanzielle Verschuldung die finanziellen Möglichkeiten einer Person oder eines Unternehmens einschränken kann.

Hohe technische Schulden können wie Kreditkartenschulden eine Abwärtsspirale von gescheiterten Modernisierungsversuchen auslösen, die zu noch mehr technischen Schulden führen.

Die Schuld für Verzögerungen auf technische Schulden zu schieben, macht es schwieriger zu erkennen, was vor sich geht und lässt Ihre funktionsübergreifenden Teamkollegen im Dunkeln tappen. Sie müssen Ihre Entwürfe in der Produktion immer wieder überprüfen, um dunkle Schulden aufzuspüren, bevor sie eine kostspielige Unterbrechung der Bedingungen und des Zeitplans verursachen. Aus diesem Grund sind Chaos Engineering und Incident Learning in der Branche so beliebt.

Fazit:

Organisationen, Teams und Einzelpersonen müssen zusammenarbeiten, um Wachstumsstrategien und technische Schulden zu bewältigen und mit dem System synchron zu sein.

SRE, DevOps und Plattform-Engineering bieten Folgendes, um den Kontext zu verdeutlichen:

Wie man einen skalierbaren Entwicklungsprozess schafft, indem man aus Fehlern lernt und die Ergebnisse verbessert
Wie Sie eine durchgängige Kultur schaffen, damit Teams die Verantwortung für die von ihnen gelieferten Produkte und Dienstleistungen übernehmen können
Verwenden Sie die besten Methoden zur Herstellung von Software und achten Sie auf das Produkt