Was sollte zuerst getan werden: Anwendungsfälle oder User Stories?

Ich habe sowohl von Anwendungsfällen (ich spreche von der Beschreibung, nicht vom Diagramm) als auch von User Stories gehört, mit denen Anforderungen gesammelt und besser organisiert werden.

Ich arbeite alleine, also versuche ich nur, den besten Weg zu finden, um Anforderungen zu organisieren und zu verstehen, was in der Entwicklung zu tun ist. Ich habe und brauche keine formalen Methoden mit riesigen Dokumenten und so weiter.

User Stories Ich werde anscheinend verwendet, um das Product Backlog zu erstellen, das alles enthält, was in der Entwicklung getan werden muss.

Anwendungsfälle hingegen beschreiben, wie im System vorgegangen wird, wie die Interaktion zwischen externen Akteuren und dem System abläuft.

Es scheint mir, dass es für einen Anwendungsfall mehrere User Stories gibt.

Dies führt mich zu folgender Frage: Was soll ich zuerst tun, wenn ich Anforderungen entdecke? User Stories finden und schreiben oder Use Cases finden und schreiben? Oder sollten sie irgendwie "zur gleichen Zeit" gemacht werden?

Ich bin eigentlich ziemlich verwirrt. Was ist in Bezug auf Anwendungsfälle und User Stories für einen Entwickler, der alleine arbeitet, ein guter Workflow, um diese Methoden korrekt zu verwenden, um eine bessere Entwicklung zu erzielen?

Anwendungsfälle und User Stories sind Tools zum Sammeln und Ausdrücken von Anforderungen.
Wie Sie bereits festgestellt haben, hat ein einzelner Anwendungsfall in der Regel einen breiteren Anwendungsbereich als eine einzelne User Story, da versucht wird, eine Benutzerinteraktion einschließlich Fehlern und Abweichungen vom normalen Pfad vollständig zu beschreiben. Eine User Story kann grob mit einem einzelnen Flow durch einen Anwendungsfall verglichen werden.

Wie bei allen Tools liegt es an Ihnen, die Tools zu verwenden, die Sie in einer bestimmten Situation für notwendig halten. Dies bedeutet, dass Sie nur Anwendungsfälle, nur User Stories oder eine Kombination aus Use Cases und User Stories verwenden können, wie Sie es für richtig halten.

Es wird immer häufiger, User Stories als Arbeitseinheit für das zu verwenden, was in einer Iteration / einem Sprint entwickelt und bereitgestellt werden kann.
In diesem Sinne würde ich mich nicht zu sehr darauf konzentrieren, Anforderungen als Anwendungsfälle zu erfassen, es sei denn, die Anwendungsfälle kommen natürlich vor, wenn ich mit den Stakeholdern spreche.

In meinem Fall habe ich immer festgestellt, dass die für vollständige Anwendungsfälle erforderliche Detailebene dadurch entsteht, dass ich zuerst meine User Stories durchdenke. Die erste Frage, die ich stelle, lautet: "Was müssen Menschen tun können?". Sobald ich die Szenarien habe, ist es einfacher, alle Anwendungsfälle und Varianten des Ablaufs für das System durchzugehen.

Abgesehen davon müssen Sie sich für einen einzelnen Entwickler, der alleine arbeitet, nicht wirklich darum kümmern, ob es sich um einen Anwendungsfall oder eine User Story oder einen Sticky an der Wand handelt, auf dem steht: "Vergessen Sie nicht 'x'". Was Sie brauchen, ist ein Prozess, bei dem Sie darüber nachdenken, was Ihre Benutzer erreichen möchten, und der Ihnen hilft, die verschiedenen Dinge zu verfolgen, die sie tun müssen. Alles andere liegt bei Ihnen in Bezug auf den Detaillierungsgrad, den Sie notieren müssen, um Ihre Entwicklung zu planen.

Wenn ich zum Beispiel an einem Solo-Nebenprojekt arbeite, sehen meine Arbeitsaufgaben ungefähr so ​​aus:

1. Anmeldung
2. Liste von 'foo' anzeigen
3. Auswahl aus Liste speichern
4. Suche

Ehrlich gesagt, jeder von ihnen hätte nicht mehr als eine Schätzung. Warum? Weil ich sie nur als Erinnerung daran benutze, was ich tun muss, damit der Benutzer sie ausführen kann, und ich werde die Details herausfinden, wenn ich zu diesem Teil komme. Mit einem Team von einer einzelnen Person kann alles in Ihrem Kopf sein und das ist in Ordnung, weil Sie es niemandem mitteilen müssen.

Nun gibt es Vorbehalte ...

Einzelner Entwickler arbeitet mit anderen Spezialisten zusammen

Müssen Sie einem anderen Team über Fortschritte berichten? Haben Sie Tester, die Ihre Arbeit validieren müssen? Haben Sie ein Management, das wissen möchte, was Sie getan haben? Haben Sie einen Projektmanager, der einen Zeitplan vorhersagen muss? Haben Sie einen Product Owner, der die erforderlichen Funktionen festlegt?

