Szablon opisu użytkownika i kryteria akceptacji

Szablon opisu użytkownika składa się z jednego zdania zawierającego trzy miejsca na uzupełnienie:

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

Proszę to skopiować i wykorzystać, ale należy pamiętać, do czego służy: szablon ten stanowi punkt wyjścia do rozmowy, a nie formularz do wypełnienia. Wypełnione zdanie stanowi punkt początkowy procesu dopracowywania. To, co sprawia, że opowieść staje się wykonalna, to elementy dodawane w dalszej części: kryteria akceptacji, które przekształcają uzgodniony zamiar w test typu „zaliczony/niezaliczony”, oraz oszacowanie, które zamienia go w zadanie możliwe do zaplanowania. W niniejszym rozdziale przedstawiono jedną opowieść, która przechodzi przez wszystkie trzy etapy.

Wypełnianie luk bez zmyślania odpowiedzi

Każdy gniazdo charakteryzuje się typową usterką, a każdą z tych usterek można sprawdzić:

• [rola]: konkretna osoba, nigdy „użytkownik”. Jeśli nie potrafiliby Państwo wskazać tej osoby na podstawie danych analitycznych lub zgłoszeń do działu wsparcia, rola ta jest jedynie elementem dekoracyjnym. Test: czy projektant mógłby podjąć inną decyzję ze względu na wybraną przez Państwa rolę?
• [cel]: to, co dana osoba robi, wyrażone jej własnymi słowami. „Chcę zresetować hasło” odnosi się do użytkownika; „Potrzebuję mikrousługi do resetowania hasła” odnosi się do schematu architektury. Test: czy dana osoba rzeczywiście wypowiedziałaby to zdanie?
• [korzyść]: argument przemawiający za zaplanowaniem zadania. Test: proszę usunąć tę klauzulę. Jeśli nic nie zostanie utracone, oznacza to, że korzyść nie została jeszcze zidentyfikowana.

Pełne uzasadnienie tego formatu (w tym trzy zasady „C” oraz lista kontrolna INVEST, którą powinna spełniać gotowa historia użytkownika) znajduje się w artykule „Czym jest historia użytkownika?”. Szesnaście praktycznych przykładów, zarówno dobrych, jak i złych, można znaleźć w sekcji „Przykłady historii użytkownika”.

Karta zadania typu „kopiuj-wklej”

Samo zdanie nie wystarczy, aby przystąpić do sprintu. Oto pełny szablon karty, który warto wprowadzić jako standard, zawierający opis, kryteria, granice oraz rozmiar dodany na końcu:

Story
  As a [role], I want [goal], so that [benefit].

Acceptance criteria (3–5, each pass/fail)
  - [ ] …
  - [ ] …
  - [ ] …

Out of scope
  - What this story deliberately does NOT cover.

Notes & dependencies
  - Designs, decisions, other teams, open questions.

Size: [added by the team, after the conversation — never before]

Na tej karcie zawarto dwa świadome wybory. Sformułowanie „poza zakresem” ma kluczowe znaczenie: większość sporów dotyczących szacowania wynika z tego, że dwie osoby oceniają różne zakresy, a ten jeden wiersz pozwala im tego uniknąć. Wielkość podaje się na końcu: liczba zapisana na karcie, zanim zespół ją omówi, staje się punktem odniesienia, co stanowi pierwszy z klasycznych błędów związanych z planowaniem pokerowym.

Warianty szablonów

Klasyczny szablon jest właściwym ustawieniem domyślnym, ale nie jest to jedyny kształt, który się sprawdza.

Wariant	Kształt	Proszę sięgnąć po to, gdy
Classic (Connextra)	Jako [stanowisko] pragnę [cel], aby [korzyść]	Domyślne ustawienia dotyczące zadań wykonywanych przez użytkowników
Opis stanowiska	Kiedy [sytuacja], pragnę [motywacja], aby móc [rezultat]	To właśnie moment wyzwalający ma większe znaczenie niż sama osobowość (ta sama osoba w pociągu pragnie czegoś innego niż ta sama osoba przy biurku)
Korzyści przede wszystkim	Aby [osiągnąć korzyść], jako [stanowisko], pragnę [cel]	Zespół wciąż formułuje korzyści w sposób cykliczny; umieszczenie tej klauzuli na początku uniemożliwia jej pominięcie
Proste sformułowanie problemu	Jedno zdanie opisujące problem, jedno opisujące wynik oraz kryteria określające, „kiedy zadanie zostanie wykonane”	Prace związane z platformą i kwestiami technicznymi, w których jedyną rzetelną osobą byłby sam zespół

