In einem früheren Beitrag habe ich geschildert, wie Sie den Wert, den der Kunde braucht, verstehen und klassifizieren können. Von der Vision, die der Kunde hat, von den Fähigkeiten, die er braucht, über die Features und Stories des Systems bis hin zu Beispielen, mit denen man die Stories verstehen und testbar machen kann.
Heute geht es um die Qualität dessen, was da entwickelt wird, denn auch die muss stimmen. Sie sollten die Qualitätsanforderungen, die der Kunde hat, früh im Blick behalten:
- Wie schnell muss das System sein (Performanz)?
- Wie viele Daten muss es verarbeiten (Größe)?
- Wie viele Benutzer wird es heute und morgen haben (Skalierbarkeit)?
- Wie sicher muss es gegen Angriffe sein (Sicherheit)?
- Wie leicht muss es erweiterbar sein (Wartbarkeit)?
- usw.
Sie müssen diese Qualitäten nicht sofort einbauen, denn das kann teuer sein. Wenn Sie zum Beispiel zu früh Wert auf Performanz legen, noch bevor Sie wissen, wie die Systemstruktur aussehen wird, investieren Sie vielleicht zu viel. Wenn Sie jedoch zu spät auf Performanz achten, müssen Sie sie „hineintesten“, wenn schon alles fertig ist. Auch das wird teuer.
Fassen Sie die Qualitäten am besten genauso in Anforderungen wie Sie es mit den funktionalen Aspekten des Systems getan haben. Sie können beispielsweise folgende Typen kreieren (wie von Stefan Toth vorgeschlagen):
Qualitätsstoryist eine Qualitätseigenschaft, die man einmalig einbaut (wie eine User Story) und die dann im System enthalten ist. Das könnte z.B. das Aufsetzen einer Load Balancer Infrastruktur sein, die für Lastverteilung und damit Skalierbarkeit sorgt.Qualitätsaspektist eine Qualitätseigenschaft, die eine oder mehrere User Stories betreffen wird und dort berücksichtigt werden muss. Beispiel: „Bei allen Adress-Eingaben, in denen der Benutzer eine Postleitzahl eingegeben hat, muss das System den Ort selbst automatisch einsetzen.“Qualitätsrichtlinieist eine Qualitätseigenschaft, die viele oder alle User Stories betreffen wird und deshalb immer im Gedächtnis aller Teammitglieder bleiben muss. Beispiel: „Neu eingebauter Code darf die Laufzeiten der bisherigen Performanztests nicht verlängern.“
Für den ersten der drei Typen von Qualitätsanforderungen, die Qualitätsstory, erzeugen Sie Einträge im Product Backlog, wie für User Stories auch. Den zweiten Typ, den Qualitätsaspekt, fügen Sie als Akzeptanzkriterium zu einer oder mehreren User Stories hinzu. Den dritten Typ, die Qualitätsrichtlinie, schreiben Sie in die Definition of Done für das gesamte Produkt.
Lassen Sie Ihren Software-Architekten mit dem Product Owner, der das Backlog pflegt, zusammenarbeiten. Der Software-Architekt wird Ihnen sagen können, welche Qualitätsanforderungen wie in Ihrem System abgebildet werden sollen. Lassen Sie den Software-Architekten, den Product Owner und das Team darüber diskutieren, mit welcher Priorität die Qualitätsanforderungen bearbeitet werden sollen. Ein gemeinsames Verständnis über Kosten der Architekturarbeit (und die Kosten, wenn man diese Arbeit unterlässt!) vermeidet Streit in einer agilen Softwarefirma.
