User Story i Use Case: czym się różnią i co pisać

Na groomingu zespół czyta historyjkę: «Jako kupujący chcę zapłacić za zamówienie kartą, żeby otrzymać towar». Wszyscy kiwają głowami, ocena — pięć punktów, historyjka trafia do sprintu. Dwa tygodnie później tester pyta, co zrobić, jeśli bank pobrał pieniądze, a sklep nie doczekał się odpowiedzi. Odpowiedzi nie ma ani w historyjce, ani w niczyjej głowie.

User story i use case odpowiadają na różne pytania. Historyjka mówi, komu i po co potrzebna jest dana możliwość, i pozostaje krótka: jedno zdanie plus kryteria akceptacji, które czynią ją weryfikowalną. Scenariusz opisuje, jak system zachowuje się krok po kroku, wraz ze wszystkimi gałęziami, w których coś idzie nie po planie. O wyborze między nimi decyduje nie metodologia zespołu, a liczba rozwidleń w zadaniu: im jest ich więcej i im droższy błąd w gałęzi, tym bardziej potrzebny jest scenariusz.

Tabel porównawczych na ten temat jest wiele. Tutaj podejście jest inne: to samo wymaganie dotyczące płatności za zamówienie zapisano na dwa sposoby i widać, co gubi każdy zapis.

Dwa zapisy — dwa różne pytania

Format historyjki «Jako , chcę <możliwość>, aby <korzyść>» wymyślił w 2001 roku zespół londyńskiej firmy Connextra. Powód był praktyczny: historyjki pisali sprzedawcy i marketingowcy, zapisywali potrzebną funkcję, a programiści musieli potem szukać autora, żeby zrozumieć, dla kogo jest dana funkcja i po co. Szablon wymusił zapisywanie «kto» i «po co» od razu.

Historyjka jest celowo niepełna. To pretekst do rozmowy, a nie specyfikacja. Weryfikowalną czynią ją kryteria akceptacji: warunki, co do których zespół i zamawiający uzgadniają, że historyjka jest gotowa. Bez nich historyjka pozostaje życzeniem.

Use case jest starszy. Ivar Jacobson przedstawił go na konferencji OOPSLA w 1987 roku, a upowszechnił się po książce z 1992 roku «Object-Oriented Software Engineering: A Use Case Driven Approach». Scenariusz opisuje aktora, jego cel i kroki interakcji z systemem. Alistair Cockburn w książce «Writing Effective Use Cases» podzielił go na główny scenariusz sukcesu i rozszerzenia — gałęzie, w których coś poszło inaczej, — i radził wyliczać te gałęzie wyczerpująco.

Oba zapisy mogą zawierać wymagania różnego poziomu — od celu biznesowego do zachowania ekranu; jak je rozróżniać, omówiono w artykule czym wymagania biznesowe różnią się od funkcjonalnych. I jeszcze jedna częsta pomyłka: diagram przypadków użycia w UML to nie to samo co tekstowy use case. Na diagramie widać aktorów i cele, ale nie kroki; jakie ma miejsce wśród innych notacji — w artykule BPMN i UML: czym się różnią.

Jak sformułować jedno wymaganie funkcjonalne, żeby każdy rozumiał je tak samo, omawia artykuł wymagania funkcjonalne: jak pisać, przykład i szablon.

Jedno zadanie: płatność za zamówienie kartą

Sklep internetowy, kupujący złożył zamówienie i płaci kartą przez zewnętrzną bramkę płatniczą. Zadanie wygląda na proste, ale rozwidleń jest w nim wiele. Karta może zostać odrzucona. Bank może zażądać potwierdzenia, a kupujący może go nie przejść. Bramka może nie odpowiedzieć wcale. A może odpowiedzieć już po tym, jak sklep przestał czekać — i wtedy pieniądze są pobrane, a zamówienie wisi nieopłacone.

Zapiszmy to zadanie dwa razy.

Zapis pierwszy: historyjka z kryteriami akceptacji

Historyjka. Jako kupujący chcę zapłacić za zamówienie kartą, żeby otrzymać towar i nie składać zamówienia od nowa, jeśli płatność nie przeszła za pierwszym razem.

Druga połowa zdania pojawiła się nie od razu. Dało ją pytanie «po co»: kupujący chce nie tylko zapłacić, ale nie stracić skompletowanego koszyka. To zmienia zachowanie systemu przy odmowie.

Kryteria akceptacji:

1. Zakładając: zamówienie złożone, karta ważna. Gdy kupujący potwierdza płatność, wtedy zamówienie otrzymuje status «Opłacone», a kupujący widzi numer zamówienia.
2. Zakładając: bank odrzucił kartę. Gdy kupujący wraca do zamówienia, wtedy koszyk i dane dostawy są zachowane i można powtórzyć płatność inną kartą.
3. Zakładając: bank zażądał potwierdzenia. Gdy kupujący go nie przeszedł, wtedy pieniądze nie są pobrane, zamówienie pozostaje nieopłacone i dostępne do ponownej płatności.

