Technische Schulden: Wie damit umgehen?

4. Juli 2013Felix Müller

Jeder von uns kennt es und liebt es: ein neues Projekt. Endlich die Möglichkeit, alles richtig und besser zu machen, als beim vorherigen Projekt. Die Zeit vergeht, das Projekt hat die Startphase verlassen und es werden von Sprint zu Sprint neue Funktionen implementiert. Hin und wieder muss etwas schneller umgesetzt werden oder passt nicht perfekt in die Architektur beziehungsweise in die bereits implementierte Klassenstruktur. Um Zeit zu sparen und weil es den Aufwand nicht lohnt, macht man mitunter Kompromisse: Man sammelt technische Schulden an.

Der Begriff der technischen Schulden bezeichnet die Inkaufnahme schlechterer Code-Qualität für einen kurzfristigen Erfolg (z.B. die termingerechte Lieferung neuer Features). Es ist eine Metapher, die sich an den finanziellen Schulden anlehnt. Sie soll den Mehraufwand verdeutlichen, der notwendig ist, um Code von minderer Qualität zu ändern. Je schlechter die Code-Qualität, desto größer die Schulden und desto aufwändiger ist die spätere Änderung des Codes. Dadurch soll die Kommunikation bezüglich Code-Qualität zwischen Entwicklern und Projektleitern verbessert werden.

Technische Schulden können durch hohen Zeitdruck entstehen oder wenn die Qualität schlicht vernachlässigt wird. Dabei können diese Schulden folgendermaßen aussehen:

  • Hohe Komplexität von Methoden: Werden Methoden zu komplex, sind Änderungen sehr aufwändig und fehleranfällig.
  • Geringe Dokumentation der öffentlichen Schnittstellen: Um schlecht dokumentierte Schnittstellen zu nutzen oder zu ändern, muss mehr Zeit investiert werden. Das verlangsamt die Weiterentwicklung.
  • Niedrige Testabdeckung: Das Hinzufügen und Ändern von Funktionen ist mit einem großen Risiko verbunden. Regressionsfehler können eintreten oder existierende Funktionen fehlerhaft werden.

Es stellt sich die Frage, wie ein Entwicklungsteam mit technischen Schulden umgehen soll. Sie zu ignorieren, endet in stark steigenden Kosten für die Änderung von Code, was ein Projekt zum Stillstand bringen kann. Zuerst müssen die Schulden sichtbar gemacht werden. Dafür können Tools zur statischen Code-Analyse verwendet werden wie beispielsweise PMD, Findbugs oder auch ein Aggregationstool wie SonarQube. Mittels Metriken, die diese Tools messen, können technische Schulden erkannt werden. Diese Kennzahlen geben Anhaltspunkte, wo in einem Softwaresystem technische Schulden lauern. Anschließend muss das Team sich die problematischen Stellen anschauen und entscheiden, ob es sich um zu behebende technische Schulden handelt. Diese Schulden können dann nach unterschiedlichen Methoden behoben werden:

  • Die technischen Schulden können in einem Backlog verwaltet werden und zusammen mit den normalen Anforderungen abgearbeitet werden.
  • Pro Iteration kann ein Anteil des Aufwands (z.B. 10%) für die Behebung der Schulden verwendet werden. Somit kann sukzessive über die Zeit an bestimmten Stellen die Höhe der technischen Schulden reduziert werden.
  • Eine eigene Iteration kann für die Behebung der technischen Schulden eingeplant werden.

Das sind einige Möglichkeiten für den Umgang mit technischen Schulden. Egal, ob man eine der vorgeschlagenen Methoden verwendet oder eine andere: wichtig ist, dass die technischen Schulden aktiv gemanagt werden. Denn sie sind ein Risiko, dass wie jedes andere Projektrisiko im Blickfeld sein muss und letztendlich den Projekterfolg beeinflusst.

Wie gehen Sie mit technischen Schulden in Projekten um? Ich freue mich über Ihre Kommentare und einen Erfahrungsaustausch zu diesem spannenden Thema.

