Die Reihenfolge der Nutzung ist das Wichtige
Die Grundlage für Softwareimplementierung stellen sogenannte Use Cases dar. Das sind Anforderungsabläufe. Diese müssen von dem Fachbereich oder der Geschäftsprozessentwicklung kommen. Diese wiederum können in Prozessabläufe/Ablaufdiagramme gruppiert werden. Siehe einen meiner vorigen Blog Einträge zu dem Thema. Die Dokumentation von Use Cases und Prozessen mit ihren Ablaufdiagrammen sollten textuell und visuell erfolgen, daher in einem Tool, wie Confluence oder in einer Word-Datei.
Mit dieser Dokumentation und Herangehensweise ist die Anforderung in einem Use Case klar formuliert und über ein Prozess-Ablaufdiagramm einfach visualisiert. Zur Umsetzung bietet sich ein Tool wie beispielsweise Microsoft Azure DevOps an, in dem die Prozesse mit ihren Phasen und konkreten Anforderungen zur Umsetzung mit Umsetzungs-Aufgaben erfasst und im Team bearbeitet werden können. In Azure DevOps sind die gruppierenden Elemente Epic und Feature und die Details zur Realisierung werden in User Stories und mit Tasks erfasst.
Use Cases sind in Azure DevOps nicht relevant. Hier kommen die Test Cases ins Spiel, also konkrete Inhaltliche Anforderungen mit Beispieldaten basierend auf den Use Cases und in Bezug zu den Epics und/oder Features.
Aus den Test Cases ergeben sich nun User Stories und während der Umsetzung können neue User Stories die Test Cases ergänzen, detaillieren oder sogar optimieren. Das ist eine grundlegend wichtige Reihenfolge - Oft werden aus den Prozessen heraus User Stories erstellt. Diese Vorgehensweise kann funktionieren, braucht aber sehr erfahrene Teilnehmende. Sowohl auf fachlicher, als auch auf organisatorischer, prozessualer und technischer Ebene. Wenn Projekte mit unerfahrenen Fachbereichen oder jungem Umsetzungsteam oder unerfahrene Teilnehmende in Bezug auf User Stories gestartet wird, ist das oft schwierig aus diversen Gründen.
Einfacher ist es somit, einen bestimmten Arbeitsablauf in einem Prozess in der Umsetzung angehen zu wollen, und dazu eben diesen Test Case vom Fachbereich aus Use Cases erstellen zu lassen, und im System zu prüfen, was fehlt - dass sind dann die User Stories. Hier ist genau die wichtige Verbindung zwischen fachlichen Arbeitsfluss und aktuellen Entwicklungsstand des Systems.
Das Gute an dieser Vorgehensweise ist, dass zu Beginn die Anforderung in Use Cases klar formuliert, in der Umsetzung diese herangezogen und daraus die Umsetzung gesteuert und am Ende der Umsetzung diese getestet werden kann. Und auf der anderen Seite muss keine komplexe Konzeption geschrieben werden, sondern alles basiert auf den Use Cases.
Erklärung des Ablauf Diagramms:
- Übergreifenden Use Cases können in kleinere Use Cases aufgeteilt werden
- Aus einer Liste von Use Cases wird ein oder mehrere Prozess-Ablaufdiagramme
- Das Prozess-Ablaufdiagramm wird als Epic und Feature in einer Hierarchie erfasst (Epic und Feature sind hierarchisch verbunden (Blaue Pfeile)
- Unter dem Feature sind funktionale Anforderungsschritte (User Stories) und sie haben Umsetzungs-Aufgaben (Tasks) darunter (Blaue Pfeile)
- Test Cases basieren auf Use Cases (gelber Pfeil) sind aber abgeleitet aus einem Epic, wenn der Prozess gesamtheitlich getestet werden soll, oder aus einem Feature, wenn nur eine Phase eines Prozesses getestet werden soll
- WICHTIG: Nicht ein Epic oder Feature definiert eine initiale User Story, die dann in einem Test Case getestet wird (roter Pfeil), sondern der Test Case definiert zu einem Epic oder Feature die funktionale Anforderung in der User Story (grüner Pfeil)