Jak pisać historyjki użytkownika (z przykładami i kryteriami akceptacji)

Historyjka użytkownika to krótki opis funkcji z punktu widzenia użytkownika: „Jako [typ użytkownika] chcę [cel], aby [powód]”. Pod spodem zapisujesz kryteria akceptacji, czyli kilka konkretnych warunków, które muszą być spełnione, by historyjka została uznana za gotową. Każdą historyjkę trzymaj na tyle małą, by dało się ją zbudować i przetestować za jednym razem, a kryteria zapisuj tak, by każdy mógł je sprawdzić.

Historyjki użytkownika spopularyzowały zwinne zespoły programistyczne, ale są równie przydatne, gdy budujesz samodzielnie w narzędziu AI do tworzenia aplikacji. Dobra historyjka to dobry prompt.

Format

Historyjka użytkownika ma trzy części:

Jako [kto] chcę [co] aby [dlaczego].

• Kto to konkretny typ użytkownika: pierwszy raz odwiedzający, płacący członek, recepcjonistka w klinice, administrator. Nie „użytkownik”.
• Co to to, co chce zrobić, w jego własnych słowach. Nie to, jak działa ekran.
• Dlaczego to efekt, na którym mu zależy. To część, którą ludzie pomijają, a która powstrzymuje przed budowaniem niewłaściwej rzeczy.

Przykład:

Jako członek siłowni chcę anulować rezerwację zajęć z telefonu, aby ktoś z listy oczekujących mógł zająć moje miejsce, a ja nie zapłaciłem opłaty za nieobecność.

Część „dlaczego” mówi dwie rzeczy, których nie powiedziała część „co”: musi działać na telefonie, a w grę wchodzą lista oczekujących i zasady dotyczące opłat.

Kryteria akceptacji

Historyjka mówi, czego się chce. Kryteria akceptacji mówią, kiedy to jest gotowe. Powinny być na tyle konkretne, by dwie osoby zgodziły się, czy każde z nich zostało spełnione.

Częsty sposób zapisu to Dany / Gdy / Wtedy:

• Dany punkt wyjścia
• Gdy użytkownik coś robi
• Wtedy następuje ten wynik

Dla historyjki o rezerwacji na siłowni:

1. Dany mam rezerwację więcej niż 12 godzin przed czasem, gdy stukam Anuluj i potwierdzam, wtedy rezerwacja zostaje usunięta, a ja widzę „Rezerwacja anulowana”.
2. Dany anuluję rezerwację, a zajęcia mają listę oczekujących, gdy anulowanie się zapisze, wtedy pierwsza osoba z listy dostaje miejsce i e-mail.
3. Dany rezerwacja mniej niż 12 godzin przed czasem, gdy stukam Anuluj, wtedy przed potwierdzeniem widzę, że obowiązuje opłata za późne anulowanie.
4. Dany jestem na ekranie o szerokości telefonu, wtedy przycisk Anuluj jest widoczny bez przewijania w bok.

Zwykła lista kontrolna też się nadaje, o ile każdy punkt da się sprawdzić. „Anulowanie jest łatwe” nie da się sprawdzić. „Anulowanie zajmuje najwyżej dwa kliknięcia z listy rezerwacji” da się.

Krok po kroku: jak napisać dobrą historyjkę

Krok 1: Zacznij od prawdziwego użytkownika i prawdziwego problemu

Wybierz jeden typ użytkownika i coś, z czym dziś ma trudność. Jeśli przeprowadzałeś rozmowy z klientami, użyj ich słów. „Zawsze zapominam anulować i dostaję obciążenie” to lepszy punkt wyjścia niż „dodaj funkcję anulowania”.

Krok 2: Napisz jednolinijkową historyjkę

Wypełnij szablon. Jeśli nie potrafisz napisać przekonującego „aby”, zapytaj, czy funkcja w ogóle jest potrzebna.

Krok 3: Dodaj od trzech do sześciu kryteriów akceptacji

Pokryj najpierw główny przypadek sukcesu, a potem ważne odmiany: inną rolę, pusty stan, limit, błąd. Jeśli piszesz więcej niż sześć, historyjka jest prawdopodobnie za duża.

Krok 4: Zanotuj, co jest poza zakresem

Jedna linijka oszczędza dużo ping-ponga: „Poza zakresem: zwroty za płatne zajęcia; administratorzy anulujący za członków.” Powstrzymuje historyjkę przed rozrastaniem się w trakcie budowy.

Krok 5: Sprawdź ją według INVEST

INVEST to popularna lista kontrolna dobrych historyjek. Historyjka powinna być:

Nie musisz oceniać każdej historyjki. Najbardziej przydatne jest wtedy, gdy historyjka wydaje się zła i chcesz wiedzieć dlaczego.

Dobre i złe przykłady

Jak podzielić zbyt dużą historyjkę

Duże historyjki to miejsce, w którym projekty stają w miejscu. Typowe sposoby podziału:

