· 

Möglichkeiten für den richtigen Umgang mit technischen Schulden

 

Anlässlich eines Vorstellungsgesprächs sollte ich eine kurze englische Präsentation über ein freiwählbares Thema im Arbeitsumfeld von Scrum vorbereiten. Ich habe mich für das Thema "Technical Dept – Tools & Practices" entschieden, da mir Qualität sehr wichtig ist und dieses Thema meiner Meinung nach ein wesentlicher Beitrag für ein erfolgreiches Produkt darstellt. Daher habe ich recherchiert, wie der richtige Umgang mit technischen Schulden aussehen könnte.

WAS SIND TECHNISCHE SCHULDEN?

Es ist eine Metapher, die bereits 1992 von Ward Cunningham geprägt wurde und stellt eine Aussage über einen zusätzlichen Aufwand dar, den man für Änderungen und Erweiterungen an einer schlecht geschriebener Software im Vergleich zu einer gut geschriebener Software eingeplant müsste. Jede Technische Schuld macht gemäß Tom Popendieck den Code schwerer zu ändern und hat somit direkten Einfluss auf die Wartbarkeit.

 

Im Alltag hat sich schnell ein solcher Fehler eingeschlichen, indem eine Codestelle schnell kopiert wird oder die Dokumentation des Codes vernachlässigt wird, da man es erst später machen will. Auch eine in die Jahre gekommene Architektur oder ein unzureichender Test führt zu einer technischen Schuld.

WAS SIND DIE LANGFRISTIGEN AUSWIRKUNGEN?

Folgende Auswirkungen entstehen in den verschiedenen Bereichen, wenn technischen Schulden ignoriert oder immer nur Symptome bekämpft werden:

  • Schlecht motiviertes Team mit niedriger Performance.
  • Je nach technischer Schuld können auch weniger innovative Neuentwicklungen oder Erweiterung die Folge sein.
  • Time to market verringert sich und Entwicklungskosten steigen, wenn Erweiterungen nur mit Umwegen auf Basis von schlechten Code entwickelt werden kann.
  • Negative Rückmeldungen vom Kunden, beispielsweise hinsichtlich Performance, sind kontinuierlich vorhanden. Somit verschlechtert sich auf Dauer die Kundenzufriedenheit und der Ruf des Unternehmens leidet.
  • Die Anzahl ist exponentiell steigend. Somit befindet man sich irgendwann in einer Abwärtsspirale.

WAS SIND DIE URSACHEN VON TECHNISCHEN SCHULDEN?

TechnicalDebtQuadranten

Martin Fowler stellt in seinem TechnicalDebtQuadranten eine Kategorisierung zur Verfügung, in dem ersichtlich wird, dass technischen Schulden entweder Absichtlich (Deliberate) oder Unbeabsichtigt (Inadvertent) entstehen. Zusätzlich unterschiedet er, ob dies Leichtsinnig (Reckless) oder Bewusst (Prudent) geschehen ist.

 

Absichtlich und Leichtsinnig

Aussagen: Keine Zeit für Design bzw. Kunde wartet
Dies beruht meistens aufgrund einer Management Entscheidung und entspricht nicht dem agilen Qualitätsverständnis. Einen Umbau zur Sicherstellung der Qualität von solchen "Quick & Dirty" Lösungen werden auch nicht in Zukunft eingeplant, sondern werden ggf. erst wieder relevant, wenn sich der Kunde beschwert.

 

Absichtlich und Bewusst

Aussage: Es muss ausgeliefert werden, die Konsequenzen sind klar
Die Entscheidung wird bewusst getroffen, um als Business Driver auf dem Markt agieren zu können. Die entsprechenden Risiken sind bekannt und es ist eingeplant, die technischen Schulden hier wieder zu reduzieren.
Erfolgt dies allerdings nicht, ist die technische Schuld irgendwann im ersten Quadranten angesiedelt.

 

Unbeabsichtigt und Leichtsinnig

Aussage: Was sind Layer?
Aufgrund von fehlendem Wissen können in diesem Fall unbewusst technischen Schulden entstehen. Durch Code Review, Coding Guidelines oder der Definition of Done in Scrum und entsprechenden Schulungen kann hier vorgebeugt werden.

 

Unbeabsichtigt und Bewusst

