Ist die Benutzerstory mit dem Use Case kompatibel?

Im Internet nachforschend, betrachten die Agile Weisen Use Cases und Benutzerstories als zwei verschiedene Dinge:

Der use-case-getriebene Ansatz war eine der heißesten Techniken zur Anforderungserfassung, und einige Menschen halten ihn mittlerweile für eine Art veraltete, alte Art der Technik, die mit vielen Problemen verbunden ist, die dazu führen, dass Ihr Team NICHT „agil“ ist aufgrund der Probleme mit dem Use Case:

  • Vorab-Anforderungen – die Versuche, die Details aller Aspekte der Vorab-Anforderungen zu definieren, führen zu viel verschwendeter Arbeit und Zeit, da ein Großteil der Arbeit neu erledigt werden muss.
  • Funktionale Zerlegung: Die funktionale Natur von Use Cases führt natürlich zur funktionalen Zerlegung eines Systems in konkrete und abstrakte Use Cases, die durch Erweiterungs- und Einbeziehung-Beziehungen zwischen Use Cases verbunden sind.

Wenn Sie im Internet mit den Stichwörtern „Use Case vs. Benutzerstory“ suchen, finden Sie eine lange Liste von Artikeln, die über die Nachteile, Probleme oder Fallstricke des Use-Case-Ansatzes berichten, während es sogar eine noch längere Liste der Vorteile im Zusammenhang mit der Benutzerstory gibt. Interessant: Dinge ändern sich in der IT-Branche so schnell, und noch schneller für diejenigen, die von den einst „trendigen“ Dingen der Vergangenheit zu den „neueren trendigen“ Dingen der Gegenwart wechseln.

Interessanterweise neigen einige Menschen dazu, Dinge in einer binären Weise wahrzunehmen und suchen nach trendigen Dingen, indem sie sie symbolisch verbinden, anstatt sie tatsächlich authentisch zu praktizieren. Einige Menschen wollen anderen sogar nicht sagen, dass sie weiterhin Use Cases verwenden, da sie sonst als veraltet und altmodisch angesehen werden könnten.

Heute setzen einige Menschen ein Gleichheitszeichen zwischen Benutzerstory und Use Case:

  • Agil = Benutzerstory oder Agil = Benutzerstory + Scrum
  • Benutzerstory = gerade genug & gerade zum richtigen Zeitpunkt
  • Benutzerstory = Erfüllung der Benutzererwartungen & Zufriedenheit
  • Use Case = Vorab detaillierte Anforderungserfassung
  • Use Case = <<include>> + <<extends>> = funktionale Zerlegung
  • Use Case ist ein „Benutzer-Eingabe“ → „System-Antwort“-Stil nur
  • Use Case = alte Art & veraltet

Als Werkzeuganbieter sind wir in Methoden, Tools und Techniken ziemlich neutral. Persönlich möchte ich betonen, dass ich ein großer Fan von agiler Entwicklung, Benutzerstories und dem Scrum-Prozess bin. Insbesondere die zugrundeliegenden Prinzipien und Best Practices im Zusammenhang mit Konzepten wie:

  • Anforderungsentdeckung anstelle von Anforderungslieferung
  • Unter dem oben genannten Prinzip ergeben sich zwei wichtige Eigenschaften im agilen Entwicklungsprozess
    • Gerade zum richtigen Zeitpunkt
    • Gerade genug

(Ich werde weitere Beiträge zu den oben genannten Prinzipien mit meinen eigenen Meinungen schreiben, die eng mit meinem PhD-Forschungsbereich zwischen 1992 und 1995 – Metamodelle und Schema-Transformationen – verbunden sind)

Gehen wir nun zurück zu den Themen „Use Case vs. Benutzerstory“. Nun, die großen Vordenker des Agilen haben bereits ihre Stimme abgegeben, bin ich so stur, versuchend, ihre „Stimmen“ durch Argumente, dass sie ähnlich oder sogar gleich sind, zu überwinden?

Lassen Sie mich Ihnen ein Beispiel zeigen, um zu veranschaulichen, ob die Benutzerstory „so anders“ ist als der Use Case:

Beispiel

Gute Benutzerstories sind viel mehr als nur Aussagen. Ein standardmäßiger Benutzerstory besteht aus drei Teilen, die allgemein als die drei C’s bezeichnet werden.

Der erste „C“ jedes Benutzerstories sollte dem standardisierten Format folgen:

Als [Rolle] möchte ich [etwas tun], damit [Vorteile]

was der minimale Inhalt eines Benutzerstories ist, der auf die Karte gesetzt werden soll.

Die Gespräche sind der Inhalt des zweiten „C“ eines Benutzerstories, der die Diskussion zwischen den Endbenutzern, dem Projektbesitzer und dem Entwicklerteam darstellt. In diesen Gesprächen werden die mündlichen Diskussionen oder viele andere nützliche Informationen wie E-Mails, Wireframes oder andere verwandte Inhalte für das Projekt dokumentiert.

