Use Cases – können sie weg oder sind sie SAFe®?

by | 22.02.2021 | objectiF RPM anwenden

Als Ivar Jacobson das Konzept der Use Cases 1987 zum ersten Mal vorstellte, ahnte er sicher nicht, wie langlebig es sein würde. Eine Erklärung für die jahrzehntelange Popularität der Use Cases liefert er selbst [1]:
The reason for the success of the use-case approach is not just that it is a very practical technique to capture requirements from a usage perspective or to design practical user experiences, but it impacts the whole development lifecycle.” Tatsächlich waren Requirements Engineering und Usability Engineering nicht die einzigen Einsatzgebiete für Use Cases. Auch um Architekturelemente einer Lösung zu finden, Software zu entwerfen, Testfälle zu identifizieren, Wiederverwendung zu realisieren, ja sogar um Geschäftsmodelle zu entwickeln wurden Use Cases in der Vergangenheit eingesetzt. Jacobson sieht das so: „Use Cases are the hub of software development.” Sicher, für ihren Erfinder dreht sich die ganze Welt der Softwareentwicklung um Use Cases. Aber gilt das auch heute noch, nachdem die agile Entwicklung Mainstream geworden ist? Sind Use Cases für Organisationen, die die agile Entwicklung inzwischen skalieren, noch ein taugliches Konzept? Wenn wir an die wohl verbreitetste Art der Skalierung – nämlich an das Scaled Agile Framework SAFe® – denken: Haben Use Cases darin noch einen Platz?

Um die Antwort auf alle drei Fragen vorwegzunehmen: Sie lautet ja. Nachfolgend zeige ich Ihnen, wie Sie Use Cases alternativ zu Epics für die Programminkrement-Planung (kurz: PI-Planung) einsetzen können – unterstützt durch objectiF RPM.

Warum Use Cases?

Bei Use Cases und Use Case Diagrammen geht es vorrangig um eines: Kommunikation. Sie sind hervorragende Instrumente, um gemeinsam mit Stakeholdern zu erarbeiten, was eine zu entwickelnde Lösung leisten sollte, damit die angestrebten Werte entstehen. Ein Use Case definiert, wie ein konkretes Ziel eines Akteurs, der mit der Lösung interagiert, erreicht wird bzw. was alles auf dem Weg zum Ziel passieren kann. Formal kann ein Use Case als eine Abfolge von Aktionen (mit Alternativen bzw. Varianten) beschrieben werden, die dem Akteur ein sichtbares Ergebnis von Wert liefert. Das kann z.B. „engineering-mäßig“ in Form von Aktivitätsdiagramm geschehen oder „semiformal“ als strukturierter Text. Damit kann der Einsatz von Use Cases auf die jeweiligen Stakeholder zugeschnitten werden.

Mit ihrer Ziel- bzw. Wertorientierung bringen Use Cases eine wichtige Voraussetzung für den Einsatz im agilen Umfeld mit. Aber wie sieht es mit ihrer Tauglichkeit für die agile Planung aus? Jacobsen hat zusammen mit einigen Mitstreitern ein Konzept entwickelt, wie Use Cases so in „Slices“ geschnitten werden können, dass Einheiten entstehen, die jeweils in einem Sprint realisiert werden können und dabei einen Wert für den Anwender schaffen. Der große methodische Durchbruch war diesem Konzept, das 2011 als Use Case 2.0 veröffentlicht wurde [2], allerdings nicht beschieden.

Dass die Karriere der Use Cases damit dennoch nicht beendet ist, habe ich bereits vor etwas mehr als einem Jahr hier im Blog dargestellt. Denn neben ihrer besonderen Eignung für die Kommunikation und ihrer Ziel- bzw. Wertorientierung haben Use Cases eine weitere zentrale Eigenschaft: Sie können auf verschiedenen Abstraktionsebenen eingesetzt werden, auf der Ebene von Software und Systemen ebenso wie auf der Geschäftsebene. Use Cases auf Geschäftsebene – also Business Use Cases – sind nicht nur ein wirksames Instrument bei der Business Analyse. Sie besitzen auch hohes Potenzial für den Einsatz in großen agilen Vorhaben, in Programmen nach SAFe®.

Business Use Cases und SAFe®

Für Organisationen, die bisher bei der Kommunikation mit Business Stakeholdern erfolgreich mit Use Case Diagrammen und Use Cases auf Geschäftsebene gearbeitet haben, gibt es keinen Grund, in großen agilen Vorhaben nach SAFe® darauf zu verzichten. Im Gegenteil.

