- Mike Cohn: User Stories sind keine Anwendungsfälle
- Alistair Cockburn: Eine User Story verhält sich zu einem Anwendungsfall wie eine Gazelle zu einem Pavillon
- Extreme Programming.org: User Stories dienen demselben Zweck wie Use Cases, sind aber nicht dasselbe.
Der anwendungsfallorientierte Ansatz war eine der heißesten Techniken zur Anforderungserfassung, und einige Leute betrachten ihn heute als eine Art veraltete Technik im alten Stil, die mit vielen Problemen verbunden ist, die dazu führen, dass Ihr Team aufgrund der Probleme des Anwendungsfalls NICHT „agil“ ist :
- Upfront-Anforderung – Der Versuch, die Details aller Aspekte der Upfront zu definieren, führt zu viel Aufwand und Zeit, da ein Großteil der Arbeit erneut durchgeführt werden muss.
- Funktionale Dekomposition: Die funktionale Natur von Use Cases führt naturgemäß zur funktionalen Dekomposition eines Systems in konkrete und abstrakte Use Cases, die durch Extends verbunden sind und Use-Case-Assoziationen beinhalten.
Wenn Sie das Web mit den Schlüsselwörtern „Use Case vs. User Story“ durchsuchen, finden Sie eine lange Liste von Artikeln, die über die Nachteile, Probleme oder Fallstricke des Use-Case-Ansatzes sprechen, während es eine noch längere Liste der Vorteile im Zusammenhang mit User Story gibt . Interessanterweise ändern sich die Dinge in der IT-Branche so schnell und noch schneller für die Leute, die von den früher „trendigen“ Dingen zu den „neueren trendigen“ Dingen von heute wechseln.
Interessanterweise nehmen manche Leute die Dinge gerne in einem binären Muster wahr und jagen trendigen Sachen nach, indem sie sie symbolisch assoziieren, anstatt sie wirklich zu praktizieren. Einige Leute möchten andere Leute nicht einmal wissen lassen, dass sie immer noch Anwendungsfälle verwenden, oder sie könnten als veraltet und altmodisch angesehen werden.
Jetzt setzen einige Leute ein Gleichheitszeichen in Bezug auf User Story und User Case:
- Agil = User Story oder Agil = User Story + Scrum
- User Story = just-enough & just-in-time
- User Story = Benutzererwartung erfüllen & zufriedenstellend
- Use Case = Upfront Detaillierte Anforderungserfassung
- Anwendungsfall = <<include>> + <<extends>> = funktionale Zerlegung
- Anwendungsfall ist nur der Stil „Benutzereingabe“ -> „Systemantwort“.
- Anwendungsfall = alter Stil & veraltet
Als Tool-Anbieter sind wir ziemlich neutral in Bezug auf Methoden, Tools und Techniken. Ich persönlich möchte deutlich betonen, dass ich ein großer Fan von agiler Entwicklung, User Story und Scrum-Prozess bin. Insbesondere die unterstreichenden Prinzipien und Best Practices beziehen sich auf Konzepte wie:
- Anforderungsermittlung statt Anforderungslieferung
- Nach dem obigen Prinzip ergeben sich zwei wichtige Eigenschaften im agilen Entwicklungsprozess
- Gerade rechtzeitig
- Gerade genug
(Ich werde weitere Beiträge zu den oben genannten Prinzipien mit meinen eigenen Meinungen schreiben, die eng mit meinem Promotionsforschungsbereich von 1992-1995 verbunden sind – Metamodell- und Schematransformationen)
Kommen wir nun zurück zu den Themen „Use Case vs. User Story“. Nun, die schwergewichtigen Agilen Weisen haben bereits dafür gestimmt, versuche ich so stur, ihre „Stimmen umzuwerfen, indem ich argumentiere, dass sie ähnlich oder sogar gleich sind?
Lassen Sie mich Ihnen ein Beispiel zeigen, um zu veranschaulichen, ob die User Story „so anders“ ist als der User Case:
Beispiel
Gute User Stories sind viel mehr als nur Statements. Eine Standard-User-Story besteht aus drei Teilen, die gemeinhin als die drei Cs bezeichnet werden.
Das erste „C“ jeder User Story sollte dem standardisierten Format folgen von:
Als [Rolle] möchte ich [etwas tun], damit [Nutzen]
Dies ist der minimale Inhalt einer User Story, der in die Karte eingefügt werden muss.
Die Conversations sind die Inhalte des zweiten „C“ einer User Story, die die Diskussion zwischen den Endbenutzern, dem Projektinhaber und dem Entwicklungsteam darstellen. Bei dieser Konvertierung werden die mündliche Diskussion oder viele andere nützliche Informationen wie E-Mails, Wireframes oder andere verwandte Inhalte für das Projekt aufgezeichnet.
Das abschließende „C“ einer User Story ist die Bestätigung. Dies ist das Akzeptanzkriterium, das verwendet wird, um zu bestätigen, dass die User Story implementiert, korrigiert und erfolgreich geliefert wurde.
Lassen Sie mich ein wenig näher darauf eingehen, wie man den Bestätigungsteil einer User Story entwickelt. Hier verwenden wir die bekannteste Vorlage namens Gherkin, die die Given-When-Then-Formel anwendet, um das Schreiben von Akzeptanztests für eine User Story zu leiten:
- (Gegeben … und) etwas Kontext
- (Wenn … und) eine Aktion ausgeführt wird
- (Dann.. und) Führen Sie einige Aktionen aus
Tools wie Cucumber und Jbehave Testing Frameworks fördern die Verwendung der Given/When/Then-Vorlage zur Durchführung automatisierter Tests, obwohl sie auch als reine Heuristik verwendet werden kann, unabhängig davon, ob ein Tool verwendet werden soll.
Sammeln wir alle Informationen für die User Story „Kurs anmelden“ und bringen sie in das 3Cs-Format:
Ich habe das allgemein verwendete 3-Cs-Format zur Darstellung der User Story „Kurs anmelden“ übernommen. Ebenso habe ich das am weitesten verbreitete Format für die Beschreibung des gleichen Anwendungsfalls „Kurs registrieren“ übernommen, der durch eine Anwendungsfallbeschreibung ausgearbeitet wurde. Ich habe die Schritte des Bestätigungsabschnitts (das letzte C) der User Story nummeriert, die der Schrittnummer zugeordnet sind, die ich in die Anwendungsfallbeschreibung eingefügt habe. Sie sind die gleichen „Neun Schritte“ des Szenarios, die in jedem der Ansätze mit unterschiedlicher Reihenfolge eingesetzt werden. Ich glaube, dass beide Modelldarstellungen für ihre entsprechenden Weisen und Anhänger akzeptabel sind. Dann noch einmal die Frage, ist die User Story dem User Case sehr ähnlich und doch unterschiedlich oder die Reihenfolge der Schritte, die jede Art von Kritik am Use Case-Ansatz hervorruft?
Semantisch gleichwertig mit anderer Bedeutung?
Lassen Sie uns untersuchen, ob es in der Modellierungsdomäne einen ähnlichen Fall gibt, um ihn mit der Situation hier zu vergleichen, oder es könnte uns helfen, unsere eigene Abstimmung über „User Story vs. Use Cases“ abzugeben, aber nicht entweder blind der Masse zu folgen oder das zu wiederholen Weise sagten wie ein Papageiengespräch.
Beispiel: Semantisch äquivalent
In UML können wir ein Anwendungsfall-Szenario mit einem Sequenzdiagramm beschreiben, aber wir verwenden normalerweise kein Kollaborationsdiagramm für denselben Zweck; obwohl beide Diagramme semantisch äquivalent sind. Mit anderen Worten, sowohl das Sequenzdiagramm als auch das Kollaborationsdiagramm haben dieselbe Anzahl von Objekten, die an einem Szenario teilnehmen, wobei dieselbe Anzahl von Nachrichten denselben Satz von Objekten zum Ausführen einer Aufgabe eines Szenarios weiterleitet. Ersteres ist jedoch Zeitfokus und Letzteres ist Raumfokus. Das Sequenzdiagramm ist intuitiver, wenn es mit der Szenariomodellierung verwendet wird, während das Kollaborationsdiagramm für die Modellierung struktureller Beziehungen zwischen Objekten geeignet ist. dh Sie möchten das Szenario des beteiligten Objekts strukturell im MVC-Framework darstellen (Modell-/Ansichts- und Kontrollschichten).
Ich persönlich glaube nicht, dass die Verwendung von User Story mein Team agil machen wird und Use Cases dazu führen werden, dass mein Team „offen“ ist. Am wichtigsten ist, wie wir diese Tools anwenden und verwenden, mit welcher Art von Denkweise und Best Practices dahinter. Ich mache mir keine allzu großen Sorgen darüber, dass Leute mich für „alten Stil“ oder veraltet halten, wenn ich tatsächlich agil handle.
Ich erinnere mich noch an die Tage der strukturierten Analyse und des Designs, vielleicht können wir Abstract Data Type in ADA verwenden, um die objektorientierten Analyse- und Designprinzipien anzuwenden, ohne die Unterstützung von OOP in 198x zu haben, richtig? Leider stoßen Sie möglicherweise gar nicht auf die Konzepte des abstrakten Datentyps! Oh! Mein Gott, ich verrate es versehentlich – bin ich alt? Oder, ich sollte positiv denken – erlebt?
Was denken Sie? Wie ist Ihre Stimme dazu? Lass es mich wissen oder korrigiere mich, wenn ich falsch liege.
