Wie man mit technischen Schulden in der agilen Software-Entwicklung umgeht

Technische Schuld

Beitrag teilen

Teilen auf facebook
Teilen auf linkedin
Teilen auf twitter
Teilen auf email

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.

Subscribe To Our Newsletter

Get updates and learn from the best

Weitere Blog-BeitrÀge

Human Resource Management mit Jira
XALT News

So managst du Human Resources mit Jira

Es gibt unzÀhlige Tools zum Managen von Human Resources. Dabei ist meist wichtig, dass diese einfach implementiert werden und möglichst schnell von allen Mitarbeitern

Quality Assurance Testing mit XRAY for Jira
Atlassian

Quality Assurance Testing mit Xray und Jira

FĂŒr ein IT-Unternehmen ist es besonders wichtig ein Software-Produkt mit einer hohen QualitĂ€t zu liefern. Die Verbesserung von Softwareentwicklungsprozessen und deren Automatisierung stellt eine

Better Call Xalt

Unsere UnterstĂŒtzung

Wir haben Ihr Interesse geweckt? Zögern Sie nicht, mit uns in Kontakt zu treten. Sie erreichen uns per Telefon, E-Mail oder in unserem BĂŒro.

Dr. Veronika Traidl

Veronika Traidl

Tomannweg 3, 81673 MĂŒnchen

Einkaufskorb