Wovon sprechen wir?
Als Technische Schulden werden Versäumnisse oder Fehler in der Softwareentwicklung bezeichnet, die bei Umsetzung eines Projektes zwangsläufig geschehen. Das können z.B. bewusst Entscheidungen für die schnellste statt der effektivsten Lösung sein, Resultate von unzureichender Recherche oder zu wenig Wissen über gesamte Zusammenhänge in frühen Projektphasen.
Meistens müssen wir Projekte unter engen Zeitvorgaben realisieren, die tägliche Entscheidung von Entwicklern muss zwischen "mach es richtig" und "mach es schnell" getroffen werden. Das muss nicht unbedingt schlecht sein, rechtzeitig abgelieferte funktionsfähige Software oft erfolgsentscheidend.
Beispiele für Technische Schulden
- Nicht vollständige Testabdeckung
- Fehlender Workflow und Infrastruktur für Build-Prozesse, automatisches Testing, Deployment
- Unvollständige oder fehlende Dokumentation (technisch und funktional)
- Übriggebliebene "Todo" Anmerkungen im Code
- Fehlende Coding Standards - vor allem bei Teamarbeit
- Missachtung der Ergebnisse von statischen Codeanalysetools
- Unaufgeräumte Struktur und Aufbau des Codes
Wie kommt es dazu?
Oft legen Auftraggeber hohen Wert auf rasche Realisierung sichtbarer Anforderungen, neuer (auch "nach oben" verkaufbarer) Funktionen. Das "Aufräumen" im Hintergrund bekommt keine Zeit und kein Budget - sieht man als Benutzer doch danach keinen Unterschied. Das Problem entsteht schon in der Ausschreibungs- und Vertragsphase, wo oft nur die Erstimplementierung einer Software bis zu einem Funktionstest geregelt wird, aber keine Maßnahmen (und Budgets!) für die laufende Wartung, Weiterentwicklung, Qualitätssicherung und Zukunftsfähigkeit des Produktes.
Doch auch wenn in der ersten Implementierung der Software sehr sorgfältig und gründlich gearbeitet wird, wächst mit zunehmender Weiterentwicklung die Komplexität und erfordert von Zeit zu Zeit ein Aufräumen, einen teilweisen Umbau - "Refactoring".
Konsequenzen?
Technische Schulden sind an sich weder gut noch schlecht - sie sind einfach vorhanden. Man sollte sich bewusst sein, dass das längere Anhäufen von aufgeschobenen Arbeiten Konsequenzen hat:
- höherer Aufwand für Fehlerbehebung der Software
- Signifikant mehr Aufwand für die Entwicklung neuer Funktionen, die auf dem vorhandenen Produkt aufbauen
- Verfehlte Meilensteine, da die Entwicklungszeit nicht sinnvoll eingeschätzt werden kann
- Der große "Big Bang" mit großem, plötzlichem Ressourceneinsatz für Updates
- Ggfs. Gewährleistungsansprüche, wenn Software nicht mehr dem "Stand der Technik" entspricht
Wir empfehlen allen Projekt- und Produktverantwortlichen, bewusst über den Umgang mit diesen "nach hinten verschobenen, nicht unbedingt gleich nötigen" Arbeiten zu entscheiden und das Softwareprodukt über einen Lebenszyklus zu betrachten.
Unsere Empfehlung
Kontinuierliche Rückzahlung: Die wichtigste Empfehlung ist, diese Schulden kontinuierlich abzubauen. Laufend eingeplante Entwicklerkapazität bzw. Budgets lassen den Rückstau erst gar nicht übergroß werden, außerdem kann gut priorisiert jeweils an den wichtigsten Stellen verbessert werden.
Gute Dokumentation: Dokumentiere alle Funktionen, den technischen Aufbau, die erforderliche Konfiguration und die Bedienung. Halte diese Dokumentation tagesaktuell und überprüfe / überarbeite sie bei jedem Release. Dokumentiere auch die bekannten, noch offenen Verbesserungsmaßnahmen.
Längerfristige Planung: Plane die Verbesserungen längerfristig, so dass bei jedem Sprint oder Release eine Anzahl derartiger Aufgaben erledigt wird.
Blick auf das Ganze: Betrachte das gesamte System inklusive der Infrastruktur, Betriebssysteme, Hintergrundsysteme und Drittanbietersoftware. Die Kette bricht bekanntlich an der schwächsten Stelle.
Zielgruppenorientierung: Beobachte Veränderungen in deinen Zielgruppen, welche Bedürfnisse entstehen, müssen erfüllt werden? Denke auch an Performance, Barrierefreiheit, nütze Umfragen und Benutzerfeedback.
Unterstützung der Redaktion: Denke an die internen Mitarbeiter, z.B. die Webredaktion. Laufende Schulungsmaßnahmen, aktuelle Informationen, Feedbackmechanismen sorgen dafür, dass die Softwarelösung auch von Administrationsseite effizient bedient wird.
Wie so oft ist es hilfreich, sich der Schwierigkeiten und unterschiedlichen Ansprüche bewusst zu sein, zu wissen, welchen Status das eigene Softwareprodukt hat, um dann abwiegen und entscheiden zu können. Krisensituationen entstehen meist dann, wenn Auftraggeber und Produktverantwortliche nur den täglich sichtbaren oberen Teil des "Eisberges" im Blick haben und irgendwann - meist plötzlich - dann doch vom unsichtbaren Rest eingeholt oder gebremst (hoffentlich nicht versenkt) werden.