Ostatni wiersz ma większe znaczenie, niż mogłoby się wydawać. Niektóre pozycje z listy zadań nie zawierają w zdaniu odniesienia do użytkownika, a udawanie, że jest inaczej, prowadzi do tworzenia wypełniaczy w stylu: „jako programista chcę, aby framework został zaktualizowany”. Dyscyplina wynikająca z szablonu (określony powód oraz kryteria, które można zweryfikować) ma zastosowanie również w tej pracy; nie ma natomiast potrzeby stosowania sztywnej struktury zdania.

Kryteria akceptacji: potwierdzenie na karcie

Kryteria akceptacji to warunki zaliczenia lub odrzucenia opowieści, określone przed rozpoczęciem prac. Na karcie pełnią one dwie funkcje: odzwierciedlają rzeczywiste ustalenia wynikające z rozmowy dotyczącej doprecyzowania oraz wyznaczają cel, do którego będzie dążyć oszacowanie. Dwa formaty obejmują niemal każdą opowieść:

Prosta lista kontrolna dotycząca warunków niezależnych:

• Zawartość koszyka jest zachowywana przez 30 dni, niezależnie od sesji.
• Stały klient widzi swój koszyk na każdym urządzeniu, na którym jest zalogowany.
• Opróżniony koszyk pozostaje pusty (usunięte produkty nie są przywracane).

Given/When/Then – w przypadku zachowań zależnych od stanu:

• Jeśli klient ma zapisany koszyk, gdy produkt stanie się niedostępny, wtedy w koszyku produkt ten zostanie wyświetlony jako wyszarzony z etykietą „brak na stanie”, zamiast być po cichu usuwany.

Proszę kierować się listą kontrolną; proszę skorzystać z schematu „Given/When/Then”, gdy warunek wstępny wiąże się z rzeczywistą pracą. Lista powinna zawierać od trzech do pięciu pozycji. Dłuższa lista zazwyczaj oznacza, że opowieść należy podzielić, a kryteria wskazują Państwu miejsca podziału. Pełne omówienie tego zagadnienia (kryteria a wymagania, kryteria a definicja zakończenia, kto je sporządza) znajduje się w rozdziale poświęconym kryteriom akceptacji.

Przykład z obliczeniami: budynek jednopiętrowy, szablon do oszacowania

Oto przebieg prawdziwej historii, przedstawiony na podstawie powyższej karty.

Krok 1: opis. Właściciel produktu pisze:

Jako osoba dokonująca zakupu po raz pierwszy chciałbym zrealizować zamówienie bez zakładania konta, aby móc sfinalizować zakup, zanim zmienię zdanie.

Krok 2: rozmowa, ujęta w postaci kryteriów. Podczas doprecyzowywania rejestru zadań zespół ujawnia niuanse, których nie oddaje samo zdanie, i zapisuje je:

• Klient może sfinalizować transakcję, podając jedynie adres e-mail i dane dotyczące dostawy, bez konieczności podawania hasła.
• W wiadomości e-mail z potwierdzeniem zamówienia oferowana jest możliwość utworzenia konta jednym kliknięciem (zamówienie jest już dołączone).
• Dział obsługi klienta może zidentyfikować zamówienie złożone przez gościa na podstawie numeru zamówienia oraz adresu e-mail.
• W przypadku realizacji transakcji jako gość stosowane są te same mechanizmy weryfikacji w celu zapobiegania oszustwom, co w przypadku realizacji transakcji za pośrednictwem konta.

Poza zakresem: konwersja historycznych zamówień gości w przypadku późniejszego utworzenia konta.

Krok 3: sprawdzenie gotowości. Cztery kryteria, jedno wykluczenie nazwane, brak niepotwierdzonych zależności: zadanie spełnia definicję gotowości i trafia do zespołu w celu oszacowania nakładu pracy.

Krok 4: oszacowanie. Zespół głosuje w rundzie „planning poker”. Wylosowano karty o wartościach 3, 5, 5, 8. Wynik 8 wynika z następującego wyjaśnienia: kryterium weryfikacji oszustw wiąże się z koniecznością ingerencji w integrację z dostawcą usług płatniczych, czego nikt inny nie uwzględnił w wycenie. Właśnie w ten sposób kryteria spełniają swoją rzeczywistą rolę: dyskusja dotyczy zakresu prac, a nie tego, czyja liczba jest prawidłowa. Zespół ponownie głosuje i osiąga konsensus w sprawie wartości 5.

Proszę zwrócić uwagę na kolejność: najpierw kryteria, potem punkty. Zgłoszenie oszacowane przed ustaleniem kryteriów powoduje powstanie szerokich, niemożliwych do rozstrzygnięcia przedziałów, które hamują przebieg sesji ustalania wielkości. W rezultacie zespół głosuje nad różnymi zgłoszeniami, które przypadkowo mają ten sam tytuł.

Najczęściej zadawane pytania

Czym jest szablon opisu użytkownika?

„Jako [rola] pragnę [cel], aby [korzyść]”. Rola określa, kto czerpie korzyść, cel określa zdolność z punktu widzenia tej osoby, a korzyść stanowi powód, dla którego dane zadanie zasługuje na umieszczenie w rejestrze zadań. Szablon ten stanowi punkt wyjścia do rozmowy, a nie formularz do wypełnienia. Wypełnianie pustych pól stanowi początek procesu dopracowywania.

Jak sformułować kryteria akceptacji dla opisu użytkownika?

Proszę sformułować od trzech do pięciu weryfikowalnych warunków, które jednoznacznie określają – „zdał” lub „nie zdał” – czy opowieść spełniła ustalone wymagania. Proszę zastosować prostą listę kontrolną, gdy warunki są niezależne, oraz schemat „Given/When/Then”, gdy zachowanie zależy od stanu. Każde kryterium powinno dać się sprawdzić przez testera, który nie brał udziału w rozmowie dotyczącej dopracowania opowieści.

Czy w kryteriach akceptacji należy stosować schemat „Given/When/Then”, czy też listę kontrolną?

Dopasuj format do zachowania. Schemat „Given/When/Then” sprawdza się wtedy, gdy wynik zależy od stanu początkowego, ponieważ zmusza do określenia warunku wstępnego, czynnika wyzwalającego i wyniku. Lista kontrolna jest szybsza w czytaniu i trudniejsza do nadmiernego rozbudowywania, gdy opis polega po prostu na stwierdzeniu: „te cztery rzeczy muszą być spełnione”. W przypadku większości opisów wystarczy właśnie lista kontrolna.

Czym jest opis zadania?

Wariant, w którym personę zastępuje się sytuacją: „Kiedy [sytuacja], chcę [motywacja], aby móc [rezultat]”. Opisy zadań wywodzą się ze szkoły „jobs-to-be-done” i sprawdzają się dobrze, gdy moment wyzwalający lepiej wyjaśnia wymaganie niż persona. Ta sama osoba ma różne potrzeby przy biurku i w pociągu.

Czy każda pozycja w rejestrze zadań wymaga szablonu opisu użytkownika?

Nie. Szablon opisuje wartość odczuwalną przez użytkownika, a narzucanie go w odniesieniu do pracy na platformach, znanych błędów lub projektów badawczych prowadzi do powstania zdań, które wprowadzają zbędną formalność, nie wnosząc przy tym żadnych informacji. Należy zachować dwa elementy, które zawsze mają zastosowanie (określony powód oraz weryfikowalne kryteria akceptacji), a formę zdania dostosować do charakteru danego zadania.

Materiały powiązane

• Szacowanie w metodologii agile: kompletny przewodnik: tutaj znajdą Państwo wszystkie niezbędne informacje.
• Czym jest historia użytkownika?: uzasadnienie szablonu, trzy zasady „C” oraz kryteria INVEST.
• Przykłady historii użytkownika: szesnaście opatrzonych komentarzami historii, które posłużą jako punkt odniesienia.
• Kryteria akceptacji: jak je sformułować: pełny rozdział poświęcony etapowi weryfikacji.
• Definicja stanu „gotowy”: etap, który historia oparta na szablonie musi przejść, aby zostać włączona do sprintu.
• Czym są punkty fabularne?: jednostka, w której określa się wielkość gotowej karty.