Als ich zur technischen Schuld schreiben wollte, fiel mir auf das mein Kollege Martin Stühmer auf der Webseite Daily DevOps & .NET dazu bereits einen Artikel zum Thema “Technische Schulden beleuchten” erstellt hat. Seinen Artikel und mehr spannendes zu Microsoft .Net, MS Zertifizierungen und IT Architektur findet ihr ebenfalls auf der Webseite.

Passend zum Artikel von Martin Stühmer findet ihr weitere IT Architekturartikel bei uns im Blog.

Technische Schulden beleuchten von @Martin Stühmer

Unabhängig von der Rolle, ob Entwickler, IT-Fachmann oder Architekt, versuchen wir, technische Schulden zu vermeiden. Wenn dies von vornherein nicht möglich ist, oder wir uns entscheiden, diese Technische Schuld für einen begrenzten Zeitraum zu akzeptieren, dann fehlen uns meist die Werkzeuge. Hier können wir Abhilfe schaffen.

Was sind den Technische Schulden?

Technische Schulden sind eine Metapher, um die Kosten und Risiken zu beschreiben, die aufgrund von Entscheidungen oder Versäumnissen entstanden sind. Es ist wichtig zu erwähnen, dass diese Metapher auf alle Arten von technischen Schulden angewendet werden kann.

Zunächst gibt es die Architekturschuld, die in der Regel auf einer Entscheidung eines einzelnen Architekten oder einer Gruppe von Architekten beruht. Dann gibt es die Implementierungsschuld, die wahrscheinlich in den meisten Projekten am häufigsten vorkommt, da sie auch durch Quellcodeanalysen identifiziert wird. Sowie die Test- und Dokumentationsschuld, welche viel zu häufig vernachlässigt werden.

Unabhängig von der Art der technischen Schuld ist allen gemeinsam, dass sie meist zu Problemen in den Projekten und später im Betrieb führen. Phillipe Kruchten beschrieb sie daher im Juli 2011 als unsichtbare negative Elemente im Backlog.

Sie werden jedoch selten erfasst und visualisiert.

Wie kann ich sie trotzdem sichtbar machen?

In den meisten Projekten sind es einzelne Personen oder eine kleine Gruppe von Personen, die sich einzelner Technischer Schulden bewusst sind. Diese Projekte haben jedoch in der Regel eine weitere Gemeinsamkeit: Wenn diese Technischen Schulden angesprochen werden, werden sie aufgeschoben oder sogar abgewiesen.

Um dies zu vermeiden, müssen technische Schulden genauso wie Anforderungen oder Fehler erfasst werden. Dazu ist lediglich eine Person mit administrativen Rechten in Azure DevOps oder vergleichbaren Plattformen erforderlich.

Erweiterung der Azure DevOps Prozesstemplates

Azure DevOps bietet die Möglichkeit zur Visualisierung von technischen Schulden durch eine Erweiterung der Prozesstemplates. Der Microsoft-Artikel Anpassen einer Prozessvorlage beschreibt detailliert, wie eine Prozessvorlage vererbt und erweitert werden kann, um folgendes Ergebnis zu erzielen.

In diesem Fall wurden die erweiterten Prozesstemplates AgileRCDA und ScrumRCDA lediglich um einen weiteren WorkItem-Typ erweitert, der künftig für die Erfassung und Visualisierung von Technical Debt verwendet werden soll. Für die Farbgebung der technischen Schulden wurde 2011 von Kruchten bereits die Farbe Schwarz verwendet.

Für die spätere Priorisierung und Sortierung empfiehlt es sich, dem WorkItem-Typ zusätzliche Parameter mitzugeben, wie z.B:

Damit ist die technische Grundlage auf Basis der Prozesstemplates geschaffen und innerhalb des Projektes müssen nur noch die WorkItems vom Typ “Technical Debt” erfasst werden.

Fazit

Die hier vorgestellte Erweiterung von Azure DevOps (oder alternativen Plattformen) benötigt nur wenige Minuten zum Erweitern und Bereitstellen. Aber schon beim nächsten Sprint Meeting zeigt sie die gewünschte Wirkung. Denn die schwarz eingefärbten WorkItems vom Typ “Technical Debt” machen schnell den Eindruck eines Grabsteins und sorgen für die nötige Sichtbarkeit.

Wundern Sie sich nicht, wenn sich nach ein paar Wochen die Grabsteine häufen. Denn auch Ihre Kollegen und Teammitglieder kennen weitere Technical Debts, die Ihnen bisher sicher nicht aufgefallen sind.