User stories

Historyjka użytkownika (ang. User story) jest sposobem zapisu wymagań klienta. Metoda ta została zaproponowana przez Kenta Becka i Martina Fowlera - twórców metodyki Extreme Programming, i jest często stosowana do gromadzenia wymagań w metodykach zwinnych np. Scrum, Kanban czy właśnie Extreme Programming.

TL;DR

User story jest sposobem zapisu wymagań klienta w metodykach zwinnych. Składa się z trzech elementów: karty, konwersacji i konfirmacji. Każda historyjka powinna być istniejąca samodzielnie, negocjowalna, wartościowa, estymowalna, mała i testowalna. W metodyce Scrum historyjki są przechowywane w backlogu produktu, a podczas planowania sprintu zespół deweloperski wybiera, które z nich zostaną zrealizowane. Historyjki są umową pomiędzy zespołem deweloperskim a Product ownerem.

Konstrukcja

User story to krótki opis wybranej funkcjonalności, napisany z punktu widzenia docelowego użytkownika danego produktu. Opis taki, zwykle jednozdaniowy, zawiera jedynie informacje najważniejsze z punktu widzenia przyszłego użytkownika - jest on zasygnalizowaniem problemu oraz punktem wyjścia do dyskusji o sposobach jego rozwiązania.

Tradycyjnie, historyjki użytkownika zapisywane są na niewielkich kartkach papieru lub kartonikach - dzięki temu możliwe jest ich fizyczne umieszczenie na Scrum board lub Kanban Board. Rozmiar kartek ma również wpływ na to, że historyjki użytkownika zapisane na nich powinny być możliwie krótkie i zwięzłe.

Jeden z najprostszych, a także najpopularniejszy szablon zapisu historyjki użytkownika wygląda następująco:

Jako<Kto?>chcę wykonać<Co?>aby<Dlaczego?>.

Kluczowe w tworzeniu historyjki jest odpowiedź na trzy pytania widoczne we wzorze:

1. Kto? - informacja na temat użytkownika systemu, jego typu.
2. Co? - informacja o zadaniu, jakie dany użytkownik ma wykonać.
3. Dlaczego? - informacja o oczekiwanym wyniku wykonanego zadania.

W języku angielskim te trzy pytania układają się w tzw. “Trzy W": Who-What-Why.

Przykładowa historyjka użytkownika:

Jako klient sklepu chcę dodać produkt do koszyka aby go później kupić.

Powyższy szablon może być oczywiście podstawą do modyfikacji - jeżeli realizowany projekt tego wymaga, może on zostać rozbudowany o dodatkowe informacje lub okrojony, jeśli dana informacja nie jest akurat w danym projekcie potrzebna.

Podczas tworzenia historyjek użytkownika należy pamiętać, aby opisywały tylko takie funkcjonalności, które mają rzeczywistą wartość dla użytkownika - nie uwzględniamy w nich informacji takich jak sposób realizacji danego zadania ani szczegółów technicznych - np. używanego języka programowania.

Elementy User story - trzy "K"

Każda historyjka użytkownika jest złożona z trzech poniższych elementów:

1. Karta - historyjka zapisana jest na niewielkiej kartce papieru. Kratka sama w sobie nie jest wymaganiem (ma za mało miejsca, aby umieścić na niej wszystkie niezbędne informacje), ale jest fizyczną reprezentacją wymagania, ułatwiającą pracę z wymaganiami, np. planowanie pracy.
2. Konwersacja - historyjka użytkownika jest podstawą do rozmowy pomiędzy wszystkimi członkami zespołu projektowego, mającej na celu ustalenie wszystkich szczegółów koniecznych do prawidłowego zaimplementowania historyjki w produkcie.
3. Konfirmacja - implementacja historyjki powinna zostać potwierdzona poprzez odpowiednie testy akceptacyjne. Testy akceptacyjne zwykle są opisywane po drugiej stronie karteczek z historyjkami. Uznaje się, że jedna historyjka nie powinna mieć więcej niż dziesięć kryteriów akceptacji.

Powyższy podział jest w języku angielskim nazywany "The three C`s" (trzy "C") - od angielskich słów "Card" (karta), "Conversation" (konwersacja) i "Confirmation" (konfirmacja).

Atrybuty User story

Zgodnie z techniką INVEST, każda historyjka użytkownika powinna być:

• Istniejąca samodzielnie (ang. Independent).
• Negocjowalna (ang. Negotiable).
• Wartościowa (ang. Valuable).
• Estymowalna (ang. Estimable)
• Mała (ang. Small).
• Testowalna (ang. Testable).

User stories w Scrum

W metodyce Scrum format historyjki użytkownika jest zwykle stosowany do przechowywania wymagań klienta w backlog produktu. Osobą odpowiedzialną za tworzenie historyjek użytkownika jest Product owner. Jest on również odpowiedzialny za przygotowanie kryteriów akceptacji dla każdej historyjki.

Podczas planowania sprintu zespół deweloperski wybiera, które historyjki zostaną zrealizowane w najbliższym Sprincie, a następnie dokonuje dekompozycji historyjek na zadania możliwe do wykonania przez jedną osobę.

Historyjka użytkownika w scrum jest pewnego rodzaju umową pomiędzy zespołem deweloperskim a Product ownerem:

• zespół deklaruje, że pracę nad daną funkcjonalnością rozpocznie dopiero po jej dokładnym omówieniu,
• Product owner natomiast deklaruje, że będzie dostępny zawsze, gdy zespół będzie chciał z nim rozmawiać.

User stories — artykuły polecane

Backlog sprintu — Backlog produktu — Feature-Driven Development — Scrum of scrums — Getting Things Done — Technika MoSCoW — Webmaster — Testowanie w projekcie — Ganttproject

Bibliografia

• Chrapko M. (2015), Scrum: o zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice
• Leffingwell D., Behrens P. (2009). A User Story Primer
• Sachdeva S. (2016), Scrum Methodology, International Journal Of Engineering And Computer Science, nr 5

Autor: Karolina Zasada