Czym jest historia użytkownika?

Opis użytkownika to krótki, napisany prostym językiem opis zmiany, przedstawiony z perspektywy osoby, która odnosi z niej korzyść: „Jako stały klient chcę zalogować się za pomocą adresu e-mail, aby móc przejrzeć historię moich zamówień.” Nie jest to celowo specyfikacja. Karta stanowi zaproszenie do rozmowy, a szczegóły pojawiają się, gdy zespół dopracowuje historię, formułuje kryteria akceptacji i określa jej zakres.

Wszystkie pozostałe elementy niniejszego przewodnika opierają się na opowieściach. To właśnie one określają wielkość kart w planowaniu pokerowym, stanowią podstawę przypisywania punktów opowieści oraz są przedmiotem podziału, gdy szacunki nie są spójne. Zespół, który tworzy nieodpowiednie opowieści, będzie dokonywał błędnych szacunków bez względu na to, jak dobrze poprowadzi sesję, ponieważ to właśnie na etapie danych wejściowych pojawiają się pierwsze problemy.

Schemat: rola, cel, korzyść

Klasyczny kształt wywodzi się z Connextra, londyńskiego zespołu zajmującego się językiem XP, około 2001 roku:

Jako [stanowisko] pragnę osiągnąć [cel], aby uzyskać [korzyść].

Są trzy gniazda, a każde z nich pełni określoną funkcję.

• Rola określa, kto otrzymuje daną wartość. „Jako użytkownik” to najczęstszy błąd w tym formacie: historia, która mogłaby dotyczyć każdego, jest historią, z którą w rzeczywistości nikt się nie skonsultował. Proszę wskazać konkretną osobę: stałego klienta, programistę zajmującego się integracją.
• Cel to funkcjonalność z punktu widzenia użytkownika, opisująca to, co dana osoba robi, a nie to, jak zbudowany jest system. „Chcę zresetować swoje hasło” to cel. „Chcę mieć mikrousługę do resetowania hasła” to decyzja projektowa ujęta w tej formie.
• Korzyść to element, który zespoły odrzucają jako pierwszy, i to właśnie ona decyduje o tym, że dana karta trafia do listy zadań do realizacji. Wyrażenie „aby” stanowi uzasadnienie dla umieszczenia danej karty w harmonogramie. Jeśli nikt nie jest w stanie jej zrealizować, zadanie nie ma racji bytu, a zapisanie tej klauzuli pozwala to ustalić przed rozpoczęciem sprintu, a nie dopiero po jego zakończeniu.

Kartka, rozmowa, potwierdzenie

Ron Jeffries ujął zasadę działania opowieści w trzech elementach oznaczonych literą „C”, przy czym kolejność ma znaczenie.

Karta jest symbolem: składa się z jednego lub dwóch zdań, celowo zwięzłych. Jej rozmiar stanowi jej cechę charakterystyczną: fizycznie nie jest w stanie pomieścić pełnego wymagania, co wymusza podjęcie kolejnego działania C.

Rozmowa stanowi właściwą podstawę dla wymagań. Zespół i właściciel produktu omawiają szczegółowo daną historię podczas doprecyzowywania backlogu: omawiają przypadki skrajne oraz to, co wyraźnie wykracza poza zakres projektu. Zespoły, które pomijają ten etap i traktują kartę jako samo wymaganie, ponoszą podwójną stratę: otrzymują dokument zbyt ubogi, by można było na jego podstawie realizować zadania, oraz pozbawione są rozmowy, ponieważ „wszystko zostało już zapisane”.

Potwierdzenie stanowi kryteria akceptacji: warunki zaliczenia lub odrzucenia, które określają, czy ukończone zadanie spełnia ustalenia wynikające z rozmów. W rozdziale poświęconym szablonom opowieści użytkownika przedstawiono dwa sprawdzone formaty, a rozdział dotyczący kryteriów akceptacji szczegółowo omawia sposób ich formułowania.

Lista kontrolna INVEST

Lista kontrolna Billa Wake’a z 2003 roku nadal stanowi najszybszy sposób sprawdzenia, czy historia jest gotowa do realizacji. Dobra historia to:

