«Später» muss definiert werden, sonst stolpern wir bald darüber

Jedes technische System ist akut gefährdet durch technische Schulden komplexer und instabiler zu werden. Selbst eine kleine Erweiterung oder Veränderung eines Umsystems kann zu einer technischen Schuld werden. Wie können wir diese zeitnah abbezahlen?

«Technische Schulden» ist eine treffende Metapher für die Folgen einer schlechten oder überholten technischen Umsetzung von IT-Systemen. Bei der Aufschiebung dieser Schulden, werden diese nicht kleiner, sondern grösser. Besonders bemerkbar machen sich diese bei der Geschwindigkeit der Umsetzung neuer Funktionalitäten oder in der Qualität.
Festgehalten werden muss, dass «technische Schulden» nicht vermeidbar sind und nicht nur auf schlechte Arbeit zurückzuführen sind.

«Das machen wir später» ist ein legitimes Fazit, wenn eine technische Schuld sichtbar wird. Aber «später» muss bald definiert werden, ansonsten ist es rasch zu spät die technischen Schulden in den Griff zu bekommen.
Die Probleme im Backlog zu parken ist ein guter Anfang – mehr nicht! Damit die technischen Schulden beglichen werden können, muss aktiv in die Verbesserung investiert werden.

Der Autor hat in den letzten 20 Jahren mehrere Refactoring-Projekte erlebt.
Diese Vorhaben hatten alle die gleiche Basis: Die technische Schuld war gross und spürbar. Die Stakeholder konnten überzeugt werden, aber die Akzeptanz blieb gering und der Aufwand wurde immer wieder unterschätzt. Irgendwann erhöhten die Geldgeber den Druck
, was neue technische Schulden begünstigte. Nach dem Projekt hiess es oft «nie wieder so ein grosses Refactoring». Um die Glaubwürdigkeit nicht zu verlieren, wurden rasch neue Funktionen implementiert, mit zunehmender Bereitschaft zu neuen Kompromissen…

Der nachhaltigere Ansatz ist eine stetige Verbesserung, welche nur gelingt, wenn dies in der Unternehmenskultur verankert wird. Die Autoren von «The DevOps Handbook» empfehlen, mindestens 20 Prozent für technische Schulden und nicht funktionale Anforderungen einzuplanen. Bei schlechter Ausgangslage deutlich mehr, damit der Berg schrittweise abgetragen werden kann, ohne ihn einfach zu verschieben. Engineers kennen ihre Systeme und können gut Auskunft geben, wo die technischen Schulden versteckt sind. Um diese langfristig zu minimieren, muss koordiniert und gezielt vorgegangen werden.

Dies erfordert eine gute Zusammenarbeit, Vertrauen und hohes Engagement aller Beteiligten in der ganzen Firma. DevOps und Frameworks der agilen Arbeitsmethodik beantworten lange nicht alle Herausforderungen, welche in diesem Spannungsfeld der raschen Weiterentwicklung und stetigen Verbesserung auftauchen. Kleine Intervalle und stabile interdisziplinäre Teams bieten eine gute Ausgangslage für die folgenden vier Prinzipien [1].

  1. Entdeckte technische Schulden werden sofort abgebaut
    Übersteigt der Aufwand ein definiertes Mass, werden die Arbeiten im Backlog erfasst und priorisiert.
  2. Die teuersten technischen Schulden werden zuerst abgebaut
    Das Team schätzt die Konsequenzen ein, um die Priorität festzulegen.
  3. Technische Schulden schrittweise abbauen
    Die stetige Verbesserung sensibilisiert das ganze Team und spornt zu mehr Sorgfalt an.
  4. Nicht alle technischen Schulden müssen zwingend abgebaut werden
    Einige Schulden werden bewusst in Kauf genommen. (Beispiele: Prototypen / Produkt ist kurzlebig oder am Ende seines Lebenszyklus)

Doch die Prioritäten richtig zu setzen und fokussiert an einzelnen Themen zu arbeiten, verlangt dem Team und der ganzen Firma viel ab. Die Alternative «es später zu tun» ist noch schwieriger, denn für kleine Verbesserungen ist es bald zu spät.

 

Quellen und weiterführende Links

Beitrag teilen

Andreas Stoller

Der Autor arbeitet als Head of Development bei der Unico und bloggt im Rahmen des CAS DevOps Leadership and Agile Methods.

Alle Beiträge ansehen von Andreas Stoller →

Schreibe einen Kommentar