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ę przy użyciu adresu e-mail, aby móc przeglądać historię moich zamówień”. Nie jest to celowo specyfikacja. Karta stanowi zaproszenie do rozmowy, a szczegóły pojawiają się, gdy zespół dopracowuje historię, opracowuje jej kryteria akceptacji oraz określa jej zakres.

Wszystkie pozostałe elementy niniejszego przewodnika opierają się na opowieściach. To właśnie one stanowią podstawę do określania wielkości w planning pokerze, są punktem odniesienia dla story points oraz podlegają podziałowi, gdy szacunki nie są spójne. Zespół, który tworzy nieodpowiednie opowieści, będzie dokonywał błędnych szacunków niezależnie od tego, jak sprawnie poprowadzi sesję, ponieważ problem zaczyna się już na etapie danych wejściowych.

Schemat: rola, cel, korzyść

Klasyczny kształt wywodzi się z firmy 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ść. Najczęstszym błędem w tym formacie jest sformułowanie „jako użytkownik”: historia, która mogłaby dotyczyć kogokolwiek, jest historią, której nikt w rzeczywistości nie zweryfikował. 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 odrzucają jako pierwszy, i to właśnie ona decyduje o tym, że dana karta trafia do listy zadań do wykonania. Wyrażenie „tak, 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 stwierdzić przed rozpoczęciem sprintu, a nie dopiero po jego zakończeniu.

Kartka, rozmowa, potwierdzenie

Ron Jeffries ujął zasadę funkcjonowania 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 wymogu, co wymusza podjęcie kolejnego działania C.

Rozmowa stanowi faktyczną podstawę wymagań. Zespół i właściciel produktu omawiają szczegółowo daną historię w ramach dopracowywania backlogu: omawiają przypadki skrajne oraz elementy wyraźnie wyłączone z zakresu. 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 jest zgodne z ustaleniami wynikającymi z rozmowy. W rozdziale poświęconym szablonom historii użytkownika przedstawiono dwa sprawdzone formaty, a rozdział dotyczący kryteriów akceptacji zawiera szczegółowe informacje na temat ich opracowywania.

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 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?”.
• Oszacowalne: zespół jest w stanie określić to liczbowo. 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, pozostawiając jeszcze trochę 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. Twierdzenie „Strona wydaje się działać szybciej” nie spełnia tego kryterium; stwierdzenie „wyniki ładują się w mniej niż sekundę” 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 oznacza 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 użytkownika ma na celu 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ń zarezerwowaną 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 zdaniach nie występuje podmiot:

• Prace nad głęboką strukturą platformy. „Jako programista chcę zaktualizować framework, aby framework został zaktualizowany” – to stwierdzenie nie wnosi nic więcej niż 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 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 historii 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 przestrzeganiem przepisów. Nie można negocjować zakresu z organem regulacyjnym. Wymóg to wymóg; należy go zapisać jako taki.

Wszystkie te przykłady łączy dyscyplina, a nie forma sformułowania: jasno określony powód, dla którego praca ma znaczenie, oraz podlegająca weryfikacji definicja jej zakończenia. Jeśli zachowają 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 rozmiar w punktach historii za pomocą planowania pokerowego, sprawdza zgodność z definicją gotowości oraz dzieli ją na mniejsze części, jeśli wyniki głosowania nie są jednolite. 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ę zacząć od szablonu.

Najczęściej zadawane pytania

Czym jest historia użytkownika?

Opis użytkownika to krótki opis zmiany, sformułowany prostym językiem z perspektywy osoby, która odnosi z niej korzyść: „Jako stały klient pragnę zalogować się za pomocą adresu e-mail, aby móc przeglądać historię moich zamówień”. Celowo nie jest to specyfikacja. Karta ta służy jako punkt wyjścia do rozmowy, a szczegóły pojawiają się w momencie, gdy zespół doprecyzuje i oszacuje 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 zadania. 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?

Karta, rozmowa, potwierdzenie. Karta stanowi przypomnienie; jest celowo zbyt mała, by pomieścić całość wymagania. To właśnie podczas rozmowy – w trakcie dopracowywania wymagań wraz z zespołem – wymaganie nabiera rzeczywistego kształtu. Potwierdzenie to kryteria akceptacji, które określają, czy gotowy produkt spełnia to, co zostało omówione – czy został uznany za pozytywny, czy negatywny.

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ótkie projekty badawcze – wszystkie te elementy mają bardziej odpowiednie, naturalne formy. Proszę zachować klauzulę korzyści i kryteria akceptacji; proszę pominąć formułę „jako programista chcę”, gdy w zdaniu nie występuje 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 obliczeniami szacunkowymi.
• Epika a fabuła a zadanie: gdzie w hierarchii znajduje się fabuła oraz na który poziom się wskazuje.
• Podział opowieści użytkownika: co zrobić, gdy opowieść nie spełnia kryteriów „małego testu”.