Wenn diese Personen Teil Ihres Projekts sind, müssen Sie sicherstellen, dass Ihre Arbeitsaufgaben über genügend Informationen verfügen, damit sie ihre Arbeit erledigen können. Der Premierminister braucht wahrscheinlich eine Möglichkeit, die relative Größe der Dinge zu erkennen und Fortschritte bei dieser Arbeit zu erzielen. Ihre Tester benötigen Details darüber, wie die Dinge voraussichtlich ablaufen (Anwendungsfälle), und Sie können sie sogar bitten, Ihnen beim Schreiben zu helfen. Das Management möchte möglicherweise wissen, woran Sie gerade arbeiten. Daher benötigen Sie eine ausreichende Geschäftsbeschreibung, damit es die Funktionen verstehen kann, die Sie bereitstellen werden.

Wenn Sie all diese Fragen mit "Ja" beantwortet haben, benötigen Sie wahrscheinlich einen strenger dokumentierten Rückstand, da Sie ihn für die Kommunikation mit den anderen Mitgliedern Ihres Teams verwenden werden.

• Sie benötigen wahrscheinlich das Konzept "Epics" oder "Features", das die Funktionen auf hoher Ebene darstellt, mit denen Sie dem Management oder Ihren Produktbesitzern Bericht erstatten können.
• Sie haben verschachtelte User Stories in diesen Epics / Features, die die kleineren Funktionsblöcke definieren, die verwendet werden, um den Fortschritt mit Ihrem Projektmanager zu kommunizieren, Ihre Arbeitsaufgaben innerhalb eines Sprints zu definieren und um das Geschäftsziel an das zu kommunizieren Testteam.
• Für die Storys werden Anwendungsfälle oder Testfälle definiert, um die verschiedenen Low-Level-Flow-Entscheidungen zu erfassen, die erforderlich sind, um sicherzustellen, dass Sie, das Unternehmen und das Testteam aufeinander abgestimmt sind und wissen, was als "korrekt" akzeptiert wird.

Alle oben genannten Punkte können einfach ignoriert werden, wenn Sie die Arbeit definieren, den Fortschritt verwalten, die Software testen und entscheiden, ob etwas „korrekt“ ist. Reduzieren Sie den zusätzlichen Aufwand und stellen Sie sicher, dass Sie das tun, was wichtig ist: funktionierende Software erstellen!

Wenn Sie eine Art von Agilität betreiben, lautet die dogmatische Antwort: Tun Sie, was für Sie funktioniert.

Der Prozess sollte Teil Ihrer Rückblicke sein. Sie sollten über Engpässe, Redundanzen, Kommunikationsprobleme, Dokumente sprechen, die niemand jemals liest usw. Und genau hier sollten Prozessänderungen vereinbart und idealerweise in Gang gesetzt werden.

Nach meiner Erfahrung werden Projektmanager, Analysten und "Geschäftsleute" geschult, um den Prozess "von innen nach außen" durchzuführen. Sie sammeln Anforderungen, die von Stakeholdern häufig mündlich in Form von User Storys angegeben werden. Sie stellen Fragen zur Klärung, damit sie detaillierte "Anwendungsfall" -Dokumente erstellen können, die das Entwicklungsteam versucht, wieder in User Stories zu übersetzen, die sie wiederholen können ...

Meine Empfehlung basiert auf meiner eigenen Erfahrung: Versuchen Sie, Ihr Team oder Ihren Analysten oder jeden anderen dazu zu bringen, User Stories mit minimalen Details direkt in den Rückstand zu stellen. Fügen Sie Prioritätsinformationen hinzu und beschreiben Sie das "Problem", das mit der Geschichte gelöst werden soll. Nennen Sie vielleicht einige mögliche Lösungen ... aber lassen Sie darüber hinaus die "Anwendungsfälle" entstehen, wenn Ihre Entwickler mit der Qualitätssicherung und / oder den Stakeholdern über die Storys iterieren .

Notieren Sie die Anwendungsfälle, auf die Sie gestoßen sind, in Ihrer Dokumentation, während die Story aufgelöst wird, und zwar in einem beliebigen Format, das den Leuten hilft, das System zu verstehen.

User Stories und Use Cases schließen sich nicht gegenseitig aus und es gibt kein "sollte" .

Sie sind nur Werkzeuge, die hilfreich sein können oder nicht, um Ihren Prozess bis zu einem gewissen Punkt zu verbessern. Es gibt viele Möglichkeiten, ich würde nur eine vorschlagen, bei der sowohl Anwendungsfälle als auch Geschichten zusammen verwendet werden:

• Versuchen Sie für Rückstand und Planung User Stories als Platzhalter für Funktionen auf hoher Ebene. (Natürlich können auch Anwendungsfälle bis zur Benutzerzielstufe hilfreich sein.)
• Um bereits implementierte Anforderungen zu dokumentieren, funktionieren Anwendungsfälle am besten.

