Jak napisać dobrą historyjkę użytkownika (user stories)?

Razem z popularyzacją SCRUMa i zwinnego podejścia do wytwarzania oprogramowania, zmienił się także sposób opisywania wymagań przez product ownera dla zespołu developerskiego. Uznanie zdobyły tzw. User Stories, czyli Historyjki Użytkownika. Opisują one z perspektywy usera, jaka funkcja produktu jest potrzebna i dlaczego:

Jako _______ (kto?), chcę _______ (co?), by _______ (dlaczego?)

Nikogo już taki format przedstawienia wymagań w backlogu nie dziwi. Znają go zarówno product ownerzy, jak i zespoły developerskie.

Ma on niewątpliwe zalety: jest prosty, zawsze wskazuje właściciela wymagania (komu na nim zależy) i jaki jest jego cel. Dzięki temu szybko oddzielamy wymagania potencjalnie sensowne, od tych które sensu na pewno nie mają (bo nie wiadomo komu są one potrzebne i w jakim celu).

Szczegóły wymagania

Mamy więc piękne backlogi złożone z pojedynczych wymagań. Jest piękny tytuł każdego wymagania w formie User Stories.

A jak dopisujemy szczegółowe informacje do każdego wymagania? Piękną… prozą. I szybko okazuje się, że formuła user stories sporo nam pomogła, ale tak jak nie wiedzieliśmy jak dobrze rozpisywać wymagania, tak dalej tego nie umiemy. Dalej deweloperzy dostarczają przyrost inny niż mieliśmy jako product ownerzy w głowie, dalej irytują się na źle i niejednoznaczne sformułowane wymagania.

Co więc powinno zawierać User Stories poza swoim tytułem?

Szablon dobrej Historyjki Użytkownika

Dobra historyjka użytkownika powinna możliwie jak najdokładniej pokazywać granicę dla zespołu, w których może się poruszać tworząc rozwiązanie. Mój szablon opisu user stories wygląda tak:

1. Nazwa

Krótka nazwa wymagania, służy do tego, by szybko identyfikować User Stories na liście backlogu produktu.

2. User Stories:

Jako __________<kto?> (użytkownik)
chcę ____________<co?> (funkcja produktu lub problem, który chcemy rozwiązać)
by ___________ <dlaczego?> (dlaczego użytkownik potrzebuje tej funkcji, jakie są wymierne korzyści z wprowadzenia jej).

3. Kryteria akceptacji:

Zespół powinien znać jednoznaczne kryteria, które powinno posiadać rozwiązanie tak, aby mogło zostać zaakceptowane przez product ownera. Najlepiej, gdy każde kryterium ma formę prostego pytania, na które można jednoznacznie odpowiedzieć TAK/NIE.

• Kryteria Funkcjonalne

  • kryteria funkcjonalne systemu, jak powinna działać funkcja z punktu widzenia użytkowników

  • np.: działanie funkcji krok po kroku, zgodność działania z przygotowaną makietą…

• Kryteria Niefunkcjonalne

  • kryteria wydajnościowe lub jakościowe.

  • np.: dostępność, czas reakcji, niezawodność, podatność na testowanie, możliwości utrzymania oraz (jeśli jest to zdefiniowane w sposób umożliwiający jednoznaczną weryfikację i pomiar) łatwość użytkowania.

4. Scenariusze testowe:

Idealną sytuacją jest przygotowanie dla zespołu tworzącego rozwiązanie zestawu testów, którymi będziemy potem weryfikować przygotowane rozwiązanie. Są one też doskonałą formą dokumentowania wymagania. Świetnie sprawdza się tutaj pisanie zgodnych z BDD (behavior-driven development) scenariuszy w języku Gherkin;

Składnia:

Przyjmując… <opis warunku> – ustalone warunki początkowe,
oraz… <kolejny warunek> – kontynuacja poprzedniego kroku,
kiedy… <akcja> – służy do opisania akcji wykonywanych dla danej funkcjonalności,
wtedy… <rezultat> – określa spodziewany rezultat.

5. Dodatkowe informacje

Dodatkowe informacje, modele, pliki.

• Model UML/BPMN

• Makiety

• Grafiki

