Qualitätsziele helfen uns, Architekturentscheidungen fundierter zu treffen. Die genau richtige Qualität ist jedoch oft subjektiv und ändert sich über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem bei langlebigen Softwaresystemen spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, bei der wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich das ISO 25010-Qualitätsmodell sowie Wardley Mapping, um die passende Qualität nach Wichtigkeit und Evolutionsstufen zu finden.

Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die Balance der passenden Qualitätszielen ist ein herausforderndes Thema. Qualitätsziele sind aber sehr wichtig in der Entwicklung passender Softwaresysteme. Sie helfen uns, Architekturentscheidungen fundierter zu treffen. Die „genau richtige Qualität“ hängt dabei stark vom Betrachtungspunkt verschiedener Stakeholder ab. Zudem ändern sich Ansprüche an die Qualitäten eines Softwaresystems über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem in langlebigen Softwaresystemen immer wieder spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, wo wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich hierzu das ISO 25010-Qualitätsmodell sowie Wardley Mapping. Damit lassen sich notwendige Qualitäten nach ihrer Wichtigkeit und Evolutionsstufen von Softwaresystemen kommunizieren. Der Vortrag verzahnt die evolutionäre Sicht auf Softwarequalität mit Beispielen aus der Praxis und zeigt, wie sich damit die richtige Balance zwischen zu viel und zu wenig Qualität gestalten lässt.

Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort. Wirklich? Warum haben wir dann Schwierigkeiten, POs/Projektleiter/Abteilungsleiter vom notwendigen Budget zu überzeugen?
Im Vortrag zeigen wir, wie es datenbasiert besser geht. Wie man für Technische Schulden KPIs erfasst und wie man jeweils Code-, Architektur-, Test-Qualität, Team-Kollaboration mit den KPIs korreliert, um eine Kosten-Nutzen-Analyse durchzuführen. Trotz Microservices und DevOps - die Herausforderungen bleiben.

Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort, “es geht um Smells, Bugs, Bedarf an Refactoring, fehlende Tests …”. Zum Teil können wir deren Umfang und Bedarf sogar messen. Aber wie entscheiden wir, was wir zuerst angehen sollen? Wie und was messen wir, sodass andere Stakeholder uns überhaupt verstehen und wir POs, Projektleiter und Abteilungsleiter vom notwendigen Budget überzeugen können?
Im Vortrag zeigen wir, wie man datenbasiert bessere Antworten findet. Was man mit den Folgen der Technischen Schulden anfängt, Wartungs- und sich verstärkende Mehraufwände in der Entwicklung als KPIs erfasst und deren Hotspots im Code identifiziert. Wie man jeweils Code-, Architektur- und Test-Qualität usw. als Ursachen identifiziert und mit den KPIs korreliert. Und wie man Technische Schulden in der Architektur in Zahlen prognostiziert, um eine Kosten-Nutzen-Analyse durchführen zu können. Und wie sich Team-Kollaboration auch auf Technische Schulden auswirkt.
Diese Herausforderungen sind seit mehreren Jahrzehnten die gleichen. Daran haben auch Microservices nichts geändert.

Die Teilnehmer erhalten Antworten auf folgende Fragen:

•    Was sind Technische Schulden genauer?
•    Wie misst man die Folgen?
•    Wie sieht eine effektive Ursachenanalyse aus?
•    Wie überzeuge ich andere Stakeholder von der Notwendigkeit?
•    Wie wirkt sich Team-Kollaboration auf Technische Schulden aus?