Es kommt darauf an . Wenn Sie alleine arbeiten, probieren Sie verschiedene Ansätze aus und wählen Sie, was für Sie am besten funktioniert.

Haftungsausschluss: Es gibt viele Methoden, wie man sie aufschreibt. "User Stories" haben eine sehr gemeinsame Definition, während "Use Cases" sehr unterschiedliche Bedeutungen haben können. Ich beziehe mich auf die klassischen UML-Diagramme, die sehr häufig sind.

User Stories oder Anwendungsfälle

Nach meiner Erfahrung gibt es unterschiedliche Denkweisen, auf welche Weise man besser verstehen kann. Also würde ich über jedes neue Projektteam entscheiden, wie die Anforderungen dokumentiert werden sollen. Normalerweise ist eine Kombination üblich, bei der Anwendungsfälle für die Übersicht und User Stories für Details verwendet werden.

• Anwendungsfälle , insbesondere als Diagramme, eignen sich besser für Menschen, die visuell denken
• User Stories werden von Leuten bevorzugt, die in Diskussionen denken, die sehr gesprächig sind

(Dies ist meinungsbasiert, ohne wissenschaftliche Grundlage)

Was ist zuerst zu tun?

Beim Schreiben der Anforderungen für ein Projekt würde ich auf einer sehr abstrakten Ebene beginnen. Anhand von Anwendungsfällen würden Sie ein (UML-) Diagramm mit den globalen Zielen des Projekts zeichnen. Schreiben Sie mit User Stories einige "epische Geschichten" auf, in denen die Hauptziele beschrieben werden.

Ein zweiter Schritt wäre, auf die Details einzugehen. Dabei sollten Sie versuchen, einen Verweis auf eine "epische Geschichte" oder ein globales Ziel beizubehalten. Dies hilft sehr bei der Strukturierung der Anforderungen.

Ich werde es anders herum betrachten: Was muss als letztes kommen?

Der letzte Schritt besteht darin, dass Sie (oder eine andere Person) Anforderungen in Ihr Backlog eingeben. Die Anforderungen müssen so sein, dass Sie wissen, wie sich der von Ihnen geschriebene Code verhalten soll, und dass Tester überprüfen können, ob sich Ihr Code so verhält, wie er sich verhalten soll.

Diese Anforderungen können sehr gut in Form einer genau definierten User Story aufgezeichnet werden. Die User Story kann also der letzte Schritt sein. Anwendungsfälle werden normalerweise zu mehr als einer User Story, daher müssen sie vor der User Story stehen.

Früher dachte ich, Use Cases seien für den Wasserfall-Ansatz gedacht, während User Stories mit dem Agile-Prozess einhergingen. Es dauerte eine Weile, bis mir klar wurde, dass sie nicht exklusiv sind.

Da Sie diese nicht teilen müssen, geht es nur um Kommunikation mit Ihnen. Solange Sie Ihre Notizen etwa eine Woche später verstehen können, sind Sie gut. Fügen Sie andernfalls weitere Details hinzu, wenn Sie die Anforderungen notieren.

Benötigen Sie eine visuelle und flexible Möglichkeit, Ihren Fortschritt zu verfolgen und Prioritäten zu setzen? In diesem Fall wären User Stories hilfreich, zusammen mit dem Fortschrittsboard, das Sie in den meisten agilen Methoden finden (Aufgaben, erledigt, aktueller Sprint).

Wenn es um reine Anforderungen geht und Sie wissen, was und wie gelöst werden muss, empfehlen wir Ihnen, mit User Stories zu beginnen, da diese einfach zu erstellen sind (ein Satz), oder mit einem Anwendungsfalldiagramm, in dem nur Akteure und Aktionen auf hoher Ebene aufgeführt sind.

Wenn Details benötigt werden, führen Sie einen Drilldown mit weiteren User Stories durch. Wenn Sie auf einen komplexen Prozess stoßen (Verzweigung, viele Bedingungen und Voraussetzungen), können Sie die User Story mit einem Anwendungsfall verknüpfen, unabhängig davon, ob Sie ein Diagramm oder die Textvorlagenversion verwenden. Und denken Sie daran, dass auch diese mit unterschiedlichen Detaillierungsgraden erstellt werden können. Das Softwareanforderungsbuch von Karl Wiegers & Joy Beatty empfiehlt, nur den Detaillierungsgrad beizubehalten, der zum Verständnis erforderlich ist. Wenn Ihnen etwas völlig klar ist, müssen Sie keinen Drilldown durchführen.

Das Obige habe ich persönlich zunächst nicht verstanden: User Stories sind ein Ausgangspunkt, eine "Zusammenfassung", aber jedes kann durch zusätzliche Dokumente ergänzt werden, um genauer zu definieren, was gemeint und benötigt wird, einschließlich detaillierter Anwendungsfälle, falls erforderlich.