Suche
Wie Teams und Projektleiter Qualität gemeinsam managen können

Der Umgang mit technischen Schulden

Eberhard Wolff
shutterstock_110667572_0
©Shutterstock/CoraMax

Im Laufe der Zeit wird Software oft zunehmend weniger änderbar und flexibel: Modifikationen wurden „mal eben schnell“ und nicht systematisch vorgenommen. So kam das Team zwar kurzfristig schneller voran, aber auf lange Sicht werden Änderungen und Weiterentwicklungen immer schwieriger, da die Codequalität abnimmt und so technische Schulden angehäuft werden.

Die Geschichte der Codequalität ist eine Geschichte voller Missverständnisse. Auf der einen Seite stehen die Projektleiter. Sie sind vor allem an einem schnellen Release mit allen Features interessiert und können Codequalität gar nicht fassen. Schließlich tut das System genau das Gleiche – egal wie gut der Code strukturiert ist. Auf der anderen Seite stehen die Entwickler. Durch die Umstände oder den Projektleiter können sie zu Kompromissen gezwungen sein, die langfristig zu Qualitätsproblemen führen. Weisen sie auf diese Entwicklung hin, hält der Projektleiter dieses Problem allzu oft lediglich für eine technische Spielerei. Wird die Codequalität dann immer schlechter, so wird die Entwicklung verlangsamt. Der kurzfristige Vorteil ist am Ende also teuer erkauft (Abb. 1). Im Extremfall ist das System ökonomisch nicht mehr weiterentwickelbar und muss neu geschrieben werden. Spätestens dann liegt ein wirtschaftlicher Totalschaden vor.

Abb. 1: Bei einem Qualitätskompromiss wird das Team zunächst schneller – dann aber langsamer, denn es entstehen technische Schulden

Um die Kommunikation zu verbessern, hat sich die Metapher der „technischen Schulden“ (Technical Debt) etabliert. Verschlechterungen in der Codequalität werden als technische Schulden aufgefasst. Zwei Merkmale sind hierbei wesentlich:

  • Durch die Aufnahme von technischen Schulden kann ein kurzfristiger, vorteilhafter Effekt erreicht werden. Beispielsweise kann ein Release schneller auf den Markt gebracht werden.
  • Genua wie finanzielle Schulden nehmen auch technische Schulden mit der Zeit zu. Die „Zinsen“ sind zum einen der erhöhte Aufwand bei der Implementierung und zum andern die Verschlechterungen der Qualität.

Die Metapher hat also den Vorteil, dass Projektleiter und Entwickler eine gemeinsame Begriffswelt haben, in der sie das Problem diskutieren können. Das ist ein erster Schritt, um die Codequalität aktiv und gemeinsam zu managen.

Aufmacherbild: 3d people – men, person carrying word “debt” on his back von Shutterstock / Urheberrecht: CoraMax

[ header = Seite 2: Was sind technische Schulden? ]

Was sind technische Schulden?

Technische Schulden sind nicht einheitlich definiert. Im Wesentlichen geht es um die innere Qualität der Software. Während bei der äußeren Qualität die vom Kunden wahrnehmbaren Features eine Rolle spielen, geht es bei der inneren Qualität darum, wie gut das System und der Code strukturiert sind. Das beeinflusst die Wartbarkeit und damit die Weiterentwicklung. Beispielsweise können die technischen Schulden Folgendes umfassen:

  • Hohe Komplexität in Methoden oder Klassen: Solche Artefakte sind schwer zu verstehen und daher schwer änderbar.
  • Niedrige Testabdeckung: Änderungen an der Software können dann sehr leicht Fehler einführen, die durch die mangelnde Testabdeckung nicht gefunden werden. Oder Entwickler schrecken sogar davor zurück, überhaupt Änderungen an der Software vorzunehmen, da sie kein „Sicherheitsnetz“ haben, das sie auf Fehler hinweist.
  • Auf Architekturebene können ungeeignete oder komplexe Entwürfe ebenfalls Änderungen an der Software erschweren. Wurde beispielsweise an den falschen Stellen Flexibilität in das System eingebaut, so erhöht das nur die Komplexität und erschwert so Änderungen.
  • Geringe Kohäsion in den Komponenten: In diesem Fall passen die Teile einer Komponente nicht zusammen, weil sie beispielsweise unterschiedliche fachliche Funktionalitäten implementieren. Dann sind Änderungen nicht mehr auf eine einzelne Komponente beschränkt, sodass eine Änderung größere Teile des Systems betrifft und dadurch erschwert wird.
  • Keine lose Kopplung: Dadurch hängen Komponenten stark voneinander ab, was wiederum dazu führt, dass Änderungen nicht auf eine Komponente begrenzt sind. Dann müssen für jede Änderung große Teile des Systems modifiziert werden, was die Arbeit ebenfalls erschwert.

