Use-Case-Slice-basiertes Product Backlog - Ein Beispiel

Wie im vorigen Blog erläutert, sind Use-Case-Slices eine hervorragende Möglichkeit, Ihr Product Backlog zu strukturieren. In diesem Blog machen wir da weiter, wo ich zuvor aufgehört habe, indem wir uns ein konkreteres Beispiel ansehen. Wir werden das Product Backlog für ein System für ein Bibliotheksterminal erstellen.

Bei der Verwendung von Use-Case-Slices sieht der Prozess im Grunde wie folgt aus:

• Erstellen Sie das Anwendungsfallmodell
• Definieren Sie erste Anwendungsfälle
• Definieren Sie Use-Case-Stories
• Definieren Sie Use-Case-Slices
• Fügen Sie bei Bedarf weitere Details hinzu.

Ich werde diese Schritte anhand eines Beispiels für einen "Point-of-Sales"-Terminal für eine lokale Bibliothek erläutern.

Erstellen Sie das Anwendungsfallmodell

In einer Use-Case-Modellierungssitzung wird ein erster Entwurf des Systems in Form von Anwendungsfällen erstellt. Beachten Sie, dass sich die Anwendungsfälle auf den Wert und nicht auf die Technologie oder das interne Design des Systems konzentrieren sollten. Ich sehe oft, dass Leute Dinge wie "Anmeldung" als Anwendungsfall verwenden; das ist schlichtweg falsch.

In einem realen System wird die Anzahl der Anwendungsfälle zwischen 4 und 20 liegen. Aus diesem Diagramm ist ersichtlich, dass es 3 Rollen (Akteure) gibt, die Aktionen in unserem System auslösen. Der Ausleiher kann Bücher ausleihen oder zurückgeben, indem er "Bücher ausleihen" oder "Bücher zurückgeben" verwendet. Der Suchende kann mit "Buch suchen" ein Buch finden. Und schließlich kann der Empfangsmitarbeiter mit "Buchstatus aktualisieren" manuelle Änderungen am Status eines Buches vornehmen. Alle diese Anwendungsfälle interagieren mit dem Inventarsystem. Das Inventarisierungssystem initiiert jedoch nie Aktionen innerhalb unseres Systems. Alle Anwendungsfälle geben dem Akteur einen gewissen Wert; das Ausleihen von Büchern hat einen Wert, etwas wie "Karte einlegen" oder "Bibliotheksmitgliedschaft bestätigen" hat keinen eigenen Wert und würde daher nicht als Anwendungsfall dargestellt werden.

Definieren Sie erste Anwendungsfälle

In diesem Schritt wird eine übergeordnete Version des Anwendungsfalls erstellt (eine so genannte Gliederungsebene). Als Beispiel verwende ich den Anwendungsfall Bücher ausleihen.

Anwendungsfall: Bücher ausleihen Kurzbeschreibung In diesem Anwendungsfall kann der Ausleiher über einen Selbstbedienungsprozess Bücher aus der Bibliothek ausleihen. Grundlegender Ablauf - Bibliotheksausweis eingeben - Angeben, dass Bücher ausgeliehen werden müssen - Bücher auf das Lesegerät legen - Status im Bestand aktualisieren Alternative Abläufe AF1 - Verleiher storniert AF2 - Verleiher hatte ausstehenden Saldo zu begleichen AF3 - Keine Bücher auf Leser AF4 - Inventarsystem nicht verfügbar AF5 - Buch bereits ausgeliehen

Dies ist keineswegs eine vollständig ausgearbeitete Beschreibung des Anwendungsfalls, aber es reicht aus, um die Aufgabe zu erledigen. An dieser Stelle brauchen wir ihn also nicht weiter zu spezifizieren.

Definieren Sie Use-Case-Stories

In diesem Schritt wird der Anwendungsfall in die einzelnen Wege aufgeteilt, die vom Anfang des Anwendungsfalls zum Ende führen. Der Anwendungsfall Checkout Books würde wie folgt aufgeteilt werden:

Definieren Sie Use-Case-Slices

Jetzt sind wir fast am Ziel, wir haben die Anwendungsfallgeschichten, also können wir mit der Definition der Anwendungsfall-Slices beginnen. Schauen wir uns die Definition noch einmal an: 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. Wir müssen also einen Weg finden, Use-Case-Stories in Slices zusammenzufassen und sie möglicherweise durch die Angabe von Testfällen aufzuteilen. Das Ergebnis hängt stark von der jeweiligen Situation ab und ist das Ergebnis der Interaktion zwischen dem Product Owner und dem Team. Für den Anwendungsfall Checkout Books könnten wir die folgenden Use-Case-Slices erhalten:

Alle diese Use-Case-Slices werden dann als Backlog-Elemente betrachtet. Wir sind also fertig. Wir haben unser Backlog erstellt.

Was haben wir getan?

Bei der Definition des Backlogs habe ich eine Reihe von Schritten unternommen. Das folgende Bild unseres Bibliothekssystems zeigt, wie alles zusammenpasst:

Natürlich werden Sie nie ein solches Diagramm zeichnen, aber es könnte Ihnen helfen zu verstehen, was wir gerade getan haben.

Fazit

Im vorherigen Blog habe ich den Prozess beschrieben. Ich hoffe, das Beispiel hier macht das Ganze konkreter. Ich denke, ich habe deutlich gezeigt, dass es einfach (und unterhaltsam) ist, User Stories anhand von Anwendungsfällen zu erstellen. Aber es fügt ein wenig Struktur hinzu, die dafür sorgt, dass Ihre User Stories nützlicher sind. Nicht nur während der Arbeit, sondern auch danach. In den nächsten Blogs werde ich mich damit beschäftigen, wie Sie diese Arbeitsweise in einer Situation anwenden können, in der Sie nicht bei Null anfangen. Zunächst werde ich mich mit Änderungen befassen und später mit einer Situation, in der Sie mit einem bestehenden System beginnen, das über eine Dokumentation verfügen kann oder auch nicht.