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)
Dzień dobry,
Na początek zaznaczę, że nie jestem fanem “historyjek” (zwłaszcza w postaci nagminnie spotykanej, bo tu musiał bym przerwać zgadzając się ze stwierdzeniem “Tak więc user story nie wnoszą żadnej wartości do projektu a komplikują postrzeganie zakresu”) i nie zamierzam ich bronić??.to tak aby nie wywiązała się “dyskusja ideologiczna o wyższości Świąt Wielkanocnych nad Bożym Narodzeniem”. Raczej spiszę kilka spostrzeżeń?..myśli nie uczesanych .
W artykule zakłada się, że to “użytkownik” pisze historyjki (cyt. “?nie pozwalamy użytkownikowi powiedzieć chce. Bo to jest nie jest jego kompetencja” – przy okazji?.za dużo o jedno “jest”)?i wtedy faktycznie jest problem. Ten sam błąd da się jednak popełnić i bez “historyjek” pozwalając użytkownikowi mówić czego chce. Zdaje się jednak, że (teoretycznie) za “historyjki” nie odpowiada użytkownik a “Product Owner”, czyli przedstawiciel zamawiającego a to nie to samo (dyrektor więzienia a nie więzień)??
Przykład z koniem: “Jako kowboj, chcę szybszego i wygodniejszego konia, bym mógł lepiej wypasać stado”. Tak by powiedział “Użytkownik” kowboj, ale “Świadomy Product Owner” właściciel stada mógłby powiedzieć “Jako właściciel stada, chcę aby moi kowboje mieli szybszy i wygodniejszy środek transportu, by mogli lepiej wypasać moje stado”. Samo ?Jako kowboj, chcę lepiej wypasać stado? czy też “Jako właściciel stada, chcę aby moi kowboje lepiej wypasali moje stado” może być zbyt ogólnikowe i prowadzić do stwierdzeń “Jako , chcę żeby BYŁO LEPIEJ” (coś w stylu “Jako Miss World chciała bym , żeby był pokój na świecie” 🙂 ) i w ten sposób można udowodnić, że “historyjki” nic nie wnoszą?..tak, źle napisane historyjki z pewnością nic nie wnoszą?.tak samo jak źle wyartykułowane wymagania biznesowe, czy źle zamodelowany proces biznesowy i kroki w tym procesie (kroków w procesie też można namnożyć ponad miarę…..albo nawet samych procesów).
Źle napisana “historyjka” niewiele się różni od źle spisanego wymagania biznesowego czy źle zamodelowanego procesu biznesowego ?po prostu jest źle.
Kluczowe może być nie to czy pisze się “historyjki” czy wymagania biznesowe, modeluje proces itd.. tylko kto to robi, po co to robi i jak to robi (np. skąd czerpie informacje).
To, że historyjkami łatwo posłużyć się do nadmuchania kosztów to fakt?..ale sprawni “nadmuchiwacze” radzili sobie doskonale i przed “edżajlem”, “skramem” i “historyjkami”.
Problemem mogą nie być “historyjki” same w sobie tylko ich zdegradowanie do nic nie wnoszących sformułowań w stylu “Ja jako firma, chcę ergonomiczny system, żeby pracowało się lepiej” albo przegięcie w druga stronę i rozmnożenie ich celem nadmuchania kosztów oraz traktowanie “historyjek” jako materiał dla dewelopera bez wykonania właściwej analizy?..i tu właściwy wydaje się cytat. z przytoczonego artykułu (“User Story ? choć przydatne, nie zawsze optymalne”) : “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.”
Narzędzia nadają się do tego do czego się nadają a źle użyte mogą sporo namieszać?.tak jak młotek nadaje się do “mocowania nóg stołu” pod warunkiem, że to nie stół typu “by IKEA”, gdzie nogi się przykręca ;).
Pozdrawiam,
1. na mój stan wiedzy i doświadczenie z audytów, “historyjki użytkownika” to w praktyce jest jednak produkt użytkownika, zresztą tak to wygląda w cytowanym diagramie,
2. product owner (PO) nie jest osobą mówiącą biznesowi “jak ma żyć”, PO tworzy zakres projektu, jeżeli jednak jest członkiem zespołu developera, to ma potężnych konflikt interesu (tak: powinien reprezentować zamawiającego),
3. owszem PO to nie użytkownik,
4. myślę, że PO powinien być jednak analitykiem projektantem, trzecią stroną (tak to wygląda to w metodach MDE/MBSE)
5. nawet jeżeli tu i teraz ustalimy coś, to praktyka pokazuje, że user story “nie działa” ;).
Od lat obserwuję efekty prac developerów, w 100% tam, gdzie pominięto analizy procesów, lub wykonano je niepoprawnie, był dramat. Dobrze wykonana analiza procesów to w 100% pełny opis organizacji i w 100% kompletny kontekst każdej pracy, wystarczy już tylko pokazać (zakres projektu), które aktywności w procesach mają być wspierane usługami aplikacji. Dlatego uważam, że albo ktoś wie (odkryje), że zwrot książki to tylko dodanie daty zwrotu do Karty Wypożyczenia, albo ten projekt będzie dramatem kosztowym. Zwracam uwagę, że poprawnie wykonany model procesowy organizacji to kilka do kilkunastu diagramów na kartkach A4, a nie setki stron nieprzydatnych “detalicznych PSEUDO-algorytmów” 😉
Artykuł wartościowy, jednak nie można go odnosić do wszystkich user stories, a jedynie do tych złych. Uważam, że właśnie pracą analityka jest dotarcie do istoty potrzeby/problemu (np. 5 WHY) i właściwe spisanie user stories.
I zgodnie z przytoczonym zdaniem, US z założenia są właśnie podstawą do wypracowania rozwiązania z zespołem deweloperskim, bo ani klient ani analityk biznesowy, nie mają zazwyczaj dość wiedzy technicznej.
Przy okazji odniosę się do wybranych stwierdzeń 🙂
1. “dodanie nowej pozycji to kliknięcie na ofercie zaś usunięcie pozycji to kliknięcie ?usuń? w koszyku, to ta sama praca” – w dużym uproszczeniu oczywiście tak, ale w praktyce jest to praca frontendowca nad dwoma różnymi podstronami (widokami), a backendowca – na dwóch różnych modułach aplikacji.
2. “nie wiem czym się różni wyszukiwanie od filtrowania” – stoją za tym dwa zupełnie różne mechanizmy prezentacji danych. Filtrowanie to najczęściej dalsze zawężanie jakiejś ograniczonej listy (np. kategorii) produktu. Wyszukiwarka służy właśnie do tego wstępnego zawężenia (przed filtrowaniem) i może mieć dodatkowe reguły – np. po wpisaniu słowa “buty” wyświetlać produkty, które w nazwie mają też “szpilki” lub “mokasyny”.
3. “nie wiem jak i po co można rozdzielić wypełnianie Zamówienia od prezentacji wypełnionego zamówienia” – tu znowu mamy 2 oddzielne widoki – wprowadzania jakichś danych i podsumowania. Czyli 2 projekty UI i możliwość rozbicia tego na 2 mniejsze zadania dla frontendowców.
Wydaje mi się, że mimo opisania tego modelem i tak po przystąpieniu do realizacji developerzy mogą rozbić “przygotowanie zamówienia” na kilka mniejszych zadań, żeby optymalizować pracę zespołu np. robić je równolegle.
Może jakimś rozwiązaniem jest podejście hybrydowe – dobre user stories poprzedzone analizą procesu. Spotkałem się z tym w praktyce i całkiem dobrze to działało.
“I zgodnie z przytoczonym zdaniem, US z założenia są właśnie podstawą do wypracowania rozwiązania z zespołem deweloperskim, bo ani klient ani analityk biznesowy, nie mają zazwyczaj dość wiedzy technicznej.”
Analityk Biznesowy to osoba która ma przekazać wymagania. Pozostaje określenie ich formy: potrafi lub nie potrafi przekazać wymagania w postaci projektu (MDD/MBSE/MDA-PIM), bo pisarz prozą już coraz rzadziej się akceptuje.
W kwestii uwag:
1. nie rozumiem konieczności użycia dwóch podstron i dwóch aplikacji by dodać lub usunąć pozycję z koszyka zakupów.
2. zapewne znowu mamy nieporozumienie, filtrowanie i wyszukiwanie to wybór podzbioru danych, czyż nie?
3. nie widzę powodu robienia dwóch widoków do Zamówienia na etapie wprowadzania i potwietdzenia.
Obserwacja pracy developerów pozwala mi dostrzec, że wielu z nich https://it-consulting.pl/wp-admin/post.php?post=25723&action=editstosuje kuriozalne “obiektowe” architektury rodem z C/C++: głównie nadmiar dziedziczenia, skomplikowane maszyny stanowe i religijne przywiązanie z zapisu danych w bazach SQL/”3 postać normalna”, co mega komplikuje całość.
User story to tylko kontekt aktora, mój ulubiony przykład: “jako student chcę znaleźć autora książki” czyli nawet w prostym e-sklepie z książkami nie wymaga to absolutnie żadnej pracy, ale jednak wielu dopisuje takie US do kosztów. Młotek to proste narzędzie mające jedną usługą: uderza, ale zapewniam, że jestem w stanie napisać setki User Story do niego… co ABSOLUTNIE nie ma prawa podnieść kosztu jego wytworzenia.
I zgoda co do tego: user story to materiał dla analityka/projektanta, nigdy dla developera.