Artikel

Technische Schuld(en) im Projekt

Beitrag von Ilona Hachmann
11. Dezember 2014

Ich mag diese Wortkombination, obwohl die Bedeutung dahinter keine schöne ist. Es gibt quasi keine Softwareentwicklung, ohne (Technische) Schulden aufzunehmen. Wobei dieses Phänomen durchaus auch in anders gearteten Projekten auftreten kann. Der Begriff „Technische Schuld“ steht für die möglichen Konsequenzen durch eine schlechte technische Umsetzung der Anforderungen während des Softwareentwicklungsprozesses. Es meint den Aufwand (Kosten!), der benötigt wird, um Änderungen an schlechtem Code durchzuführen, im Vergleich zu vorbildlich programmierter Software.

Es gibt unterschiedliche Arten der Technischen Schuld:

Sie wurde bewusst aufgenommen, um einen Termin zu halten.
Sie wurde versehentlich aufgenommen, weil man es nicht besser konnte oder wusste.

Ich habe noch kein Softwareentwicklungsprojekt ohne Technische Schulden kennen gelernt, seien es die vorhandenen oder bei der Entwicklung neu aufgenommene.

Gerade bei den bewusst aufgenommen Schulden sind die Ursachen vielfältig, und die Entscheidung dafür muss in dem Moment nicht unbedingt schlecht gewesen sein. Alle Für und Wider wurden sicherlich gewissenhaft abgewogen. Doch irgendwann holt sie einen ein. Der ursprünglich rasch gewonnene Produktivitätsschub durch den damals eingegangenen Qualitätskompromiss rächt sich bitterlich. So kann u.U. der Einbau neuer Dialogfelder zu horrenden Entwicklungszeiten führen oder ist gar überhaupt nicht mehr möglich. Wenn es dann brennt, ist eine Diskussion bzgl. Tilgung der Schulden unvermeidbar. In der Phase, in der es noch zwickt, werden Schulden häufig wegignoriert – gerade vom Management. So war es doch schließlich der Entwicklertrupp, der so programmiert hat, oder?

Welche konkreten Technischen Schulden gibt es in der Software? Wie hoch (in Bearbeiterjahren) sind eigentlich die Technischen Schulden? Welche und wie können die getilgt werden? Müssen sie überhaupt getilgt werden?

In einer offenen Projektkultur könnten die bewusst eingegangenen Schulden bereits während des Entstehens notiert werden. In einer agilen Umgebung werden sie z.B. in einem (Technical-)Backlog abgelegt. Für Schulden aus Unwissenheit gibt es analytische Tools, die bestimmte Qualitätsmerkmale in einer Software überprüfen (z.B. Entwicklungsrichtlinien, doppelte Codefragmente). Die identifizierten Schulden können nun bewertet und geschätzt werden. Garantiert treten Abhängigkeiten zwischen einzelnen Themen auf. Nach der Bestandaufnahme folgt die Überlegung, ob und wie getilgt werden kann.

Zur Tilgung können folgende Ansätze überlegt werden:

Die weitere Aufnahme von Schulden ist verboten. Dies wird über zuvor festgelegte Qualitätskriterien garantiert und fortlaufend gemessen. Stichwort Quality Gates.
Definiere verschiedene Maßnahmen, die sukzessive umgesetzt werden (Code kommentieren, doppelten Code beseitigen, Abhängigkeiten entzerren, Architektur-Redesign).

Alle Ansätze sind unterschiedlich aufwändig, und sofort stellt sich die Frage nach dem Budget.

Was nun im Einzelnen für das aktuelle Softwareentwicklungsprojekt das Sinnvollste ist, lässt sich nur situationsabhängig bewerten. Manchmal ist es vielleicht auch besser, eine Software oder einen Teil davon sterben zu lassen.
Hier ahnt man es, mit einer Entscheidung wie z.B. Reorg durch Neuentwicklung gerät man wieder an den Anfang der Schulden-Schleife.

Am Besten ist es sicherlich, zu Beginn des Projekts einfach keine Schulden zu machen. Ein anspruchsvolles Ziel und eher unwahrscheinlich einzuhalten. Realitätsnäher ist es, die Schulden frühzeitig zu erkennen und im laufenden Betrieb sanfte Änderungen vornehmen. Schritt für Schritt für Schritt.

Doch wie bei so vielen Dingen im Leben gilt auch hier: Hauptsache anfangen!

Weitere interessante Artikel:

| Keine Kommentare