Verbessern von Anwendergeschichten mit Anwendungsfällen

Eines der größten Probleme in Unternehmen, die Scrum (oder die meisten anderen agilen Methoden) einführen, ist die Qualität der Elemente im Product Backlog. Product Owner tun sich schwer damit, die User Stories zu definieren, die benötigt werden, um den Prozess voranzutreiben. Und ihre Rolle ist oft fast unmöglich. Wie kann man großartige User Stories erstellen, die einen echten Mehrwert bieten, gerade detailliert genug sind, aber auch die Dokumentation liefern, die später im Lebenszyklus der Anwendung benötigt wird? Es geht hier nicht darum, ob User Stories von Natur aus schlecht sind (das sind sie nicht), sondern darum, dass es wirklich schwierig ist, User Stories so zu schreiben, dass sie wirklich helfen und langfristig nützlich sind. Was wir brauchen, ist kein Ersatz für User Stories, sondern eine bessere Methode, um sie zu erstellen. Wie sollten Sie also vorgehen, um zu guten User Stories zu kommen? Darum geht es im weiteren Verlauf dieses Blogs.

Wenn ich Organisationen bei der Umstellung auf agile Arbeitsweisen helfe, stelle ich oft fest, dass die agilen Teams großartige Arbeit leisten, es aber echte Probleme mit dem Product Backlog gibt. Die Rolle eines Product Owners ist hart, und das zeigt sich oft. Um den Product Ownern gegenüber fair zu sein: Es ist extrem schwierig, gute User Stories für das Product Backlog zu finden. Und noch schwieriger ist es, dafür zu sorgen, dass sie leichtgewichtig sind, vom Team verstanden werden und einen geschäftlichen Nutzen generieren.Nicht selten degeneriert das Product Backlog im Laufe der Zeit, und das führt zu echten Problemen für die Teams. Wenn Sie eine wirklich erfolgreiche agile Organisation haben wollen, müssen Sie sich auf den Prozess der User Story-Erstellung konzentrieren.Wie ich bereits sagte, ist es meine Erfahrung, dass die meisten Organisationen mit der Rolle des Product Owners, der Qualität der Elemente im Product Backlog und der Rolle der Analysten zu kämpfen haben. Im Allgemeinen sehe ich die folgenden Probleme immer wieder (in keiner bestimmten Reihenfolge):

• Fokus: User Stories sind kleine Inseln für sich, und es ist schwer zu erkennen, wie alles "zusammenpasst".
• Prozess: Sowohl Product Owner als auch Analysten kämpfen damit, wie sie zu brauchbaren User Stories kommen, wie sie "traditionelle" Analysefähigkeiten in diese neue Welt übertragen können.
• Detail: Es ist oft unklar, welcher Detaillierungsgrad für die User Stories erforderlich ist. Und so bleiben entweder alle User Stories undefiniert oder die Analysten bestehen auf einer umfangreichen, nicht benötigten Dokumentation der User Story.
• Umfang: Es ist oft schwierig, einer User Story einen Geschäftswert zuzuordnen, da sie nicht wirklich einen Geschäftsprozess widerspiegelt, sondern nur einen kleinen Teil davon. Häufig ist dies ein Symptom, das durch Anforderungen verursacht wird, die entlang der Technologieachse statt der Geschäftsachse aufgeteilt sind.
• Systemdokumentation: Ein großer Stapel von User Stories macht noch keine gute Systemdokumentation, aber eine Systemdokumentation wird schließlich benötigt.

Wie sich herausstellt, lassen sich diese Probleme beseitigen, indem man den Prozess ändert, mit dem man zu den User Stories gelangt.

Anwendungsfälle als Retter in der Not

Ende 2011 haben Ivar Jacobson, Ian Spence und Kurt Bittner ein ebook über Use Case 2.0 geschrieben (siehe [1]), zu dem ich einen kleinen Beitrag geleistet habe. Dieser Artikel gibt eine überzeugende Antwort auf die genannten Probleme: Verwenden Sie einfach Use Cases, um Ihre User Stories zu definieren. Beachten Sie, dass ich nicht behaupte, dass Use Cases User Stories sind. Ich stimme mit Mike Kohn überein, dass sie es nicht sind. Aber Use-Case-Slices sind User Stories, und darauf konzentriere ich mich. Use-Case-Slices wurden von Ivar Jacobson, Ian Spence und Kurt Bittner Ende 2011 in ihrem ebook "Use-Case 2.0 - The Guide to Succeeding with Use Cases" vorgestellt. In diesem Blog werde ich nur eine Teilmenge ihrer Ideen verwenden und mich darauf konzentrieren, wie man sie mit Scrum in Einklang bringen kann. In späteren Blogs werde ich das Thema weiter vertiefen und weitere Ideen einbeziehen. Schauen wir uns zunächst eine Definition an: Ein Use Case Slice ist eine oder mehrere Geschichten, die aus einem Use Case ausgewählt werden, um ein Arbeitselement zu bilden, das für den Kunden von klarem Wert ist (Jacobson, Spence, Bittner) Für uns, die wir uns mit User Stories befassen, ist diese Definition etwas irreführend, also lassen Sie uns diese Definition neu formulieren: Ein Use-Case-Slice ist eine Sammlung von Front-to-Back-Flows durch einen Use-Case, einschließlich der zugehörigen Testfälle, der für den Kunden von klarem Wert ist. Ein Front-to-Back-Flow wird als Use-Case-Story bezeichnet. Die Änderungen in der Definition sind zweifacher Art. Erstens ist der Begriff "Stories" vielleicht etwas irreführend, da es den Anschein haben könnte, dass damit User Stories gemeint sind. Das ist aber nicht der Fall. Zweitens schließt die ursprüngliche Definition die Testfälle nicht mit ein, aber im Rest des Ebooks steht eindeutig, dass sie mit einbezogen werden müssen, also habe ich das in meine Version der Definition aufgenommen. Damit das klar ist, lassen Sie uns sehen, wie das funktioniert, indem wir uns einen hypothetischen Anwendungsfall ansehen. In diesem Anwendungsfall gibt es eine Reihe von Möglichkeiten, um vom Anfang zum Ende zu gelangen. Wir können den Anwendungsfall dann konzeptionell in all diese einzelnen Anwendungsfallgeschichten aufteilen.

