Googlując po Internecie, Agile Sages uważa, że ​​przypadki użycia i historyjki użytkowników to dwie różne rzeczy:

• Mike Cohn:  Historie użytkowników to nie przypadki użycia
• Alistair Cockburn:  Historia użytkownika jest dla przypadku użycia, tak jak gazela jest dla altany
• Extreme Programming.org:  Historyjki użytkownika służą temu samemu celowi, co przypadki użycia, ale nie są takie same.

Podejście oparte na przypadku użycia było jedną z najgorętszych technik przechwytywania wymagań, a niektórzy ludzie uważają, że jest to przestarzała technika w starym stylu, która wiąże się z wieloma problemami, które powodują, że Twój zespół NIE jest „zwinny” z powodu problemów związanych z przypadkiem użycia :

• Wymóg wstępny — próba zdefiniowania szczegółów wszystkich aspektów wstępnych spowoduje wiele zmarnowanego wysiłku i czasu, ponieważ wiele pracy będzie musiało zostać wykonane ponownie.
• Funkcjonalna dekompozycja: Funkcjonalna natura przypadków użycia naturalnie prowadzi do funkcjonalnej dekompozycji systemu pod kątem konkretnych i abstrakcyjnych przypadków użycia, które są powiązane rozszerzeniami i zawierają skojarzenia przypadków użycia.

Jeśli przeszukasz sieć za pomocą słów kluczowych „przypadek użycia vs historyjka użytkownika”, znajdziesz długą listę artykułów sugerujących wady, problemy lub pułapki podejścia do przypadku użycia, a lista korzyści związanych z historyjką użytkownika jest jeszcze dłuższa. . Co ciekawe, w branży IT rzeczy zmieniają się bardzo szybko, a nawet szybciej dla ludzi, którzy przestawiają się z „modnych” rzeczy w przeszłości na „nowsze trendy” obecnie.

Co ciekawe, niektórzy ludzie lubią postrzegać rzeczy w sposób binarny i gonić za modnymi rzeczami, kojarząc się z nimi symbolicznie, zamiast faktycznie praktykować. Niektórzy ludzie nawet nie chcą, aby inni wiedzieli, że nadal używają przypadków użycia, lub mogą zostać uznane za przestarzałe i staromodne.

Teraz niektórzy umieszczają znak równości związany z historyjką użytkownika i przypadkiem użytkownika:

• Agile = historyjka użytkownika lub Agile = historyjka użytkownika + Scrum
• Historia użytkownika = w sam raz i dokładnie na czas
• Historia użytkownika = spełnianie oczekiwań użytkowników i satysfakcjonujące
• Przypadek użycia = Z góry Szczegółowe przechwytywanie wymagań
• Przypadek użycia = <<include>> + <<extends>> = dekompozycja funkcjonalna
• Przykładem użycia jest tylko styl „wprowadzane przez użytkownika” -> „odpowiedź systemu”
• Użyj przypadku = stary styl i przestarzały

Jako dostawca narzędzi jesteśmy dość neutralni w metodach, narzędziach i technikach. Osobiście chcę wyraźnie podkreślić, że jestem wielkim fanem rozwoju Agile, user story i procesu scrum. W szczególności podkreślono zasady i dobre praktyki związane z takimi pojęciami jak:

• Odkrywanie wymagań, a nie dostarczanie wymagań
• Zgodnie z powyższą zasadą daje to dwie ważne właściwości w procesie tworzenia Agile
  • Just-in-time
  • Wystarczająco

(Będę pisał więcej postów związanych z powyższymi zasadami z moimi własnymi opiniami, co jest ściśle związane z moim obszarem badań doktoranckich w latach 1992-1995 – metamodel i transformacje schematów)

Wróćmy teraz do tematów „przypadek użycia a historyjka użytkownika”. Cóż, waga ciężka Agile Sages już oddała głos na to, czy jestem tak uparty, próbując obalić ich „głosy, argumentując, że są podobne, a nawet takie same?

Pokażę Ci przykład ilustrujący, czy historyjka użytkownika „tak bardzo różni się” od przypadku użytkownika:

Przykład

Dobre historyjki użytkowników to znacznie więcej niż tylko stwierdzenia. Standardowa historyjka użytkownika składa się z trzech części, powszechnie nazywanych trzema literami C.

Pierwsze „C” każdej historyjki użytkownika powinno być zgodne ze standardowym formatem:

Jako [rola] chcę [coś zrobić], aby [korzyści]

czyli minimalna zawartość historyjki użytkownika, którą należy umieścić na karcie.

Rozmowy to zawartość drugiego „C” historyjki użytkownika, która reprezentuje dyskusję między użytkownikami końcowymi, właścicielem projektu i zespołem programistycznym. W tej konwersji rejestruje dyskusję ustną lub wiele innych przydatnych informacji, takich jak e-maile, makiety lub inne powiązane treści dotyczące projektu.