Aussage: Nun können wir es besser ...
Zum Zeitpunkt der Entwicklung entsprach die Umsetzung dem damaligen Wissens- und Technikstand. Da eine Weiterentwicklung sowohl in der Technik als auch Wissen vorhanden ist, würde unter Umständen die Umsetzung nun anders aussehen. Durch ein nachträgliches Refactoring kann hier eine Verbesserung des Codes erzielt werden.

 

WIE SOLL MAN MIT TECHNISCHEN SCHULDEN NUN UMGEHEN?

Umgang mit technischen Schulden

 1) Strategische Entscheidungen

 

Auf Basis einer Produkt-Portfolio Matrix, in der der Erfüllungsgrad der bereits umgesetzten und die zukünftigen Anforderungen gegenübergestellt wird, kann eine Entscheidung getroffen werden, wie mit der technischen Schuld umgegangen werden soll.

 

Problem Childs: In den gerade in der Entwicklung befindlichen Produkte sollten die technische Schulden prinzipell vermieden, damit Innovationen überhaupt möglich werden.

Rising Stars: Da dies die zukünftigen Cash Cows werden könnten, müssen die technischen Schulden alle ohne Kompromisse entfernt werden.

Cash Cow: Mit diesen Produkten wird das Geld verdient, so dass hier die Wartbarkeit eine große Rolle spielt. Die technischen Schulden müssen somit immer wieder neu betrachtet und kontinuierlich reduziert werden.

Poor Dogs: Hier sind die Produkte angesiedelt, die kein Geld (mehr) bringen und nichts mehr investiert werden sollte. Hier können die technischen Schulden einfach ignoriert werden.

 

2) Visualisierung

Es stehen zahlreiche Tools zur Verfügung, mit dessen Hilfe eine statische Code Analyse durchgeführt werden kann. Es können auf Basis verschiedener Qualitätsmetriken wie potentielle Bugs, nicht eingehaltene Coding Standards, Doppelter Code, Fehlende Dokumentation, Unit test und Testabdeckung eine ungefähre Abschätzung errechnet werden. Somit können technische Schulden kontinuierlich überwacht werden, so dass entsprechende Maßnahmen abgeleitet werden können.
Beispiele: ReSharper, SonarQube, Checkstyle

 

Zusätzlich sollten technische Schulden ebenfalls in einem globalen Backlog in einem Issue Tracker System wie JIRA mit einem eigenen Issue Type gepflegt werden. Zusätzlich ist es sinnvoll eine technische Schuld mit einem "Pain factor" zu versehen, mit Hilfe diesem eine Aussage getroffen werden kann, wie schmerzhalft es ist, wenn die technische Schuld nicht behoben wird.

 

3) Scrum

Scrum bietet einen guten Rahmen, dass das Scrum Team mit technischen Schulden umgehen kann:

  • Scrum Master: Der Scrum master ist dafür zuständig, dass das Management die technischen Schulden als solche wahrnimmt. Für das Team stellt er die Möglichkeiten sicher, dass technische Schulden in erster Linie vermieden, aber auch reduziert werden können.
  • Product Owner: Der Product owner übernimmt die Verantwortung für die Pflege der bestehenden technischen Schulden im globalen Backlog mit Pain factor. Auf Basis des Pain factors und je nach Strategie erfolgt die Priorisierung und es werden vom PO die entsprechenden Stories in der Sprintplanung vorgesehen.
  • Development Team: Dem Team stehen verschiedene Methoden zur Verfügung, damit von vorneherein technische Schulden vermieden werden können:
    - Definition of Done: Festlegung, keine neuen technischen Schulden aufzubauen, Messbar mit Tools für die statische Code Analyse
    - Pair programming und Code Review: Auf Basis des Vier-Augen Prinzip und Wissensverteilung kann technische Schulden vermieden werden
    - Coding Guidelines
    - Test Driven Development

 

FAZIT

Es ist somit sehr gut möglich, vor allem mit einer agilen Vorgehensweise, technische Schulden in den Griff zu bekommen. Es stehen unterschiedliche Methoden zur Verfügung, so dass technische Schulden beherrschbar werden. Qualität bleibt einfach der Stellhebel für den Erfolg eines Unternehmens und sollte daher niemals vernachlässigt werden.


Kommentar schreiben

Kommentare: 0