Wenn Sie Ihre Use-Case-Modellierung richtig gemacht haben, hat jede dieser Use-Case-Stories einen bestimmten Wert. Ein Use-Case-Slice ist dann einfach eine Auswahl (eine oder mehrere) dieser Use-Case-Stories plus eine Anzahl von Testfällen, die erfüllt werden sollten. Beachten Sie, dass zwei Use-Case-Slices aus genau denselben Use-Case-Stories bestehen können, denen aber unterschiedliche Testfälle zugeordnet sind. Dies mag theoretisch erscheinen, kann aber äußerst hilfreich sein, um den Umfang einer Use-Case-Slice zu begrenzen, so dass sie über mehrere Sprints verteilt werden kann. Im nächsten Blog werde ich ein konkretes Beispiel dafür geben, wie Sie dies anwenden können. Ein auf diese Weise definierter Anwendungsfall erfüllt alle Kriterien für eine User Story. Schließlich wissen wir, für wen sie bestimmt ist (der auslösende Akteur), was angefordert wird (die Anwendungsfallgeschichten und Testfälle) und welchen Wert sie hat (abgeleitet aus der Art und Weise, wie der Anwendungsfall konstruiert wurde). Daher ist ein Anwendungsfall-Slice ist eine User Story und kann als Element im Product Backlog verwendet werden.

Aber so weit sind wir noch nicht

Es stellt sich immer noch die Frage nach dem Detailgrad. Die Art und Weise, wie die Leute traditionell Anwendungsfälle schreiben, bedeutet, dass eine Menge ziemlich detaillierter Arbeit geleistet werden muss. Und das ist etwas, das wir in einem agilen Umfeld nicht tun wollen. Wenn Sie sich die Literatur ansehen, wird davon abgeraten, aber fast jeder, der behauptet, Anwendungsfälle zu schreiben, scheint es trotzdem zu tun. Die Lösung besteht darin, genügend Anwendungsfälle zu definieren, um die Use-Case-Slices definieren zu können, aber nicht mehr. Wir brauchen nicht die genauen Details jedes Schritts im Anwendungsfall; wir brauchen ein allgemeines "Gefühl" dafür, was der Anwendungsfall tun soll, und wir müssen in der Lage sein, die Anwendungsfallgeschichten zu identifizieren. Einen detaillierten Anwendungsfall zu erstellen, kann eine Menge Arbeit sein, aber nur den erforderlichen Detaillierungsgrad zu erreichen, ist einfach und dauert höchstens ein paar Stunden. In [2] haben Ian Spence und Kurt Bittner 4 Ebenen von Use-Case-Beschreibungen definiert; in ihrer Terminologie müssen die Use-Cases auf der Ebene Bulleted Outline liegen. Wenn dieser High-Level Use-Case geschrieben ist und ein Use-Case-Slice mit dem Team besprochen wird, z.B. in einer Backlog-Grooming-Sitzung, kann entschieden werden, dass bestimmte Use-Case-Stories in bestimmten Bereichen etwas mehr Details benötigen. Diese Bereiche werden dann detailliert, aber der Rest des Anwendungsfalls wird so belassen, wie er ist. Dies ist die Ebene Essential Outline, wie in [2] beschrieben.

Wie kann dies zur Lösung der Probleme beitragen?

Nun, es hilft in vielerlei Hinsicht.

• Fokus: Indem Sie die Anwendungsfälle in den Mittelpunkt stellen, liegt der Fokus immer auf dem gesamten System. Dadurch wird sichergestellt, dass der Kontext der User Story (des Anwendungsfalles) immer bekannt ist. Dies hilft, die Absicht der User Story zu vermitteln.
• Prozess: Verwendung des Use-Case-Modells -> use case -> use-case slice Arbeitsweise haben der Product Owner und die Analysten eine Standardarbeitsweise, die für das Team leicht verständlich ist.
• Detail: Der Detaillierungsgrad ist schon früh ein Diskussionspunkt, so dass wir am Ende gerade genug Details haben, gerade noch rechtzeitig
• Umfang: Die Definition eines Use-Case-Slice stellt sicher, dass jede User Story eine Front-to-Back Story ist, die sich tatsächlich auf den Wert konzentriert.
• Systemdokumentation: Anwendungsfälle ergeben eine wirklich gute Systemdokumentation, die in den späteren Phasen des Anwendungslebenszyklus hilfreich ist. Das ist viel besser als ein großer, eher zufälliger Stapel von User Stories

In den nächsten Blogs werde ich zunächst ein Beispiel vorstellen, bei dem wir Anwendungsfall-Slices zur Definition des Product Backlogs verwenden. Später werde ich mich auf die Anwendung dieser Arbeitsweise bei Änderungen und bei bestehenden Systemen konzentrieren, die entweder keine Dokumentation haben oder deren Dokumentation auf anderen Konzepten als Anwendungsfällen basiert.

Referenzen

[1] Ivar Jacobson, Ian Spence, Kurt Bittner - Use-Case 2.0, The Guide to Succeeding with Use Cases. Erhältlich als ebook bei ivarjacobson.com
[2] Ian Spence, Kurt Bittner - Use Case Modeling - ISBN: 978-0201709131