Ostatnie „C” historyjki to potwierdzenie, które jest kryterium akceptacji, które służy do potwierdzenia, że ​​historyjka została zaimplementowana, poprawiona i pomyślnie dostarczona.

Pozwólcie, że omówię nieco dalej, jak rozwinąć część potwierdzającą w historyjce użytkownika. Tutaj używamy najbardziej znanego szablonu o nazwie Korniszon, który przyjmuje formułę „Gdy-Wtedy”, aby kierować pisaniem testów akceptacyjnych dla User Story:

• (Biorąc pod uwagę… i) jakiś kontekst
• (Kiedy.. i) jakaś akcja jest wykonywana
• (Wtedy.. i) Wykonaj kilka czynności

Narzędzia takie jak frameworki testowe Cucumber i Jbehave zachęcają do korzystania z szablonu Given/When/Then do przeprowadzania testów automatycznych, chociaż może on być również używany wyłącznie jako heurystyka, niezależnie od tego, czy narzędzie ma być użyte.

Zbierzmy wszystkie informacje do historyjki użytkownika „kurs rejestracji” i umieśćmy je w formacie 3Cs:

Przyjąłem powszechnie używany format 3 Cs do reprezentowania historyjki użytkownika „kursu rejestru”. Podobnie przyjąłem również najpowszechniej używany format opisu dla tego samego przypadku użycia „kursu rejestru” opracowanego przez opis przypadku użycia. Ponumerowałem kroki sekcji potwierdzenia (ostatnie C) historyjki użytkownika, która jest powiązana z numerem kroku, który umieściłem w opisie przypadku użycia. Są to te same „dziewięć kroków” scenariusza, które należy umieścić w każdym z podejść w innej kolejności. Uważam, że obie reprezentacje modeli są do zaakceptowania dla odpowiadających im mędrców i wyznawców. Potem znowu pytanie, czy historyjka użytkownika jest bardzo podobna do przypadku użytkownika, a jednak są różne, czy też kolejność kroków powoduje wszelkiego rodzaju krytykę podejścia do przypadku użycia?

Semantycznie równoważne z innym znaczeniem?

Zbadajmy, czy istnieje podobny przypadek w domenie modelowania, aby porównać z sytuacją tutaj, czy może nam to pomóc w oddaniu własnego głosu na „historię użytkownika a przypadki użycia”, ale nie albo ślepo podążaj za tłumem, ani nie powtarzaj tego, co mędrcy mówili jak papuga.

Przykład: ekwiwalent semantyczny

W UML możemy opisać scenariusz przypadku użycia za pomocą diagramu sekwencji, ale zwykle nie używamy diagramu współpracy w tym samym celu; nawet przez oba diagramy są semantycznie równoważne. Innymi słowy, zarówno diagram sekwencji, jak i diagram współpracy mają taką samą liczbę obiektów uczestniczących w scenariuszu z taką samą liczbą komunikatów przesyłanych wokół tego samego zestawu obiektów w celu wykonania zadania scenariusza. Jednak pierwsza z nich to koncentracja na czasie, a druga to koncentracja na przestrzeni. Diagram sekwencji jest bardziej intuicyjny, gdy używa się go z modelowaniem scenariuszy, podczas gdy diagram współpracy jest odpowiedni do modelowania strukturalnych relacji między obiektami. tzn. chcesz strukturalnie przedstawić scenariusz uczestniczącego obiektu w ramach MVC (warstwy modelu/widoku i kontroli).

Osobiście nie uważam, że używanie historyjek użytkownika sprawi, że mój zespół stanie się zwinny, a przypadki użycia sprawią, że mój zespół będzie „z góry”. Najważniejsze jest to, w jaki sposób stosujemy i wykorzystujemy te narzędzia, z jakim nastawieniem i najlepszymi praktykami się za nimi kryją. Nie martwię się zbytnio, że ludzie uznają mnie za „starego stylu” lub przestarzałą, kiedy faktycznie zachowuję się zwinnie.

Wciąż pamiętam, że w dniach analizy strukturalnej i projektowania, być może możemy użyć abstrakcyjnego typu danych w ADA, aby zastosować analizę zorientowaną obiektowo i zasady projektowania bez wsparcia OOP w 198x, prawda? Niestety, możesz w ogóle nie natknąć się na pojęcie abstrakcyjnego typu danych! Oh! Mój Boże, przypadkowo ujawniam – jestem stara? A może powinienem myśleć pozytywnie – doświadczony?

Co myślisz? Jaki jest twój głos w tej sprawie? Daj mi znać lub popraw mnie, jeśli się mylę.