• Niezależne: można je zaplanować samodzielnie, bez konieczności włączania do sprintu trzech innych zadań.
• Do uzgodnienia: ta karta zachęca do rozmowy; zakres może ulec zmianie. Opowieść, w której każdy szczegół jest ustalony, to wymóg przebrany za opowieść.
• Istotne: zdanie z „aby” wytrzymuje próbę jednego szczerego pytania „dlaczego?”.
• Możliwe do oszacowania: zespół jest w stanie określić wartość liczbową. Zadanie, którego wielkości nikt nie potrafi oszacować, wiąże się z niewiadomą; należy przeprowadzić analizę wstępną, aby ją ustalić.
• Mały: mieści się w sprincie z zapasem miejsca. Jeśli tak nie jest, proszę go podzielić.
• Możliwość przetestowania: można sformułować kryteria akceptacji, które zostaną uznane za spełnione lub niespełnione. Stwierdzenie „Strona wydaje się działać szybciej” nie spełnia tego kryterium; stwierdzenie „wyniki ładują się w czasie krótszym niż sekunda” spełnia je.

W sekcjach „Szacunkowe” i „Małe” historie łączą się z pozostałą częścią niniejszego przewodnika. Duża rozbieżność głosów w planowaniu pokerowym zazwyczaj wskazuje na późno ujawnioną porażkę etapu INVEST: historia podlegała negocjacjom w sposób, którego nikt nie przewidział, lub była zbyt obszerna, by ktokolwiek mógł ogarnąć ją w całości.

Czym nie jest historia użytkownika

To nie jest zadanie. Historia przedstawia coś, co użytkownik może zobaczyć; zadanie to krok, jaki podejmuje zespół, aby to osiągnąć. „Zaloguj się za pomocą adresu e-mail” to historia. „Skonfiguruj magazyn sesji” to jedno z jej zadań. Rozdział poświęcony różnicom między epiką, historią i zadaniem omawia tę hierarchię oraz wyjaśnia, dlaczego punkty przypisuje się wyłącznie na poziomie historii.

Nie jest to dokument zawierający wymagania. Wymagania powinny być dopracowane przed rozpoczęciem prac. Celem opisu użytkownika jest zapewnienie podstaw do rozpoczęcia dyskusji i nic więcej. Ocenianie opisów użytkownika według standardów dotyczących wymagań („to zbyt niejasne!”) pomija istotę projektu: ta niejasność stanowi przestrzeń przeznaczoną na osąd zespołu.

Nie jest to obietnica realizacji. Opis zadania określa wynik; sposób realizacji leży w gestii zespołu. Gdy opis zadania zawiera z góry ustalone rozwiązanie, część kryteriów INVEST podlegająca negocjacji zostaje już wykluczona.

Kiedy opisy użytkownika nie są odpowiednim narzędziem

Ten format ma swoje ograniczenia, a udawanie, że jest inaczej, podważa wiarygodność w oczach osób, które muszą tworzyć te skomplikowane konstrukcje. W niektórych przypadkach w zdaniu nie występuje podmiot:

• Prace nad głębszymi aspektami platformy. „Jako programista chcę zaktualizować framework, aby framework został zaktualizowany” – to stwierdzenie nie wnosi nic więcej niż to, co zawiera tytuł zgłoszenia. Proszę opisać to jako zwykłą pracę techniczną, wskazując konkretny rezultat: co przestanie działać lub ulegnie spowolnieniu, jeśli nie zostanie to zrealizowane, oraz co stanie się łatwiejsze, gdy zostanie to zrealizowane.
• Błędy o znanej przyczynie. Zgłoszenie usterki (oczekiwane zachowanie, rzeczywiste zachowanie, kroki pozwalające odtworzyć błąd) stanowi lepszą formę niż dostosowana retrospektywnie historia użytkownika. W rozdziale poświęconym punktom historii użytkownika omówiono, kiedy przypisuje się punkty błędom.
• Zadania badawcze typu „spike”. Zadanie typu „spike” to pytanie połączone z określonym przedziałem czasowym, a jego wynikiem jest wiedza. Próba wtłoczenia go w schemat „rola–cel–korzyść” przesłania to, co ma największe znaczenie: to, czego zespół musi się nauczyć.
• Kwestie związane z zapewnieniem zgodności. Nie można negocjować zakresu z organem regulacyjnym. Wymóg to wymóg; należy go zapisać jako jeden.

Wszystkie te przykłady łączy dyscyplina, a nie forma zdania: jasno określony powód, dla którego praca ma znaczenie, oraz weryfikowalna definicja jej zakończenia. Jeśli zachują Państwo te elementy, format spełni swoją rolę nawet tam, gdzie nie ma bezpośredniego zastosowania.

