jak pisać skuteczne user stories?
jest 5 przewodnich zasad, które polecam:
- każdy powinien być szczęśliwy
uzyskanie wszystkich na pokładzie jest ważne, więc niech wszyscy, którzy będą pisać i używać twoich historii użytkowników, wprowadzą swoje pomysły i zgodzą się na format, którego wszyscy będziecie używać. - bądź konsekwentny
gdy już masz uzgodnioną strukturę, upewnij się, że się jej trzymasz. - skup się na tym, co ważne
kiedy je piszesz, unikaj nieistotnych szczegółów., Poświęć trochę czasu, aby były zwięzłe, usuń wszelkie gofry, ponieważ po prostu staje na drodze. - brak szczegółów implementacji
zawsze skupiamy się na „Dlaczego”, a nie na „jak”. Dlaczego użytkownik czegoś chce, a nie jak to zbudujemy. Jeśli potrzebujesz podać szczegóły techniczne, należy je załączyć jako oddzielny plik specyfikacji. - jasne, wykonalne & testowalne
upewnij się, że każdy może zrozumieć każdą historię i że jest to osiągalne w czasie, z którego jesteś zadowolony. Jeśli dostarczasz w 2-tygodniowych sprintach, nie powinno to trwać dłużej niż te 2 tygodnie.,
Historia użytkownika anatomia
do historii użytkownika są 3 obowiązkowe części, tytuł, opis i kryteria akceptacji. Twój zespół może zgodzić się, że historia użytkownika musi mieć inne pola, zanim rozpocznie się praca nad nią. Na przykład możesz wymagać cesjonariusza, punktów historii lub wpływu na biznes, ale uważam, że są one opcjonalne, ponieważ nie każda organizacja będzie ich wymagać.
Tytuł
tytuły powinny być krótkie, unikalne i nie wprowadzać w błąd.,
kilka dobrych przykładów:
- „Dodaj panel kontakt do strony głównej”
- „Dodaj obsługę karty debetowej do koszyka”
- „zaktualizuj tagowanie szablonu wiadomości e — mail”
niektóre mniej dobre (niestety prawdziwe) przykłady:
- „dokonaj uzgodnionych zmian”
- „32072 – zaktualizowane mapowanie — Upsell user story (27263)”
- „links-tracking query string for Bill trigger and smart post install …”
opis
opis posiada prawdziwą moc historii użytkownika. Powinno to stworzyć empatię w zespole dla użytkownika i zrozumienie problemu do rozwiązania.,
bardzo popularna struktura opisu przyjmuje formę „jako … chcę … więc mogę …”.
ta struktura skłania do pytania „jako kto”? Kto ma problem z użytkownikiem? Możesz odwołać się do osoby tutaj, jeśli jej używasz, alternatywnie, podać nazwę użytkownika i dodać kontekst do sytuacji użytkownika. Staraj się unikać używania „jako klienta” lub „jako użytkownika”, ponieważ jest to mniej skuteczne w tworzeniu empatii dla rzeczywistego użytkownika.
opis powinien być napisany prostym, jasnym językiem, bez terminów technicznych i skrótów., Powinieneś zadać sobie pytanie ” czy Twoja babcia to rozumie?”Nowy członek zespołu powinien być w stanie przeczytać opis i dokładnie zrozumieć, na czym polega problem, który należy rozwiązać.
poniższe przykłady pochodzą z projektu polegającego na dodaniu funkcjonalności do systemu kont online dla klientów brytyjskiej firmy energetycznej.,
kilka dobrych przykładów:
- „jako John, klient z tradycyjnym licznikiem energii elektrycznej, chcę zrozumieć, dlaczego nie widzę Wykresów zużycia energii bardziej szczegółowo niż miesiąc po miesiącu, więc mogę zdecydować, czy chcę to zmienić i zainstalować inteligentny licznik.”
- ” jako Bart, proaktywny klient tradycyjnych liczników, chcąc upewnić się, że mój następny rachunek jest dokładny, chcę wiedzieć, czy odczyt licznika został już złożony dzisiaj i że nie muszę składać kolejnego.,”
niektóre mniej dobre przykłady:
- „jako użytkownik chcę uniemożliwić klientom trad możliwość drążenia poniżej najwyższego poziomu, aby zarządzać ich doświadczeniem klienta”
- ” jako klient, który dostarczył dziś odczyt licznika lub miał szacowany odczyt paliwa, nie powinienem mieć prawa do przesyłania kolejnego odczytu licznika dzisiaj, ponieważ SAP nie może zaakceptować więcej niż jednego odczytu licznika na paliwo dziennie.”
mniej dobre przykłady zostały przepisane na dobre przykłady powyżej, ponieważ problemy, które opisali, nie były jasne., Ten proces udoskonalania powinien być wykonywany za każdym razem, gdy jakakolwiek część historii użytkownika nie jest jasna. Po prostu upewnij się, że wszyscy w zespole są świadomi i zgadzają się na zmiany.
kryteria akceptacji
kryteria akceptacji są używane do udowodnienia kompletności historii użytkownika. Jest to pomocne dla programistów i testerów.
pisanie kryteriów akceptacji jest skutecznym sposobem przejścia przez wszystkie szczegóły historii przed rozpoczęciem jakiejkolwiek pracy. Wiele potencjalnych pułapek lub nieoczekiwanej pracy można” odkryć ” wcześnie, pisząc dobre kryteria akceptacji.,
bardzo popularna struktura kryteriów akceptacji przyjmuje formę „Given… When… Then…”, jak widać w poniższych przykładach.
Jeśli Historia użytkownika ma więcej niż 10 kryteriów akceptacji, może to wskazywać, że historia robi zbyt wiele rzeczy. W tym przypadku zalecam rozważenie podzielenia się historią.
cały zespół powinien być zaangażowany w pisanie kryteriów akceptacji. Jeśli nie jest to możliwe, Gorąco polecam wszystkim przeczytać i zgodzić się na nie przed rozpoczęciem pracy nad nimi. Dotyczy to zwłaszcza osób zaangażowanych w testowanie pracy.,
numerowanie kryteriów akceptacji ułatwia odwoływanie się do nich.
kilka dobrych przykładów:
- biorąc pod uwagę klienta z tradycyjnym licznikiem na wykresie zużycia energii
po kliknięciu na podpowiedź przez miesiąc
wyświetlane jest wyskakujące okienko pasujące do określonego projektu. - biorąc pod uwagę, że klient z podwójnym paliwem przegląda wykres słupkowy zużycia energii
gdy ma miesiące z szacowanymi wartościami
, legenda wykresu powinna wyraźnie pokazywać ikonę szacowanej energii elektrycznej z jasnoczerwonym paskiem
następnie legenda wykresu powinna wyraźnie pokazywać ikonę szacowanego gazu z jasnoniebieskim paskiem.,
gdy nie potrzebujemy user stories
zadania techniczne
czasami zadanie techniczne nie wydaje się odnosić do klienta. W takim przypadku nie używaj historii użytkownika. Ale zawsze warto zastanowić się, dlaczego wykonujesz zadanie techniczne; czy aktualizujesz bibliotekę, aby poprawić szybkość dla użytkowników? Jeśli tak, to powinna to być historia użytkownika.
błędy
Jeśli błąd zostanie znaleziony podczas testowania wątku użytkownika, nad którym aktualnie pracujemy, powinien być powiązany z tym wątkiem użytkownika.,
jeśli zostanie znaleziony błąd dla czegoś, co nie jest bieżącą historią użytkownika, to nie powinien być powiązany z historią użytkownika, ale dodany do zaległości jako niezależne zadanie.
ciągłe doskonalenie
historie użytkowników będą ewoluować, gdy więcej dowiadujemy się o pracy do wykonania. Jest to dobre, Kontynuuj ich ulepszanie aż do momentu, w którym udostępniasz pracę użytkownikom., Po prostu upewnij się, że wszyscy w Twoim zespole są świadomi i zgadzają się na wprowadzane zmiany.
Czytaj dalej Bądź zwinny, zastanów się, jak twoje historie użytkowników pracują dla Twojego zespołu, przedyskutuj je w retros i ulepszaj sposób, w jaki je piszesz.
Dodaj komentarz