• Według roli użytkownika. Członkowie anulują własne rezerwacje; personel anuluje dowolne.
• Według kroku przepływu. Przeglądaj zajęcia; zarezerwuj zajęcia; dostań przypomnienie.
• Najpierw prosty przypadek. Anuluj darmowe zajęcia teraz; opłaty i zwroty obsłuż w późniejszej historyjce.
• Według wariantu danych. Obsłuż najpierw jedną lokalizację, więcej później.
• Najpierw szczęśliwa ścieżka, potem błędy. Najpierw zbuduj działanie, potem dodaj obsługę pełnych zajęć, wygasłych karnetów i tak dalej.

Każdy kawałek nadal powinien być czymś, z czego użytkownik może skorzystać i co zauważy.

Używanie historyjek jako promptów

Historyjka użytkownika z kryteriami akceptacji jest bardzo bliska dobremu promptowi dla narzędzia AI do budowania aplikacji. Daje AI kto, co, dlaczego i definicję ukończenia. Wysyłaj jedną historyjkę w wiadomości:

Jako członek siłowni chcę anulować rezerwację zajęć z telefonu, aby ktoś z listy oczekujących mógł zająć moje miejsce. Kryteria akceptacji:

1. Anuluj jest przy każdej rezerwacji w Moich rezerwacjach, z krokiem potwierdzenia.
2. Anulowanie więcej niż 12 godzin przed zajęciami po prostu usuwa rezerwację.
3. Mniej niż 12 godzin przed, pokaż „Obowiązuje opłata za późne anulowanie w wysokości 5 USD” przed potwierdzeniem i zapisz opłatę przy rezerwacji.
4. Jeśli zajęcia mają listę oczekujących, pierwsza osoba dostaje miejsce i e-mail.
5. Działa na ekranie o szerokości telefonu. Poza zakresem: zwroty, anulowania przez personel za członków. Zbuduj to, potem sprawdź w podglądzie każde kryterium i napisz, które przechodzą.

Możesz też poprosić AI o wstępne historyjki na podstawie surowego pomysłu, a potem edytować je samodzielnie:

Oto mój pomysł na aplikację: [dwa lub trzy zdania]. Napisz historyjki użytkownika dla wersji pierwszej, pogrupowane według typu użytkownika, każda z 3 do 5 kryteriami Dany/Gdy/Wtedy. Zaznacz, które są niezbędne do startu, a które mogą poczekać.

Zawsze czytaj wynik i edytuj go. AI nie zna twoich użytkowników. Ty znasz.

Kryteria akceptacji pełnią też rolę planu testów. Gdy historyjka jest zbudowana, samodzielnie przejdź przez każde kryterium. Nasz przewodnik testowanie aplikacji przed startem rozwija to podejście.

Gdzie historyjki pasują do innych dokumentów

• Dokument wymagań produktu opisuje cały produkt: problem, użytkowników, zakres. Historyjki użytkownika to szczegółowe elementy w jego środku. Zobacz jak napisać PRD z AI.
• Zgłoszenie błędu opisuje coś zepsutego w stosunku do historyjki, która już została zbudowana. Zobacz jak napisać dobre zgłoszenie błędu.
• MVP to najmniejszy zestaw historyjek dostarczających podstawową wartość. Zobacz czym jest MVP.

Częste błędy

• „Jako użytkownik…” Zbyt ogólne. Nazwij konkretny typ użytkownika.
• Pominięcie „aby”. Bez powodu nie da się sensownie podejmować kompromisów.
• Pisanie rozwiązania zamiast potrzeby. „Chcę listę rozwijaną” zamyka projekt, zanim ktokolwiek pomyślał o nim.
• Kryteria, których nie da się przetestować. „Łatwe”, „szybkie” i „intuicyjne” to życzenia, a nie kryteria.
• Historyjki, które są w rzeczywistości epikami. „Zarządzaj moim kontem” to dziesięć historyjek.
• Pisanie wszystkich historyjek z góry. Pisz szczegółowo kilka następnych; resztę trzymaj jako jednolinijkowce, aż do nich dojdziesz.

Historyjki w Mythex

W Mythex tryb Plan to dobre miejsce, by zamienić pomysł w historyjki: agent omawia podejście, zanim cokolwiek edytuje. Gdy historyjka jest gotowa, przełącz się na Build i wklej ją, jedną historyjkę w wiadomości. Po każdej z nich /test może przeklikać podgląd i sprawdzić przepływ, a każdą odpowiedź możesz cofnąć przez Przywróć do tego punktu, jeśli poszła w złą stronę. Zobacz skuteczne prompty w dokumentacji oraz nasz przewodnik jak pisać prompty dla narzędzi do budowania aplikacji z AI.

Lista kontrolna historyjki użytkownika

• Nazywa konkretny typ użytkownika
• Opisuje potrzebę, a nie projekt
• Zawiera prawdziwe „aby” jako powód
• Ma od trzech do sześciu testowalnych kryteriów akceptacji
• Obejmuje co najmniej jeden przypadek brzegowy lub błąd
• Podaje, co jest poza zakresem
• Jest na tyle mała, by ją zbudować i przetestować za jednym razem
• Kryteria sprawdzone po zbudowaniu, jedno po drugim

Pytania