Technischen Schulden in der agilen Software-Entwicklung

Technische Schuld

Beitrag teilen

Stell dir vor du fährst Auto und merkst, dass deine Bremsen nicht mehr richtig funktionieren. Doch statt diese direkt reparieren zu lassen, entscheidest du dich zunächst dazu, dein Auto zu waschen und ein neues Radio zu installieren und deine Bremsen provisorisch mit alten Teilen instand zu setzen. So baust mit deiner Priorisierung, der DurchfĂĽhrung anderer Aufgaben und der quick & dirty Lösung eine Technische Schuld (Technical Dept) auf. 

Technische Schuld im Laufe der Zeit

FrĂĽher oder später rächt sich allerdings diese Herangehensweise, da die Technische Schuld nicht wie erwartet linear zunimmt, sondern mit der Zeit exponentiell wächst. 

Indem immer mehr dieser quick & dirty Herangehensweisen innerhalb der Entwicklung verwendet werden, wird der Berg an Schulden immer größer. Dies führt letztendlich dazu, dass zur Lösung der Probleme unzählige Tasks abgearbeitet werden müssen.

Geschuldet ist diese Entwicklung grundsätzlich auch der Tatsache, dass aufgrund der Verwendung von agilen Arbeitsmethoden und DevOps der Druck durch Stakeholder wächst, um in immer kĂĽrzeren Zeitspannen mehr zu erreichen. 

Im Rahmen dieses Artikels wird näher darauf eingegangen, was technische Schuld genau ist und welche Ursachen es für diese Schulden gibt. Wie sich diese auf ein Produkt oder Service auswirkt. Und wie man sie effektiv verwalten kann.

Was sind technische Schulden?

Immer dann, wenn unsaubere Wege gegangen werden, entsteht eine neue Schuld gegenĂĽber allen beteiligten Stakeholdern. Diese Schuld wird meist dann sichtbar, wenn genutzte Systeme oder Software nicht richtig funktionieren oder instabil laufen. Um diese Fehler zu beheben, bedarf es anschlieĂźend erheblichen Mehraufwand.

Dies lässt sich zusätzlich noch weiter vereinfachen, indem man diese Schuld als Kluft zwischen einer wohlüberlegten, designten, entwickelten und getesteten Software und einer Software, die einfach mal so zusammengeschustert wurde, ansieht.

Woran erkennt man technische Schulden?

  • Fehlende oder keine Dokumentation: Heutzutage soll schnell und agil gearbeitet werden. Da bleibt die Dokumentation oftmals liegen. Dies fĂĽhrt jedoch dazu, dass meist nur wenige wissen, welchen Stand das Projekt bereits hat. Andere oder neue Mitarbeiter bleiben da auĂźen vor und arbeiten stur darauf los. 
  • Wir kĂĽmmern uns später darum: Klar, Projekte mĂĽssen abgeschlossen werden. Doch wie sagt man so schön? “Machs’ gleich richtig, sonst machst du’s doppelt”.
  • Copy & Paste aus anderen Projekten
  • AbkĂĽrzungen und Einsparungen: Qualitätskontrolle und Testings werden beispielsweise aufgrund von Deadlines nicht durchgefĂĽhrt
  • Bugfix und kleinere Anpassungen benötigen länger zur Implementierung

Welche Ursachen gibt es fĂĽr den Aufbau von technischer Schuld?

Fehlende Vision oder Konzept der fertigen Software

Es sollte von Anfang an klar sein, was entwickelt werden soll. Fehlt dies, kommt es sehr oft zu Nacharbeiten am Design, User Interface, der Architektur oder Infrastruktur. Die führt während des gesamten Projektes zu Problemen und Qualität am Code.

Fehlende oder mangelhafte Dokumentation von Requirements

Oft sind Software-Anforderungen nur vage oder wenig beschrieben. Dies führt dazu, dass Teams und Mitarbeiter nicht zu 100 % wissen, was genau erreicht werden soll. Dadurch entsteht zusätzliche Belastung und damit neue technische Schuld.

Fehlende Kommunikation und hohe Erwartungshaltung durch das Management

Bei Projektstart, neuen Teams oder bei der Zusammenarbeit mit externen Dienstleistern kann es vorkommen, dass eine zu hohe Erwartungshaltung an das Projekt-Team vorherrscht und möglichst schnell erste Resultate erzielt werden sollen. Deshalb gilt möglichst frühzeitig den maximalen Workload zu kommunizieren und so auf Qualität statt Quantität zu setzen.