Gdzie opowieści spotykają się z szacowaniem

Jednostką szacowania jest historia. Po jej sporządzeniu przebiega ona zgodnie z poniższą procedurą: zespół omawia ją, szacuje jej wielkość w punktach historii za pomocą planowania pokerowego, weryfikuje ją pod kątem definicji gotowości oraz dzieli na mniejsze części, jeśli wyniki głosowania nie są jednomyślne. Dobrze sformułowana historia przyspiesza każdy z tych etapów, co stanowi praktyczny powód, dla którego warto w ogóle zwracać uwagę na jej format.

Aby zapoznać się z zastosowanym formatem, w rozdziale poświęconym przykładom opowieści użytkownika omówiono szesnaście opowieści wraz z komentarzami – zarówno tych dobrych, jak i złych. Aby stworzyć własną opowieść, proszę zacząć od szablonu.

Najczęściej zadawane pytania

Czym jest historia użytkownika?

Opis użytkownika to krótki, napisany prostym językiem opis zmiany, przedstawiony z perspektywy osoby, która odnosi z niej korzyść: „Jako stały klient chcę zalogować się za pomocą adresu e-mail, aby móc przejrzeć historię moich zamówień”. Celowo nie jest to specyfikacja. Karta ta stanowi punkt wyjścia do rozmowy, a szczegóły pojawiają się w momencie, gdy zespół dopracowuje i szacuje zakres prac.

Na czym polega format opisu użytkownika?

Klasyczny format to: rola – cel – korzyść: „Jako [rola], chcę [cel], aby [korzyść]”. Rola określa, kto czerpie korzyść, cel określa możliwość z punktu widzenia użytkownika, a korzyść stanowi argument przemawiający za samym zaplanowaniem pracy. Jeśli nikt nie jest w stanie uzupełnić części „aby”, historia nie ma uzasadnienia, by znaleźć się w rejestrze zadań.

Jakie są trzy elementy opisu użytkownika (user story) oznaczone literą „C”?

Karta, rozmowa, potwierdzenie. Karta stanowi przypomnienie; jest celowo zbyt mała, by pomieścić całe wymaganie. To właśnie podczas rozmowy wymaganie nabiera rzeczywistego kształtu w trakcie dopracowywania go wspólnie z zespołem. Potwierdzenie to kryteria akceptacji, które określają, czy praca końcowa spełnia to, co zostało omówione – czy została zaliczona, czy odrzucona.

Co oznacza skrót INVEST?

Niezależne, podlegające negocjacji, wartościowe, możliwe do oszacowania, niewielkie, możliwe do przetestowania. Jest to lista kontrolna Billa Wake’a służąca do oceny, czy zadanie jest gotowe do realizacji. W praktyce największe znaczenie mają trzy ostatnie kryteria: zadanie, którego zespół nie jest w stanie oszacować, które nie zmieści się w sprincie lub którego poprawności nie można potwierdzić za pomocą testów, jest zadaniem, które nie jest jeszcze gotowe.

W jakich sytuacjach nie należy stosować opowieści użytkownika?

Gdy format wprowadza zbędną formalność zamiast jasności. Dogłębne prace nad platformą, poprawki błędów o znanej przyczynie, wymagania dotyczące zgodności oraz krótkoterminowe projekty badawcze – wszystkie te elementy mają swoje bardziej odpowiednie formy. Proszę zachować klauzulę korzyści oraz kryteria akceptacji; proszę pominąć formułę „jako programista chcę”, gdy w zdaniu nie występuje użytkownik.

Materiały powiązane

• Szacowanie w metodologii agile: kompletny przewodnik. Tutaj znajdą Państwo wszystkie niezbędne informacje.
• Przykłady historii użytkownika: szesnaście opatrzonych komentarzami historii, w tym te, które zakończyły się niepowodzeniem, wraz z uzasadnieniem.
• Szablon opisu użytkownika i kryteria akceptacji: szablon, jego warianty oraz przykład z obliczeniem szacunku nakładu.
• Epopeja, fabuła a zadanie: gdzie w hierarchii plasuje się fabuła i na który poziom się wskazuje.
• Podział opowieści użytkownika: co zrobić, gdy opowieść nie spełnia kryteriów „małego testu”.