Historyjka jest krótka, łatwo ją ocenić i omówić z właścicielem produktu. Wartość — nie stracić zamówienia — widać w pierwszej linii.

Zapis drugi: scenariusz z przepływami alternatywnymi

Scenariusz: Zapłacić za zamówienie kartą. Aktor: kupujący. Cel: zamówienie opłacone.

Przepływ główny:

1. Kupujący wybiera płatność kartą.
2. System przekazuje kwotę i numer zamówienia do bramki płatniczej.
3. Kupujący wprowadza dane karty na stronie bramki.
4. Bramka potwierdza płatność.
5. System zmienia status zamówienia na «Opłacone» i pokazuje kupującemu numer zamówienia.

Przepływy alternatywne:

• 4a. Karta odrzucona. System pokazuje przyczynę odmowy, zamówienie pozostaje nieopłacone, kupujący może wybrać inną kartę.
• 4b. Potwierdzenie nie powiodło się. System nie zmienia statusu zamówienia i proponuje powtórzyć płatność.
• 4c. Bramka nie odpowiedziała w wyznaczonym czasie. System nie anuluje zamówienia, tylko oznacza je jako «Oczekuje na potwierdzenie płatności» i ponownie odpytuje bramkę o status płatności.
• 4d. Bramka potwierdziła płatność po upływie limitu czasu. System na podstawie powiadomienia z bramki przenosi zamówienie do statusu «Opłacone». Jeśli zamówienie do tego momentu zostało już anulowane — system uruchamia zwrot pieniędzy.
• 4e. Powiadomienie o płatności przyszło dwa razy. System przetwarza je jednokrotnie i nie tworzy drugiej płatności.

Co zgubił każdy zapis

Historyjka zgubiła gałęzie 4c, 4d i 4e. To dokładnie te, w których pieniądze i status zamówienia się rozchodzą: kupujący zapłacił, a sklep o tym nie wie. Nie widać ich w zdaniu «chcę zapłacić za zamówienie kartą» i nie przychodzą do głowy na groomingu. Wychodzą na jaw dopiero na testowaniu albo na produkcji — w postaci wiadomości od kupującego, któremu pobrano pieniądze dwa razy albo nie wydano zamówienia.

Kryteria akceptacji można dopisać i dobry zespół je dopisze. Ale format historyjki nie zmusza do szukania gałęzi. Zmusza do odpowiedzi «po co», a wyliczenie awarii zostawia piszącemu.

Scenariusz zgubił «po co». Są w nim kroki i odmowy, ale nie ma linii, z której wynikałoby, że koszyk trzeba zachować. Bez pytania o wartość w gałęzi 4a łatwo napisać «zamówienie zostaje anulowane» — formalnie poprawnie, a kupujący składa koszyk od nowa i odchodzi. Scenariusz odpowiada, jak system się zachowuje, ale nie sprawdza, czy użytkownikowi właśnie takie zachowanie jest potrzebne.

Historyjka chroni przed zbudowaniem nie tego. Scenariusz — przed zbudowaniem tego, ale z dziurą w gałęzi, w której przepadają pieniądze.

Co zapisać w swoim zadaniu

Zacznij od policzenia rozwidleń. Jedna ścieżka, dwie-trzy oczywiste kontrole — historyjka z kryteriami akceptacji zamyka zadanie w całości, scenariusz byłby biurokracją. Wiele gałęzi, z których każda prowadzi do innego stanu pieniędzy, danych albo zobowiązań wobec klienta — potrzebny jest scenariusz przynajmniej dla tej części.

Najczęściej sprawdzają się oba zapisy naraz. Historyjka wprowadza zadanie do backlogu i utrzymuje rozmowę o wartości z biznesem. Do ryzykownej części — płatności, zwroty, integracje z systemami zewnętrznymi — dokłada się scenariusz z przepływami alternatywnymi, a kryteria akceptacji odwołują się do jego gałęzi. Wtedy ocena i testowanie opierają się na jednej liście gałęzi, a nie na tym, co każdy wyobraził sobie sam.

Zespół pracuje w Scrumie — to nie zakaz scenariuszy. Zespół pisze specyfikację — to nie zakaz historyjek. Formę zapisu wybiera się pod zadanie, a nie pod proces.

Jak to brzmi na rozmowie rekrutacyjnej

W naszej bazie pytań z prawdziwych rozmów rekrutacyjnych ten temat pojawia się 26 razy, a 16 z tych pytań oznaczono jako junior. To więcej niż połowa: o różnicę między historyjką a scenariuszem pytają już na wejściu do zawodu.

Słaba odpowiedź to streszczenie definicji: «user story — krótka, z Agile, use case — długi i szczegółowy». Zgadza się, ale to powtórka podręcznika, a nie zrozumienie. Mocna odpowiedź pokazuje, że widzisz, co gubi każdy zapis. Historyjka trzyma wartość, ale pomija gałęzie. Scenariusz wylicza gałęzie, ale nie pyta «po co». Dalej — jak wybierasz: po liczbie rozwidleń i cenie błędu w nich. Jeśli masz przykład z praktyki, gdzie gałąź wyszła na jaw późno — to najlepszy argument.