Es gibt sicher noch weitere Eigenschaften eines Systems, die als technische Schulden aufgefasst werden können – es gibt wie gesagt keine einheitliche Definition. Wer unter technischen Schulden nur den Bereich der Wartbarkeit versteht, für den beeinflussen nicht alle technischen Eigenschaften eines Systems den Schuldenstand. Ausnahmen wären beispielsweise die Performance: Sie gehört mit zur äußeren Qualität, da sie durch einen Nutzer wahrgenommen werden kann. Außerdem verhindert ein Problem in diesem Bereich meistens die Produktionseinführung und muss dann sofort beseitigt werden – es können also keine Schulden angehäuft werden. Ähnliches gilt beispielsweise auch für die Sicherheit einer Anwendung.

[ header = Seite 3: Ursachen für technische Schulden ]

Ursachen für technische Schulden

In der Praxis ergeben sich technische Schulden meistens, weil Teams Qualität vernachlässigen oder unter hohem Zeitdruck arbeiten, sodass die nachhaltige Entwicklung des Codes in den Hintergrund gedrängt wird. Technische Schulden können sich sogar ergeben, ohne dass der Code überhaupt geändert wird. Beispielsweise kann eine neue Technologie dazu führen, dass der Code wesentlich vereinfacht werden könnte. Solange diese Vereinfachung nicht durchgeführt worden ist, kann der Unterschied als technische Schulden interpretiert werden. Außerdem lernen Teams während der Entwicklung ständig dazu und Anforderungen ändern sich. So können Lösungen, die vorher noch problemadäquat waren, plötzlich in den Bereich technische Schulden gehören, weil die Struktur nicht mehr sinnvoll ist.

Wichtiger als die Frage, woher die Schulden kommen, ist vor allem, dass sich das Team und der Projektleiter überhaupt dieser Schulden bewusst sind. Erst dann wird Qualität steuerbar, während sonst in vielen Projekten die Entwickler die Qualität zwar intuitiv bewerten können, aber zumindest die Kommunikation mit dem Projektleiter schwierig ist. Ist das Bewusstsein vorhanden und gelingt die Kommunikation zwischen den Beteiligten, wird auch ein aktiver Trade-off möglich: Die Qualität kann gegen andere Parameter des Projekts abgewogen werden.

Sind technische Schulden schlecht?

Wie finanzielle Schulden sind auch technische Schulden nicht unbedingt schlecht. Es kann durchaus sinnvoll sein, kurzfristige Kompromisse in der Qualität einzugehen, um ein anderes Ziel – zum Beispiel das Halten einer Deadline – zu erreichen. Es geht nur darum, Businessentscheidungen klar zu begründen. Denn im Extremfall kann das Reißen einer Deadline das gesamte Projekt sinnlos machen. Unter solchen Umständen sind die technischen Schulden sicher nicht so wichtig. Wenn die Dinge aber nicht so klar liegen, müssen technischen Schulden gegenüber anderen Belangen im Projekt abgewogen werden.

