Dzisiaj o technice typowo agile’owej, używanej w projektach prowadzonych metodyką SCRUM. User Story Mapping (USM) to technika organizowania historii w backlogu wokół aktywności i zadań realizowanych przez użytkownika rozwijanego produktu informatycznego. Pozwala pracować ze zbiorem historii efektywniej niż z monolityczną listą. Daje możliwość ich priorytetyzacji, identyfikacji tzw. MVP, a także planowania wydań. Używana może być zarówno na etapie planowania produktu (budowania i rozwoju wizji), przeglądu i porządkowania już istniejącego backlogu, kontroli postępów w pracach nad produktem i planowania reżimu jego powstawania. Na czym dokładnie polega i czy jest jakieś jej odniesienie względem artefaktów analizy biznesowej bądź architektury? Czy można połączyć jej elementy z modelem analitycznym opisującym szerzej świat biznesowo-systemowy w organizacji?

Praca z Historiami Użytkownika

Historie użytkownika są podstawowym „artefaktem” opisującym wizję i wymagania względem produktu w SCRUM. Powstają na etapie niskiej świadomości co do szczegółów rozwiązania docelowego, ale wysokiej co do oczekiwań z perspektywy użytkownika (wymagają dalszego ich pogłębiania i skonkretyzowania). Taki jest bowiem charakter metodyk zwinnych: praca z wizją, ciągła praca nad pogłębianiem wiedzy o produkcie na podstawie wcześniej zidentyfikowanych założeń, uszczegóławianie i realizacja tylko tych tematów, które dadzą w danym momencie określoną stopę zwrotu (i w założeniu możliwość szybkiej zmiany kierunku działań) oraz nieustanna analiza wynikająca z dobieranych nowych historii (a przez to niestety także zaciąganie długów, korygowanie i nieustanny refaktoring, ale może jeszcze kiedyś o tym napiszę). Miejscem narodzin User Stories może być praca z klientem (przy wykorzystaniu metod design thinking, map ścieżek klienta, product value creation, itd).

Historie pisane są z perspektywy użytkownika (w formule JAKO… CHCĘ… ABY…), zawierają oprócz treści wymagania (CHCĘ) dodatkowo uzasadnienie dla historii (ABY) oraz beneficjenta (JAKO). Używając takiej formuły uzyskamy za każdym razem obraz produktu i jego cech z jednej perspektywy – użytkownika. Sukcesywna realizacja historii i tworzenie wynikających z nich części oprogramowania pozwala obserwować przyrost funkcjonalności użytecznej dla jego odbiorcy. Przynajmniej jest tak w założeniach tej metody, które jak wiadomo po odpowiedniej modyfikacji nie doprowadzą do oczekiwanego efektu.

Historie użytkownika łączone są w epiki, tematyczne zbiory wymagań, zebrane wg określonego kryterium – powstają w wyniku agregacji bądź dekompozycji dużego tematu na mniejsze. Historie często gromadzone w narzędziach typu JIRA stanowią moniolityczną listę. Z jednej strony narzędzie jest wsparciem (organizuje, porządkuje, pozwala zarządzać) z drugiej przeszkodą. Praca nad monolityczną listą historii staje się uciążliwa. Trzeba jakoś zorganizować backlog, aby móc wyobrazić sobie produkt. Ważna jest bowiem świadomość, z jakich aspektów produkt się składa, aby móc powiedzieć jaka część produktu została już stworzona, a jaka oczekuje na wdrożenie. Jednym z pomysłów jest zebranie grup historii w epiki, następnie wdrażanie całych „gotowych” epików i monitorowanie stopnia wykonania historii w obrębie epików. Ale co, jeśli naszym epikiem jest „Wyszukiwarka produktów” – czy wszystkie funkcje zaplanowane w obrębie wyszukiwarki muszą zostać dostarczone od razu, aby wyszukiwarka została wdrożona? Może istnieje część niezbędna i część opcjonalna. Tutaj pojawia się pojęcie MVP czyli minimalnego użytecznego produktu, które (niestety) czasem jest zaniedbywane. MVP również można próbować określać na poziomie epików (pionowo – ten zbiór epików i znajdujących się w nich historii stanowi minimalną wartość dla klientów) albo samych historii (ten zbiór historii stanowi minimalną wartość dla klientów). Jednak w przypadku identyfikowania ich na poziomie historii (co jest w mojej opinii lepszą metodą), nigdy nie dokończymy całego epiku aby go wdrożyć. Dzieje się tak dlatego, że MVP może obejmować wybrane zbiory historii z wielu epików (z wyszukiwarki, katalogu, koszyka itp). Jak więc sobie poradzić z ogarnięciem wizji naszego produktu, skoro: a) nie dostarczamy całych kompletnych epików, b) historie należące do MVP są rozproszone pomiędzy epikami? Możemy nałożyć kolejny filtr w JIRA. Ale znowu mamy monolityczną listę…

User Story Mapping

Ludzki mózg po pierwsze lubi obrazy, po drugie wszystko ujmuje dynamicznie, w ruchu. Aby móc zrozumieć i przetworzyć dane, najlepiej jest mu poradzić sobie z wzorem, obrazem, osią czasu, najtrudniej z długą monotonną listą. User Story Mapping to technika pracy z backlogiem produktu, która częściowo implementuje te założenia, pozbywa się długiej listy i wizualnie grupuje historie opisujące wizję względem produktu. Po pierwsze ubiera historię w oś czasu i „jakieś kroki” (o nich za chwilę). Po drugie pozwala na wizualne ich grupowanie. Jest przede wszystkim techniką facylitacji, może być też widokiem na żyjący w organizacji backlog. Ale po kolei.

