Historie użytkownika w Scrumie: Wszystko, co musisz wiedzieć

Cel jest jasny: chcesz opracować produkt, który zapewni klientom wysoką wartość dodaną. Chcesz osiągnąć wynik, z którego zadowoleni będą członkowie zespołu i interesariusze. Ale jak osiągnąć ten cel? Jak możesz spełnić wszystkie wymagania produktu w małych, dokładnych krokach? 

W Agile historie użytkowników okazały się skutecznym narzędziem do tego celu. Prowadzą Cię krok po kroku od pierwszego pomysłu do produktu gotowego do sprzedaży. Pokażę ci, czym są historie użytkowników, jak je tworzyć i jak możesz z nich skorzystać.

Definicja historyjek użytkownika w Agile opisuje wymagania produktu z punktu widzenia użytkownika. Innymi słowy, historyjki użytkownika mówią Ci, jakie cechy i funkcje powinien mieć produkt. Sprawia to, że są one głównym narzędziem do omawiania i walidacji potrzeb użytkowników oraz pracy nad ich wdrożeniem przy wspólnym zrozumieniu. 

Historyjki użytkownika zapewniają uniwersalny język, który członkowie zespołu, interesariusze i klienci rozumieją i którym się posługują. W praktyce oznacza to, że możesz użyć historyjek użytkownika, aby rozwinąć zrozumienie produktu pożądanego przez klienta, który pozostawia niewiele miejsca na nieporozumienia. 

Kilka historyjek użytkownika razem tworzy przypadek użycia. Historie użytkowników mają swoje korzenie w Agile Software Development.

Historyjki użytkownika opisują wymagania i życzenia dotyczące wyniku projektu, który ma zostać utworzony z perspektywy klienta lub użytkownika. Historie użytkowników Agile mają tę podstawową strukturę:

WHO (rola), chce CO (cel/pragnienie) DLACZEGO (wartość dodana)?

Przyjrzyjmy się bliżej poszczególnym komponentom historyjek użytkownika:

KTO (UŻYTKOWNIK)

Wypełniasz symbol zastępczy WER swoim klientem lub typowym przedstawicielem grupy docelowej. To, jak szczegółowo opiszesz KTO w historyjce User Agile, zależy od samej historyjki użytkownika i postępu projektu. Dlatego bądź wystarczająco szczegółowy, aby stworzyć znaczącą historię użytkownika.

WHAT (FUNKCJA)

W tym miejscu umieszczasz życzenia użytkownika. Możesz zadać sobie pytanie, czego oczekuje lub potrzebuje użytkownik. Jeśli Twój produkt jest nadal we wczesnej fazie rozwoju, możesz sformułować założenia oparte na swoim doświadczeniu co do tego, jakich funkcji oczekuje użytkownik. Jeśli masz już podobny produkt na rynku, możesz również wyprowadzić pożądane funkcje z opinii na temat tego produktu.

DLACZEGO (WARTOŚĆ DODANA)

Dopiero wartość dodana pokazuje, dlaczego dana funkcja jest ważna dla użytkownika. Zatem PYTANIE DLACZEGO pozwala na uczciwą refleksję, jak dobrze znasz wymagania klienta. Ponieważ: Dodanie wymagania do User Story jest proste – na przykład dlatego, że klient wyraża takie życzenie. Ale dopiero, gdy zrozumiesz, dlaczego klient tego potrzebuje, masz kontekst do realizacji wymagania. Dopiero wtedy możesz zakwestionować, czy propozycja/życzenie klienta skutecznie zaspokaja jego rzeczywistą potrzebę – czy też istnieje inteligentniejszy sposób. Przyjrzyjmy się przykładowi: 

Klient chce pelerynę przeciwdeszczową do jazdy na rowerze. Możesz więc teraz dołączyć wymaganie “peleryna przeciwdeszczowa”. Możesz też zapytać klienta, dlaczego potrzebuje peleryny przeciwdeszczowej. Powiedzmy, że klient odpowie “Ponieważ nie chcę zmoknąć”. 

Oznacza to, że niekoniecznie musisz dostarczać pelerynę przeciwdeszczową. Możesz również dostarczyć rower ze zintegrowanym dachem. Najważniejsze jest to, aby potrzeba lub problem klienta został rozwiązany – czyli nie zmoknąć. Im lepiej rozumiesz „dlaczego”, tym lepiej możesz zaprojektować swoją User Story.

Czym są User Stories w Agile (przykład)?

Znasz już poszczególne elementy składające się na Agile User Stories. Przykładowa historia użytkownika Agile może wyglądać następująco: 

Jak KLIENT Chciałbym BEZPIECZNE HASŁO***,*** ABY DANE MOICH KLIENTÓW BYŁY CHRONIONE.

Oto “KLIENT” użytkownik, “BEZPIECZNE HASŁO” funkcja i “ABY DANE MOICH KLIENTÓW BYŁY CHRONIONE” wartość dodana. 

Kiedy pracujesz z historyjkami użytkownika w Scrumie, dodajesz do nich kryteria akceptacji. Kryteria akceptacji opisują wymagania techniczne, które historyjki użytkownika muszą spełnić w momencie akceptacji. Innymi słowy: Kryteria akceptacji to wymagania, których potrzebujesz, aby historyjka użytkownika tworzyła wartość.

Znaczenie historyjek użytkownika Agile w backlogu może być bardziej zróżnicowane. Ponieważ: W backlogach historyjki użytkownika mogą nie tylko opisywać wymagania, ale także reprezentować specjalny typ hierarchii. Istnieją 3 typy hierarchii:

Eposy: Epiki to szeroko zdefiniowane obszary funkcjonalne produktu, których konkretny zakres może być nadal niejasny.