Use Case Diagramme und ein Business Use Case Backlog helfen,

  • die angestrebte Lösung zu definieren und abzugrenzen,
  • das Lösungsverhalten auf hohem Abstraktionsniveau zu beschreiben,
  • zu entscheiden, welche Business Use Cases als Ganzes oder in Teilen für ein Minimum Viable Product unverzichtbar sind,
  • abzuschätzen, wie viele Feature Teams ein Agiler Release Train (ART) zur Realisierung der Lösung umfassen sollte.
Use Cases helfen beim MVP

Dass man auf der Basis von Diagrammen besser – d.h. zielorientierter – diskutieren kann, gilt auch für die Definition eines Minimum Viable Products (MVP)

Der Motor eines Programms nach SAFe® ist die PI-Planung. Dabei werden die Features bestimmt, die im nächsten Inkrement realisiert werden sollen, und anschließend auf die Teams eines ART verteilt. Für die Iterationsplanung werden die Features von den Teams weiter bis auf das Niveau von User Stories zerlegt. Voraussetzung für die PI-Planung ist ein priorisiertes Programm Backlog. Es kann aus Business Use Cases und daraus abgeleiteten Feature Requirements aufgebaut werden.

Hier kommt die Tool-Unterstützung durch objectiF RPM ins Spiel: Auf der Basis der Vorlage für SAFe®-Programme können Sie in objectiF RPM mit wenigen Klicks ein Business Use Case Backlog einrichten und das Programm Backlog für Business Use Cases konfigurieren. Business Use Cases können mit objectiF RPM auf zwei Arten in Feature Requirements zerlegt werden: formal mit dem Slicing-Mechanismus nach Use Case 2.0 oder – einfacher und pragmatischer – per Ableitungsfunktion. Der von objectiF RPM unterstützte PI-Planungsworkflow, der auf dem Programm Backlog aufsetzt, kann anschließend unverändert genutzt werden.

Die Unterstützung für den Einsatz von Business Use Cases in objectiF RPM reicht jedoch noch viel weiter. Genannt werden sollen hier nur zwei der vielfältigen Funktionen:

  • Business Use Cases können direkt mit den Geschäftszielen der Stakeholder in Beziehung gesetzt werden. Das ermöglicht Traceability von den Geschäftszielen bis zu den realisierten Architekturkomponenten.
  • Zu Business Use Cases können Testfälle definiert werden. Mit den Beziehungen zwischen Business Use Cases und ihren Testfällen wird die Grundlage für End-to-End Tests geschaffen.

Wie der Einsatz von Business Use Cases in einem Programm nach SAFe® mit objectiF RPM konkret aussehen kann, zeige ich Ihnen im nachfolgenden kurzen Video an einem Beispiel.

Fazit

Auf der SAFe®-Website habe ich keine Hinweise auf den Einsatz von Business Use Cases gefunden. Das allein sollte allerdings kein Grund sein, das Konzept der Use Cases bei der Adaption von SAFe® auszusortieren – speziell dann nicht, wenn es einer Organisation in ihren Projekten lange Zeit gute Dienste erwiesen hat. Außerdem gilt: Use Case Diagramme auf Geschäftsebene besitzen auch im Kontext von SAFe® einen besonders hohen Wert. Sie zeigen im Verlauf eines Programms eine weit stabilere Sicht auf die Lösung als das „dynamische Geschehen“ im Backlog, mit dem das Feedback der Stakeholder aufgegriffen und in veränderte Features und neue User Stories umgesetzt wird.

Was kann objectiF RPM beim Einsatz von SAFe® bei Portfolio und Programm-Management sonst noch für Sie tun? Hier können Sie die aktuelle Version von objectiF RPM kennenlernen.

Quellen:

[1] Ivar Jacobson, Ian Spencer, Brian Kerr: Use Case 2.0 – The Hub of Software Development, Januar 2016, abgerufen unter: https://www.ivarjacobson.com/sites/default/files/field_iji_file/article/use-case_2.0_final_rev3.pdf

[2] Ivar Jacobson, Ian Spence und Kurt Bittner: Use Case 2.0, A Guide to Succeed with Use Cases, e-Book 2011, als Download verfügbar unter: https://www.ivarjacobson.com/publications/white-papers/use-case-ebook