Felix Müller Felix Müller ist als Software Engineer bei adesso tätig und beschäftigt sich mit der Entwicklung von Web-Anwendungen im Java-Umfeld und mit dem firmeninternen Build Management.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Alexander von Hedenström 4. Juli 2013 Website des Autors

Sehr geehrter Herr Müller,

Vielen Dank für Ihren Blog-Beitrag, der sicher viele Projekte ansprechen wird.

Ich persönlich finde das Thema Kennzahlen besonders interessant, vor allem in der Kommunikation mit Nicht-Technikern. Welche Kennzahlen ermitteln und kommunizieren Sie? Können Kennzahlen ein Abnahmekriterium darstellen?

Mit freundlichen Grüßen,
Alexander von Hedenström

Felix Müller 4. Juli 2013

Guten Tag Herr von Hedenström,

intern verwenden wir SonarQube (ehemals Sonar) für die Aggregation von Metriken. Das funktioniert sehr gut. Wie mit den Metriken umgegangen wird, ist natürlich projektspezifisch. Der gängiste Anwendungsfall ist das tägliche Reviewen des SonarQube Dashboards und ggf. das Einleiten von Gegenmaßen: beispielsweise wenn eine Klasse offensichtlich mehr als ein Konzept implementiert (LCOM4 > 1) und zudem sehr komplex ist (erkennbar an der zyklomatischen Komplexität). Dann kann man sich im Team überlegen, ob die Klasse das richtige Abstraktionslevel hat. Wenn nicht, dann wäre ein Aufteilen der Klasse in mehrere Klassen die Folge.

Ich persönlich bin nur im Umgang mit technischen Kennzahlen geübt wie z.B. die Code Coverage oder zyklomatische Komplexität. Solche Metriken können gut dafür verwendet werden, um schnell eine Übersicht über die Code Qualität eines Softwaresystems zu erhalten: Wo befinden sich womöglich problematische Stellen im Code? Ich denke nicht, dass diese Metriken dafür verwendet werden sollten, um kategorisch zu entscheiden, ob ein System eine hohe Code Qualität hat oder nicht. Dafür sind solche Metriken zu ungenau und bieten nur einen sehr eingeschränkten Blickwinkel auf ein Stück Code. Um auf Ihre Frage zu den Abnahmekriterien einzugehen: Folglich können Sie durchaus ein Abnahmekriterium darstellen, aber sie sollten es meiner Meinung nach nicht.

Das sind jedoch alles Kennzahlen mit denen Nicht-Techniker wenig anfangen können. Persönlich habe ich solche Metriken noch nicht in der Kommunikation mit Nicht-Technikern verwendet.

An welche Kennzahlen haben Sie gedacht, die in der Kommunikation mit Nicht-Technikern eingesetzt werden können bzw. als Abnahmekriterium dienen sollen?

Beste Grüße,
Felix Müller

Alexander von Hedenström 5. Juli 2013 Website des Autors

Guten Tag Herr Müller,

Ich dachte tatsächlich an die Testabdeckung, vielleicht auch an die Dokumentation im Code. Nach entsprechender Aggregation könnte ich mir auch vorstellen dass Kennzahlen über Komplexität zumindest vermittelbar sind — natürlich nicht auf Ebene einzelner Klassen.

SonarQube steht auch noch auf meiner persönlichen Liste. Ich freue mich darauf, das Werkzeug auf beispielsweise mein aktuelles Projekt loszulassen!

Ein schönes Wochenende,
Alexander von Hedenström

Felix Müller 5. Juli 2013

Guten Tag Herr von Hedenström,

in der Kommunikation mit dem Kunden können einzelne Metriken (wie z.B. die von Ihnen genannten) durchaus eingesetzt werden. Ich glaube, es gibt keinen Kunden, der sich nicht freut, wenn er beispielsweise hört, dass mehr als 80% seiner Software mit automatischen Tests getestet sind.

Dennoch würde ich immer acht geben, dass die Zahlen nicht als „heiliger Gral“ angesehen werden.

Ebenso ein schönes Wochenende,
Felix Müller

An­o­nym 10. Juli 2013 Website des Autors

Finde ich super. Danke für die Information.
LG

Kommentar hinzufügen:

Ihr Kommentar: