Czym są “user stories” i dlaczego warto w nie inwestować?

Czym jest User Story dla programisty lub testera?

• User Story to sposób zapisu wybranej funkcjonalności z perspektywy użytkownika końcowego, zawierający najważniejsze informacje o wartościach, których poszukuje klient.

• User Story to kluczowy element w procesie tworzenia oprogramowania, zwłaszcza w metodykach Agile i Scrum.

• 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).

User stories to lista tego, na co programista/tester powinien poświęcić czas w obrębie danego zadania. Często jest tak, że pracując nad jakimś zadaniem zatraca się szerszy kontekst biznesowy.

Zaczyna się poprawiać i zmieniać rzeczy które nie są bezpośrednio związane z zadaniem. W skrajnych przypadkach może okazać się, że praca którą wykonywaliśmy jest… niepotrzebna (analogicznie jak gładź na ścianie w naszym przykładzie z remontem).

Dla programisty historyjki użytkownika to taka kotwica, która pozwala mu wracać do tego, co tak naprawde jest wymagane w konkretnym zadaniu. Dokładnie wiemy z czego tester będzie go rozliczał (a z czego nie). Być może, na danym etapie projektu nie potrzebujemy obsługiwać jakichś skrajnych przypadków, które zajęłyby 80% czasu pracy nad danym zadaniem.

Jeśli nie sprecyzujemy tego, może okazać się, że programista, z założenia, będzie próbował je obsłużyć.

User stories to wytyczne także dla testera - może okazać się, że wyklikany “błąd” wcale nie jest błędem tylko przypadkiem którego aktualnie nie obsługujemy (bo nie musimy). Unikamy w ten sposób zbędnych przepychanek pomiędzy testerem a programistą.

Minusem spisywania User Stories jest potrzeba poświęcenia im czasu, natomiast w porównaniu do tego jakie koszty może wygenerować brak takich wymagań to może okazać się że jest to świetna inwestycja.

Analogiczne problemy można spotkać w świecie IT

Jak można było temu zapobiec?

Zanim wybraliśmy się na urlop, powinniśmy usalić z fachowcem konkretne wymagania. W przypadku świata IT miałyby one określoną formę i strukturę - nazywaną User Story.

Dzięki takim historyjkom minimalizujemy ryzyko niedomówień, spisujemy konkretne wymagania danej funkcjonalności. Po wykonanej pracy punkt po punkcie możemy przejść listę i sprawdzić czy praca została wykonana.

Spisanie takiej listy jest komfortowe dla obu stron - Wykonawca wie co ma robić (ale też czego nie robić) i z czego będzie rozliczany, a my jako zlecający wiemy czego się spodziewać.

Historia i rozwój User Stories

• User Story powstało jako odpowiedź na potrzebę efektywnego i elastycznego podejścia do tworzenia oprogramowania.

• Wraz z rozwojem metodyk Agile i Scrum, User Story stało się nieodzownym elementem procesu tworzenia oprogramowania.

Struktura i szablon User Story

Odpowiednio dobrany użytkownik (persona)

W pierwszej części User Story kluczowe jest określenie, kto jest użytkownikiem funkcji, czyli "Jako ktoś, chciałbym...".

Użytkownik powinien być dobrze zdefiniowaną personą, reprezentującą grupę docelową korzystającą z danej funkcjonalności.

Jak zdefiniować użytkownika?

1. Zrozumienie grupy docelowej

   • Określ, kto będzie korzystał z produktu: czy to klient końcowy, pracownik, administrator, czy inna specyficzna rola.

   • Przykład: "Jako klient sklepu internetowego" lub "Jako administrator systemu IT".

2. Uwzględnij cele użytkownika

   • Zastanów się, jakie problemy użytkownik chce rozwiązać za pomocą produktu.

   • Przykład: Klient sklepu internetowego może chcieć szybciej finalizować zakupy, a administrator systemu – monitorować działania użytkowników.

3. Dostosowanie do scenariusza użycia

   • Persona powinna być precyzyjnie dopasowana do specyfiki zadania, aby User Story miało sens w danym kontekście.

   • Przykład: Dla aplikacji edukacyjnej personą może być "Jako uczeń, chcę mieć dostęp do wyników testów, aby móc śledzić swoje postępy."

4. Oparcie na danych i analizach

   • Warto oprzeć się na badaniach użytkowników, np. ankietach, wywiadach czy analizie zachowań, aby zrozumieć ich potrzeby i priorytety.

Najlepsze praktyki w pisaniu User Stories dla zespołów Agile

1. Użyj formatu "Jako... chcę... aby..."

• Pisanie User Stories w standardowym formacie pomaga w jasnym określeniu kto (użytkownik), co (cel), i dlaczego (korzyść).

Przykład: "Jako klient, chcę dodać produkt do koszyka, aby móc kontynuować zakupy później."

2. Zachowaj prostotę

• Unikaj technicznego żargonu i pisz w sposób zrozumiały dla wszystkich członków zespołu (biznes, programiści, testerzy).

• Historie powinny być krótkie i koncentrować się na potrzebach użytkownika.

3. Określ kryteria akceptacji

• Dodaj szczegółowe kryteria, które wyjaśniają, kiedy User Story będzie uznane za ukończone.

• Przykład: "Produkt zostanie dodany do koszyka i wyświetli się komunikat o sukcesie."

4. Twórz User Stories wspólnie

• Włącz cały zespół w proces tworzenia User Stories, aby zapewnić pełne zrozumienie i wspólną wizję zadania.

