Ziel dieser Serie von Posts, ist es darzustellen, wie technische Schulden erkannt werden können. Nach der Erkennung kann man sich häufig an Mustern orientieren, um die Schulden abzubauen. Einige Werkzeuge geben uns Entwicklern auch direkt Lösungen an die Hand. Aber auch bei der Erkennung von technischen Schulden gilt “You get what you measure” – wie in allen Teilbereichen des Managements. Wir brauchen also einen möglichst automatischen Prozesse, der uns regelmäßig an unsere Schulden erinnert, so dass

• bekannte technische Schulden nicht in „Backlog-Vergessenheit“ geraten und
• neue technische Schulden erkannt werden.

Hierbei müssen in unseren Projekt Prozesse etabliert werden. Diese gliedern sich in Prozesse

• ohne Werkzeugunterstützung
• mit Werkzeugunterstützung
  • Build brechend – automatisch
  • Warnung – manuell

Das manuelle Vorgehen ohne Hilfsmittel (z.B. sporadische Code-Reviews) ist nicht Thema dieser Blog-Serie. In den folgenden Posts werden Werkzeuge für Prozesse mit Werkzeugunterstützung dargestellt. Die Prozesse teilen sich in einen “Build brechenden” Prozess, bei dem Regelverstöße den Build der Software unterbinden, und einen Prozess, der lediglich Warnungen erzeugt, die im Anschluss manuell bearbeitet werden müssen. Der Verlauf von technischen Schulden in Verbindung mit den verschiedenen Prozessen ist in der folgenden Grafik dargestellt

Bei der Planung der QS Anforderungen ist es im Allgemeinen das Ziel, einen möglichst kleinen „Korridor“ von technischen Schulden und damit Abweichungen der Architektur zuzulassen (hier gelb markiert). Die rote Linie zeigt den Verlauf, wenn keine QS implementiert wird. Es kann hier maximal zu „Zufallsrefactorings“ kommen, die die Situation verbessern. Zufallsrefactorings sind Reduzierungen der technischen Schulden bei der Bearbeitung einer Anforderung. Findet sich dort eine Schuld wird Sie häufig im Zuge der Umsetzung der Anforderung behoben. Es gibt aber keinen geordneten Prozess für den Abbau der Schulden. Die Kurve wird über die Zeit permanent ansteigen. Die schwarze Linie zeigt den Verlauf bei einem automatischen “Build brechenden” Prozess. Er schafft einen guten Grundstock bei der Bekämpfung technischer Schulden, da harte Regeln neue Schulden verbieten und nach und nach auch alte Schulden abgebaut werden. Aber auch hier werden die Schulden über die Zeit ansteigen, wenn auch weniger stark. Grund hierfür ist, dass nicht alle Schulden in dem betrachteten Prozess berücksichtigt werden können, da sonst beispielsweise zu viele False/Positives entstehen und die Entwicklungsarbeit behindern. Ein Projekt kann nur innerhalb des gewünschten Korridors verbleiben, wenn neben dem automatischen Prozess auch ein manueller etabliert wird.