
User Story i Story Mapping czyli jak podnieść koszty
Tytułowe User Story i Story Mapping miały (mają) być remedium na problemy z wymaganiami. Czy są nim? Słownik Języka polskiego:
rozwiązanie: ?projekt i realizacja założeń architektonicznych, konstrukcyjnych, plastycznych itp.?
Innymi słowy rozwiązanie to określone narzędzia pracy. W tym przypadku narzędziem jest aplikacja (oprogramowanie).
Nadal popularne wśród developerów user story, jako narzędzie opisu wymagań pokazało swoje wady, lekarstwem na nie ma (miało) być story mapping.
Kluczową wadą tego (użytkownik opisuje aplikację) podejścia jest założenie, że użytkownik ma racje (wie czego chce). Problem w tym, że nawet jeżeli użytkownika wie co robi, to mało realne jest by wiedział czego (jakie rozwiązanie) potrzebuje. Zauważają to nawet entuzjaści metod zwinnych:
Do czego User Story się nadają? Mówiąc krótko, do krótkoterminowego przechowywania wymagań ze zwróceniem szczególnej uwagi na dostarczaną wartość. Ponadto służą jako wstęp do dalszej dyskusji mającej na celu wypracowanie wspólnego zrozumienia zagadnienia i dalsze prace nad modelowaniem rozwiązania. (źr.: User Story – choć przydatne, nie zawsze optymalne)
Niewątpliwie są wstępem i chyba na tyle. Co do wspólnego zrozumienia osobiście mam wątpliwości, by przyszły użytkownik miał kompetencje do bycia projektantem rozwiązań. Gdyby je miał, po prostu by to rozwiązanie zaprojektował.
Swego czasu (2016) pisałem o user story:
Wszelkie metody zakładające, że użytkownik wie czego chce i jest najlepszym źródłem ??wymagań? bazują na zaufaniu dla tych opisów (źr. : User Story c.d. – Jarosław Żeliński IT-Consulting).
Z tym zaufaniem jest jednak problem, bo użytkownik bardzo często ma konflikt interesu ze sponsorem projektu: nikt rozsądny nie buduje więzienia na podstawie pomysłów i zaleceń przyszłych więźniów. Czy to krzywdząca analogia? Nie sądzę: sklep internetowy nie chce być oszukany przez kupujących, system rejestracji czasu pracy też nie powinien dać się oszukać, system zarządzania przepływem pracy nie powinien być podatny na symulację pracy, itp. itd.
Jako inżynierowi, przyświeca mi raczej myśl przypisywania Henry’emu Fordowi (producent samochodów marki Ford):
„Gdybym na początku swojej kariery, jako przedsiębiorca, zapytał klientów, czego chcą, wszyscy byliby zgodni: chcemy szybszych koni. Więc ich nie pytałem.”
I uważam, że jest w tym wiele racji. Idea powyższego cytatu zasadza sie na tym, że ludzie chcą szybkiej i wygodniej podróżować, i to powinno być ich „wymaganiem”. pozwolić im powiedzieć „Jako kowboj, chcę szybszego i wygodniejszego konia, bym mógł lepiej wypasać stado”, to nic innego jak pozwolić mu (userowi) projektować rozwiązanie. I dokładnie na to nie przystał H.Ford. Z perspektywy czasu widać, że miał rację.
User story „po polsku” brzmi: ?Jako <kto?> chcę <co?>, po to aby <po co?>?
I tu pojawia się idea podejścia inżynierskiego MBSE (Model Based System Engineering): nie pozwalamy użytkownikowi powiedzieć <co> chce. Bo to jest nie jest jego kompetencja (zapewne będzie chciał szybszego konia). Projekty oparte na user story są często komentowane: „Dostaliśmy dokładnie to co chcieliśmy, a nie to co jest nam potrzebne”. Inżynierskie „user story” to raczej: „Jako <kto?> chce uzyskać <po co>”, czyli pozwolimy powiedzieć: „Jako kowboj, chcę lepiej wypasać stado”.
Lekarstwem na user story ma być story mapping. Jeden z autorów bloga na ten temat podaje przykład:
W wielkim skrócie jest to mapowanie User Stories (lub opcjonalnie wymagań w innej formie) na kroki procesu. Musimy zatem określić proces, jego poszczególne kroki i przypisać im określone Historyjki Użytkownika.

Schemat Story Map (źr.: Story mapping – nieco szersze spojrzenie – Analiza Biznesowa, dostęp 2020.12.14)
Zamawianie Produktu to proces biznesowy, nad tą linią jest opis procesu, pod nią historyjki użytkownika, uszeregowane wg. kolejności wdrożenia.
W tym momencie przytoczę diagram z artkułu jaki napisałem trzy lata temu:

Po lewej strony są konteksty użytkownika (namiastka user story), po prawej rozwiązanie. Czy widać problem? User story to kontekst i perspektywa użytkownika, jego intuicja („wie” co chce mieć). „Oddany sprawie i klientowi developer” jest w stanie przygotować sześć narzędzi pracy (opcji w aplikacji) i to na koszt zamawiającego! Dobry analityk projektant poświęci czas na zrozumienie i zaprojektuje młotek (to dlatego kod aplikacji wykonanych zwinnie potrafi być o rząd wielkości bardziej złożony niż projekty aplikacji zbudowane w oparciu o analizę i modele, a to znaczy, że zwinne metody tu dadzą produkt 10-ktotnie droższy po dziesięciokrotnie dłuższym czasie!).
Jak inaczej? Posłużę się przykładem cytowanego wyżej autora piszącego o story mapping’u.
Proces biznesowy, zgodnie z definicją, to aktywność wieńczona produktem. Tym produktem jest określony, mający wartość biznesową, dokument (zestaw danych, formularz). Tak więc „analityczna” wersja wyżej prezentowanego diagramu Schemat story map, wyglądała by tak:

Operujemy dokumentem Oferta (lista produktów, w tym opisy i ceny), Koszyk (kolekcja wybranych produktów, osobny dokument), Zamówienie (kolekcja produktów uzupełniona danymi nabywcy, adresem dostawy, formą płatności), Zlecenie przelewu (zawiera dane dla banku, do wykonania ręcznie lub poprzez integrację z usługą płatności), List przewozowy (dane dla kuriera). Diagram zawiera przykładową strukturę jednego z tych dokumentów.
Dla wygody czytania powtórzę tu diagram zawierające user story:

- Wyszukiwanie produktu, to praca z dokumentem Oferta (wyszukiwanie poza MVP?),
- Zarządzanie koszykiem, to kompletowanie listy wyboru z oferty, dodanie nowej pozycji to kliknięcie na ofercie zaś usunięcie pozycji to kliknięcie «usuń” w koszyku, to ta sama praca,
- Konfiguracja dostawy to po prostu wypełnienie Zamówienia (ten formularz zawiera wszelkie dane i do opłatności i dostawy),
- Płatność to formularz przelewu,
- Potwierdzenie zamówienia? Nie wiem co autor ma tu na myśli (można rozwijać ten proces o komunikację email z zamawiającym, nie ma jednak takiej potrzeby), jeżeli ktoś dokona przelewu to de facto autoryzuje to zamówienie, owszem można wysłać mailem dane do przelewu i link do aktywnego formularza Zamówienia (będzie zachowany).
A teraz user story:
- wyświetlanie produktów to prezentacja Oferty,
- nie wiem czym się różni wyszukiwanie od filtrowania, jednak wariantowa prezentacja Oferty to cały czas praca z Ofertą, sortowanie także,
- zarządzanie koszykiem to trywialna praca z formularzem Koszyk, nie rozumiem sensu tego podziału (patrz przykład z młotkiem),
- konfiguracja dostawy to dane na formularzu Zamówienie, czy na prawdę ma on powstawać w kawałkach? I tak do niczego nie posłuży jeżeli nie bezie kompletny,
- płatności są albo na stronie, albo poza stroną, czyli samodzielnie,
- nie wiem jak i po co można rozdzielić wypełnianie Zamówienia od prezentacji wypełnionego zamówienia.
Moje wrażenia:
- każdy proces to praca i jej efekt w postaci poprawnie wypełnionego formularza
- rozbijanie opisu na user story, które tak na prawde jest albo kolejnym kontekstem użytkownika, albo wręcz wypełnianiem konkretnej części formularza (np. wprowadzanie adres, a może be tego???) nie ma większego sensu.
Co obserwuję na rynku? Nie tak dawno miałem w ręku wycenę pewnej aplikacji opracowaną przez pewnego developera: najpierw „story map” (ok. 60 user story!) potem wycena na ok. 300 tys. zł. problem w tym, że aplikacja (dostali projekt ode mnie) miała 6 (sześć!) formularzy po maks. 20 pól każdy, na moje pytanie skąd u nich tyle user story (bo w wycenie podali koszt za user story) nie odezwali się do do dzisiaj.
Tak więc user story, zastosowane w opisany wyżej sposób, nie wnoszą żadnej wartości do projektu a komplikują postrzeganie zakresu. Analiza i opracowanie sformalizowanego modelu procesu będą zawsze prostsze jako diagram. Specyfikacja aplikacji oparta na formularzach i ich logice jest znacznie wygodniejsza, bo zamawiający wie co dostanie, a developer ma precyzyjną informację i nie ma możliwości zawyżania ceny. Pomijam, że user story to niestety tylko wyobrażenia zamawiającego, które potraktowane bezkrytycznie jako wymagania, zaowocują jedynie „szybszymi końmi” a nie samochodem. Dlatego User Story to dobry pomysł na zebranie potrzeb językiem zamawiającego i bardzo zły jako bezpośrednia metoda specyfikowania wymagań wobec systemu. (Patrz: https://it-consulting.pl/czym-pracuje-czyli-visual-paradigm/#Specyfikacja-potrzeb – User-Story)
Na koniec na poprawę humoru system oczami zamawiającego (po lewej) i oczami projektanta ( po prawej):
![Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]](https://it-consulting.pl/wp-content/uploads/2022/05/image-14.png)

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.