Table of Content
Alle Teams kämpfen mit technischen Schulden und jedes Software-Team erzeugt technische Schulden, die es zu minimieren versucht. Einige Teams sind besser in der Erstattung dieser Schulden als andere und es gelingt ihnen, die negativen Auswirkungen der Technologieverschuldung zu erkennen, mögliche Auswirkungen zu quantifizieren, Fehlerbehebungen zu priorisieren und sich auf einen Lösungsplan festzulegen.
Technische Schulden ziehen die Softwareentwicklung nach unten. Sie erschweren das Erstellen, Ausführen und Bereitstellen von Code und können sogar zu größeren Produktivausfällen führen. Die Behebung technischer Probleme ist der einfache Teil und erfordert in der Regel ein Refactoring oder eine Änderung des Codes. Der schwierige Teil ist die Priorisierung und Quantifizierung der technischen Schulden. Software-Teams scheitern an der Schuldenbewältigung, weil sie den Ball nicht schnell genug ins Rollen bringen, nicht weil sie technische Probleme nicht lösen können.
Die Begleichung der technischen Schulden und die Entwicklung von Funktionen konkurrieren ständig um die Priorität des Rückstands. Bei der Umstellung der Anwendungsentwicklung von Wasserfall auf Agile werden technische Schulden oft von alten Systemen und Code übernommen. Es gibt keine Einheitslösung für die Beseitigung von technischen Schulden, aber es ist klar, dass agile Teams sie routinemäßig in vielen verschiedenen Formen angehen müssen. Und die Arbeit an den falschen Themen für eine bestimmte Art von Schulden verschwendet wertvolle Ressourcen und Zeit und unterläuft agile Prinzipien.
Drei Gesichter: Lokal, global und systemisch
Einige Schulden zwingen die Teams schließlich dazu, einen Software-Konkurs zu erklären, während andere einfache Zinszahlungen rechtfertigen. Triviale Schulden können ignoriert werden, da sie jederzeit beglichen werden können. Teams unterliegen dem Irrtum, dass alle technischen Schulden getilgt werden sollten. Die Wahrheit ist jedoch, dass nur die unhaltbarsten Schulden beseitigt werden müssen. Die technische Verschuldung gliedert sich in drei Kategorien: lokal, global und systemisch. Und es ist wichtig, jeden Typ richtig zu kategorisieren, um das Haltbare vom Unhaltbaren zu trennen.
Lokale Schulden
sind in einer einzigen Methode, Klasse oder Funktion eingeschlossen. Stellen Sie sich SOLID-Verstöße vor, die auf eine Methode, Klasse, Funktion oder einzelne Datei angewendet werden. Ihre Auswirkungen sind nur bei der Änderung des betreffenden Codes zu spüren
Globale Schulden
sind in einer einzelnen Anwendung oder einem Service enthalten. Im Gegensatz zu den lokalen Schulden handelt es sich bei den globalen Schulden um SOLID-Verstöße in einem größeren System über Subsysteme hinweg, die sich auf scheinbar unzusammenhängende Bereiche ausbreiten. Beispiele dafür sind ein Missverhältnis zwischen Abstraktionsschichten (Darstellung vs. Daten), Probleme an anderen Integrationspunkten und harte Kopplung. Diese Probleme wirken sich nicht auf die Nutzer der Anwendung oder des Dienstes aus, sondern sind bei der Änderung des Dienstes selbst zu spüren.
Systemische Schulden
laufen über mehrere Anwendungen, Infrastrukturen oder sogar Teams hinweg. Beispiele hierfür sind mehrere Dienste, die sich einen Datenspeicher teilen, eine hohe Kopplung über verschiedene Kontextgrenzen hinweg und ein krasses Missverhältnis zwischen technischen Implementierungen und Geschäftslogik. Systemische Schulden sind langfristig unhaltbar.
Jede Kategorie von Schulden birgt unterschiedliche Auswirkungen, daher müssen sie unterschiedlich priorisiert und behandelt werden.
Lokale technische Schulden: Agile ‚Low-Hanging Fruits‘
Bekannte Refactoring-Techniken wie „Extract Method“ oder „Extract Superclass“ beseitigen üblicherweise lokale technische Schulden. Sie können sogar bekannte Code-Katas spiegeln, wodurch sie die wenigsten Konsequenzen haben oder sogar geradezu trivial werden. Schauen wir uns ein Beispiel an:
Ein Entwickler hat vor einem Jahr Code geschrieben. Der Code ist überkompliziert, aber durch Tests abgedeckt. Es ist bei weitem nicht der beste Code, aber er funktioniert. Die Business-Anforderungen haben sich nicht geändert, also bleibt der Code so, wie er ist.
Es kann sein, dass die Entwickler den Code restrukturieren wollen, aber es lohnt sich nicht, da sich der Code in einem Jahr nicht geändert hat. Andererseits hemmt die lokale technische Schuld in häufig modifiziertem Code die Entwicklung, da ein solcher Code in der Regel den Kern eines Unternehmens bildet und mehr Entwickler ihn verstehen und modifizieren müssen. Hier Schulden zu beseitigen ist wie die Beseitigung von Schlaglöchern, um die Überholspur einer Autobahn zu erhalten. Wenn technische Schulden nicht richtig adressiert werden, dann werden Entwickler zunehmend morschen Code als Workaround schreiben, was letztendlich zu globalen technischen Schulden führen kann.
Statische Codeanalyse-Tools können lokale technische Schulden mindern und ihre Ausführung vor dem Commit und als Teil der Deployment-Pipeline eliminiert die Schulden praktisch. Aber Sie brauchen einen anderen Ansatz, um bestehende Probleme zu bekämpfen. Zunächst ist es gut, neuen Teammitgliedern lokale Fixes als Lernübung zuzuweisen. Teams können auch die “Pfadfinderregel” anwenden, dass der Code besser als bisher hinterlassen werden sollte. Eine Praxis, die gut funktioniert, da Code-Verbesserungen proportional dazu sind, wie oft der Code geändert wird.
Globale Technische Schulden: Erste Anzeichen für Ärger
Globale Technische Schulden sind schädlich. Hier ist ein Beispiel aus einer typischen MVC-Webanwendung:
Das Team isoliert komplexe Ansichtsebenen in eine Darstellungsschicht und eine neue Anforderung besteht darin, dass die Benutzeroberfläche benutzerdefinierte Daten anzeigen muss. Die vorhandenen Mittelschichten unterstützen dies nicht, so dass die Darstellungsschicht direkt auf die Datenbank zugreift. Dies ist zunächst eine undichte Abstraktion, die die Theorie der zerbrochenen Fenster auslösen und auf andere Bereiche übergehen kann.
Das kommt im echten Leben häufiger vor, als Entwickler es gerne zugeben. Leider gibt es keine schnelle Lösung für diese Probleme, da eine Lösung die Konzentration auf den gesamten zugehörigen Code erfordert. Senior-Entwickler sind am besten geeignet, die Schulden zu tilgen, indem sie Interessen sorgfältig trennen, Grenzen schaffen und größere architektonische Interessen durchsetzen.
Vernünftige Governance- und Workflow-Verbesserungen können Probleme mildern, bevor sie auftreten, und das Hinzufügen einer sorgfältigen Codeüberprüfung zu bestimmten Releases ist ein guter Ausgangspunkt. Nicht alle Releases sind gleich. Releases, die Code über Grenzen hinweg ändern oder grundlegende Geschäftskonzepte überarbeiten, müssen sorgfältig geprüft werden, um die technische Verschuldung zu minimieren. Releases, die eine einzelne, weniger genutzte Klasse modifizieren, nicht. Diese Überlegungen sollten sich in den Arbeitsabläufen nach vorn verlagern, d. h. die Entwickler sollten mögliche technische Schulden so früh wie möglich besprechen, um spätere Probleme zu mildern.
Globale technische Schulden müssen berücksichtigt werden, wenn sie die Entwicklung von häufig modifiziertem Code behindern. Wenn die Lösung nicht sofort klar ist, dann führen Sie einen Spike zu einer mögliche 80/20-Lösung durch und handeln Sie schnell, bevor die Situation zu einem systemischen Problem wird. Das Aufräumen wird Zeit aus den Sprints in Anspruch nehmen, also planen Sie entsprechend.
Systemische Technische Schulden
Systemische Technische Schulden sind die gefährlichste Form, die sich in allen SDLC-Phasen manifestiert. Sie können die Entwicklung ernsthaft verlangsamen, Entwickler demotivieren, eine Neufassung erzwingen oder sogar das Unternehmen ruinieren. Systemische Probleme sind so stark, weil sie Probleme auf architektonischer Ebene erfassen. Zu den auftretenden Problemen gehören die Verwendung einer NoSQL-Datenbank, wo ein RDBMS die richtige Wahl wäre, die enge Kopplung zwischen unabhängigen Diensten, die Kommunikation über Kontextgrenzen hinweg über eine gemeinsame Datenbank, die Aufteilung von Business-Angelegenheiten in zu viele Microservices und die Wahl der falschen Deployment-Architektur.
Systemische Probleme neigen dazu, sich in Entwicklungsteams einzuschleichen. Sie sind immer da, lauern knapp unter der Oberfläche, bis eine harmlose Änderung oder Anforderung einen Moment der großen Frustration erzeugt. Dann seufzt jeder im Raum und erkennt, dass etwas nicht stimmt.
Es gibt keine vorgeschriebene Lösung für die Behebung systemischer Probleme. Die Begleichung dieser Schulden erfordert Teams von Entwicklern, sorgfältige Planung und Ausführung sowie Zeit – die knappste Ressource. Es liegt daher im Interesse der Organisation, diese Probleme eher früher als später zu bekämpfen.
Der Aufbau einer entwicklungsfähigen Architektur ist ein automatisierter Weg, um systemische Probleme zu bekämpfen. Building Evolutionary Architectures schlägt vor, die wichtigsten architektonischen Merkmale wie Komponentenkopplung oder Haltbarkeit mit Fitness-Funktionen zu testen. Die Deployment-Pipeline führt die Fitnessfunktionen im Rahmen der Kriterienüberprüfung aus und lehnt damit stark problematischen Code ab. Wenn dieser Ansatz nicht möglich ist, müssen Sie strenge, hochrangige Code-Reviews mit erfahrenen Entwicklern durchführen, um Probleme manuell zu identifizieren.
An dieser Stelle ist es nun möglich, eine Strategie zu entwickeln und zu priorisieren, um die technische Verschuldung Ihres Unternehmens zu reduzieren.
Priorisierung des Backlogs
Technische Schulden werden zum Problem, wenn man sich nicht darum kümmert. Viele Organisationen ignorieren diese Problematik und hoffen, dass sich das Problem von selbst löst oder konzentrieren ihre Bemühungen in die falsche Richtung. Teams machen zudem einen Fehler bei der Berücksichtigung der technischen Schulden über mehrere Projekte hinweg sowie der direkten und indirekten Auswirkungen, die diese haben können. Beispielsweise können technische Schulden in abhängigen Projekten die Bereitstellung in anderen Projekten behindern. Agile Teams müssen verstehen, dass der Wert jeder Schuld ein Faktor ihres Umfangs (lokal, global, systemisch), ihrer Auswirkungen auf häufig geänderten Code sowie der Zeit, die für seine Behebung benötigt wird, ist. Teams müssen Korrekturen priorisieren und Releases über alle Projekt-Backlogs hinweg koordinieren.
Ihre Technologieschuldenstrategie sollte einen 80/20-Ansatz zur Verbesserung der Entwicklung auf den am häufigsten modifizierten Codepfaden darstellen. Es geht nicht darum, technische Schulden zu beseitigen, sondern sie gut im Griff zu behalten und in Ihre agile Bereitstellung zu integrieren. Lassen Sie die Dinge ebenfalls, wie sie sind, wenn sie die alltäglichen Entwicklungsaktivitäten nicht behindern. So arbeitet das Team weiterhin in die richtige Richtung.
Die Bearbeitung unbedeutender lokaler Schulden kann also an den unteren Rand des Stapels geschoben werden, während die Auseinandersetzung mit globalen technischen Schulden wahrscheinlich der größte 80/20-Gewinn ist, da sie gegen systemische Schulden absichert und die Entwicklung von häufig modifiziertem Code verbessert. Priorisieren Sie Spikes, die auf 80/20 Lösungen abzielen und machen Sie dann weiter. Damit bleibt Ihnen die Problematik der systemischen technischen Schulden. Deren Bewältigung kann viele Sprints erfordern und muss daher Teil einer langfristigen Strategie sein. Auch hier gilt: Priorisieren Sie Spikes zu 80/20 Lösungen für systemische Probleme. Das Spike-Ergebnis sollte dabei helfen, Fixes abzuschätzen und sie gegenüber anderen Elementen im Backlog zu priorisieren.
Versuchen Sie nicht, technische Schulden in einem einzigen riesigen Release zu beseitigen. Fixes für technische Schulden sollten in kleinen kontinuierlichen Batches releast werden. Praktisch gesehen können diese Releases tatsächlich mehrere Fixes für lokale technische Schulden bündeln. Globale und systemische Korrekturen erfordern mehrere kleine und fokussierte Releases. Die Bewältigung der globalen und systemischen Schulden ist kompliziert. Deshalb sollten Sie langsam und bewusst vorgehen und keine weiteren Änderungen in den Releases für diese Schuldarten vornehmen. Ihre Release-Management-Strategie sollte außerdem die Transparenz von Fixes und deren Beziehung zu anderen Projekten und Releases fördern.
Priorisierung der Zukunft durch technische Investitionen
Technische Investitionen in automatisiertes Testen, statische Analysen und Fitnessfunktionen bringen Qualität in den Prozess. Im Laufe der Zeit verschieben sich so die technischen Schulden aus einzelnen Backlog-Tickets in die aktuelle Kultur. Und diese Art des agilen Kulturwandels kann Probleme so weit mildern, dass systemische Schulden nur noch selten auftreten.
Diese Zukunft fühlt sich wahrscheinlich weit weg an, daher müssen Sie mit der Priorisierung des Backlogs beginnen, indem Sie die verschiedenen Kategorien der technischen Schulden sowie den betroffenen Code und die Geschäftsabläufe berücksichtigen. Außerdem müssen Sie die Bemühungen über alle Projekte hinweg priorisieren, da nicht alle Projekte gleich erstellt werden. Die Transparenz aller Projekte und Releases mit Software wie z. B. Panaya ist ein entscheidender Faktor bei der Entscheidung, was zu tun ist.
Vermeiden Sie die Behebung lokaler Probleme und priorisieren Sie die Integration einer statischen Codeanalyse in die bestehende Testfolge, um die Entstehung weiterer lokaler technischer Schulden zu minimieren. Als nächstes sollten Sie Spikes priorisieren, die auf 80/20 Lösungen für die schlimmsten Übeltäter im Bereich der technischen Schulden abzielen. Muten Sie sich anfangs nicht zuviel zu, indem Sie systemische Schulden in Angriff nehmen. Entwickeln Sie eine technische Strategie zur Milderung ihrer Auswirkungen und konzentrieren Sie sich auf 80/20 Spikes, nachdem Sie drängende Problemstellen angegangen sind.
Dies kann mit einer Enterprise Agile Delivery-Lösung erreicht werden. Die Umstellung auf Agile muss nicht notwendigerweise hart sein. Erfahren Sie in diesem Webinar, wie.