O user story pisałem nie raz od ponad dekady, i w zasadzie zawsze powodem jest to samo: kolejny ratowany projekt, gdzie powodem dramatu było stosowanie user story jako wymagań. Kiedy user story jest stosowane jako wymaganie? W zasadzie zawsze tam, gdzie pominięto etap analizy i projektowania. Jakie są skutki? Kilkukrotnie wyższa pracochłonność, czyli znacznie wyższe koszty i dłuższy termin dostarczenia oprogramowania. Niestety, nie raz, tak realizowane projekty kończą się wstrzymaniem prac zanim powstanie pełna funkcjonalność aplikacji, z powodu znacznego przekroczenia budżetu i terminu.
Co proponuję? To co proponuję wielu doświadczonych praktyków na świecie:
Proces MBSE powstawania systemu [zotpressInText item=”{5085975:FI9PGYD7}”](more…)
Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć [zotpressInText item=”{5085975:HC624KKJ},{5085975:3QENML5V},{5085975:B7SVMTNQ}”] napisał niedawno na swoim profilu LinkedIn:
“People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you?ve worked through a set of user stories? No. Not even close!” [“Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!”.]
Świat od dekad boryka się z jakością i skutecznością specyfikowania wymagań na oprogramowanie. OMG.org opublikowało standard o nazwie MDA (ang. Model Driven Architecture [zotpressInText item=”{5085975:UWH8D5UI}”]), który tak opisuje proces tworzenia oprogramowania:
CIM -> PIM -> PSM
Są to odpowiednio modele: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu działania (PIM: Platform-Independent Model, jest to model dziedziny systemu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego czasu szerzej opisałem zależności między tymi modelami [zotpressInText item=”{5085975:TBT7B5D2}”] (czytaj więcej o MDA).
CIM to model działania organizacji: procesy biznesowe i ich produkty. Z uwagi na to, że obecnie już nie rodzą się projekty jednorazowej informatyzacji całości organizacji, pojawia się potrzeba określenia zakresu projektu, bo nie jest już nim cała organizacja. Model PIM to udokumentowany mechanizm działania systemu (oprogramowania), logika jego działania. Nie ma tu mowy o tym w jakiej technologii powstanie, bo z zasady mamy ich wiele do wyboru, a wybór technologii zależy od wielu poza-funkcjonalnych ograniczeń i wymagań. Technologia jest (powinna być) konsekwencją wyboru wykonawcy i ten dopiero opracuje model PSM, który w praktyce jest tak zwaną Koncepcją Wdrożenia, można ją także udokumentować w notacji UML, ale na tym etapie powszechna praktyką jest jedynie zaprojektowanie środowiska, zestawienie go i praca od razu w kodzie.
Kluczowym problemem jest przejście z CIM na PIM, czyli jak udokumentować zakres projektu dostarczenia oprogramowania i przekształcić go na wymagania wobec tego oprogramowania?
CIM -> [zakres projektu] -> PIM -> PSM
W metodach zwanych zwinnymi, modele CIM i PIM są pomijane. Typowym zaś narzędziem “zbierania wymagań” są tak zwane historyjki użytkownika (user story). Problem w tym, że są one kluczowym ryzykiem projektów gdyż z reguły są niespójne i niekompletne jako wymagania. Specyfikacja wymagań powinna być: spójna, kompletna i niesprzeczna. Opisanie zakresu projektu historyjkami użytkownika, nie mając modelu procesów biznesowych całości (model CIM), jest pozbawieniem się narzędzia do weryfikacji kompletności, spójności i niesprzeczności takiej specyfikacji. Wszystkie wady (niekompletność, niespójność, sprzeczności) odkrywane są i usuwane (uzupełniane) dopiero na etapie wdrażania. Jest to proces “odkrywania wymagań w toku wdrożenia”.
Historyjki użytkownika jako lista potrzeb biznesowych? Owszem! Historyjki użytkownika jako wymagania dla developera? NIE! To tylko materiał dla projektanta, ponieważ bardzo często jedna i ta sama funkcja systemu realizuje wiele różnych historii użytkownika. Implementacja “per user story” prowadzi do bardzo kosztownych i nieefektywnych rozwiązań (Opisywałem to na blogu: wpis projekt Biblioteka, dwie historyjki użytkownika: chciałbym wypożyczyć książkę oraz chciałbym zwrócić książkę są realizowane jedną usługą aplikacji: Karta Wypożyczenia, która zawiera również pole Data zwrotu. Nadal spotykam programistów przekonujących, że powinny to być dwa osobne ekrany – dwa przypadki użycia, czytaj dwa razy więcej pracy kodera i dwa razy większy koszt).
Czy można sformalizować proces zbierania historyjek użytkownika?
User Story to jedno z najbardziej problematycznych narzędzi w metodach zwinnych. Najczęściej zalecana struktura tych “historyjek”, wraz z przykładami:
“Jako ?typ użytkownika? chcę osiągnąć ?cel?, aby ?jakiś powód?”.
Na przykład:
“Jako Administrator chcę otrzymywać wiadomość e-mail, gdy zostanie przesłany formularz kontaktowy, abym mógł na niego odpowiedzieć”
albo
”Jako użytkownik mam możliwość kliknięcia określonej lokalizacji na mapie”;
[zotpressInText item=”{5085975:B7K58W5A}”]
Tak spisywane wymagania stanowią ogromny problem z powodu nierównej gradacji, sprowadzanie ich do poziomu tak zwanych atomowych user story (drugi z powyższych przykładów) prowadzi do bardzo dużych liczb tych historyjek. Próba ich weryfikacji (walidacja user story) staje się co najmniej trudnym zadaniem. Jakakolwiek wycena oprogramowania na bazie takich historyjek to wróżenie z fusów (więc developerzy mocno zawyżają wyceny z uwagi na ryzyko utraty rentowności). Autorzy innego opracowania zauważają:
Rzeczywiście, przy około 800 US [User Story], hierarchia była raczej trudna do określenia, a obraz systemu podczas planowania był bardzo duży. Skalowalność jest więc zdecydowanie problemem w projektach zwinnych, w których US są słabymi artefaktami inżynierii wymagań. Zdecydował się on [autor] na wprowadzenie wzorca US: “Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zdefiniować hierarchię w postaci Celu, Zadania i Użytkownika, ale bez powiązania semantycznego.
[zotpressInText item=”{5085975:F6WU4MAH}”]
Znam projekt, w którym liczba przypadków użycia, w pewnym średniej tylko wielkości projekcie, szybko sięgnęła czterystu. Wycena na ich podstawie pokazała, że planowany koszt wielokrotnie przekracza planowany budżet. Ten projekt zarzucono, jednak wiele tak wycenionych projektów jest realizowanych, co daje obraz skali strat jakie przynoszą (zawyżony koszt to strata). Powyżsi autorzy piszą na zakończenie:
Przyszłe prace obejmują identyfikację luk reprezentacyjnych, które napotykają praktycy w modelowaniu US, oraz przegląd sposobów, w jakie nasze ramy i [metoda] GORE w ogóle mogłyby rozwiązać te problemy. Równolegle oceniana będzie również zdolność praktyków do stosowania proponowanych ram zamiast zwykłych szablonów. Obecnie trwają prace nad narzędziem CASE (Computer Aided Software Engineering), które zostanie wykorzystane do wsparcia eksperymentów.
[zotpressInText item=”{5085975:F6WU4MAH}”]
Nie znalazłem wyników dalszych prac, więc podzielę się wynikami swoich.
Gradacja User Story
Podstawowym problemem z user story jest, moim zdaniem, brak standardu pozwalającego na zdefiniowanie “atomowej historyjki użytkownika” czyli poziomu, poniżej którego nie dzielimy ich na mniejsze. Jako audytor wielu dokumentacji (często w roli biegłego) zauważyłem, że historyjki użytkownika są doprowadzane do poziomu pojedynczych kroków scenariuszy przypadków użycia. Często też historyjki użytkownika utożsamiane są z przypadkami użycia (UML) i tak modelowane, co jest poważnym błędem. Np. powyższe:
“Jako użytkownik mam możliwość kliknięcia określonej lokalizacji na mapie”
Mogło by to być częścią scenariusza usługi (przypadek użycia UML), której celem jest Pokazanie Określonego Miejsca:
AKTOR inicjuje usługę Cel podróży
SYSTEM wyświetla formularz Adres
AKTOR wprowadza dane i naciska OK
SYSTEM wyświetla mapę z naniesioną lokalizacją
AKTOR klika określony punkt na mapie
SYSTEM powiększa obraz pokazując detale lokalizacji
Powyższa historyjka to jedynie punkt 5. tego scenariusza. Nie trudno dojść do wniosku, że samo kliknięcie na mapie to pozbawiona kontekstu i celu, wyrwana prosta czynność, i jej samodzielne istnienie w specyfikacji jako osobny byt, pozbawione jest sensu. Z perspektywy oprogramowania powstającego w określonym celu, uznanie tej historyjki za samodzielne wymaganie nie ma uzasadnienia. Uznanie jednak, że aplikacja służy między innymi do zapoznawania się określonymi miejscami w przestrzeni, a usługą tej aplikacji jest Pokazanie Określonego Miejsca jak najbardziej ma sens. Idąc za sugestią by historyjka użytkownika miała strukturę:
“Jako [Użytkownik], chcę [Zadanie], aby [Cel]”
zmusza do zastanowienia się czy klikanie na mapie jest celem, czy może jednak tym celem jest Pokazanie Określonego Miejsca, a klikanie jest elementem scenariusza (procedury) realizacji tego celu (pamiętamy, że przypadki użycia mają scenariusze, a te złożone są z sekwencji kolejnych kroków!).
Formalizacja User Story
Pojęcia Użytkownik, Zadanie, Cel, jako spójny zestaw pojęć odpowiadają definicji atomowego (elementarnego) procesu w notacji BPMN (dodatek C, Słownik , [zotpressInText item=”{5085975:QJUPRFNR}”]): Aktywność jest skojarzona z jej wykonawcą (pula, tor), tworzy produkt (data object). Biorąc pod uwagę fakt, że produkt ma tu określonego adresata i musi on stanowić sobą wartość dla tego adresata, mamy punkt wyznaczający granicę “dzielenia na części” tych historyjek. Nie będzie to “możliwość wstawienia z listy numeru NIP nabywcy” a “utworzenie faktury” (bo wartość ma dopiero poprawnie wystawiona faktura, a nie kliknięcie np. w pole NIP by wybrać kontrahenta).
Jak sformalizować historyjkę użytkownika? Podstawą formalizacji (i celem) jest opracowanie metody kontroli poprawności (walidacja). Popatrzmy jeszcze raz na szablon:
“Jako ?typ użytkownika? chcę osiągnąć ?cel?, aby ?jakiś powód?”.
Typ użytkownika to rola, celem jest produkt pracy, a powodem? Powodem jest zawsze to, że określona osoba oczekuje na efekt tej pracy (bez tego praca ta byłaby po prostu zbędna). Można więc wyobrazić sobie taki zapis:
Jako sprzedawca, chcę wystawić fakturę, klientowi.
Mamy tu:
rola: sprzedawca
cel: faktura
powód: oczekuje tego klient.
W tym miejscu widać pełną zgodność tej definicji z konstrukcją: aktywność, jej produkt, jego odbiorca. Innymi słowy analityczny model procesów biznesowych wykonany w notacji BPMN, to nic innego jak połączone w logiczne ciągi historyjki użytkownika.
Wyobraźmy sobie taką listę historyjek użytkownika, wykonaną wg. powyższego opisu:
Specyfikacja historyjek użytkownika
Niektóre narzędzia CASE, pozwalające na ich profilowanie, pozwalają przedstawić to także na modelu wymagań (co później umożliwia śladowanie, czyli kontrolę kompletności, spójności i niesprzeczności):
Diagram wymagań (notacja SysML)
Powyższe mogłoby być konsekwencją takiego modelu procesów:
Diagram procesu realizacji zamówienia (notacja BPMN).
Jak widać, model procesu daje pełny kontekst dla aktywności. Fakt, że proces to logiczny przepływ pracy, powoduje, że tworzenie modeli BPMN gwarantuje spójność, kompletność i niesprzeczność listy aktywności, ich produktów i ról.
Kilka słów o priorytetach
Często stosowane jest nadawanie wymaganiom priorytetów. Jeżeli mówimy o MBSE/MDD (odpowiednio: Model-Based System Engineering, Model-Driven Development), czyli podejściu w którym “model to wymaganie”, priorytety nie są stosowane, gdyż ma powstać to co zostało zaprojektowane (nikt nie nadaje priorytetów składnikom w recepturze na potrawę, nikt nie nadaje priorytetów na elementy składowe produkowanych przedmiotów).
Kiedy i jakim wymaganiom nadajemy priorytety? Ma to sens w przypadku wymagań biznesowych oraz w stosunku do przypadków użycia oprogramowania (przypominam, że Use Case w notacji UML to cecha systemu). Najczęściej spotykane systemu priorytetyzacji to trzystopniowa skala oraz tak zwana MoSCoW.
Trzystopniowa skala to:
niespełnienie tego wymagania pogorszy efektywność pracy
niespełnienie tego wymagania spowoduje ograniczenie funkcjonalności
niespełnienie tego wymagania uczyni system nieprzydatnym do celu w hakim powstaje.
Jak widać jedynka to najniższy priorytet. Z uwagi na zarządzanie projektem i wymaganiami, dodatkowo stosowane są, niezależnie od priorytetów, statusy wymagań: proponowane, zatwierdzone, odrzucone, odroczone, projektowane, wdrożone (mozna spotkań inne ale ich sens jest taki sam).
Skala MoSCoW to:
M – Must have – wymagania obligatoryjne, które system musi zapewniać. S – Should have – wymagania, które powinny znaleźć się w systemie. C – Could have – wymagania dodatkowe, które są pożądane, ale nie są niezbędne. W – Won’t have – wymagania, które nie zostaną wdrożone (ale mogą być wdrożone w przyszłości).
Jak widać skale te różnią sie podejściem. Generalnie celem jest zarządzanie wymaganiami. Skala trzystopniowa to świadome zarzadzanie zakresem projektu. Definicje są precyzyjne: nie ma żadnego problemu z nadawaniem priorytetów. Skala MoSCoW ma charakter uznaniowy: definicje tych czterech grup nie są precyzyjne: nie wiadomo jak odróżnić to co “powinno być” od tego co “jest pożądane”?
Podsumowanie
Stosowanie typowych historyjek użytkownika ma dwie kluczowe wady: 1. nie ma jednej metody zarządzania ich gradacją i strukturą, wielu autorów przywołuje własne, nieco się różniące metody standaryzacji, 2. ich drobiazgowość oraz brak metody kontroli spójności, prowadzą do szybko rosnącej ich liczby, w konsekwencji chaosu, szczególnie w średnich i większych projektach.
Powyżej widać, że modelowanie procesów biznesowych na podstawie zebranych przykładowych dokumentów (produkty pracy ludzi: dokumenty) i opracowanie na ich podstawie diagramu przypadków użycia, daje znacznie lepsze wyniki niż zbierane na warsztatach historyjki użytkownika. Same wymagania wyrażone jako historyjki użytkownika, nie dają żadnej szansy (brak metody) na kontrolę ich spójności, kompletności i niesprzeczności. Wymagania, jako konsekwencja poprawnie wykonanych modeli procesów biznesowych, z zasady są spójne, kompletne i niesprzeczne.
W przytoczonym tu przykładzie widać, że dwie aktywności (rejestracja zamówienia i kontrola jego statusu) realizowane są jako dostęp do zapisanego w systemie Zamówienia. Daje to jasną przesłankę do tego, że dwie historyjki użytkownika (dwie aktywności na modelu procesów) to dwa różne konteksty użycia tej samej usługi aplikacji: Zamówienia (czyli dostęp do ich tworzenia, aktualizacji i podglądu, to typowy przypadek użycia typu CRUD). Prawa dostępu do tego dokumentu modeluje się zaś regułami biznesowymi (nie pokazano ich na diagramach), np. “Klient ma wgląd tylko w Zamówienia, które sam złożył”.
Można uznać, że małe projekty, o małym ryzyku chaosu wywołanego brakiem modeli procesów, można realizowac “na skróty” czyli historyjki użytkownika i od razu model PSM (implementacja) z pominięciem CIM i PIM, jednak jest to poważne ryzyko już przy średnich projektach. Dlatego proces MDA:
{CIM -> [zakres projektu] -> PIM} -> PSM
wydaje się być znacznie efektywniejszy co pokazuje praktyka (w nawiasach klamrowych {} zakres pracy analityka-projektanta).
Zakres projektu to albo całe procesy biznesowe albo świadomie wybrane ich określone aktywności. Nie jest to także żaden “wodospad” (waterfall), bo analityczny model procesów biznesowych powstanie szybciej i taniej niż lista setek historyjek z pomocą wielodniowych warsztatów angażujących całe zespoły ludzi. Wygenerowane z modelu procesów biznesowych przypadki użycia, są z zasady spójne i kompletne, więc ich iteracyjne (kolejne) specyfikowanie (każdy projektujemy jako samodzielny mikroserwis) pozwala bez ryzyka oddawać je kolejno do implementacji, i jednocześnie dokumentować (uszczegóławiać) kolejne.
To sprawdzona w praktyce metoda wspierana przez wiele narzędzi CASE (wszystkie diagramy i ich przekształcenia pokazane w tym artykule powstały z użyciem Visual-Paradigm). Diagram przypadków użycia UML jest tu automatycznie generowany z modeli BPMN, wg poniższych zasad:
Po tej operacji wystarczy sprawdzić konteksty dokumentow i skonsolidować w jeden ewentualne nadmiarowe przypadki użycia. I na koniec:
“Jeśli nie masz modeli pojęciowych, brakuje Ci ważnego elementu układanki w projektowaniu rozwiązań, który jest niezwykle pomocny w dostrzeganiu i przekazywaniu ogólnego obrazu tych historyjek.”
Zostałem niedawno zapytany czy pomogę bo “mamy już ponad 150 przypadków użycia w dokumentacji…”. Myślę sobie, to niemożliwe, nie ma tak wielkich systemów (wycena okazała się w efekcie pięciokrotnie zawyżona tylko dlatego, że użyto metody zorientowanej na “user story”).
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.
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:
Proces biznesowy i struktura dokumentu Koszyk.
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):
Booch, G. (1994). Object-oriented Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.
Wokół metod zwinnych narasta wiele mitów, szczególnie tych o skuteczności w dużych projektach. Dzisiaj kolejne kilka słów o popularnym narzędziu jakim jest tak zwane “user story” czyli historyjka użytkownika, o ich ewolucji i o tym, że mogą być przydatne i kiedy.
Co prawda, jako źródło informacji wolę dokumenty, ale bywa, że tym źródłem informacji są jednak użytkownicy, bo dotyczy to projektowania np. nowych portali biznesowych. Tu niestety nie ma ani ustaw z wzorami dokumentów ani “dotychczasowego papierowego obiegu dokumentów”. Bardzo podobnie wyglądają start-up’y w obszarze operacyjnym. Podobnie wygląda analiza i projektowanie systemów wspierających obsługę klientów (CRM i podobne). Dlaczego? Bo tej sfery nie regulują ani przepisy ani żadne normy. Nie licząc elementów prawa cywilnego, są całkowicie uznaniowe.
User Story
Historyjki użytkownika, mają swój rodowód w EX (programowanie ekstremalne) i są z reguły definiowane tak:
In software development and product management, a user story is a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function (źr. ang. wiki).
Scott Ambler pisze:
User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. ?1?
Generalnie jest to opis w potocznym języku, ten – z uwagi na niejednoznaczność – jako wymaganie, stwarza problemy. Podejmowane są próby formalizowania tych historyjek. Pisze o tym autor bloga QAgile (podając przykłady, polecam cały artykuł):
W podejściu agile takim jak Scrum wymagania definiujemy na ogól w postaci User Story. Prosta forma, która ma adresować oczekiwania i potrzeby użytkowników często zespołom przysparza dużo problemów w implementacji.?2?
Swego czasu ja także pisałem o efektach stosowania tej metody z zbytnią ufnością w jej skuteczność:
Niedawno po raz kolejny widziałem negatywne skutki tego podejścia, tym razem był to wdrażany i zakończony porażką (projekt przerwano) obieg dokumentów, nie tylko kosztowych, więc postanowiłem do tamtego artykułu dodać coś jeszcze: wymagania zbierano tu z w postaci “user story”.[…]
Tak więc opisowe user story może być wymaganiem biznesowym, testem ale raczej nie specyfikacją tego co ma powstać. Bez analizy pozwalającej wyspecyfikować wymagania dziedzinowe (logikę wewnętrzną) nie mamy szans na sprawne stworzenie oprogramowania wykraczającego poza prosty zestaw kartotek i rejestrów.?3?
User story to opis z perspektywy użytkownika. Najlepszą chyba metaforą będzie tu znana anegdota z opisywaniem słonia:
Każdy z tych okrzyków to odrębne 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.
I tu wpadamy w efekt ?kręcenia filmu?. Najczęściej tak zwana analiza wygląda tak, że pracownicy analizowanej firmy, w toku warsztatów lub wywiadów, opowiadają z jakimi to sytuacjami mają do czynienia, co robią, kiedy i jak, opisując konkretne przypadki z jakimi mieli do czynienia i to, jak sobie z nimi poradzili. Do tego dochodzą przypadki, w których sobie słabo poradzili, przypadki tego jak sobie radzą z tym, że czegoś nie rozumieją, a to wszystko jest okraszone sposobami pracy wynikającymi nie raz z niewiedzy, nieznajomości prawa czy wewnętrznych regulacji. Na domiar złego, nie raz można się spotkać z przypadkami, w których opowiadający o swojej pracy wplata elementy pozwalające mu na działania niepożądane takie jak upraszczanie procedur lub wręcz łamanie prawa (np. swego czasu pewien urzędnik na moich oczach w trakcie warsztatów zgłosił jako wymaganie wobec systemu obiegu dokumentów, możliwość podpisania orzeczenia sędziego przeterminowanym podpisem elektronicznym!).?4?
Historyjki użytkownika mają sens, jednak nie jako “kompletny opis wymagań na aplikację” (wczoraj usłyszałem, że w pewnej dużej instytucji zebrano już ok. tysiąca (!) takich historyjek i proces ten nadal trwa). Mają jednak sens jako “sample” do analizy. Przekazywanie takich historyjek bezpośrednio developerowi jest ogromnym ryzykiem. Dlaczego? Historyjka, nawet w sformalizowanej formie, niesie tylko subiektywne “spojrzenie z zewnątrz”, a programista zaczyna domyślać się i gdybać, niejednokrotnie przekraczając dozwolone granice:
…?jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT?, do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz ?algorytm? wyliczenia podatków. Jeżeli programista zaczyna ?lepiej wiedzieć? od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie ? jako developerowi ? robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach ?polegnie?.?3?
Bywa bardzo często, że programista bez żadnego oporu przyjmuje historyjkę: “ja jako sprzedawca, chcę umieścić na fakturze towar, którego nie ma jeszcze w magazynie, w celu zaliczenia sprzedaży w danym dniu” … (Komentarz zbędny…)
Czy to znaczy, że należy odejść całkowicie od tego narzędzia? Moim zdaniem nie. Wystarczy uznać , że “user story” to WYŁĄCZNIE opis z perspektywy użytkownika, swoiste “jedno spojrzenie z setek możliwych”.
Swego czasu opisałem taksonomię pojęć stosowanych w analizie wymagań:
Taksonomia wymagań na system (źr. opracowanie własne Jarosław Żeliński)
U szczytu tej hierarchii mamy wymagania biznesowe. Są to w zasadzie owe historyjki użytkownika. To wyrażone językiem zamawiającego, oczekiwania w stosunku do oprogramowania. Rolą analityka jest takie przeanalizowanie i przetworzenie tych opisów, by doprowadzić do powstania sformalizowanego opisu (np. w postaci modeli UML: przypadki użycia, model dziedziny, ograniczenia, inne) czyli do postaci specyfikacji usług aplikacji i logiki (mechanizmu) działania tej aplikacji.
Kolekcjonowanie wymagań biznesowych w postaci np. user story, ma sens jako zbieranie “sampli”, przykładowych sytuacji. Na ich podstawie, w toku analizy, można tworzyć modele i testować te historyjki (stają się scenariuszami testowymi). Tu polecam między innymi blog i książki Scotta Amblera:
In this episode, Scott Ambler helps us to understand the power of using models and how to use models in an agile environment.?5?
Wspominałem nie raz o nim i o jego książkach na tym blogu:
Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć? ?6?
Ostatnio popularność zdobywa podejście sformalizowane do historyjek użytkownika, bazujące na koncepcji Scott’a Amblera (modelowanie) i Rona Jeffries’a, zwolennika porządkowania, nie tylko treści wywiadów ;). Tu posłużę się ilustracjami z artykułu na stronie Visual Paradigm.
User story is one of the most important tool for agile development. They are often used for identifying the features of a system under developed. User stories are well compatible with the other agile software development techniques and methods, such as scrum and extreme programming. […]
Concept of 3C’s
The 3C’s refer to the three critical aspects of good user stories. The concept was suggested by Ron Jeffries, the co-inventor of the user stories practice. Nowadays, when we talk about user stories, we usually are referring to the kind of user stories that are composed of these three aspects: Card – User stories are written as cards. […] Conversation – Requirements are found and re-fined through a continuous conversations between customers and development team throughout the whole software project. […] Confirmation – or also known as Acceptance criteria of the user story. […]?7?
W dużym skrócie: historyjki dzielimy na jednostkowe elementarne (niepodzielne) opisy w postaci “kart”, zawierających opis tego czego zamawiający oczekuje od aplikacji, zapis uwag (konwersacja) dotyczących kolejnych dyskusji z zamawiającym na temat danej historyjki to historia ustaleń, opis oczekiwanego uzyskanego efektu czynności opisanych w danej historyjce potwierdzenie uzyskania oczekiwanego efektu. Idąc zaś za wskazówkami Amblera, implementację poprzedzamy pracą nad koncepcją implementacji posługując się modelami na dość wysokim poziomie abstrakcji.
Karta historyjki to prosty zapis utrzymany w konwencji “ja jako <<aktor>>, chcę <<nazwa czynności>> w celu <<oczekiwany efekt>>. Osobiście w projektach dopuszczam bardziej “luźną” formę takiej historyjki, jednak pilnuje co do zasady, by dotyczyła wyłącznie jednego “uzyskanego efektu końcowego”. Każda karta ma unikalne oznaczenie, jest bowiem używana jako jedno zadanie, w backlogu i sprintach (kanban). W dokumentacji (wspomniane narzędzie VP) user story wygląda to tak:
Historyjki mają swój cykl życia i dobrą praktyką jest rejestrowanie wszelkich kolejnych uzgodnień w toku pracy:
Tak zapisujemy “słowotok” zamawiającego na temat jego wizji realizacji danej usługi aplikacyjnej. Analogicznie zapisujemy opis oczekiwanego efektu końcowego:
Do tego momentu mamy “klasyczne” zwinne prowadzenie projektu z jego wadami opisanymi powyżej.
Wymagania powinny być “spójne, kompletne i niesprzeczne”
Jak to osiągnąć? Analityk zaczyna zbierać te historyjki i zaczyna składać z nich kompletny proces biznesowy. Stanowi on weryfikator, czy całość (zestaw takich historyjek) stanowi jakąś spójną, kompletną i niesprzeczną logikę biznesową w skali całej firmy. Zmorą projektów są wymagania odkrywane w toku wdrożenia, dlatego warto poświęcić czas na weryfikację pomysłu na całość systemu i zweryfikować spójność i kompletność tej całości z pomocą utworzenia modelu każdego całego procesu:
Warto modelować proces gdyż wtedy widać, że nie zawsze prawdą jest, że jedna (każda) historyjka jest odrębnym przypadkiem użycia. Przypadki użycia wyprowadza się z elementarnych aktywności jeden do jednego, co z uzasadnieniem opisywałem w artykule Transformacja…. Model procesu biznesowego daje kontekst, pozwala lepiej zrozumieć “sens” całości. Czy powyższy model procesu (notacja BPMN) z naniesionymi historyjkami, nie przypomina Wam wyników badania słonia? Tu słoń został przez analityka odkryty: to proces biznesowy (jego model w notacji BPMN). Przypadkami użycia będą elementarne aktywności w procesie. Więcej na temat zwinnego prowadzenia projektu z użyciem user story można znaleźć w tutorialu Agile handbook.
Na zakończenie…
(źr. Martin Fowler, Analysis Patterns, 1997)
We are called ?analysts? for a reason! We don?t merely hear stories and convert them into ?requirements?. Our integrated value lies in going above and beyond the story and expanding beyond engendering deliverables. We coalesce critical thinking and intellectual curiosity to transform stories into abstracts and to propose the needs as well as what the problem really is.?1?
[2022-12-03] Niedawno znalazłem te prezentację, polecam:
Sprzedawca
4.1.3.1. Sprzedaż
unnamed
Sprzedawca
Magazynier
4.2.3.1. Wydanie towaru
unnamed
Magazynier
Klient, 
Pracownik BOK
4.3.3.1. Rejestracja Zamówień
4.3.3.2. Śledzenie Zamówień
unnamed
Pracownik BOK
unnamed
Klient
![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)