Aber Qualität und technischen Schulden kommt eine besondere Rolle zu, denn Kompromisse in der Qualität können sehr schnell Niederschlag in einer niedrigeren Produktivität finden. Auch in der schlanken Produktion (Lean Production), die in der Industrie einen Siegeszug hinter sich hat und bei der Softwareentwicklung als Leitmotiv für die agile Bewegung dient, werden bezüglich Qualität keine Kompromisse gemacht: Wenn ein Qualitätsproblem auftaucht, wird die Produktion angehalten [1]. Jeder Mitarbeiter am Fließband kann die Produktion stoppen. Die Produktion wird erst wieder aufgenommen, wenn die Ursache des Problems tatsächlich behoben worden ist. Nur oberflächlich die Symptome zu kurieren, reicht nicht. Dieser Umgang mit Qualität liegt vor allem darin begründet, dass Fehler als Verschwendung (Waste) aufgefasst werden. Schließlich entsteht Aufwand für die Korrektur des Fehlers und Ausschusses. Die Qualität ist also nicht selbst das Ziel, sondern die damit einhergehende höhere Produktivität.

Bei der Softwareentwicklung gilt daher teilweise die Meinung, dass Kompromisse bezüglich der Qualität nicht eingegangen werden können.

[ header = Seite 4: Kann man technische Schulden vermeiden? ]

Kann man technische Schulden vermeiden?

Diese Haltung fand beispielsweise ihren Niederschlag im Extreme Programming (XP) [2], das grundsätzlich Qualitätskompromisse ablehnt. In der Praxis ist es jedoch kaum möglich, diesem Anspruch gerecht zu werden, denn an jedem Projekt arbeiten unterschiedlich erfahrene Entwickler, die unterschiedliche Qualität liefern. In der Realität gibt es also nur die Möglichkeit, die Qualität in dem System zu steuern oder dafür zu sorgen, dass sie dort besonders hoch ist, wo es sinnvoll ist – weil beispielsweise viele Änderungen an diesem Bereich im Code zu erwarten sind.

Dazu gibt es den Ansatz des Strategic Design [3], bei dem das System in verschiedene Komponenten aufgeteilt wird und ein Fokus auf Qualität an den Stellen gelegt wird, wo das besonders sinnvoll ist.

Umgang mit technischen Schulden

Um mit technischen Schulden sinnvoll umzugehen, müssen sie zunächst gemessen werden. Dazu gibt es verschiedene Werkzeuge. Beispielsweise integriert Sonar (Abb. 2) [4] einige Ansätze für statische Codeanalyse, die einen Hinweis auf technische Schulden geben können. Die Ergebnisse können im historischen Verlauf und auch in der Verteilung im Code des Projekts dargestellt werden. Für die Bewertung der Architektur gibt es ebenfalls Werkzeuge [5, 6, 7], die passende Metriken bereitstellen und dadurch eine Bewertung auch auf dieser Ebene ermöglichen.

Abb. 2: Screenshot von Sonar: Verschiedene Metriken und die historische Entwicklung

Sich nur auf das Messen zu verlassen, ist aber nicht ausreichend. Metriken können Hinweise auf Probleme in der Software geben, aber eine zusätzliche Bewertung durch das Team ist dennoch notwendig. Denn Metriken können durchaus auch fehlerhafte Hinweise geben. Ebenso ist es möglich, dass dem Team Probleme im System bekannt sind, die nicht durch eine Metrik erkannt werden können.

Wenn die technischen Schulden bekannt sind, muss der Umgang mit ihnen festgelegt werden. Entsprechend dem Strategic Design [3] sollte dabei bewertet werden, in welchem Bereich technische Schulden akzeptabel sind, weil diese Stelle im Code beispielsweise auf absehbare Zeit nicht geändert werden wird. Sind hingegen zahlreiche Änderungen zu erwarten oder die Änderbarkeit des Codes aus anderen Gründen wichtig, ist es vermutlich sinnvoll, die technischen Schulden in diesem Teil des Codes abzutragen.