Przykładowa historyjka

Jak taki szablon sprawdza się w praktyce? Zobacz to na konkretnym przykładzie

1. Nazwa

Miesięczny grafik pracy zmianowej.

2. User Stories:

Jako planista
chcę przygotować miesięczny grafik pracy zmianowej
by przedstawić pracownikom plan ich pracy na kolejny miesiąc.

3. Kryteria akceptacji:

• Kryteria Funkcjonalne:

• czy rozwiązanie odpowiada tym zawartym w dołączonej makiecie?

  • czy dostęp do funkcji ma tylko planista?

  • czy tworzony grafik jest zgodny z Kodeksem Pracy i Regulaminem Pracy?

  • …

• Kryteria niefunkcjonalne

  • czy grafik zostaje wygenerowany w czasie krótszym niż 3 sekundy (średnio, dla 95% zapytań)?

    • czy wygląd grafiku jest spójny z identyfikacją wizualną rozwiązania (wykorzystane są elementy graficzne i kolorystyka zawarte w naszym Graphic Design Guidelines)?

    • …

4. Scenariusze testowe:

Scenariusz 1: Poprawne przygotowanie grafiku.
Przyjmując, że planista zaplanował godziny pracy dla wszystkich pracowników z działu
Oraz że suma godzin mieści się w ramach Kodeksu Pracy i Regulaminu Pracy
Kiedy planista wybierze opcję Zatwierdź grafik
Wtedy grafik zostaje zapisany i staje się widoczny dla pracowników działu, którzy otrzymują powiadomienie e-mail o nowym grafiku.

Scenariusz 2: Niepoprawne przygotowanie grafiku.
Przyjmując, że planista zaplanował godziny pracy dla wszystkich pracowników z działu
Oraz że suma godzin nie mieści się w ramach Kodeksu Pracy i Regulaminu Pracy
Kiedy planista wybierze opcję Zatwierdź grafik
Wtedy widzi komunikat błędu o brakujących pracownikach i nadwyżce/niedoborze zaplanowanych godzin dla pracowników.

5. Dodatkowe informacje

• Makiety rozwiązania

• Kodeks pracy

• Regulamin pracy

Dobre Historyjki wymagają czasu

Napisanie dobrej Historyjki Użytkownika wymaga czasu. I to na wielu płaszczyznach.

Po pierwsze, samo ich napisanie wymaga poświęcenia dłuższej chwili. Można je oczywiście tworzyć szybko i niedbale, potem jednak możesz się spodziewać takiego samego efektu pracy zespołu. Bo na podstawie tych niedbałych wymagań będzie pracować.

Po drugie, dobre historyjki często są jak wino – długo dojrzewają. Najpierw pojawiają się w backlogu w formie samego opisu User Stories, z biegiem czasu i kolejnych przemyśleń product ownera dochodzą poszczególne kryteria akceptacji. Gdy Product Owner jest już pewny swojej wizji, doprecyzowuje historyjkę scenariuszami testowymi. Takie dojrzewanie historyjki pomaga w jej lepszym przemyśleniu. Wiele pomysłów pojawia się nagle, często podczas dyskusji np. nad innymi funkcjami produktu. Mając ją w backlogu, zawsze gdy wpadnie Ci jakiś pomysł, możesz szybko do niej dopisać potrzebne informacji.

Po trzecie (i chyba najważniejsze). Sprawność w pisaniu dobrych historyjek, tak jak w każdej innej dziedzinie, przychodzi z czasem i doświadczeniem. Współpracując z różnymi zespołami deweloperskimi będziesz poznawał ich punkty widzenia na dobre wymagania.

Także podczas scrumowych retrospektyw będziecie często do tego formatu wracać i go usprawniać. Nie przejmuj się więc, że nie udało Ci się od razu stworzyć idealnej historyjki – zespół marudzi, że nie do końca wie co ma rodzić, a powstające rozwiązanie nie odpowiada w 100% Twojej wizji. To naturalne. O ile będziesz pracować i usprawniać swój “historyjkowy warsztat” – idziesz w dobrym kierunku.

Życzę Ci wielu dobrych i ciekawych historii do opowiedzenia 🙂