Deine Softwareentwicklung hat sich mit der Zeit deutlich verlangsamt? Du hast viel mehr Probleme, neue Features für dein bestehendes Produkt zu entwickeln? Von der SW-Qualität und den auftretenden Bugs brauchen wir erst gar nicht anzufangen. Das Entwicklungsteam betet vor jedem Deployment? Ich kann dich beruhigen, du bist nicht alleine! Aber das macht es natürlich nicht besser. Ein absolutes Grundkonzept in der SW-Entwicklung sind technische Schulden. Das Bewusstsein darüber und der richtige Umgang damit kann ein Erfolgsfaktor für dein Vorhaben sein. Dieser Artikel gibt dir einen Überblick zum Thema technische Schulden. Es soll vor allem die Konsequenzen aufzeigen, welche entstehen, wenn technische Schulden ignoriert werden.
Der Begriff technische Schulden wurde Anfang der 90er von Word Cunningham erstmals verwendet. Er beschreibt eine Metapher zu einem Kredit. Bei einem Kredit gibt es den eigentlichen Kreditbetrag, also die Schuld, welche zu begleichen ist. Zusätzlich gibt es noch Zinsen, welche bezahlt werden müssen, aufgrund dieses Kreditbetrages. Die Zinsen werden höher oder sind gleichbleibend, wenn sich der Kreditbetrag nicht verringert. Zurück zur Softwareentwicklung ist der Kredit beispielsweise eine schlechte SW-Implementierung, fehlende Tests, fehlende Automatisierungsmechanismen, schlechte Infrastruktur oder eine veraltete SW-Architektur. Die Zinsen sind Geschwindigkeitsverluste bei der Implementierung neuer Funktionalitäten oder Qualitätsverluste.
Gerade im Managementbereich spricht man zwar nicht von technischen Schulden, man spürt sie aber. Die Auswirkungen sind oft dann zu spüren, wenn man ein Produkt schnell auf dem Markt gebracht wurde und die Entwicklungsgeschwindigkeit anschließend deutlich absinkt. Die Fragen, welche dann oft im Raum stehen, können die Folgenden sein:
Von außen betrachtet und ohne das Wissen über technische Schuld sind alle diese Fragen komplett berechtigt. Die Antwort darauf ist jedoch, dass entweder der Kredit zurückgezahlt werden muss oder die Zinsen zu hoch sind.
Technische Schulden entstehen durch den gleichen Effekt, wie auch normale Schulden entstehen. Ich brauche im aktuellen Moment einen Betrag (Geld, SW-Leistungen) ohne dafür die Zeit fürs Sparen aufbringen zu müssen. Die Währung, mit der ich diesen Zeitvorteil bezahle, nennt sich Zinsen. Grundsätzlich ist es nicht Negatives einen Kredit zu nehmen, allerdings muss dieser dann auch zurückgezahlt werden oder ich muss mir der Zinsen bewusst sein.
Was sind die Gründe für technische Schulden in der SW-Entwicklung? Ein Hauptgrund, welchen ich gerade in der aktuellen Zeit sehe, ist zu viel Druck und zu wenig Zeit. Gerade wenn Unternehmen einen hohen Wettbewerbsdruck haben, entwickeln sie schnelle "Quick and Dirty" Lösungen, um den Markt nicht an den Konkurrenten zu verlieren. Es gibt durchaus Situationen, in denen das sehr sinnvoll ist. Das große Aber ist jedoch, dass uns bewusst sein muss, dass diese "Quick and Dirty" Lösungen auch wieder aufgeräumt werden müssen. Das kostet Zeit und Geld! Es darf nicht der Eindruck entstehen, dass das Produkt oder die Lösung schon fast fertig ist und danach keine Arbeit mehr benötigt.
Der Begriff, welcher diese Aufräumarbeiten beschreibt, ist Refactoring. Im Prinzip ist das Ziel dabei, den vorhandenen SW-Code zu optimieren. Gerade bei komplett neuen Produkten und neuen Teams ist die Lernkurve immens. So ist es völlig normal, dass SW-Entwickler immer wieder ihren SW-Code optimieren. Sie müssen nur Zeit dafür bekommen.
Ein anderer Grund für den Aufbau von technischen Schulden sind oft unklare Anforderungen zu Beginn. Das kann dazu führen, dass Funktionen gebaut werden, welche später nicht mehr oder anders benötigt werden. Oftmals weiß auch niemand mehr, warum diese Funktion eigentlich entwickelt wurde. Gerade in der agilen Softwareentwicklungen sind ändernde Anforderungen jedoch an der Tagesordnung.
Ein anderer Grund ist das fehlende Bewusstsein für Softwaretests und Automatisierung. Natürlich ist es viel cooler, ständig an neuen Features zu arbeiten. So sieht man viel besser die Früchte seiner Arbeit. Allerdings kann eine Ignoranz für Softwaretests und Testautomatisierung dazu führen, dass sehr lange keine Features mehr entwickelt werden können, da Zeit für Refactorings aufgewendet werden muss. Das ist aber nicht allein die Schuld der SW-Entwickler. Product Owner, welche immer nach neuen Features schreien, um die viel zu hohen Erwartungen zu erfüllen, sind ebenfalls eine Ursache.
Natürlich muss hier eine Balance gefunden werden zwischen einer schnellen Entwicklung von Features, um schnell Kundenfeedback zu bekommen und einer nachhaltigen Entwicklung. Es ist völlig klar, dass mehr Zeit für ein neues Release benötigt wird, wenn noch alle Tests dazu geschrieben werden. Allerdings gibt es kein Schwarz und Weiß. Die Implementierung von Softwaretests und Automatisierungsmechanismen helfen schneller neue Releases auf den Markt zu bringen und Kundenfeedback zu bekommen. Je nach Fall und Situation muss hier die optimale Lösung gefunden werden. Aber es gibt keine Entschuldigung dafür, kurz vor offiziellen Launch noch keinen einzigen Softwaretest geschrieben zu haben.
Ein weiterer Grund ist die fehlende technische Erfahrung im Team. Gerade bei kompletten Neuentwicklungen oder Plattformen, welche nicht nur für ein Produkt entwickelt werden, ist die technische Erfahrung absolut goldwert. Dabei ist Erfahrung nicht nur mit Alter oder Berufserfahrung gleichzusetzen. Eine neu verwendete Programmiersprache oder Technologie bringen auch berufserfahrene Entwickler ins Schwitzen. Positiv betrachtet hat das Team und die SW-Entwickler eine massive Lernkurve. Allerdings kann diese Lernkurve nur positiv genutzt werden, wenn die einzelnen Personen lange im Team bleiben. Eine ständige Durchmischung des Teams wirkt sich negativ auf die Lernkurve aus.
Mehr Zeit für Refactoring und auch externe Beratung können helfen technische Schulden durch fehlende technische Erfahrung zu minimieren.
Klares Nein! Es ist unmöglich, keine technische Schuld aufzubauen. Schulden oder ein Kredit sind an sich auch nichts Negatives. Es ist nur der Umgang damit, der zu langfristigen Problemen führt. Dabei geht es nicht um Schuldzuweisungen. Das gemeinsame Ziel ist es, langfristige besser Software entwickeln zu können.
Es ist die Verantwortung von SW-Entwickler, die technischen Schulden im Blick zu haben und aktiv darauf hinzuweisen. Es ist aber die Verantwortung vom Product Owner die aktuellen Probleme und Konsequenzen aufzuzeigen und sichtbar zu machen. Der Product Owner muss die Auflösung der technischen Schulden in der Planung entsprechend berücksichtigen.
Den größten Hebel hat jedoch das Management bzw. die Geschäftsführung. Die Konsequenzen eines "Quick und Dirty" Launches müssen allen bewusst sein. Die Bereitstellung von anschließender Zeit und Kapazität zur Auflösung dieser versteht sich von selbst. Es hilft aber schon, sich über das Thema technische Schuld bewusst zu sein. Das Management muss die Auflösung der technischen Schulden regelrecht einfordern, bevor an weitere Features entwickelt wird.
Die Konsequenzen von technischen Schulden sind eine sinkende Entwicklungsgeschwindigkeit. Die Auswirkung daraus ist je nach Produkt völlig unterschiedlich. Für ein Produkt, welches im Lebenszyklus weiter fortgeschritten ist, sind die Auswirkungen geringer. Je mehr Veränderungen und Anpassungen in der Zukunft liegen, desto schwerwiegender wirken die technischen Schulden.
Eine sinkende Entwicklungsgeschwindigkeit kann wiederum zu einer Verschlechterung der sogenannten "Time To Market" führen. Die Organisation ist nicht mehr in der Lage schnell auf Veränderungen zu reagieren. Veränderungen können vom Markt oder auch vom Kunden her resultieren. Die bildhafte Darstellung eines Tankers zeigt die Trägheit.
Die Inflexibilität durch technische Schulden ist besonders bei Plattformen gravierend. Damit sind Plattformen gemeint, welche Funktionalitäten nicht nur für ein Produkt anbieten, sondern gleich für eine ganze Reihe. Das Unternehmen ist nicht mehr in der Lage, zeitnahe Anpassungen oder Veränderungen durchzuführen.
Sind die technischen Schulden so weit vorangeschritten, dann ist manchmal der beste Rat, alles wegzuschmeißen und von vorne zu beginnen. Das trifft besonders auf technische Schulden innerhalb der Softwarearchitektur zu. Das mag zunächst alternativlos klingen, ist aber oft der beste Rat. Bevor sehr viel Zeit in Aufräumarbeiten gesteckt wird, kann man besser von vorne anfangen.
Softwareentwicklung ist eine sehr kreative Arbeit. Es erfüllt so viele Menschen mit Softwarecode neue Produkte zu entwickeln. Es ist kein Geheimnis, dass bei der Wissensarbeit zufriedene Mitarbeiter deutlich besserer Ergebnisse leisten. Fast niemand möchte die ganze Zeit nur mit Aufräumarbeiten beschäftigen. Viel mehr Spaß bringt es, neue, coole Features zu entwickeln. Genauso macht es wenig Spaß, nur Schulden abzubezahlen, ohne sich etwas gönnen zu dürfen.
Nach diesem Artikel bist du sicherlich total motiviert, jede technische Schuld aus dem Weg zu räumen. Das musst du allerdings gar nicht. Qualität, ob nun in der Softwareentwicklung oder nicht, ist kein Ziel an sich. Qualitätsverbesserungen oder Optimierungen müssen eine Produktivitätsverbesserung bringen. Da Zeit, Geld und Kapazität endlich ist, fokussierst du dich am besten auf die Produkte, welche in Zukunft eine hohe Produktivität benötigen. Die folgenden Punkte unterstützen dich dabei technische Schulden zu reduzieren.
Im ersten Schritt zeigst du jedem Product Owner und jedem im Managementteam diesen Artikel. Kleiner Spaß bei Seite. Die Bedeutung von technischen Schulden müssen jedem geläufig sein. Es kann auch transparent dargestellt werden, wie die aktuelle Verteilung im Sprint ist. In der Regel befinden sich im Sprint Artefakte zu den Themen Features, Bugs, Risiken oder technische Schuld.
Das Ziel dahinter ist mehr Zeit zu gewinnen, um technische Schulden gar nicht erst entstehen zu lassen oder sie abbauen zu können.
Der Product Owner kann für jeden Sprint neue Prioritäten setzen. Es spricht nichts dagegen, 1-2 Sprints komplett zu nutzen, um Aufräumarbeiten zu leisten. Je nach Team und Situation eignet es sich auch jeden Sprint Zeit für technische Schulden zu blocken. Empfehlenswert ist es, gemeinsam in einem Workshop mit dem Team zu entscheiden, welche technische Schulden die höchste Priorität haben. Erst dann ist eine sinnvolle Planung und eine Messung der Verbesserung auch möglich.
Software, welche nicht automatisiert testbar ist, führt langfristig immer zu einer Reduzierung der Entwicklungsgeschwindigkeit. Es verschwendet aber nicht nur Zeit beim Entwicklungsteam. Der Product Owner oder generell gesprochen die Qualitätssicherung muss alles manuell durchtesten. Dabei wird nicht fürs manuelle Testen Zeit verschwendet, sondern auch für die anschließende Beseitigung der Fehler. Je größer der Zeitraum zwischen eigentlicher Entwicklung und Feedback, desto ineffizienter.
Dabei gibt es so viele Tools und Mechanismen, welche helfen können. Vom richtigen Testmanagement angefangen, bis zu Mock Up Daten im Bereich IoT. Eine richtig aufgesetzte DevOps Strategie inklusive Organisationsveränderungen kann für mehr Flexibilität und Produktivität sorgen. Das ganze Wissen muss dabei nicht mühsam aufgearbeitet werden. Es gibt Experten auf dem Gebiet, welche helfen können. Das kostet natürlich Geld, aber ein frischer und neutraler Blick auf die Implementierung oder auch auf die Prozesse kann Wunder bewirken.
Wir haben jahrelange Erfahrung in den Bereichen Testmanagement und DevOps. Wir helfen bei einer Problemanalyse und anschließender Implementierung geeigneter Continuos Integration / Continuos Deployment Tools. Sprich uns gerne an, wir helfen dir weiter.
Erzähle uns in einem kostenlosen Erstgespräch mehr über dein individuelles Projekt. Wir helfen dir bei den nächsten Schritten und teilen unser Wissen.
Nachricht schreiben