User Story to wygodna i wystarczająca forma opisu wymagań w projektach informatycznych, zaczynając od start-upów, a kończąc na dojrzałych korporacjach.

 

Zgadzasz się z tym?

Ja mam swoje zdanie bazujące na wieloletniej pracy z User Story. Definicję, przykładowe User Story i ich zastosowanie 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

 

Historia User Story zaczyna się pod koniec 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:

  • User Story Card
  • User Story Conversation
  • User Story Confirmation

 

User Story Card

Karta, czyli nagłówek User Story.

Niemalże od początku stosowania 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.

 

User Story Conversation

Powyższy tytuł to nie wszystko. W trakcie prac nad User Story konieczne jest doprecyzowanie detali. W klasycznej definicji odbywa się to w trakcie rozmowy, z której wnioski lądują właśnie w User Story.

 

User Story Confirmation

Według tej koncepcji, 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.

 

Inne formy

Przedstawiona struktura dobrze systematyzuje opis historyjek, a jednocześnie:

  • utrudnia opis wymagań technicznych – te 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 CCC w pełnej formie stosować w treści.

 

User Story – przykłady

 

Zgodnie z powyższym schematem, definiowanie przykładowego User Story może wyglądać 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

Wprowadzam rozmiary pokoju i system od razu “wie”, które zestawy na pewno nie są odpowiednie (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 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ę jeszcze inne ograniczenia.

Klient na końcu dostanie listę tych zestawów, które spełniają oczekiwania. Lista będzie posortowana według standardowych kryteriów, czyli np. ceny, opinii, dostępności itp.

 

Confirmation

  • Gdy wprowadzę rozmiary pustego pokoju, to system wyliczy czy konkretny zestaw mebli może się w nim zmieścić.

  • 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 wskażę dodatkowe meble na plan pokoju, to system uwzględni je w obliczeniach i zasugeruje tylko te zestawy, dla których pozostanie wystarczająco dużo miejsca.

  • Gdy naniosę informacje o dodatkowych ograniczeniach na ścianach, to system potraktuje je tak samo jak okna czy drzwi i nie będzie sugerował 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. 

 

User Story – przykład dla systemu ERP

 

Card

Jako pracownik działu sprzedaży chciałbym aby system podpowiadał mi dostawców, z którymi dobrze się współpracuje, żeby nie tracić czasu i pieniędzy na zamawianie towaru z niepewnych źródeł.

 

Conversation

System powinien zbierać historię zamówień, analizować ich wielkość, cenę, terminy realizacji. Następnie porównywać to z rzeczywistością, czyli datą otrzymania towaru, wynikami kontroli jakości, zwrotami, szybkością odpowiadania na reklamacje. 

Czy potrzebna jest też subiektywna opinia, np. łatwość dogadania się? (do ustalenia)

Taka analiza powinna być globalna (wszystkie oddziały firmy), a także lokalna, w ramach jednej fabryki. Rynek lokalny może się różnić w każdym regionie. 

W efekcie powinien powstać ranking dostawców.Użytkownik powinien być ostrzegany przy próbie składania zamówień u bardzo “podejrzanych” dostawców. 

 

Confirmation

  • Gdy wprowadzam zamówienie zakupowe, to otrzymuję informację zwrotną na temat jakości relacji z danym dostawcą (według kryteriów określonych na stronie …)

  • Mogę przeglądać informacje o jakości współpracy z dostawcą z perspektywy całej firmy, oraz wyłącznie mojego zakładu.

  • Mogę dodawać subiektywne opinie i oceny do dostawców, na przykład doceniając poprawę jakości usług, która nie będzie od razu widoczna w automatycznych statystykach.

 

Jak stosować i nie stosować User Story – przykłady

 

Przykładowe User Story to tylko element drogi do przygotowania wartościowego backloga. Jest kilka kluczowych elementów niezbędnych do zastosowania z sukcesem historyjek użytkownika.

 

Odpowiednio dobrany użytkownik (persona) 

W pierwszej części User Story występuje 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, tak jak np. przedstawiciel mniej niż 1% klientów, który kupuje drogie, mahoniowe meble w sklepie specjalizującym się głównie w ofercie ekonomicznej.

  • 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 …”. Wartościowi użytkownicy (persony) są definiowani na przykład:

    • na podstawie ankiet i rozmów z użytkownikami,

    • w wyniku obserwacji ich interakcji z systemem,

    • w trakcie rozmów z osobami, które mają z nimi bezpośredni kontakt (np. sprzedawcy),

    • na podstawie badań statystycznych.

 

W przeciwnym razie już na starcie pojawi się spore ryzyko, że User Story może dostarczyć coś, czego nikt nie chce. 

 

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 możliwych pomysłów na stos zwany backlogiem nie jest najlepszym pomysłem.Wyobraź sobie samochód, w którym jest założona sportowa, dynamiczna skrzynia 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 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. Wszystko co jest poza procesem, jest prawdopodobnie zbędne. Poniżej jest 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 rozwiązanie

Innym sposobem przedstawienia historyjek użytkowników jest User Story Map – czyli wizualizacja całego procesu, z perspektywy wszystkich 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.

Taką mapę przygotujesz choćby w arkuszu kalkulacyjnym. Tak właśnie powstała poniższa mapa.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Każda historyjka zamienia się z czasem w koszt poświęcony na jej wytworzenie i utrzymanie. W zamian za ten koszt powinna powstać mierzalna wartość. W przeciwnym razie będzie to zwykła strata z perspektywy biznesowej.

 

Pracując nad User Story zastanów się więc:

  • jaka jest skala problemu, który chcemy rozwiązać i 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, sklep meblowy:

  • Przeprowadzono ankietę, w wyniku której 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 będą pasowały do ich mieszkania. 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. Koszt inwestycji w budowanie tak złożonych algorytmów będzie niewspółmierny do zysków.

  • Warto skupić się na innych problemach, które przy niższych kosztach szybciej przełożą się na wyniki biznesowe.

 

Metodyczna, profesjonalna analiza

Chociaż User Story pisane są z perspektywy użytkowników systemu, to zdecydowanie nie polecam oddelegowania budowania backloga osobom bez odpowiedniego przygotowania. Taki backlog będzie 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 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.

 

O tym jak to zrobić piszemy dużo w mailingu poświęconemu mapowaniu historyjek użytkowników.

 

Artur Guła

 

Zapisz się na storymapping.pl 

 

 

Budujmy wspólnie lepsze produkty!

03 sierpnia 2021

User Story - przykład i zastosowanie

+48 523 68 98