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 kolejności: kryteria akceptacji, które przekształcają uzgodniony zamysł w test typu „zaliczony/niezaliczony”, oraz oszacowanie, które pozwala przekształcić 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, a nie „użytkownik”. Jeśli nie potrafiliby Państwo zidentyfikować 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. Sformułowanie „Chcę zresetować hasło” odnosi się do użytkownika; sformułowanie „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 artykule 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 przyjąć 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]

W tej karcie zawarto dwa świadome wybory. „Poza zakresem” ma kluczowe znaczenie: większość sporów dotyczących szacowania wynika z tego, że dwie osoby oceniają różne zakresy, a jedno zdanie w tym miejscu 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 w planowaniu 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 decydujący wyjaśnia więcej niż sama osobowość (ta sama osoba w pociągu pragnie czegoś innego niż siedząc przy biurku)
Najpierw korzyści	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 kwestie techniczne, w których jedyną wiarygodną 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ć) przenosi się na tę pracę; forma zdania nie musi być jednak taka sama.

Kryteria akceptacji: potwierdzenie na karcie

Kryteria akceptacji to warunki zaliczenia lub odrzucenia opisu zadania, określone przed rozpoczęciem prac. Na karcie pełnią one dwie funkcje: odzwierciedlają rzeczywisty wynik rozmowy dotyczącej doprecyzowania opisu zadania oraz wyznaczają cel, do którego będzie dążyć oszacowanie nakładu pracy. Dwa formaty obejmują niemal każdy opis zadania:

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:

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

Proszę kierować się listą kontrolną; proszę stosować schemat „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ą Panu i Pani miejsca podziału. Pełne omówienie (kryteria a wymagania, kryteria a definicja zakończenia, kto je sporządza) znajdą Państwo w rozdziale poświęconym kryteriom akceptacji.

Przykład z obliczeniami: budynek parterowy, szablon do oszacowania

Oto przebieg prawdziwej historii przy użyciu powyższej karty.

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

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

Krok 2: rozmowa, ujęta w postaci kryteriów. W ramach dopracowywania rejestru zadań zespół wydobywa 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 zamówienia jako gość stosowane są te same mechanizmy weryfikacji oszustw, co w przypadku realizacji zamówienia przy użyciu 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 zakresu.

Krok 4: oszacowanie. Zespół głosuje w rundzie planning poker. Wylosowano karty o wartościach 3, 5, 5, 8. Liczba 8 wynika z następującego wyjaśnienia: kryterium sprawdzania 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 właściwa. Zespół ponownie głosuje i osiąga konsensus na poziomie 5.

Proszę zwrócić uwagę na kolejność: najpierw kryteria, potem punkty. Oszacowanie zadania przed ustaleniem jego kryteriów prowadzi do powstania szerokich, niemożliwych do rozstrzygnięcia przedziałów, które hamują przebieg sesji ustalania wielkości zadań. W rezultacie zespół głosuje nad różnymi zadaniami, 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.

W jaki sposób należy sformułować kryteria akceptacji dla opisu użytkownika?

Proszę sformułować od trzech do pięciu weryfikowalnych warunków, które jednoznacznie określają – poprzez wynik pozytywny lub negatywny – 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 być możliwe do sprawdzenia przez testera, który nie brał udziału w rozmowie dotyczącej doprecyzowania.

Czy w kryteriach akceptacji należy stosować schemat „Dane/Gdy/Wówczas”, 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 oraz rezultatu. Lista kontrolna jest szybsza w odczytaniu i trudniejsza do nadmiernego rozbudowywania, gdy opis sytuacji sprowadza się po prostu do stwierdzenia: „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, gdy przebywa przy biurku, a inne – w pociągu.

Czy każda pozycja w backlogu 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.

Warto przeczytać

• 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 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 terminu „gotowy”: etap, który szablonowy zadanie musi przejść, aby zostać włączone do sprintu.
• Czym są punkty fabularne?: jednostka, w której określa się wielkość gotowej karty.