Historia użytkownika jest zgodna z przypadkiem użycia?

Przeszukując internet, Sędziowie Agile uznają przypadki użycia i historie użytkownika za dwa różne rzeczy:

Metoda oparta na przypadkach użycia była jedną z najpopularniejszych technik zbierania wymagań, a niektórzy ludzie uważają ją za przestarzałą, staroświecką technikę, która wiąże się z wieloma problemami, które sprawiają, że zespół nie jest „agilny” z powodu wad przypadków użycia:

  • Wymagania na wstępie – próba określenia szczegółów wszystkich aspektów na wstępie prowadzi do wielu straconych wysiłków i czasu, ponieważ duża część pracy będzie musiała zostać ponowiona.
  • Rozkład funkcyjny: funkcjonalna natura przypadków użycia naturalnie prowadzi do rozkładu funkcyjnego systemu pod kątem konkretnych i abstrakcyjnych przypadków użycia, które są powiązane za pomocą relacji rozszerzania i dołączania przypadków użycia.

Jeśli poszukasz w internecie słów kluczowych „przypadek użycia vs historia użytkownika”, znajdziesz długą listę artykułów sugerujących wady, problemy lub pułapki metody przypadków użycia, podczas gdy lista korzyści związanych z historią użytkownika jest jeszcze dłuższa. Ciekawe, jak szybko zmienia się branża IT, a jeszcze szybciej zmieniają się ludzie, którzy przechodzą od dawniej „modnych” rzeczy do obecnie „nowoczesnych” trendów.

Ciekawym faktem jest to, że niektórzy ludzie lubią postrzegać rzeczy w sposób dwustanowy i gonić za nowymi trendami, łącząc się z nimi symbolicznie zamiast naprawdę je stosować. Niektórzy ludzie nawet nie chcą, by inni wiedzieli, że nadal używają przypadków użycia, bo mogą zostać uznani za przestarzałych i staroświeckich.

Teraz niektórzy ludzie ustawiają znak równości między historią użytkownika a przypadkiem użycia:

  • Agile = historia użytkownika lub Agile = historia użytkownika + Scrum
  • Historia użytkownika = wystarczająco i w odpowiednim czasie
  • Historia użytkownika = spełnianie oczekiwań użytkownika i satysfakcja
  • Przypadek użycia = zbieranie szczegółowych wymagań na wstępie
  • Przypadek użycia = <<dołącz>> + <<rozszerz>> = rozkład funkcyjny
  • Przypadek użycia to tylko styl „wejście użytkownika” → „odpowiedź systemu”
  • Przypadek użycia = staroświeckie i przestarzałe

Jako dostawca narzędzi jesteśmy dość neutralni w kwestii metod, narzędzi i technik. Osobiście chcę podkreślić, że jestem wielkim fanem rozwoju agilnego, historii użytkownika i procesu Scrum. W szczególności podstawowe zasady i najlepsze praktyki związane z koncepcjami takimi jak:

  • Odkrywanie wymagań zamiast dostarczania wymagań
  • Zgodnie z powyższą zasadą powstają dwa ważne aspekty w procesie rozwoju agilnego
    • W odpowiednim czasie
    • Wystarczająco

(Napiszę więcej postów dotyczących powyższych zasad z moimi własnymi poglądami, które są blisko związane z moim obszarem badań doktorskich w latach 1992–1995 – metamodel i przekształcenia schematów)

Teraz wróćmy do tematów „przypadek użycia vs historia użytkownika”. Sędziowie Agile już oddali głos na to, a czy ja jestem tak uparty, że próbuję zmienić ich „głosy”, argumentując, że są podobne lub nawet takie same?

Pokażę Ci przykład, aby ilustrować, czy historia użytkownika jest „tak różna” od przypadku użycia:

Przykład

Dobre historie użytkownika to znacznie więcej niż tylko stwierdzenia. Standardowa historia użytkownika składa się z trzech części, powszechnie nazywanych trzema C.

Pierwsze „C” każdej historii użytkownika powinno podlegać znormalizowanemu formatowi:

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

co stanowi minimalną zawartość historii użytkownika do umieszczenia na karcie.