Unzureichende Zusammenarbeit der Mitarbeiter

Heutzutage wird in der Software-Entwicklung meist mit agilen Methoden wie SCRUM gearbeitet. Dadurch geht man davon aus, dass alle beteiligten Mitarbeiter diese Methodik beherrschen und auf Anhieb miteinander zusammenarbeiten können. Dies ist oft nicht der Fall und führt schnell zu Misskommunikation und Frust im Team. Tickets bleiben liegen und / oder werden nur spärlich bearbeitet. Und täglich kommen neue Issues hinzu.

Flaschenhalseffekt – Fehlende Mitarbeiter, Zeit und zu viele Tasks als Hindernis

Problematisch wird es weiterhin, die “Schulden” abzubauen, wenn Mitarbeiter selbst zum Flaschenhals im Unternehmen werden. Oftmals kann es der Fall sein, dass nur wenige Mitarbeiter sich in Systemen auskennen und diese zu pflegen wissen. Sind diese Mitarbeiter dann verhindert, krank oder kĂĽndigen im schlimmsten Fall das Arbeitsverhältnis, kennt sich niemand mehr im System aus und es kommt zu einem vollständigen Stillstand. Ein solcher Fall sollte bereits frĂĽhzeitig erkannt werden und aktiv dagegen angegangen werden.

Wechsel der verwendeten Technologie oder einer neuen Version

Täglich gibt es Updates, welche Veränderungen im Code und der Herangehensweise verursachen. Dadurch kann es vorkommen, dass existierende Code-Bausteine überflüssig werden, nicht mehr benötigt werden oder Probleme verursachen. Dies muss erst in einer weiteren Iteration behoben werden und führt wiederum zu technischer Schuld.

Fehlender Prozess zur Qualitätskontrolle

Sowohl bei kleinen als auch großen Teams ist Qualität im Code stets zu überprüfen, um herauszufinden, ob am Ende alle Teile perfekt zusammenarbeiten. Fehlende Prozesse zur Qualitätssicherung verursachen letztendlich zusätzliche Arbeit und weitere Tasks zur Problembekämpfung.

Die Ursachen, die dazu führen, dass technische Schuld aufgebaut wird, können vielfältig sein. Die hier aufgelisteten sind ein erster Anhaltspunkt, um direkt und proaktiv zu handeln.

Wie kann mit technischer Schuld umgangen und diese abgebaut werden?

Unabhängig davon, wie technische Schuld zustande kommt, gibt es einige Handlungsempfehlungen, um die Entstehung proaktiv zu vermeiden.

Priorisierung von Tasks

Wurden Versäumnisse ausgemacht, gilt es zunächst, diese zu dokumentieren und anschlieĂźend zu priorisieren. Wie diese Versäumnisse priorisiert und angegangen werden, hängt letztendlich von den geschaffenen Rahmenbedingungen (Team, Arbeitsmethode, strategische Entscheidungen oder den verwendeten Tools) ab. 

In agilen Teams ist es meist bereits der Fall, dass in täglichen Meetings oder Sprints die Priorität von Tasks festgelegt wird. Wiederkehrende Issues und andere Tickets werden daher meist höher eingestuft und zeitnah bearbeitet. Zusätzlich ergibt sich die Priorisierung von Tasks auch durch den Impact des Problems auf die ganzheitliche Unternehmung (z.B. Impact auf Usability, Umsatz oder Experience) oder wie wichtig eine Lösung fĂĽr die Performance des Produkts oder der Software ist. Die restlichen Tickets (z.B. Irrelevant fĂĽr den derzeitigen Sprint) sollten im Backlog an höchster Stelle abgelegt werden und in den nächsten Meetings mit in den Sprint aufgenommen werden. 

Entwicklung eines Code-Styleguides

Eine einfache Möglichkeit technische Schulden nicht entstehen zu lassen, ist es bereits vor Projektstart Richtlinien festzulegen. Dadurch soll sichergestellt werden, dass nicht mehrere verschiedene Herangehensweisen verwendet werden.

Diese sollten im Optimalfall definieren, wie Code genau aussehen soll. Das heißt beispielsweise an welche Stelle Kommata, Breaks oder Klammern gesetzt werden müssen. Dies bietet zusätzlich den wesentlichen Vorteil, dass die Struktur und Layout des Codes übersichtlich sind.

Code Refactoring