Jak tworzymy User Story Map?

Aby zbudować User Story Map najpierw identyfikujemy główne aktywności realizowane przez użytkownika (użytkowników) w obrębie produktu. Aktywności nawiązują do sposobu korzystania z produktu bądź realizacji usługi z wykorzystaniem produktu – ujętego w czasie. Słowem kluczowym jest tu słowo produkt, oznacza ono bowiem konkretny soft – narzędzie, aplikację, rozwiązanie informatyczne, z którego korzysta użytkownik. USM opisywać będzie więc aspekt wytwarzanego oprogramowania a nie procesu biznesowego, w obrębie którego oprogramowanie będzie tworzone. Identyfikowane są aktywności, jednak metoda nie określa czym mają one być. Mogą być etapami realizacji usługi, bądź aspektami działania oprogramowania (np. krokami zakupu realizowanwgo za pomocą aplikacji mobilnej). Jak w innych technikach metod zwinnych, tak i tutaj wiele zasad z perspektywy inżynierii wymagań jest niedookreślonych (jest czymś na wzór „frameworka”, a przez to może być inaczej stosowane przez różne grupy użytkowników) i to korzystający z nich ma prawo sam zadecydować o zasadach. Trochę podobnie jest i tutaj. Po identyfikacji aktywności stanowiących szkielet aplikacji, aktywności te są dekomponowane do poziomu jaki uzna analityk/ product owner za stosowne. Są to najczęściej czynności (akcje) składowe realizowane przez użytkownika, pozwalające na wykonanie danej aktywności (kroku).

Aktywności i akcje w USM

Mając aktywności i akcje, ułożone w linii ich wykonywania (happy path), kolejnym etapem jest grupowanie historii użytkownika wokół kroku (bądź ich identyfikacja, choć osobiście uważam, że początkową identyfikację historii – cech funkcjonalnych oprogramowania – można dokonać innymi technikami, jak customer journey map i wynikający z niej product value creation). Historie układane są pionowo jedna pod drugą.

USM ze zidentyfikowanymi historiami użytkownika

Kolejnym etapem jest priorytetyzacja – ułożenie najważniejszych historii najwyżej, najmniej istotnych najniżej. Dalej z górnej części wyodrębniany jest zbiór historii kluczowych dla użytkownika – pozwalający w podstawowy sposób zrealizować usługę bądź skorzystać z produktu (najbardziej „chudo”, najprościej). To jest nasze MVP. Pozostałe historie będące niżej w pionie grupowane są na kolejne wydania, w których proponuje się ich dostarczanie. W trakcie prac projektowych historii może przybywać (aktualizuje się wówczas listy) bądź mogą one zmieniać ważność/ rangę.

User Story Map z podziałem historii na MVP i wydania

Pracując z tak zbudowanym product backlogiem mogę zarządzić zarówno zakresem, czasem jak i priorytetami.

Czy historie użytkownika wystarczają?

Doświadczenie analityka pracującego na pokładzie zespołu wytwórczego mówi, że same historie zwykle nie wystarczają do wytworzenia oprogramowania/ nietrywialnego rozwiązania informatycznego. Należy pogłębić je o aspekt analityczny, najlepiej model, czego tutaj nie będę udowadniał. Dodatkowo sama historia kieruje jedynie w określoną stronę, czytając ją nie wiadomo jednak czy została zrealizowana w pełni. Po czym możemy to poznać? Historie uzupełniane są o kryteria akceptacyjne, czyli zestaw stwierdzeń, które mówią co oznacza, że „jako użytkownik aplikacji mobilnej mogę wyszukać produkt…”. Znajdą się tam kwestie dotyczące kryteriów wyszukiwania, komunikatów jakie mają się pojawiać itp. Z perspektywy wymagań są to jednak nadal wyrażone słowem wymagania, a nie model.

Historia użytkownika z opisem w formule Jako/Chcę/Aby oraz listą kryteriów akcpetacyjnych

Historie uzupełniają również projekty ekranów, czy diagramy informujące jak zrealizować daną funkcję, jak zmapować dane, jak rozszerzyć strukturę tabel, aby spełnić wymaganie użytkownika.

Mimo, że w SCRUM technika User Story Mapping jest użyteczna i wspomaga analityka/ właściciela produktu w pracy, nie stanowi wszystkiego, co jest niezbędne do dokonania rzetelnej analizy biznesowo-systemowej.

Świat analizy biznesowo-systemowej nie zatrzymuje się jedynie na identyfikacji historii i ich porządkowaniu. Trzeba w oparciu o cel spójny z celami organizacji zaplanować optymalny proces biznesowy, zidentyfikować wymagania, zaplanować (a także opisać) struktury danych, zaprojektować logikę działania aplikacji, skoordynować jej działanie z całą infrastrukturą informatyczną firmy podczas podejmowania nowych historii i tworzenia kodu. W jaki sposób można mapować zidentyfikowane historie na model analityczny? Jak i w jakich miejscach będzie trzeba go rozszerzać, pracując sukcesywnie z wykorzystaniem USM? O tym przeczytasz w kolejnym artykule.