Czy User Story to wygodna i wystarczająca forma opisu wymagań w projektach informatycznych? Czy sprawdzi się wszędzie, zaczynając od start-upów, a kończąc na dojrzałych korporacjach?
Ja mam swoje zdanie bazujące na wieloletniej pracy z User Story. Definicję, przykładowe User Story i ich zastosowanie, oraz moją opinię znajdziesz poniżej.
W kolejnych rozdziałach przeczytasz o:
- Podstawach, czyli definicji User Story
- Przykładach User Story
- Zastosowaniu User Story – wady i zalety
- Co dalej po zdefiniowaniu User Story – przykładowe kolejne kroki
Klasyczna definicja User Story, czyli CCC
Historia User Story sięga końca lat 90-tych ubiegłego wieku, kiedy to Kent Beck opublikował zestaw praktyk związanych z wytwarzaniem oprogramowania pod nazwą Extreme Programming (XP). Według tego modelu User Story powinno być:
- zdefiniowane przy użyciu języka naturalnego,
- opracowane z perspektywy konkretnego użytkownika,
- nastawione na dostarczenie wartości dla tego użytkownika – efektu,
- możliwe do dostarczenia w krótkim, skończonym czasie.
Rok wcześniej (1998) Alistair Cockburn określił User Story jako “zaproszenie do rozmowy”, co dobrze wpasowuje się w powszechną obecnie koncepcję CCC (Card, Conversation, Confirmation) wprowadzoną w 2001 roku przez Rona Jeffriesa.
Według tej koncepcji User Story składa się z trzech elementów:
1. User Story Card
Karta (Card), czyli nagłówek/tytuł User Story.
Wraz z początkami User Story przyjęto za standard opis według konwencji:
Jako <użytkownik> chciałbym <możliwość, czynność>, aby <korzyść>
Czy warto opisywać User Story w ten sposób? Przykłady podam w dalszej części.
2. User Story Conversation
Powyższy tytuł to nie wszystko. W trakcie prac nad User Story konieczne jest doprecyzowanie detali (Conversation). W klasycznej definicji odbywa się to w trakcie rozmowy, z której wnioski lądują właśnie w User Story.
Ważne jest to, aby te wnioski faktycznie znalazły się w opisie historyjki, a nie pozostały jedynie w głowach uczestników.
3. User Story Confirmation
I trzecie C, czyli dyskusje nad wymaganiami powinny zakończyć się ustaleniem kryteriów akceptacji danej historyjki. Jest to test, lub zestaw testów, których wykonanie potwierdzi, że historyjka została dostarczona i pozwala osiągnąć założone korzyści.
Tak jak w przypadku Conversation, tak i tutaj ważne jest zapisanie tych testów, a nie tylko omówienie.
Czy zawsze stosować Jako…chciałbym…aby?
Przedstawiona klasyczna struktura zapisu User Story dobrze systematyzuje opis historyjek. Ma jednak pewne wady, czyli:
- utrudnia opisywanie wymagań technicznych. Takie zadania lepiej opisywać w tradycyjnej, analitycznej formie, nie korzystając ze schematu “jako…chciałbym…aby…”
- komplikuje przeglądanie backloga, gdy np. 100 historyjek zaczyna się od: “jako klient firmy ABC chciałbym, aby…” – wiele systemów do zarządzania historyjkami nie wyświetli całego tekstu, więc User Story będą nie do rozróżnienia. Proponuję upraszczać tytuły, a klasyczny opis wynikający z CCC wpisać w treści historyjki.
User Story – przykłady
Zgodnie z powyższym schematem, zdefiniowanie przykładowego User Story może przebiegać następująco.
User Story – przykład dla e-commerce
Card
Jako klient sklepu meblowego chciałbym odfiltrować tylko te zestawy mebli, które mieszczą się do mojego pokoju, dzięki czemu przeglądanie ofert zajmie mi dużo mniej czasu.
Conversation
Przykładowy zapis z rozmowy zespołu:
Wprowadzam rozmiary pokoju i system od razu “wie”, które zestawy na pewno są nieodpowiednie (dokładny algorytm obliczeń – patrz diagram na stronie …)
Pomocny byłby edytor wizualny, w którym można nanieść nie tylko drzwi czy okna, ale też inne posiadane obecnie meble, które klient chce zachować w pokoju.
Niektóre ściany mają też ograniczenia, np. klient nie chce zasłonić ładnej tapety, albo nie może nic powiesić na zaimprowizowanej ścianie z kartongipsu.
Z czasem mogą pojawić się dodatkowe ograniczenia.
Klient na końcu dostanie listę tych zestawów, które spełniają oczekiwania. Lista będzie posortowana według kryteriów stosowanych standardowo w sklepie, czyli np. ceny, opinii, dostępności itp.
Confirmation
- Gdy wprowadzę rozmiary pustego pokoju, to system wyliczy czy konkretny zestaw mebli mieści się w nim czy nie.
- Gdy wskażę w planie pokoju okna i drzwi, to system wyliczy czy konkretny zestaw mebli może się w nim zmieścić w taki sposób, aby umożliwić otwarcie okien i drzwi.
- Gdy naniosę dodatkowe meble na plan pokoju, to system uwzględni je w obliczeniach i zasugeruje tylko te zestawy, dla których możliwe będzie ułożenie starych i nowych mebli razem.
- Gdy naniosę informacje o dodatkowych ograniczeniach na ścianach, to system potraktuje je tak samo jak okna czy drzwi i nie zasugeruje ustawienia tam mebli.
- Gdy moje wymagania spełni kilka zestawów mebli, to będę mógł posortować ją według różnych kryteriów, np. ceny, opinii, dostępności, materiału, koloru.
Jak stosować i nie stosować User Story – przykłady
Przykładowe User Story to tylko krok na drodze do przygotowania wartościowego backloga. Jest jeszcze kilka innych elementów niezbędnych do zastosowania.
Odpowiednio dobrany użytkownik (persona)
W pierwszej części User Story występuje osoba – użytkownik, czyli “Jako ktoś, chciałbym…”
Jak zdefiniować tego kogoś?
- Użytkownik w User Story powinien reprezentować szeroką grupę odbiorców systemu. To nie może być ekstremalny charakter. W przykładzie meblarskim to nie mógłby być klient, który kupuje drogie, mahoniowe meble, jeżeli sklep specjalizuje się w ofercie ekonomicznej, dostosowanej do przeciętnego odbiorcy.
- Profil i zachowanie użytkownika powinno wynikać z badań i obserwacji. To nie może być gdybanie typu “ktoś tak pewnie robi”, “wyobraź sobie, że jesteś … i robisz …”. Szkoda czasu na takie wymyślanie użytkowników. Wartościowe persony są definiowane na przykład:
- na podstawie ankiet i rozmów z użytkownikami,
- w trakcie rozmów z osobami, które mają z nimi bezpośredni kontakt (np. sprzedawcy),
- w wyniku obserwacji ich interakcji z systemem,
- na podstawie ogólnodostępnych badań statystycznych.
W przeciwnym razie już na starcie pojawi się spore ryzyko, że User Story może dostarczyć coś, czego nikt nie chce.
Uzasadnienie, czyli konkretna korzyść z każdego User Story
Każda historyjka przekłada się z czasem na koszt poniesiony na jej wytworzenie i utrzymanie. W zamian za ten koszt musi powstać mierzalna wartość – od razu lub za dopiero jakiś czas. W przeciwnym razie będzie to strata z perspektywy biznesowej.
Pracując nad User Story zastanów się więc:
- jaka jest skala problemu, który chcesz rozwiązać – wyraź to w liczbach,
- jaki będzie efekt po zrealizowaniu tego User Story – na ile zmienią się te wskaźniki?
- czy zysk będzie adekwatny do kosztów?
Wyliczanie wartości User Story – przykład
Przykład User Story dla e-commerce. Wspomniany już sklep meblowy:
- Przeprowadzono ankietę – zebrano informacje od klientów, którzy ostatecznie nie zdecydowali się na zakupy w tym sklepie.
- Tylko 5% ankietowanych podkreśliło, że nie byli w stanie sprawdzić, czy meble zmieszczą się w ich mieszkaniu. Dużo częstszą przyczyną była słaba wizualizacja kolorów, brak opisu materiału, niejasne informacje na temat opcji zakupu i jeszcze kilka innych powodów.
- Przeliczając to na potencjalny zysk nieuzasadnione jest rozpoczynanie prac nad tym wymaganiem. Środki potrzebne na zbudowanie tak złożonych algorytmów będą niewspółmiernie większe od potencjalnych zysków.
- Warto skupić się na innych problemach, które przy niższych nakładach szybciej przełożą się na wyniki biznesowe.
Analiza z perspektywy procesu
Każde User Story to osobna historyjka. Systemy to jednak nie pozszywane ze sobą losowo części, ale funkcjonalności ułożone w moduły i procesy. Dlatego odkładanie wszystkich pomysłów na stos zwany backlogiem nie jest najlepszym pomysłem.
Z takiej sterty historyjek ciężko zbudować coś spójnego. Efektem może być nieoptymalny produkt. Na przykład samochód wyścigowy, w którym założono dynamiczną skrzynię biegów, a do tego wstawiono zbyt słaby silnik, który i tak nie wykorzysta jej potencjału.
Każde z wymagań być może nawet zostało spełnione. Tylko, że osobno.
Dlatego User Story powinny być zawsze analizowane z perspektywy procesu, a każda historyjka musi mieć swoje miejsce w sekwencji prowadzącej do uzyskania oczekiwanej wartości. Jeżeli jest coś poza procesem, to jest to prawdopodobnie zbędne.
Poniżej załączam przykład z narzędzia Visual Pardigm, które pozwala na mapowania User Story do kroków procesu zapisanych w notacji BPMN.
(źródło: https://www.visual-paradigm.com/features/agile-user-story-mapping-tool/)
User Story Map jako uniwersalne rozwiązanie
Innym sposobem przedstawienia historyjek użytkowników jest Mapa Historyjek Użytkowników (User Story Map) – czyli wizualizacja procesu, z perspektywy uczestników.
Aby zbudować mapę historyjek użytkownika nie potrzebujesz wiedzy na temat BPMN czy innej notacji. W zamian potrzebne są umiejętności z zakresu prowadzenia efektywnych warsztatów, moderacji, zarządzania dynamiką grupy czy motywacji. To wszystko uzupełnione umiejętnościami zadawania odpowiednich pytań, ogólną dociekliwością i analitycznym podejściem.
User Story Map przygotujesz choćby w arkuszu kalkulacyjnym. Tak właśnie powstała poniższa mapa.
Budowanie całego backloga historyjek
User Story są pisane językiem naturalnym. Może więc kusić przekazanie opieki nad backlogiem osobom znającym biznes, bez specjalnego przygotowania do tej roli.
Zdecydowanie nie polecam takiego rozwiązania. Backlog będzie wtedy chaotyczną listą ogólnych życzeń i pomysłów.
Zaimplementowanie systemu na tej podstawie będzie niemożliwe.
Aby więc przygotować spójny i wartościow zestaw User Stories, pokrywających kluczowe procesy, konieczne jest metodyczne podejście, takie jak mapowanie story do BPMN czy tworzenie User Story Map.
Do tego warto dodać:
- spójny słowniki pojęć,
- zapisywanie oczekiwań w postaci liczbowej,
- precyzyjne określanie testów akceptacyjnych
- i wiele więcej…
To z kolei wymaga odpowiedniego przygotowania i kompetencji ze strony osób opracowujących te wymagania.
Co dalej?
Zdefiniowanie backloga pełnego dobrych historyjek to do dopiero początek procesu.
Następnie należy, na przykład:
- podzielić go na kolejne wersje, mając na uwadze cele biznesowe,
- uszczegółowić wymagania i potwierdzić ich wykonalność,
- ustalić sposób realizacji od strony technicznej,
- oszacować czasochłonność prac.
Chcesz jeszcze bardziej zgłębić temat? Poznaj technikę User Story Mapping!
