Personas meet Use Case 2.0

Wenn Sie softwarebasierte Produkte oder Systeme entwickeln, kennen Sie diesen Moment: Sie haben Businessziele erkundet, zahlreiche Stakeholder befragt, diverse Anwender an ihren Arbeitsplätzen beobachtet, Dokumente und Abläufe analysiert, Wettbewerbs- oder vergleichbare Kaufprodukte evaluiert, Brainstorming gemacht, Ideen gesammelt, technische Restriktionen ausgelotet. Und da stehen Sie nun mit all Ihren Erkenntnissen und fragen sich: Wie fange ich an? Wie setze ich das Wissen ein, um ein Produkt zu entwickeln, dass die Anwender begeistert und die Ziele der Stakeholder erfüllt? Und wie gehe ich vor, sodass frühzeitig Nutzen für die Anwender entsteht? Wenn Sie zukünftige Anwender jederzeit in die Arbeit einbeziehen können, dann haben Sie die denkbar beste Unterstützung bei der Entscheidung, was unverzichtbar, wichtig und nützlich ist. Aber was tun Sie, wenn das nicht möglich ist? Wie machen Sie aus all Ihren Erkenntnissen konkrete Anforderungen, die Sie agil umsetzen können?

Hier mein Vorschlag:

1. Bauen Sie Modelle der Anwender. Modellieren Sie Personas [1]. Personas werden aus Eigenschaften und Verhaltensmustern vieler realer Anwender zusammengesetzt. Im Gegensatz zu Akteuren, wie sie bei der Use Case Analyse verwendet werden, sind Personas keine abstrakten Rollen. Eine Persona wird vielmehr so lebendig beschrieben, als würde sie wirklich existieren. Eigentlich werden Personas auf der Basis von Daten entwickelt, die die Marktforschung liefert. Dazu haben Sie keinen Zugang? Macht nichts. Sammeln Sie das Know-how über Anwender, das Ihre Kollegen z.B. im Service, Vertrieb und Marketing besitzen, und konstruieren Sie draus im Team provisorische oder Ad-hoc-Personas. Nach unserer Erfahrung ist das Ergebnis immer noch äußerst hilfreich.

Wozu ist diese ganze Aktion gut? Die Personas dienen als Filter für die Vielfalt Ihrer Erkenntnisse der Business Analyse oder des Requirements Engineering. Sie helfen, zu bewerten, was wichtig für die zukünftigen Anwender ist. Ganz nebenbei entwickelt Ihr Team Empathie für die Anwender.

Und dann?

2. Dann denken Sie sich in Form von Geschichten eine bessere Zukunft für Ihre Personas aus – und damit auch für die Anwender des neuen Produkts. Upps, jetzt wird es methodisch ziemlich fragwürdig, oder? Nein! Geschichten erzählen oder Storytelling ist einen der ältesten Kulturtechniken der Menschheit. Mit Hilfe von Geschichten können wir Menschen Ideen sehr gut transportieren. Erzählen Sie – aus Sicht der Personas und orientiert an deren Ziele und Erwartungen – Geschichten über darüber, wie das neue System im Arbeitsalltag genutzt wird. Sie werden es selbst erleben: Im Team kann man über Geschichten viel besser diskutieren als über Konzepte. Die Geschichten heißen übrigens Szenarios bzw. Personaszenarios.

Bezeichnet der Begriff Szenario nicht den Durchlauf durch einen Use Case? Werden hier also Use Cases definiert? Nein. Ein Szenario, so wie es hier verstanden wird, beschreibt das, was eine Persona tut, um ein fachliches Ziel zu erreichen – unterstützt durch das neue System oder Produkt. Ein Use Case ist ein spezifisches Verhalten eines Systems, das dazu beiträgt, ein Business-Ziel zu erreichen. Ein kleiner, aber entscheidender Unterschied in der Sichtweise.

Wie wird aus Wissen ein Produkt, das die Anwender begeistert und die Ziele der Stakeholder erfüllt?

Ein Use Case wird als Folge von Aktionen eines Systems beschrieben, die in Interaktion mit einem Akteur ausgeführt wird. Aus Persona-Szenarios kann man Use Cases durch Abstraktion des Ablaufs gewinnen. Genau darum geht es im nächsten Schritt.

3. Abstrahieren Sie die Personas zu Rollen, das heißt zu Akteuren, und die Persona-Szenarios zu Use Cases, die das Verhalten anbieten, das vom System erwartet wird. Spezifizieren Sie dann jeden Use Case im Detail: Beschreiben Sie zunächst den erfolgreichen Weg durch einen Use Case als Folge von Interaktionsschritten im Sinne von Akteur tut … System tut …Akteur tut … Dieser Weg wird als Basic Flow An vielen Stellen des Basic Flow können Bedingungen eintreten, die den Anwender vom geraden Weg abbringen. Diese Umwege werden als Alternative Flows bezeichnet. Anhand der Persona-Szenarios, also Ihren Geschichten, können Sie herausfinden, welche Wege und Umwege durch einen Use Case sinnvoll sind. Diese Flows werden auch als Use Case Stories bezeichnet. Geben Sie jeder Use Cases Story einen Namen.

Use Case Story klingt irgendwie nach agiler Entwicklung, nicht wahr? Use Case Stories sind aber nicht zu verwechseln mit den User Stories aus Scrum oder XP. User Stories werden mit kurzen schablonenhaften Sätzen der Form Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> beschrieben, bilden die Kundenanforderungen in agilen Projekten ab, sind Kommunikationsinstrument des Teams und dienen als Planungseinheiten für das agile Projektmanagement. Genau das leisten Use Case Stories auch. Sie erlauben es, ein System „scheibchenweise“ zu realisieren und mit jedem Scheibchen Nutzen für den Anwender zu schaffen. Wie das funktioniert, wurde unter dem Namen Use-Case-2.0 [2] im Jahr 2011 erstmals beschrieben. Und das geht so:

4. Bestimmen Sie die Use Case Stories, die für die Anwender – vertreten durch Ihre Personas – höchste Priorität haben und den größten Wert schaffen. In den Persona-Szenarios sollten Sie dafür jede Menge Anhaltspunkte finden. Je nachdem wie umfangreich die Use Case Stories sind, können Sie davon eine oder mehrere zu einer „Scheibe“, einem Use Case Slice Zu so einer „Scheibe“ gehören übrigens auch immer Testfälle. „Zerschneiden“ Sie also nach und nach die entwickelten Use Cases. Die Use Case Slices bilden die Planungseinheiten für die Sprint-Planung im agilen Projekt.

Wenn Sie diesen Einstieg in die agile Entwicklung von softwarebasierten Produkten oder Systemen spannend finden, fragen Sie sich vielleicht: Wie kann man die vier Schritte dokumentieren und nachvollziehbar machen? Als Tool-Hersteller haben wir eine Antwort darauf: Mit in-STEP RED (umbenannt in objectiF RPM).

Hinweise:

[1] Alan Cooper, Robert Reimann, David Cronin, Christopher Noessel: About Face: The Essentials of Interaction Design, John Wiley & Sons; Auflage, 4. Auflage, September 2014
[2] Ivar Jacobson, Ian Spence, Kurt Bittner: Use-Case 2.0 – The Guide to Succeeding with Use Cases, E-Book 2011, http://www.ivarjacobson.com/Use_Case2.0_ebook/

Das könnte Sie auch interessieren:

Wie benutzen Sie Personas konkret?