Der letzte „C“ eines Benutzerstories ist die Bestätigung, die die Akzeptanzkriterien darstellt, die verwendet werden, um zu bestätigen, dass der Benutzerstory korrekt implementiert und erfolgreich geliefert wurde.

Lassen Sie mich etwas weiter ausführen, wie man den Bestätigungsabschnitt eines Benutzerstories entwickelt. Hier verwenden wir die bekannteste Vorlage namens Gherkin, die die Given-When-Then-Formel nutzt, um das Schreiben von Akzeptanztests für einen Benutzerstory zu leiten:

  • (Gegeben.. und) ein Kontext
  • (Wenn.. und) eine Aktion ausgeführt wird
  • (Dann.. und) Führen Sie einige Aktionen aus

Werkzeuge wie Cucumber und Jbehave-Testframeworks fördern die Verwendung der Given/When/Then-Vorlage für die Durchführung automatisierter Tests, obwohl sie auch rein als Heuristik verwendet werden können, unabhängig davon, ob ein Werkzeug eingesetzt wird.

Lassen Sie uns alle Informationen für den Benutzerstory „Kurs anmelden“ sammeln und in das 3Cs-Format bringen:

confirmation

Ich habe das üblicherweise verwendete 3-Cs-Format für die Darstellung des Benutzerstories „Kurs anmelden“ übernommen. Ebenso habe ich auch das am häufigsten verwendete Format für die Beschreibung desselben „Kurs anmelden“-Anwendungsfalls übernommen, wie er in einer Anwendungsfallbeschreibung dargestellt wird. Ich habe die Schritte des Bestätigungsabschnitts (des letzten C) des Benutzerstories nummeriert, die mit der Nummerierung der Schritte übereinstimmen, die ich in der Anwendungsfallbeschreibung verwendet habe. Es handelt sich um dieselben „neun Schritte“ des Szenarios, die in jeder Herangehensweise in unterschiedlicher Reihenfolge eingefügt werden. Ich glaube, dass beide Modellrepräsentationen für ihre jeweiligen Anhänger und Vertreter akzeptabel sind. Die Frage bleibt jedoch: Ist der Benutzerstory sehr ähnlich dem Anwendungsfall, aber dennoch unterschiedlich, oder verursacht die Reihenfolge der Schritte die ganze Kritik am Anwendungsfallansatz?

Semantisch äquivalent mit unterschiedlicher Bedeutung?

Lassen Sie uns untersuchen, ob es im Modellierungsgebiet einen ähnlichen Fall gibt, damit wir ihn mit der vorliegenden Situation vergleichen können, oder ob es uns helfen könnte, unsere eigene Meinung zu „Benutzerstory vs Anwendungsfall“ zu bilden, ohne blind der Masse zu folgen oder das zu wiederholen, was die Weisen gesagt haben, wie ein Papagei.

use case description - user story

Beispiel: Semantisch äquivalent

In UML können wir einen Anwendungsfall-Szenario mit einem Sequenzdiagramm beschreiben, aber wir verwenden normalerweise kein Zusammenarbeitsschema für denselben Zweck; obwohl beide Diagramme semantisch äquivalent sind. Mit anderen Worten, sowohl das Sequenzdiagramm als auch das Zusammenarbeitsschema haben die gleiche Anzahl von Objekten, die an einem Szenario teilnehmen, und die gleiche Anzahl von Nachrichten, die zwischen derselben Gruppe von Objekten übertragen werden, um eine Aufgabe eines Szenarios auszuführen. Allerdings ist das erste zeitorientiert und das letztere raumorientiert. Das Sequenzdiagramm ist intuitiver, wenn es mit der Szenariomodellierung verwendet wird, während das Zusammenarbeitsschema für die Modellierung struktureller Beziehungen zwischen Objekten geeignet ist. Zum Beispiel, wenn Sie das Szenario der beteiligten Objekte strukturell in ein MVC-Framework (Modell/Ansicht und Steuerungsebene) darstellen möchten.

Persönlich glaube ich nicht, dass die Verwendung von Benutzerstories meine Mannschaft agile machen wird, und dass Anwendungsfall die Mannschaft „vorausschauend“ machen wird. Am wichtigsten ist, wie wir diese Werkzeuge mit welcher Einstellung und besten Praktiken einsetzen. Ich mache mir keine großen Sorgen darüber, dass Menschen mich als „altmodisch“ oder veraltet betrachten, wenn ich tatsächlich agil handele.

Ich erinnere mich noch an die Zeit der strukturierten Analyse und des Entwurfs, vielleicht konnten wir in ADA den abstrakten Datentyp verwenden, um objektorientierte Analyse- und Entwurfprinzipien anzuwenden, ohne die Unterstützung von OOP im Jahr 198x zu haben, oder? Leider könnten Sie die Konzepte des abstrakten Datentyps gar nicht kennenlernen! Oh! Mein Gott, ich habe versehentlich preisgegeben – bin ich alt? Oder sollte ich positiv denken – erfahrener?

 

Kommentar hinterlassen