User Stories als Stellvertreter für Qualitätsziele
Architektur-Stories sind User Stories, die die Umsetzung eines Qualitätsziels forcieren. Sie stehen stellvertretend für das Qualitätsziel und werden deshalb Stellvertreter-Stories genannt. Dieser Beitrag beschreibt die Idee von Stellvertreter-Stories am Beispiel des Qualitätsziels Hochverfügbarkeit.
Qualitätsziele messen
Ein Qualitätsziel beschreibt eine nicht-funktionale Anforderung an ein Softwaresystem, die entscheidend für den Erfolg des Systems ist. Viele Qualitätsziele haben Einfluß auf die Architektur des Softwaresystems. So erfordert das Qualitätsziel Hochverfügbarkeit eine Strukturierung des Systems, welche die redundante Auslegung kritischer Komponenten ermöglicht.
Qualitätsziele werden häufig als überprüfbare Qualitätsszenarien beschrieben. Ein mögliches Szenario für einen hochverfügbaren Online-Surfshop könnte wie folgt lauten: "Eine Kundin will das System an 7 Tagen in der Woche 24 Stunden am Tag nutzen. Das System ist während dieser Zeit zu 99% verfügbar."
Qualitätsziele als User Stories?
User Stories sollen frei von technischem Jargon sein, so dass die Story "Das System soll 24/7 zu 99% verfügbar sein" nichts im Product Backlog zu suchen hat. Vielmehr gilt es, eine Story mit klar erkennbarem Geschäftswert zu finden, die das genannte Qualitätsziel vertritt. Hierbei ist es wichtig, dass das umzusetzende Qualitätsziel für diese Story eine herausragende Bedeutung hat. Für den Online-Surfshop ist die Artikelsuche ein geeigneter Stellvertreterkandidat. Die Suche wird häufig und von vielen Kundinnen gleichzeitig genutzt und muss entsprechend hochverfügbar sein. Eine Stellvertreter-Story für das Qualitätsziel Hochverfügbarkeit könnte also lauten: "Als Kundin möchte ich nach Produkten suchen". Die Anforderung "Das System soll 24/7 zu 99% verfügbar sein" wird der Story als Akzeptanzkriterium zugefügt.
Das vertretene Qualitätsziel steht im Vordergrund der Story, so dass die umzusetzende Funktionalität möglichst klein gewählt werden sollte. So könnte die Suche in der ersten Version ausschließlich exakte Treffer liefern, was sich relativ einfach realisieren lässt. Wichtiger als die vollumfängliche Funktionalität (diese kann in Folge-Stories nachgeliefert werden) sind die Akzeptanzkriterien der Story, speziell die, die auf die Aspekte des vertretenden Qualitätsziels abzielen.
Architekturarbeit
Qualitätsziele sollten so früh wie möglich umgesetzt und validiert werden. Entsprechend ist es die Aufgabe des/der Architekt/-in von Beginn an dafür zu sorgen, dass Stellvertreter-Stories geschrieben und vom Product Owner entsprechend hoch priorisiert werden. Gemeinsam mit dem Entwicklungsteam entwickeln der/die Architekt/-in mögliche Umsetzungsstrategien.
Ein weiterer wichtiger Aspekt der Architekturarbeit ist die Zusammenarbeit mit der QA mit Fokus auf dem Testen von Qualitätszielen. Entsprechend könnte ein Testszenario für das Qualitätsziel Hochverfügbarkeit wie folgt lauten: "Bei 100 parallel ausgeführten Suchen werden zufällig einzelne Instanzen des Suchservices heruntergefahren und nach einer gewissen Zeit neu gestartet. Die Suche darf nur bei weniger als 1% aller Suchen zu einem Fehler führen."
Agile Architekturarbeit
Neben der Strukturierung und fachlichen Aufteilung des Systems in Komponenten ist eine der Hauptaufgaben des/der Architekt/-in die Ermittlung von Qualitätszielen, sowie dafür zu sorgen, dass diese umgesetzt werden und den Anforderungen stand halten. Agile Softwareentwicklung und Architekturarbeit gehen dabei Hand in Hand, indem die Qualitätsziele von Beginn an als Stellvertreter-Stories in den Entwicklungs-Flow integriert und umgesetzt werden.
