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ści: „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 jej kryteria akceptacji oraz określa jej zakres.

Wszystkie pozostałe elementy niniejszego przewodnika opierają się na opisach zadań. To właśnie one stanowią podstawę do określania wielkości w planning pokerze, są punktem odniesienia dla punktów opisu zadania oraz podlegają podziałowi, gdy szacowanie nie prowadzi do zbieżności wyników. Zespół, który tworzy nieodpowiednie opisy zadań, będzie dokonywał błędnych szacunków bez względu na to, jak dobrze poprowadzi sesję, ponieważ to właśnie na etapie wprowadzania danych 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 [rola] 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ć kogokolwiek, 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 tę formę.
• Korzyść to element, który zespoły pomijają w pierwszej kolejności, a 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 określenia wymagań. Zespół i właściciel produktu omawiają szczegółowo daną historię podczas dopracowywania 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 zawiera szczegółowe omówienie sposobu ich formułowania.

Lista kontrolna INVEST

Lista kontrolna Billa Wake’a z 2003 roku nadal stanowi najszybszy sposób sprawdzenia, czy dana 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 się jeszcze zmienić. 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?”.
• Oszacowalne — zespół jest w stanie określić wartość liczbową. Zadanie, którego wielkości nikt nie potrafi oszacować, wiąże się z niewiadomą; proszę przeprowadzić spike, aby ją ustalić.
• Mały — mieści się w sprincie z zapasem miejsca. Jeśli tak nie jest, podziel go.
• Możliwość przetestowania — można sformułować kryteria akceptacji, które mogą zostać uznane za spełnione lub niespełnione. Kryterium „Strona wydaje się działać szybciej” nie zostanie spełnione; kryterium „wyniki ładują się w czasie krótszym niż sekunda” zostanie spełnione.

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. „Skonfigurowanie magazynu sesji” jest jednym z jej zadań. W rozdziale „Epika a historia a zadanie” omówiono hierarchię oraz wyjaśniono, dlaczego punkty przypisuje się wyłącznie na poziomie historii.

Nie jest to dokument zawierający wymagania. Wymagania powinny być dopracowane przed rozpoczęciem prac. Opis zadania ma być wystarczający do rozpoczęcia dyskusji i nic więcej. Ocenianie opisów zadań według standardów dotyczących wymagań („to zbyt niejasne!”) mija się z celem projektu: ta niejasność stanowi miejsce zarezerwowane dla osądu 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, element podlegający negocjacji w ramach kryteriów INVEST już nie istnieje.

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ą, podają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. W rozdziale poświęconym punktom fabularnym omówiono, kiedy błędom przypisuje się punkty.
• 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 taki.

Wspólnym mianownikiem wszystkich tych przypadków jest 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ą planning pokera, sprawdza zgodność z definicją gotowości oraz dzieli ją 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 w ogóle warto zwracać uwagę na jej format.

Aby zapoznać się z zastosowaniem tego formatu, w rozdziale poświęconym przykładom historii użytkownika omówiono szesnaście opatrzonych komentarzami historii – zarówno dobrych, jak i złych. Aby stworzyć własną historię, proszę skorzystać z 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 dyskusji, a szczegóły pojawiają się w momencie, gdy zespół doprecyzowuje 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 historii użytkownika?

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 wykonania nie da się potwierdzić żadnym testem, 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ą bardziej odpowiednie, naturalne formy. Proszę zachować klauzulę korzyści oraz kryteria akceptacji; proszę pominąć formułkę „jako programista chcę”, gdy w zdaniu nie występuje żaden użytkownik.

Warto przeczytać

• 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 szacunków.
• Epic vs historia vs zadanie — gdzie w hierarchii znajduje się historia oraz na który poziom się odwołuje.
• Podział opowieści użytkownika — co zrobić, gdy opowieść nie spełnia kryteriów „małego testu”.