Der Auftrag eines Softwareprodukts kann folgendermassen beschrieben werden: Die Kunden haben Wünsche und Bedürfnisse (Anforderungen), welche die Auftragnehmer mittels einer Softwarelösung in gegebenen Rahmen bzgl. Zeit und Kosten erfüllen.
Traditionell lag der Fokus bei Softwareentwicklung auf der Einhaltung der Fristen und Budgets anstatt auf der Sicherstellung der tatsächlichen Anforderungen der Kunden. Unzählige Memes machen sich darüber lustig, dass Softwareprodukte die Kundenerwartungen nicht erfüllen. Sehr berühmt ist das Cartoon mit der Schaukel, aber weniger bekannt ist, dass die Karikatur aus dem Jahre 1973 stammt:
Quelle: knowyourmeme.com/photos/475752-tree-swing-cartoon-parodies
Fünfzig Jahre später kämpft die Softwareentwicklung bisweilen immer noch mit dem gleichen Problem. Woran liegt das?
Das Fliessband
Klassische Vorgehensweisen der Softwareentwicklung – wie etwa das Wasserfallmodell – sehen einen Prozess wie am Fliessband vor: Die Auftraggeber liefern eine klare Vorgabe dessen, was sie vom Produkt erwarten – die Anforderungen. Im Wasserfallmodell heisst diese Vorgabe „Lastenheft“. Die Auftragnehmer analysieren diese Anforderungen und erarbeiten ein Lösungskonzept („Pflichtenheft“), d. h. eine Beschreibung davon, wie sie die Anforderungen implementieren wollen.
Nachdem das Pflichtenheft durch die Auftraggeber abgenommen wird, folgt die Implementierung, die das Lösungskonzept als Blaupause nimmt und die darin abgebildeten Komponenten umsetzt. Diese werden gegen das Lösungskonzept getestet. Wenn alle Fehler behoben sind, wird das fertige Produkt ausgeliefert.
Die Erfüllung der Wünsche und Bedürfnisse der Kunden lässt sich anhand einer Beweiskette nachvollziehen: Jede Funktion im Code ist letzten Endes auf eine Anforderung im Pflichtenheft zurückzuführen, denn darauf hat man sich schliesslich verständigt. Was könnte da noch schief gehen?
Die Erfahrung hat gezeigt, dass dieses Vorgehen viele Probleme aufweist: Anforderungen ändern sich im Laufe der Zeit und Aufwände lassen sich am Anfang des Projekts nicht zuverlässig abschätzen, aber das Produkt wird erst am Ende des Projekts ausgeliefert und nur dann können die Kunden feststellen, ob es seiner Vorstellung entspricht, usw. Viele Probleme sind auf die mangelnde Flexibilität des Vorgehensmodells zurückzuführen und eine oft übersehene Ursache ist dabei die Fehlkommunikation im Prozess.
Sogar, wenn die Kunden die Anforderungen von Anfang an genau kennen, ist es nicht gewährleistet, dass alle Beteiligten diese auch so verstehen. Der Grund dafür ist …
Die Stille Post
Im Mittelpunkt der klassischen Vorgehensweisen steht die Dokumentation. Die Arbeitsprodukte – Lastenheft, Pflichtenheft, Feinkonzeptionen, Testfälle usw. – werden wie in der Reihenfertigung von einem Arbeitsplatz zum nächsten befördert. Die Kommunikation erfolgt sparsam und ausschliesslich zwischen unmittelbar benachbarten Stationen.
In jeder Interaktion entstehen potenziell Kommunikationsverluste. Wichtige Informationen können so verfälscht oder überhaupt nicht ankommen. Die Kundenperspektive erreicht die Entwickler:innen oft gar nicht und so wächst die Gefahr, dass Funktionalitäten an den Kundenanforderungen vorbei umgesetzt werden.
Auf dem kurzen Dienstweg
Die agile Softwareentwicklung legt den Fokus auf die Kommunikation. Eine Anforderung kann nach den agilen Prinzipien nur dann erfolgreich umgesetzt werden, wenn ein gemeinsames Verständnis darüber herrscht, was diese Anforderung genau bedeutet. Aus diesem Grund heisst es im Manifest für agile Softwareentwicklung (2001), dass „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ geschätzt werden.
Agile Methoden, so wie Scrum, beschreiben die Anforderungen üblicherweise anhand von User Stories. Eine User Story ist in erster Linie ein Platzhalter für die Kommunikation: Sie entsteht in Rohform als allgemeine Erklärung davon, was Benutzer:innen vom System wollen bzw. brauchen, und wird im agilen Prozess kontinuierlich verfeinert.
Das bedeutet konkret, dass das Entwicklungsteam seine Fragen und Bedenken mit den Kunden und deren fachlichen Ansprechpartner:innen und Endnutzer:innen direkt besprechen kann. So wird stets die Kundenperspektive miteinbezogen.
Die Kommunikation findet also häufig, offen und nicht linear statt, was ein gemeinsames Verständnis der Anforderungen fördert. Die Erkenntnisse aus dieser Kommunikation schlagen sich in der User Story nieder und bilden die Basis für deren Umsetzung. Dabei muss darauf geachtet werden, dass sie präzise formuliert werden, um Missverständnisse zu vermeiden.
Eine bewährte Methode dafür sind die Akzeptanzkriterien.
Strukturierte Anforderungen
Akzeptanzkriterien sind Bedingungen, die durch die Umsetzung erfüllt werden müssen, damit eine User Story erfolgreich abgeschlossen werden kann. Sie beschreiben testbare Eigenschaften der geforderten Funktionalität, die im Rahmen der Abnahme geprüft werden können. Deswegen sind sie auch als „Abnahmekriterien“ bekannt.
Sie bilden das Bindeglied zwischen User Stories und Testfällen. Bereits vor der Entwicklung können aus den Akzeptanzkriterien Testfälle abgeleitet werden, mit denen die Richtigkeit und Vollständigkeit der Umsetzung geprüft wird. Diese Testfälle tragen zusätzlich zum gemeinsamen Verständnis der Anforderung bei.
Akzeptanzkriterien helfen also, das durch die Verfeinerung erreichte Verständnis so festzuhalten, dass während und am Ende der Entwicklung geprüft werden kann, dass diese der Anforderung entspricht.
Dafür müssen Akzeptanzkriterien schätzbar, wertstiftend und testbar sein. In anderen Worten, sie beschreiben kleine, aber funktionale Bedingungen, welche den Kunden einen Mehrwert bringen und so konkret formuliert sind, dass sie durch Testen prüfbar sind.
Kommunikation muss in den Mittelpunkt
Ein Softwareprodukt kann nur dann erfolgreich fertiggestellt werden, wenn es die Wünsche und Bedürfnisse der Kunden erfüllt. Um dies sicherzustellen, muss ein gemeinsames Verständnis über diese Wünsche und Bedürfnisse herrschen.
Die Erfahrung hat gezeigt, dass dieses Verständnis nicht durch ein dokumentationsbasiertes Vorgehen erreicht wird: Die Kommunikation muss stattdessen im Mittelpunkt stehen. Dafür sind agile Methoden am besten geeignet. Der Einsatz von Akzeptanzkriterien bei der Beschreibung und Verfeinerung von User Stories ist ein Tool aus dem agilen Baukasten, das sich als besonders erfolgreich darin erwiesen hat, ein gemeinsames Verständnis von Anforderungen zu erreichen und dieses in einer testbaren Form auszudrücken.