Eine solche Entscheidung zu fällen, ist nicht einfach. Letztendlich ist es eine Geschäftsentscheidung. Denn genau genommen ist das Abtragen einer technischen Schuld eine Investition. Es wird in die Qualität investiert, weil sich das Team davon einen langfristigen Vorteil verspricht. Der Code wird leichter änderbar, sodass in Zukunft Aufwand eingespart werden kann. Für diese Abwägung muss bekannt sein, ob der spezifische Teil des Codes in Zukunft tatsächlich geändert wird. Außerdem muss bewertet werden, ob sich das Heben der Qualität lohnt – also welche Aufwände eingespart werden. Das müssen die Techniker einschätzen und zusammen mit dem Projektleiter entscheiden – wie dies auch bei Schätzung des Aufwands bei der Implementierung neuer Features notwendig ist. Problematisch ist dabei, dass die innere Qualität und ihr Nutzen nicht klar erkennbar sind, sodass die Priorisierung schwierig ist. Bei einem Feature ist die Auswirkung für jeden Nutzer klar erkennbar und der Nutzen kann daher auch einfach bewertet werden. Bei Verbesserungen an der Qualität ist das leider nicht so einfach möglich.

Viele Teams legen die Entscheidung über das Abtragen der technischen Schulden in die Hände der Entwickler. Das erscheint zunächst sinnvoll, weil sie die technischen Schulden am besten bewerten und auch gut abschätzen können, welche Auswirkungen die technischen Schulden haben. Allerdings widerspricht dieses Vorgehen der Auffassung, dass diese Entscheidung eine Geschäftsentscheidung ist, weil es das Abtragen der Schulden beispielsweise gegenüber der Implementierung von neuen Features priorisiert. Um genau diese Kommunikation zu ermöglichen, ist ja die Metapher der technischen Schulden entstanden.

Sollen die technischen Schulden tatsächlich abgetragen werden, so gibt es dafür verschiedene Ansätze:

  • Die möglichen Optimierungen können analog zu Anforderungen beispielsweise in ein eigenes Backlog aufgenommen und dann jeweils umgesetzt werden, wenn Projektleiter und Team das für sinnvoll halten.
  • Alternativ ist es auch möglich, die Qualitätsverbesserungen wie eine besondere Art von Anforderung zu handhaben. Dann muss eine Priorisierung gegenüber Anforderungen erfolgen, was oft schwierig ist.
  • Für die Abarbeitung der technischen Schulden kann ein festes Budget verwendet werden. Beispielsweise könnten pro Iteration 10 Prozent des Aufwands in diesen Bereich investiert werden. Gegebenenfalls kann das Budget angepasst werden, wenn größere Maßnahmen notwendig sind. Mit diesem Ansatz ist es möglich, ständig in das Abtragen der Schulden zu investieren und so keine allzu großen Probleme entstehen zu lassen.
  • Alternativ ist es möglich, ein Release zu planen, in dem nur technische Schulden abgetragen werden. Dadurch ist es sehr einfach möglich, auch größere Änderungen vorzunehmen. Auf der anderen Seite steht dann die Weiterentwicklung still, was üblicherweise Kunden verärgert. Außerdem erhöht sich so das Risiko, dass in Optimierungen in Bereichen investiert wird, die gar nicht geändert werden. Wird das Abtragen neben der Implementierung neuer Features eingeplant, ist es einfacher möglich, das Abtragen der technischen Schulden auf die Bereiche zu konzentrieren, die absehbar auch geändert werden.

[ header = Seite 5: Fazit ]

Fazit

Durch die Metapher der technischen Schulden gibt es einen Ansatz, um die Kommunikation rund um Softwarequalität zwischen Entwicklern und Projektleitern zu verbessern. Dadurch kann dieses Problem angegangen und entschieden werden, wann und wo eine Investition in die innere Qualität sinnvoll ist. Technische Schulden sind keine exakte Wissenschaft, können aber hilfreich sein, um den Aspekt der Qualität bei der Softwareentwicklung in den Fokus zu rücken. So kann entschieden werden, wann Schulden aufgenommen und wann sie zurückgezahlt werden sollen. Dadurch verringert sich das Risiko bei der Softwareentwicklung, und alle Beteiligten können gemeinsam Entscheidungen in diesem Bereich treffen.

Geschrieben von
Eberhard Wolff
Eberhard Wolff
  Eberhard Wolff (http://ewolff.com) ist Java Champion und arbeitet als freiberuflicher Architekt und Berater. Sein technologischer Schwerpunkt liegt auf Spring, NoSQL und Cloud.
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>