In der Hitze des Gefechts kann es schon mal vorkommen, dass Code einfach so geschrieben wird, ohne auf dessen Struktur oder Lesbarkeit zu achten. Dies erschwert im weiteren Projektfortschritt den Ăśberblick zu behalten, Bugs zu fixen oder neue Features zu implementieren. Um Herr der Lage zu werden, bietet das Code Refactoring eine Herangehensweise den vorhandenen Code Schritt fĂĽr Schritt zu optimieren und zu ĂĽberarbeiten.

Tools zur Visualisierung von technischer Schuld

Mit Hilfe von einigen Tools lassen sich Versäumnisse oder Strukturprobleme im Code bereits von Anfang an vermeiden oder zumindest im Nachhinein überprüfen und optimieren. Eines davon ist SonarQube.

Dieses Tool analysiert deinen Code auf Qualität, Sicherheit und gibt an, an welchen Stellen Code-Segmente zum Beispiel doppelt enthalten sind. Weiterhin gibt es eine zeitliche Einschätzung an, wie lange der Abbau von technischen Schulden innerhalb des Codes dauert.

SonarQube bietet die Möglichkeit zukĂĽnftige technische Schulden bereits beim Build Prozess der Software zu erkennen und kann so konfiguriert werden, dass Builds den Status “failed” erhalten, wenn die technische Schuld zu groĂź ist.

Keine Individual Code Ownership zulassen

Wie oben bereits angesprochen, ist es keine gute Idee, nur eine bzw. wenige Person(en) / Entwickler fĂĽr wichtige System verantwortlich (und unersetzbar) sind. Wenn es ein Problem mit der Web-Anwendung gibt, ist der Code-EigentĂĽmer die Person, die es beheben muss. Code Ownership ist schlecht fĂĽr Code-EigentĂĽmer, weil es ihr und das Unternehmens-Wachstum bremst. AuĂźerdem verursacht Code Ownership Probleme fĂĽr die Organisation und fĂĽr die Code Owner. Wenn niemand weiĂź, wie ein System funktioniert, kann niemand effektive Code-Reviews geben. Schlimmer noch, der Code wird vielleicht gar nicht ĂĽberprĂĽft.

Wenn das Team fĂĽr den Code verantwortlich ist, kann jeder dabei helfen, Designentscheidungen zu treffen. Jeder kann sich an der Diskussion ĂĽber das Systemdesign beteiligen, Ideen einbringen und die Verantwortung fĂĽr diese Entscheidungen mittragen. Weiterhin ist es nicht mehr so schlimm, wenn ein Mitarbeiter nicht mehr am Porjekt beteiligt oder krank ist. 

Zusammenfassung

Man muss sich im Klaren sein, dass “technical debt” zunächst keinen offensichtlichen und spürbaren Mehrwert bietet und es gewisse Zeit in Anspruch nimmt diesen abzubauen. Weiterhin werden die meisten Ergebnisse erst mit der Zeit messbar und sichtbar. Jedoch bedeutet dies nicht, auf der faulen Haut liegen zu bleiben und auf das Beste zu hoffen. Man sollte sich am Ende also die Frage stellen, für welche Schulden ist es sinnvoll, diese abzubauen, welche haben den größten Impact auf geschäftliche oder wirtschaftliche Faktoren und bei welchen würde ein Abbau keinerlei Auswirkungen haben.

Das könnte dich auch interessieren

Philip Kroos 2023-09-22
0

Confluence Whiteboards (beta) – Das Ende von Miro?

EinfĂĽhrung Stellen Sie sich Folgendes vor: Sie befinden sich in einer virtuellen Besprechung, Ihr Team

Atlassian
Mario Schaefer 2023-08-22
0

Jira vs Jira Service Management vs Jira Work Management

In der schnelllebigen digitalen Welt von heute ist effektives Projektmanagement der Grundstein für erfolgreiche Geschäftsabläufe.

Atlassian
Mario Schaefer 2023-07-06
0

Ein Vergleich beliebter Container-Orchestrierungs-Tools

Table Of ContentsshowÜberblick: Tools für die Container-OrchestrierungErläuterung der gängigen ToolsKubernetesWarum ist Kubernetes so beliebt?AnwendungsfälleVergleich mit

DevOps
Einkaufskorb

B/S/H

Die BSH Hausgeräte GmbH ist der größte Hersteller von Haushaltsgeräten in Europa und eines der weltweit führenden Unternehmen in dieser Branche.

Projekte & Lösungen