Dzisiejszy wpis będzie o Historyjkach Użytkownika czyli User Stories. Część z Was zna na pewno ten temat. Dla tych którzy nie znają – będzie, o tym jak zbierać oczekiwania od osób, które zlecają Wam pewne zadania. Jak zbierać oczekiwania w taki sposób, żeby dochodziło do jak najmniejszej ilości nieporozumień.
User stories / Historyjki użytkownika – co to jest?
Na początek spróbujmy zdefiniować historyjki użytkownika. To nie są horrory, które się dzieją pod kątem użytkowania systemu. To nie są dramaty z cyklu “coś się wywróciło w ostatniej chwili”. To nie są też komediowe sytuacje, ani też wymagania science fiction.
Historyjki użytkownika to pewien sposób na usystematyzowanie zbierania wymagań i oczekiwań od osób, które mogą Ci zlecić, żeby w tym projekcie coś się zadziało. Geneza historyjek użytkownika to IT. Skąd to się tam wzięło? Ponieważ wymagania bardzo często są nieprecyzyjne. Przychodzi ktoś i mówi “zrób mi, żeby na tej stronie ktoś mógł kupić mój produkt”. Później okazuje się, że to jest na tyle nieprecyzyjne, że nikt nie wie do końca o co chodzi. Historyjki użytkownika jako format zostały wprowadzone szczególnie przy projektach robionych w zwinny sposób. Jako sposób usprawniający komunikację, nie są idealne ale sprawiają, że jesteś w miarę szybko wyłapać, że coś jest nie tak z danym wymaganiem.
Przykład historyjki użytkownika. Jak to może wyglądać.
Wyobraź sobie, że przygotowujesz bloga lub stronę internetową. Ktoś mówi, że chce mieć na blogu baner, kontakt, mapę i ofertę i ebooka do pobrania. Bardzo często ta rozmowa jest na poziomie tematów fizycznych – ebook, kontakt, strona itd. To często nie wystarcza do tego, żeby zrozumieć szerszy kontekst. A jak nie rozumiesz kontekstu, to nie jesteś do końca tego w stanie sensownie zrobić. Dlatego format historyjek pozwala wcześniej wyłapać co i jak. To przydaje się nie tylko w IT, jeżeli pracujesz na innych projektach, też możesz wykorzystać te sposoby.
Jak sprawdzić czy historyjka, którą dostajemy od użytkownika jest faktycznie taka jaka powinna być. Korzystamy tutaj z podejścia INVEST. Jest to 6 punktów, które historyjka musi spełnić:
- Independant – niezależna. To jest historyjka niezależna od pozostałych. Mogę się skupić np tylko i wyłącznie na pliku do pobrania, nie zajmując się pozostałymi tematami. Wydzielony kawałek funkcjonalności i wymagań, którym mogę się zająć.
- Negotiable – negocjowalna. Możemy w ramach tego obszaru rozmawiać co konkretnie jest pod spodem.
- Valuable – wartościowa. Ona musi przynosić wartość dla projektu. Chodzi o to, żeby nie wpadały różne nagłe natchnienia ze strony użytkownika, niewiele wnoszące do tematu.
- Estimable – oszacowywalna. Jesteśmy w stanie oszacować to co dostaliśmy pod kątem tego ile czasu nam to zajmie i jak to jest skomplikowane. Jeżeli jesteś w stanie oszacować czas, koszt to znaczy, że rozumiesz go na tyle, że możesz nad tym pracować.
- Small – mała. Chodzi o to, żeby historyjka zmieściła się w ramach jednej iteracji, czyli jednego sprintu. Jak zrobimy ją za dużą to niesie ze sobą większe ryzyko niepowodzenia.
- Testable – testowalna. Jestem w stanie przetestować to co sobie człowiek zażyczył.
To jest pierwszy filtr, który możesz założyć, kiedy ktoś przychodzi do Ciebie z tematem “chcę, żeby to było zrobione” – sprawdzasz czy ta “rzecz” jest niezależna, negocjowalna, wartościowa, oszacowywalna, mała i testowalna.
3 różne formaty historyjek użytkownika, które możesz zastosować
Format nr 1:
Jako (rola)
mogę (funkcjonalność)
bo wtedy (potrzeba/korzyść)
np. Jako administrator systemu mogę zablokować użytkownika, który wysyła obraźliwe komentarze, bo wtedy pozostali mogą spokojnie korzystać z tej funkcji.
Format nr 2:
Jako (rola)
chcę (funkcjonalność)
bo (powód)
np. Jako administrator systemu finansowego chcę mieć możliwość sprawdzenia jakie zmiany były dokonane w ciągu ostatniego miesiąca, bo mój szef spyta mnie dlaczego wprowadziliśmy i jakie korekty i muszę być na to przygotowany.
Format nr 3:
Jako (rola)
mogę (funkcjonalność)
np. Jako księgowy mogę wydrukować historię faktur.
Wydaje mi się, że pierwsze dwie wersje są dosyć fajne, bo oprócz tego, że określają kto to robi i co to ma robić daje też szerszy kontekst.
Scenariusze testowania
Do historyjek można stworzyć scenariusze testowania. Jak sprawdzimy czy to jest faktycznie to, czego oczekiwaliśmy. Wygląda to tak:
Scenariusz: Tytuł
Zakładając, że (kontekst)
I (więcej kontekstu)
Kiedy (wydarzenie)
Wtedy (wynik)
I (więcej wyniku)
Przykład:
Użytkownik nie ma założonego konta w serwisie
Zakładając, że użytkownik nie ma założonego konta w serwisie
I nie wybrał opcji zakupu bez zakładania konta
Kiedy próbuje dokonać zakupu
Wtedy system nie pozwoli mu na to
I wyświetli komunikat, o tym, że nie ma konta i żeby kliknął w link do jego założenia
I to by było na tyle. Warto przepuścić historyjkę użytkownika przez 6 punktów INVEST, umówić się na jakiś format, którego będziecie się trzymać (możesz skorzystać z któregoś z trzech, które przedstawiłem) oraz ustalić sposób testowania.
Na koniec jeszcze kilka słów o tym, co my jako Leadership Center robimy w ramach Agile i Scrum. Przede wszystkim robimy szkolenia – więc jeżeli interesuje Cię Scrum, pracujesz Scrumowo, chcesz poprawić swoją metodę pracy w iteracjach to możemy takie szkolenie zrobić w formie zamkniętej. Drugie szkolenie to Agile dla nietechnicznych. Dla tych wszystkich, którzy pracują z zespołami IT. Zapraszam
Szkolenie Profesjonalny Scrum Master >>>