Dr. Carola Lilienthal Workspace Solutions GmbH

Kein Projekt wird jemals ganz frei von technischen Schulden sein. Genauso wie unsere Wohnungen oder unser Arbeitsplatz nie ganz aufgeräumt sind. Das ist nicht möglich. Aber selbstverständlich ist es möglich, mit der nötigen Aufmerksamkeit von Anfang an, auf technische Schulden zu achten und ihr Ausmaß einzudämmen. Es kommt hin und wieder vor, dass ich Software analysieren darf, die neben einigen Mängeln im Großen und Ganzen in einem guten Zustand ist.

Die wenigsten Product Owner haben heute noch die Chance, ein System auf der grünen Wiese entwickeln zu lassen. Meistens stehen sie gemeinsam mit ihrem Entwicklungsteam vor der Herausforderung, ein oder mehrere über Jahre gewachsene Systeme um neue Features zu erweitern und zu warten. Aus Sicht des Entwicklungsteams braucht man dafür eine qualitativ hochwertige und flexible Architektur mit möglichst wenig technischen Schulden. Sind die technischen Schulden gering, dann können Bugs schnell und einfach gefixt werden, und Erweiterungen sind kostengünstig umzusetzen – aber was braucht der Product Owner?

Für den Product Owner sind technische Schulden etwas sehr Abstraktes, und er kann sie allein auf Basis der Aussagen der Entwickler schlecht nachvollziehen. Noch dazu sind Entwickler aus seiner Sicht häufig qualitätsversessen – ständig jammern sie über schlechten Code und fehlende Zeit für die aus ihrer Sicht notwendigen Refactorings. Damit Product Owner und Entwicklungsteam sinnvolle Entscheidungen über den Abbau technischer Schulden treffen können, brauchen sie ein gemeinsames Verständnis, wo Schulden existieren und welche Schulden wann und warum abgebaut werden sollten.

Technische Schulden

Der Begriff „Technische Schulden“ wurde 1992 von Ward Cunningham geprägt. Technische Schulden entstehen, wenn bewusst oder unbewusst falsche oder suboptimale technische Entscheidungen getroffen werden. Diese führen zu einem späteren Zeitpunkt zu Mehraufwand, der Wartung und Erweiterung teurer macht. Zu dem Zeitpunkt der falschen oder suboptimalen Entscheidung hat man also technische Schulden aufgenommen, die man mit ihren Zinsen irgendwann abbezahlen muss, wenn man nicht überschuldet enden will.

In der Literatur werden verschiedene Arten und Varianten von technischen Schulden aufgeführt. Für diesen Artikel stelle ich die Schulden in den Fokus, die das Entwicklungsteam dem Product Owner nahebringen muss. Andere Problemfelder, die man auch als Schulden von Softwareprojekten betrachten kann, wie fehlende Dokumentation, schlechte Usability oder ungenügende Hardware, bleiben hier außen vor.

Implementationsschulden: Im Sourcecode finden sich so genannte Code Smells, wie lange Methoden, leere Catch-Blöcke etc. Implementationsschulden sind heute weitgehend automatisiert mit einer Vielzahl von Tools im Sourcecode zu finden. Jedes Entwicklungsteam sollte diese Schulden in seiner täglichen Arbeit sukzessive beheben, ohne den Product Owner damit zu belasten. Der Aufwand, um dem Product Owner diese sehr programmiersprachennahen Schulden zu vermitteln, steht in keinem Verhältnis zum Nutzen.

Testschulden: Es fehlen Tests bzw. nur der Gutfall wird getestet. Die Testabdeckung mit automatisierten Unit Tests ist gering. Auch die Testabdeckung lässt sich heute mit Werkzeugen messen und auf Dashboards wie SonarQube Teamscale etc. hervorragend visualisieren. Über den Abbau von Testschulden sollte es zwischen Product Owner und Entwicklungsteam keinen Dissens geben, denn eine angemessen hohe Testabdeckung bewahrt vor Fehlern und Folgefehlern. Hier Kompromisse einzugehen, ist wie Autofahren ohne Sicherheitsgurt: eindeutig fahrlässig.

Design- und Architekturschulden: Das Design der Klassen, Pakete, Subsysteme, Schichten und Module ist uneinheitlich, komplex und passt nicht mit der geplanten Architektur zusammen. Diese Schulden sind durch einfaches Zählen nicht zu ermitteln und dadurch auch schwerer zu vermitteln. Im Abschnitt „Identifizieren von Design- und Architekturschulden“ wird das näher betrachtet.

Je nachdem wie Product Owner und Entwicklungsteam mit diesen technischen Schulden umgehen, erstellen sie entweder eine Software, die im Korridor geringer technischer Schulden bleibt, oder ein System mit einer sich immer weiter ausbreitenden Architekturerosion.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Business Technology 1.16 - "Entscheidungswege: Informiert und mutig ans Ziel"

Alle Infos zum Heft
208954Technische Schulden als Entscheidungsgrundlage
X
- Gib Deinen Standort ein -
- or -