5. Rozbijaj na małe, zarządzalne elementy

• Duże User Stories (epiki) podziel na mniejsze, bardziej konkretne zadania, które można zrealizować w jednym sprincie.

6. Zorientuj się na wartość biznesową

• Skup się na tym, jakie korzyści przyniesie historia użytkownikowi lub biznesowi, zamiast koncentrować się na rozwiązaniach technicznych.

7. Używaj Definition of Ready (DoR)

• Upewnij się, że User Story spełnia kryteria gotowości przed rozpoczęciem prac: jasno określony cel, kryteria akceptacji i zrozumienie przez zespół.

8. Regularnie priorytetyzuj

• Współpracuj z Product Ownerem, aby regularnie oceniać priorytety User Stories zgodnie z wartością biznesową i potrzebami użytkowników.

9. Testuj i weryfikuj z użytkownikami

• Regularnie testuj rozwiązania z użytkownikami końcowymi, aby upewnić się, że odpowiadają ich oczekiwaniom.

10. Iteruj i ulepszaj

• W miarę postępu projektu, aktualizuj i doprecyzowuj User Stories, bazując na feedbacku od zespołu i użytkowników.Identyfikacja wymagań użytkownika

Historyjki użytkownika a kryteria akceptacji

• Kryteria akceptacji to uszczegółowienie danej historyjki użytkownika o konkretne potrzeby biznesowe.

• Kryteria akceptacji powinny być spełnione, aby móc uznać, że zakładana wartość historyjki została dostarczona i jej zakres zrealizowany zgodnie z założeniami.

Testy akceptacyjne i priorytetyzacja zadań

• W procesie tworzenia oprogramowania, testy akceptacyjne i priorytetyzacja zadań są krytycznymi etapami, które bezpośrednio wpływają na jakość i użyteczność końcowego produktu.

Zaangażowanie zespołu w tworzenie User Story (lepsza praca w zespole)

• Stworzenie historyjki pozwala na polepszenie współpracy w zespole projektowym.

• Każdy wie, co należy do jego obowiązków i nad czym obecnie pracują pozostali, a dzięki elementowi konwersacji, łatwiej o spójne ustalenia.

Prosto i do celu

• Format User Stories pozwala na to, aby w prosty, konkretny i zwięzły sposób opisać wszystkie najważniejsze zagadnienia, które należy wprowadzić.

• Dzięki temu jest on technicznie zrozumiały zarówno dla Project Ownera, jak i dla deweloperów.

Uzasadnienie, czyli konkretna korzyść z każdego User Story

Każde User Story powinno wyraźnie wskazywać, jaką wartość dostarcza użytkownikowi lub biznesowi. Część "aby [korzyść]" odpowiada na pytanie: dlaczego ta funkcjonalność jest potrzebna?

Dlaczego uzasadnienie jest ważne? Określa cel biznesowy.

Dzięki uzasadnieniu zespół rozumie, jakie korzyści przyniesie realizacja zadania i jak wpisuje się ono w cele projektu. Pomaga w priorytetyzacji. Korzyść wynikająca z User Story pozwala Product Ownerowi określić, które zadania mają największe znaczenie dla użytkownika lub biznesu. Minimalizuje zbędną pracę. Jasne uzasadnienie eliminuje ryzyko wykonywania działań, które nie przynoszą wartości.

Jak formułować korzyści? Konkretne i mierzalne efekty.

Uzasadnienie powinno wyraźnie wskazywać, jak User Story ułatwia życie użytkownikowi lub wspiera cele biznesowe.

Przykład: "Jako użytkownik aplikacji mobilnej chcę mieć możliwość zapisania ulubionych artykułów, aby móc do nich wrócić później."

Korzyść: użytkownik oszczędza czas i zwiększa wygodę korzystania z aplikacji. Skupienie na potrzebach użytkownika.

Zastanów się, jakie problemy rozwiązujesz. Uzasadnienie powinno odnosić się do rzeczywistych potrzeb.

Przykład: "Jako administrator systemu chcę widzieć raporty dzienne, aby szybciej analizować wydajność zespołu."

Unikaj ogólników. Korzyści powinny być konkretne. Zamiast: "aby działało lepiej", napisz: "aby użytkownik mógł szybciej znaleźć potrzebne informacje."

Uzasadnienie w User Story to kluczowy element, który wskazuje wartość dodaną dla użytkownika. Dzięki niemu zespół rozumie, dlaczego dane zadanie jest ważne i jak wpływa na realizację celów projektu. Precyzyjne sformułowanie korzyści ułatwia priorytetyzację i zapewnia lepsze efekty pracy zespołu.

• Skuteczne stosowanie User Stories - od identyfikacji potrzeb, które z punktu widzenia użytkownika są kluczowe, przez tworzenie historyjek, aż po ich integrację w cykle rozwoju i testy, jest decydujące dla sukcesu każdego projektu.

• Każda historyjka przekłada się na koszt poniesiony na jej wytworzenie i utrzymanie.

• W zamian za ten koszt musi powstać mierzalna wartość – od razu lub za jakiś czas.

• Współpraca między różnymi członkami zespołu – Product Ownerami, deweloperami, projektantami UX/UI i testerami – jest istotna dla tworzenia produktów, które łączą wysoką jakość techniczną z praktycznym użytkowaniem. Historyjki użytkowników sprawiają, że ta współpraca jest łatwiejsza i bardziej płynna.