Cechy: Funkcje to specyficzne cechy wydajności w epice.

Historie: Historie to techniczne historie użytkowników Agile i historie użytkowników w ramach funkcji.

Możesz wdrożyć te typy hierarchii w ramach sprintu. Tworzą one konkretną korzyść dla użytkownika. 

Aby napisać pomocne historyjki użytkownika w zwinnym zarządzaniu projektami, kluczowe są szczegółowe dyskusje ze wszystkimi interesariuszami. Powinny one zapewnić Ci kompleksowe zrozumienie grupy docelowej i produktu, który ma zostać stworzony. Na tej podstawie możesz na przykład stworzyć personę. 

Ponadto, tzw. Kryteria INVESTaby stworzyć przekonującą historię użytkownika:

Niezależny: Historyjka użytkownika powinna być niezależna od innych historyjek użytkownika. Oznacza to, że implementacja historyjki nie może zakładać, że inna historyjka została zaimplementowana wcześniej. Ma to tę zaletę, że w każdej chwili możesz ustalić priorytety historyjek użytkownika lub usunąć je z rejestru. 

Przyjrzyjmy się jeszcze raz przykładowi z rowerem. Powiedzmy, że zdecydowałeś się zainstalować mały daszek nad siodełkiem roweru zamiast peleryny przeciwdeszczowej, aby klient nie był już mokry. To byłaby historia użytkownika. Ale teraz zdajesz sobie sprawę, że najpierw musisz opracować bardziej stabilne siodełko, do którego można przymocować dach. To byłaby inna historia użytkownika. Obie historie opierają się na sobie nawzajem. To jest dokładnie to, czego powinieneś unikać.

Oczywiście czasami nie da się uniknąć sytuacji, w której musisz wykonać jedną historyjkę użytkownika przed inną. Zasadniczo jednak unikaj historyjek użytkownika, dla których najpierw musisz wdrożyć 20 innych historyjek użytkownika.

Do negocjacji: Pisanie User Stories może czasami zająć sporo czasu – dlatego nie powinny być one potem wykute w kamieniu. To znaczy: Właściciel produktu Interesariusze i deweloperzy powinni zawsze wspólnie omawiać i udoskonalać historię użytkownika. 

Cenne: Wynik historyjek użytkownika w zwinnym zarządzaniu projektami musi mieć wartość dodaną dla klienta.

Możliwe do oszacowania: Przekonująca historia użytkownika pozwala zespołowi programistów oszacować, ile wysiłku zajmie jej wdrożenie.

Mały: Historyjka użytkownika powinna być tak “mała”, aby można ją było zrealizować w jednym sprincie.

Testowalne: Historyjki użytkownika w Scrumie powinny być testowalne. Jest to jedyny sposób na sprawdzenie, czy rzeczywiście można je wdrożyć w praktyce.

Jeśli nie jesteś zaznajomiony z pisaniem historyjek użytkownika w Agile, może się wydawać, że to tylko dodatkowa praca. Jednak historie użytkowników zapewniają zespołom ważny kontekst dla ich zadań, dodatkowo wyjaśniając znaczenie każdego zadania.

Zasadniczo w ten sposób korzystasz z User Stories:

Koncentracja na użytkowniku: Historyjki użytkownika są jak zorientowana na problem lista rzeczy do zrobienia. Twój zespół może z nich korzystać, aby śledzić swoje zadania i dokładnie wiedzieć, jak zaspokoić potrzeby użytkowników.

Holistyczna współpraca: Historie użytkowników pokazują wszystkim zaangażowanym na pierwszy rzut oka, dokąd zmierzają sprawy. W ten sposób wszyscy mogą współpracować i wielokrotnie decydować, w jaki sposób użytkownik otrzyma szczególnie wysoką wartość dodaną. 

Kreatywne rozwiązania: Tworzenie historii użytkownika w zwinnym tworzeniu oprogramowania kreatywne wyniki . Ponieważ: zmuszają zespoły do krytycznego myślenia o najlepszym rozwiązaniu dla produktu końcowego.

Stałe sukcesy: Każda historia użytkownika to małe wyzwanie. Zespoły mogą więc świętować mały sukces po każdej historii. Motywuje to przez cały proces rozwoju.

User stories są ważnym narzędziem w pracy zwinnych zespołów. Pokazują one wielokrotnie i szczegółowo, dla kogo opracowujesz co i dlaczego. Pomaga to nie tylko stworzyć wysokiej jakości produkt dostosowany do grupy docelowej, ale także utrzymać motywację zespołu przez cały proces. 

Aby odnieść sukces na tym makropoziomie zwinnej pracy, Twoja organizacja jako całość musi myśleć i funkcjonować w sposób zwinny. Aby wesprzeć Ciebie i Twoją organizację w tym zakresie, współpracowaliśmy z uznanymi ekspertami, aby stworzyć Projekt Scagile zaprojektowany. Pokaże Ci to w różnych webinarach, jak prawidłowo podejść do zwinnej transformacji. Szkolenie jest bezpłatne. Zachęcamy do obejrzenia!

Jeśli potrzebujesz bardziej zróżnicowanych pytań do retrospektyw, zapoznaj się z naszym postem na ten temat: 54 świeże metody retrospektywne dla początkujących i profesjonalistów (między innymi Mario Kart Retro, Marathon Retro i Elon Musk Retro).

Jedną z najlepszych metod trwałego rozwijania zwinnego nastawienia u członków zespołu jest wdrożenie zwinnego Health Checku. Nasz darmowy zestaw konstrukcyjny Team-Health Check może pomóc Ci zadać właściwe pytania – po prostu kliknij i sprawdź.