Rozmowy to zawartość drugiego „C” historii użytkownika, która reprezentuje dyskusję między użytkownikami końcowymi, właścicielem projektu i zespołem rozwojowym. W tych rozmowach zapisywane są rozmowy ustne lub inne przydatne informacje, takie jak e-maile, szkice, lub inne treści związane z projektem.

Ostatnie „C” historii użytkownika to potwierdzenie, które stanowi kryteria akceptacji używane do potwierdzenia, że historia użytkownika została poprawnie zaimplementowana i pomyślnie dostarczona.

Pozwól mi nieco rozwinąć, jak opracować część potwierdzenia historii użytkownika. Tutaj używamy najbardziej znanej szablonu zwanego Gherkin, który wykorzystuje wzór Given-When-Then, aby kierować pisaniem testów akceptacyjnych dla historii użytkownika:

  • (Dane są… i) pewne kontekst
  • (Kiedy… i) wykonywana jest pewna akcja
  • (Wtedy… i) wykonywane są pewne akcje

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

Zbierzmy wszystkie informacje dotyczące historii użytkownika „zarejestruj kurs” i umieśćmy je w formacie 3C:

confirmation

Użyłem powszechnie stosowanego formatu 3C do przedstawienia historii użytkownika „zarejestruj kurs”. Podobnie, przyjąłem również najbardziej powszechnie używany format opisania tego samego przypadku użycia „zarejestruj kurs”, który został szczegółowo opisany w opisie przypadku użycia. Ponumerowałem kroki sekcji potwierdzenia (ostatnie C) historii użytkownika, które są związane 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żdej z metod, ale w innej kolejności. Uważam, że oba sposoby reprezentacji modelu są akceptowalne dla ich odpowiednich wyznawców. A teraz pytanie: historia użytkownika jest bardzo podobna do przypadku użycia, a mimo to różni się od niego, czy to kolejność kroków powoduje całą gamę krytyki wobec podejścia przypadku użycia?

Semantycznie równoważne, ale z różnym znaczeniem?

Zbadajmy, czy istnieje podobny przypadek w dziedzinie modelowania, aby porównać go z sytuacją tutaj, albo może pomóc nam oddać własną opinię na temat „historii użytkownika wobec przypadków użycia”, a nie ślepo śledzić tłum lub powtarzać słowa mistrzów jak papuga.

use case description - user story

Przykład: semantycznie równoważne

W UML możemy opisać scenariusz przypadku użycia za pomocą diagramu sekwencji, ale zazwyczaj nie używamy diagramu współpracy do tego samego celu; mimo że oba diagramy są semantycznie równoważne. Innymi słowy, zarówno diagram sekwencji, jak i diagram współpracy mają tę samą liczbę obiektów uczestniczących w scenariuszu z tą samą liczbą wiadomości przekazywanych między tym samym zestawem obiektów w celu wykonania zadania scenariusza. Jednak pierwszy z nich skupia się na czasie, a drugi na przestrzeni. Diagram sekwencji jest bardziej intuicyjny przy modelowaniu scenariuszy, podczas gdy diagram współpracy jest odpowiedni do modelowania relacji strukturalnych między obiektami. Na przykład, jeśli chcesz przedstawić strukturalnie scenariusz uczestniczących obiektów w architekturze MVC (warstwy modelu, widoku i sterowania).

Osobiście nie myślę, że stosowanie historii użytkownika sprawi, że mój zespół stanie się agilny, a przypadki użycia sprawią, że nasz zespół będzie „przyspieszony”. Najważniejsze jest to, jak stosujemy i używamy tych narzędzi z jakim myśleniem i najlepszymi praktykami za sobą. Nie jestem zbyt zaniepokojony tym, że ludzie mogą uważać mnie za „stary styl” lub przestarzałego, skoro w rzeczywistości działam agilnie.

Wciąż pamiętam czasy analizy i projektowania strukturalnego, może mogliśmy użyć typu danych abstrakcyjnych w ADA, aby zastosować zasady analizy i projektowania obiektowego, nawet bez wsparcia OOP w latach 80., prawda? Niestety, możesz nawet nie napotkać pojęć typu danych abstrakcyjnych! O mój Boże, przypadkowo ujawniłem – jestem stary? Albo powinienem myśleć pozytywnie – doświadczony?

 

Leave a Reply