Erwartete Lesezeit: 3 minuten
In der IT versteht man unter technische Schulden Umsetzungen, bei denen man Einbußen in der Qualität in kauf genommen hat. Sei es bewusst oder versehentlich.
Technische Schulden kann man mit Hilfe dieses Quadrates qualifizieren. Wie man anhand dieses Beispiels sehen kann, gibt es gefährliche und weniger gefährliche Schulden.
Umsichtigt bewusst eingegangene Schulden :
Es muss schnell geliefert werden. Hier nimmt man kleinere hantierbare Qualitätsmängel in Kauf , hat aber die Behebung und die Optimierung bereits auf dem Zettel.
Umsichtig versehentlich eingegangene Schulden:
Es gibt kleinere nicht Einführung verhindernde Fehler, die man akzeptiert.
Auch unvorhersehbare Situationen , wie z.B. CPU Auslastung bei Servern, die man nicht vorraussehen konnte aber handeln kann , fallen in diesem bereich.
Bewusst rücksichtslos eingegangene Schulden:
Dieses ist die gefährlichste technische Schuld. Hier werden bewusst schwere Fehler akzeptiert. Häufig auch durch Termin- und Kostendruck ausgelöst. Jeder der in der IT arbeitetet kennt die Situation. Man erstellt eine Schätzung und vom Stakeholder oder vom Chef kommt die Ansage : Halbes Budget und ihr müsst es in 2/3 der Zeit schaffen. Das hier die Qualität leidet , dürfte jedem klar sein. Die Wartung wird aufgrund einer schlechten Architektur und Implementierung komplexer, es werden Fehler die man durch Tests gefunden hätte erst nach der Einführung gefunden. Es gibt Sicherheitslücken, die zu schweren folgen haben können. Hierunter fällt auch die nicht Behebung von bekannten technischen Schulden durch den Zwang schnell neue Features zu liefern.
Versehentlich rücksichtslose technische Schulden:
Diese technische Schulden sind nicht weniger gefährlich. In den meisten Fällen liegen hier Unwissenheit bzw. geringe Expertise vs. Entscheidungen vor. Es werden Entscheidungen von Menschen getroffen, die auf eine Aufgabe gesetzt wurden , aber nicht die Voraussetzungen erfüllen und dann falsche Entscheidungen treffe.
Was kann man gegen technische Schulden machen?
Abhängig von Schweregrad können die folgenden Punkte helfen, die Anzahl von technischen Schulden zu reduzieren (nur ein Beispiel):
- Aufbau der passenden Infrastruktur: Versionskontrollsystem, Build-Server , CI Pipeline
- Automatisierte Tests (Modul und Regressionstests), die im Zuge der CI automatisch ausgeführt werden.
- Erstellung einer Systemdokumentation
- Statische Codeanalysetools (z.B. Sonar) zur Vermeidung von Codesmells und Anti-Pattern
- Durchführungen von notwendigen Refactorings
- Dokumentation und Bewertung von bekannten Technischen Schulden. (Kosten-, Auswirkungen, Strafen,….)
- Bugfixing , wenn ein Fehler gefunden wird.
- Entscheidungen dokumentieren. (Auch wenn es nach Fingerpointing aussieht, es ist wichtig zu wissen , warum eine technische Schuld eingegangen wurde)
- „Manuelle Tests“ durch den Auftraggeber.
- Kein Verringerung der Fehlerklasse um die Produkticsetzung zu gewährleisten.
- Wissenstransfer und Wissensaufbau
Jetzt werden bestimmt einige von Euch sagen: Ja ist doch klar, so haben wir es gelernt.
Ich bin seit 2002 in der Softwareentwicklung unterwegs und ich habe schon alles erlebt.
Sei es über jede einzelne Stunde in einer Schätzung mit einem Stakeholder zu feilschen (Wozu braucht Ihr eine Dokumentation , Ihr habt doch den Source Code) oder das ist der Zieltermin und das ist der Umfang den ich haben will.Auch wenn klar ist ,dass mit der aktuellen Personaldecke das nicht zu schaffen ist heißt es : Ihr habt es doch sonst auch immer geschafft. Alle kritischen Fehler werden auf Mittel gesetzt , damit man nach Produktion gehen kann. Bis es in Produktion mal so richtig knallt.