By using our website, you agree to the use of our cookies.
By using our website, you agree to the use of our cookies.

Programm Details

Mittwoch, 16.10.2019   |   12:00 - 12:45 Uhr   |    Mi 2.2

Technische Schulden einschätzen und wirksam kommunizieren


Elmar Juergens
CQSE GmbH
Experte für Softwarequalität

Nils Göde
CQSE GmbH
Experte für Softwarequalität

Die typischen Beispiele für technische Schulden sind uns allen bekannt. Trotzdem werden diese in den meisten Projekten nicht, oder nicht ausreichend, adressiert. Ein Grund dafür ist, dass die Kosten, um Qualitätsprobleme zu beheben offensichtlich sind, ihr Nutzen aber häufig unklar bleibt.

Der Nutzen der Bereinigung von technischen Schulden ergibt sich aus dem konkreten Projektkontext. Um ihn greifbar zu machen, müssen wir technische Findings auf die Ebene von Projektkonsequenzen heben, die sich für andere Stakeholder ergeben. Diese Aufgabe können wir Architekten am besten erfüllen, da wir das notwendige Detailverständnis mit der Übersicht über das System verbinden.

In 15 Jahren Forschung und Praxis haben wir Erfahrungen gesammelt, technische Schulden zu erheben, projektspezifisch zu interpretieren und zu kommunizieren. In diesem Vortrag teilen wir nützliche Ansätze, die jeder Architekt als Handwerkszeug in seine eigenen Projekte mitnehmen kann.

Zielpublikum: Architekten, Entwickler, Projektleiter, QA-Verantwortliche
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic



Extended Abstract:

Uns als Architekten liegt die Zukunftsfähigkeit unserer Applikationen am Herzen. Vor diesem Hintergrund müssen wir uns immer wieder mit Qualitätsmängeln -- technischen Schulden -- auseinandersetzen. Doch obwohl wir die typischen Beispiele für technische Schulden kennen, wie z.B. lange Methoden, geklonter Code, Architekturverletzungen, fehlende Kommentare oder unverständliche Bezeichner, werden diese Problem in den meisten Projekten nicht adressiert. Dafür gibt es eine Reihe von Gründen, bei denen die Fragen nach dem Nutzen oft an erster Stelle steht. Die Kosten um ein einzelnes Qualitätsproblem zu beheben und technische Schulden zu reduzieren sind recht offensichtlich -- der Nutzen ist es meistens nicht. Die immer wiederkehrende Frage nach dem "Was bringt das denn?" lässt sich leider nicht mit einer allgemeingültigen Formel beantworten.

Doch auch wenn es keine allgemeine Antwort auf die Frage nach dem Nutzen gibt, kann man sich dieser sehr wohl im Kontext eines einzelnen Projektes nähern. Der konkrete Projektrahmen liefert eine Vielzahl an hilfreichen Daten wie z.B. die Kosten um die Software zu entwickeln, die Folgekosten von Fehlern oder die Art und Häufigkeit von Code-Änderungen. Mit diesen Informationen lässt sich der Nutzen ("Was bringt es das Problem zu beheben?") oder anders formuliert das Risiko ("Mit welchen Konsequenzen ist zu rechnen wenn das Problem nicht gelöst wird?") greifbar machen. Das ist die Grundvoraussetzung dafür, um technische Schulden mit den Projektbeteiligten zu diskutieren und Maßnahmen zu ergreifen.

Die Kernaufgabe besteht also darin, das abstrakte Konzept der technischen Schulden mit Leben zu füllen, d.h. in den eigenen Projektkontext zu übertragen und mit den dort vorhandenen Informationen die Konsequenzen, bzw. den Nutzen, herauszuarbeiten und den beteiligten Personen zu vermitteln. Für diese Aufgaben eigenen wir Architekten uns am besten. Auf der einen Seite haben wir das notwendige Detailverständnis, auf der anderen Seite aber auch den Überblick über das Gesamtsystem. Zudem nehmen wir als Architekt oft ohnehin eine zentrale Rolle ein, d.h. es existieren Kommunikationswege zu allen relevanten Personen.

Neben einem ausgeprägten Verständnis des Systems sind für die Erfüllung der Aufgabe aber auch Best Practices und Methoden erforderlich. Nicht zuletzt, da der Nutzen mit fortlaufendem Projekt immer wieder neu geprüft, bewertet und an die Beteiligten kommuniziert werden muss. Seit vielen Jahren erfüllen wir diese Aufgabe oder unterstützen Architekten dabei dies zu tun. In 15 Jahren Forschung und Praxis haben wir weitreichende Erfahrungen gesammelt. In diesem Vortrag skizzieren wir verschiedene Ansätze und Methoden um technische Schulden im Kontext eines konkreten Projektes zu ermitteln und zu kommunizieren. Wir gehen auf konkrete Kostenmodelle ein mit denen einzelne Klassen von technischen Schulden konkret quantifiziert werden können (wie z.B. für geklonten Code in https://www.cqse.eu/publications/2010-how-muchis- a-clone.pdf). Als Ergänzung präsentieren wir Beispiele aus konkreten Kundenprojekten, in denen wir technische Schulden quantifiziert haben. Die Teilnehmer erhalten damit einen Werkzeugkasten mit verschiedenen Ansätzen und Methoden, die sie in ihrem eigenen Projekt anwenden können.