Category

Neue Funktionen müssen immer schneller implementiert werden, dabei geht «Funktion» oft vor Softwarequalität und Code-Qualität. Die «technische Schuld» (englisch: technical debt ) ist eine Metrik – oder ein Begriff – für die «Kosten», die entstehen, um die Qualität der SW (Code-Qualität, SW Architektur) und somit auch die Sicherheit einer fehlerfreien Ausführung wieder herzustellen. Die «technische Schuld» ist per se nicht schlecht, aber sie muss von der Führung aktiv gemanagt werden. Dazu muss sie als Führungskennzahl erfasst werden, sichtbar sein und regelmässig überwacht werden. Heimtückischer weise wächst sie nicht linear sondern sprunghaft oder gar exponentiell.

In einer guten Teststrategie wird durch das Management die Risikobereitschaft definiert. Dabei wird –ähnlich wie bei einem Kredit oder einer Hypothek – die Tragbarkeit der «technischen Schuld» geprüft. Ein Done ist erst dann ein «gültiges Done», wenn auch die mit der Implementierung der neuen Funktionen einhergehende «technische Schuld» wieder abgebaut – oder eben zurückbezahlt- ist. Moderne Tools liefern Metriken zum einfachen und systematischen Erfassen dieser wichtigen Führungskennzahl.

Wie gross ist Ihre «technische Schuld» können Sie es sich leisten?
In erfolgreichen SW Projekten wird die «technische Schuld» einer Strategie folgend verwaltet. Die Schuld wird gezielt aufgebaut, aber ebenso geplant wieder abgebaut. Dies hat Einfluss in die Planung sowie die Gestaltung des Entwicklung- und Testprozess. Dies liegt in der Verantwortung der Führung und des Managements.

Investitionen in gute Codequalität und gute Architektur sind nachhaltige Investitionen. Über 80% der Entwicklungs-Arbeiten sind Wartungsarbeiten sowie Änderungen an bestehendem Code. Prof. Niklaus Wirth meinte einmal, dass SW nicht für den Compiler geschrieben wird, sondern für Menschen die den Code warten müssen. Stellt sich die Frage nach „ quick and dirty “, ist die Tragbarkeit der «technischen Schuld» mit zu berücksichtigen, denn irgendwann wird die Schuld untragbar oder so gross, dass ein «Neubeginn» billiger wird. Versicherungstechnisch spricht man hier von einem «Total-Schaden». Oft wird bei «quick and dirty Lösungen»  immer wieder im gleiche Stil weiter «gewurstelt». Neben bestehenden schlechten Codestellen fallen weitere «Spaghetti – Zeilen» nicht mehr auf, ein Freipass…

So beginnt ein Teufelskreis, denn mit der wachsenden «technischen Schuld», verlangsamt sich –wegen unlesbarem und schlechtem Code – auch die Entwicklungsgeschwindigkeit. Dies verzögert das Fertigstellen neuer Features und das Projekt muss mit explosiv steigenden Opportunitätskosten leben.

Die Idee von «Quick» und Time to Market lässt sich nicht mehr realisieren!

Was empfiehlt NOSER?
Eine gute Teststrategie definiert den Umgang mit der «technischen Schuld». Das Management und die Führung muss hier in die Pflicht und Verantwortung genommen werden. Als Führungskennzahl wird eine zum Projektziel passende Obergrenze für die “technische Schuld” definiert. Limitieren heisst das Zauberwort! In agilen Prozessen muss die Definition of Done eine Aussage über die «technische Schuld» beinhalten.

Detail bei Fowler: „Technical Debt Quadrant“ (http://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html)

Die «technische Schuld» muss bewusst erfasst und gemanagt werden. Aufgebaute «technische Schuld» muss unter der definierten Grenze bleiben und geplant abgebaut werden. Dazu gibt es bewährte Prinzipien wie Codereview oder «Boyscout». Ebenso können «technische Schulden» mit gezielten User Stories abgebaut werden (z.B. einen festen Anteil an Stories für technische Schuld im Sprint einplanen). Wichtig ist jedoch, dass die Schuld sowie deren Verlauf transparent ausgewiesen wird.

Fazit
Es ist wichtig, bei den Entscheidungsträger ein Bewusstsein für die «technische Schuld» zu schaffen. Es ist wichtig, die «technische Schuld» als Führungskennzahl in der Projektleitung zu etablieren und deren Umgang in der (Test-) Strategie festzuhalten.