Tytułowe User Story i Story Mapping mia­ły (mają) być reme­dium na pro­ble­my z wyma­ga­nia­mi. Czy są nim? Słownik Języka polskiego: 

roz­wią­za­nie: ?pro­jekt i reali­za­cja zało­żeń archi­tek­to­nicz­nych, kon­struk­cyj­nych, pla­stycz­nych itp.?

Innymi sło­wy roz­wią­za­nie to okre­ślo­ne narzę­dzia pra­cy. W tym przy­pad­ku narzę­dziem jest apli­ka­cja (opro­gra­mo­wa­nie).

Nadal popu­lar­ne wśród deve­lo­pe­rów user sto­ry, jako narzę­dzie opi­su wyma­gań poka­za­ło swo­je wady, lekar­stwem na nie ma (mia­ło) być sto­ry mapping. 

Kluczową wadą tego (użyt­kow­nik opi­su­je apli­ka­cję) podej­ścia jest zało­że­nie, że użyt­kow­nik ma racje (wie cze­go chce). Problem w tym, że nawet jeże­li użyt­kow­ni­ka wie co robi, to mało real­ne jest by wie­dział cze­go (jakie roz­wią­za­nie) potrze­bu­je. Zauważają to nawet entu­zja­ści metod zwinnych:

Do cze­go User Story się nada­ją? Mówiąc krót­ko, do krót­ko­ter­mi­no­we­go prze­cho­wy­wa­nia wyma­gań ze zwró­ce­niem szcze­gól­nej uwa­gi na dostar­cza­ną war­tość. Ponadto słu­żą jako wstęp do dal­szej dys­ku­sji mają­cej na celu wypra­co­wa­nie wspól­ne­go zro­zu­mie­nia zagad­nie­nia i dal­sze pra­ce nad mode­lo­wa­niem roz­wią­za­nia. (źr.: User Story – choć przy­dat­ne, nie zawsze opty­mal­ne)

Niewątpliwie są wstę­pem i chy­ba na tyle. Co do wspól­ne­go zro­zu­mie­nia oso­bi­ście mam wąt­pli­wo­ści, by przy­szły użyt­kow­nik miał kom­pe­ten­cje do bycia pro­jek­tan­tem roz­wią­zań. Gdyby je miał, po pro­stu by to roz­wią­za­nie zaprojektował. 

Swego cza­su (2016) pisa­łem o user story:

Wszelkie meto­dy zakła­da­ją­ce, że użyt­kow­nik wie cze­go chce i jest naj­lep­szym źró­dłem ??wyma­gań? bazu­ją na zaufa­niu dla tych opi­sów (źr. : User Story c.d. – Jarosław Żeliński IT-Consulting).

Z tym zaufa­niem jest jed­nak pro­blem, bo użyt­kow­nik bar­dzo czę­sto ma kon­flikt inte­re­su ze spon­so­rem pro­jek­tu: nikt roz­sąd­ny nie budu­je wię­zie­nia na pod­sta­wie pomy­słów i zale­ceń przy­szłych więź­niów. Czy to krzyw­dzą­ca ana­lo­gia? Nie sądzę: sklep inter­ne­to­wy nie chce być oszu­ka­ny przez kupu­ją­cych, sys­tem reje­stra­cji cza­su pra­cy też nie powi­nien dać się oszu­kać, sys­tem zarzą­dza­nia prze­pły­wem pra­cy nie powi­nien być podat­ny na symu­la­cję pra­cy, itp. itd. 

Jako inży­nie­ro­wi, przy­świe­ca mi raczej myśl przy­pi­sy­wa­nia Henry’emu Fordowi (pro­du­cent samo­cho­dów mar­ki Ford):

„Gdybym na począt­ku swo­jej karie­ry, jako przed­się­bior­ca, zapy­tał klien­tów, cze­go chcą, wszy­scy byli­by zgod­ni: chce­my szyb­szych koni. Więc ich nie pytałem.”

I uwa­żam, że jest w tym wie­le racji. Idea powyż­sze­go cyta­tu zasa­dza sie na tym, że ludzie chcą szyb­kiej i wygod­niej podró­żo­wać, i to powin­no być ich ​„wyma­ga­niem”. pozwo­lić im powie­dzieć ​„Jako kow­boj, chcę szyb­sze­go i wygod­niej­sze­go konia, bym mógł lepiej wypa­sać sta­do”, to nic inne­go jak pozwo­lić mu (use­ro­wi) pro­jek­to­wać roz­wią­za­nie. I dokład­nie na to nie przy­stał H.Ford. Z per­spek­ty­wy cza­su widać, że miał rację.

User sto­ry ​„po pol­sku” brzmi: ?Jako <kto?> chcę <co?>, po to aby <po co?>?

I tu poja­wia się idea podej­ścia inży­nier­skie­go MBSE (Model Based System Engineering): nie pozwa­la­my użyt­kow­ni­ko­wi powie­dzieć <co> chce. Bo to jest nie jest jego kom­pe­ten­cja (zapew­ne będzie chciał szyb­sze­go konia). Projekty opar­te na user sto­ry są czę­sto komen­to­wa­ne: ​„Dostaliśmy dokład­nie to co chcie­li­śmy, a nie to co jest nam potrzeb­ne”. Inżynierskie ​„user sto­ry” to raczej: ​„Jako <kto?> chce uzy­skać <po co>”, czy­li pozwo­li­my powie­dzieć: ​„Jako kow­boj, chcę lepiej wypa­sać stado”.

Lekarstwem na user sto­ry ma być sto­ry map­ping. Jeden z auto­rów blo­ga na ten temat poda­je przykład:

W wiel­kim skró­cie jest to mapo­wa­nie User Stories (lub opcjo­nal­nie wyma­gań w innej for­mie) na kro­ki pro­ce­su. Musimy zatem okre­ślić pro­ces, jego poszcze­gól­ne kro­ki i przy­pi­sać im okre­ślo­ne Historyjki Użytkownika.

Schemat Story Map (źr.: Story map­ping – nie­co szer­sze spoj­rze­nie – Analiza Biznesowa, dostęp 2020.12.14)

Zamawianie Produktu to pro­ces biz­ne­so­wy, nad tą linią jest opis pro­ce­su, pod nią histo­ryj­ki użyt­kow­ni­ka, usze­re­go­wa­ne wg. kolej­no­ści wdrożenia.

W tym momen­cie przy­to­czę dia­gram z art­ku­łu jaki napi­sa­łem trzy lata temu:

Po lewej stro­ny są kon­tek­sty użyt­kow­ni­ka (namiast­ka user sto­ry), po pra­wej roz­wią­za­nie. Czy widać pro­blem? User sto­ry to kon­tekst i per­spek­ty­wa użyt­kow­ni­ka, jego intu­icja („wie” co chce mieć). ​„Oddany spra­wie i klien­to­wi deve­lo­per” jest w sta­nie przy­go­to­wać sześć narzę­dzi pra­cy (opcji w apli­ka­cji) i to na koszt zama­wia­ją­ce­go! Dobry ana­li­tyk pro­jek­tant poświę­ci czas na zro­zu­mie­nie i zapro­jek­tu­je mło­tek (to dla­te­go kod apli­ka­cji wyko­na­nych zwin­nie potra­fi być o rząd wiel­ko­ści bar­dziej zło­żo­ny niż pro­jek­ty apli­ka­cji zbu­do­wa­ne w opar­ciu o ana­li­zę i mode­le, a to zna­czy, że zwin­ne meto­dy tu dadzą pro­dukt 10-ktot­nie droż­szy po dzie­się­cio­krot­nie dłuż­szym czasie!).

Jak ina­czej? Posłużę się przy­kła­dem cyto­wa­ne­go wyżej auto­ra piszą­ce­go o sto­ry map­pin­g’u.

Proces biz­ne­so­wy, zgod­nie z defi­ni­cją, to aktyw­ność wień­czo­na pro­duk­tem. Tym pro­duk­tem jest okre­ślo­ny, mają­cy war­tość biz­ne­so­wą, doku­ment (zestaw danych, for­mu­larz). Tak więc ​„ana­li­tycz­na” wer­sja wyżej pre­zen­to­wa­ne­go dia­gra­mu Schemat sto­ry map, wyglą­da­ła by tak:

Operujemy doku­men­tem Oferta (lista pro­duk­tów, w tym opi­sy i ceny), Koszyk (kolek­cja wybra­nych pro­duk­tów, osob­ny doku­ment), Zamówienie (kolek­cja pro­duk­tów uzu­peł­nio­na dany­mi nabyw­cy, adre­sem dosta­wy, for­mą płat­no­ści), Zlecenie prze­le­wu (zawie­ra dane dla ban­ku, do wyko­na­nia ręcz­nie lub poprzez inte­gra­cję z usłu­gą płat­no­ści), List prze­wo­zo­wy (dane dla kurie­ra). Diagram zawie­ra przy­kła­do­wą struk­tu­rę jed­ne­go z tych dokumentów. 

Dla wygo­dy czy­ta­nia powtó­rzę tu dia­gram zawie­ra­ją­ce user story:

• Wyszukiwanie pro­duk­tu, to pra­ca z doku­men­tem Oferta (wyszu­ki­wa­nie poza MVP?),
• Zarządzanie koszy­kiem, to kom­ple­to­wa­nie listy wybo­ru z ofer­ty, doda­nie nowej pozy­cji to klik­nię­cie na ofer­cie zaś usu­nię­cie pozy­cji to klik­nię­cie «usuń” w koszy­ku, to ta sama praca,
• Konfiguracja dosta­wy to po pro­stu wypeł­nie­nie Zamówienia (ten for­mu­larz zawie­ra wszel­kie dane i do opłat­no­ści i dostawy),
• Płatność to for­mu­larz przelewu,
• Potwierdzenie zamó­wie­nia? Nie wiem co autor ma tu na myśli (moż­na roz­wi­jać ten pro­ces o komu­ni­ka­cję ema­il z zama­wia­ją­cym, nie ma jed­nak takiej potrze­by), jeże­li ktoś doko­na prze­le­wu to de fac­to auto­ry­zu­je to zamó­wie­nie, owszem moż­na wysłać mailem dane do prze­le­wu i link do aktyw­ne­go for­mu­la­rza Zamówienia (będzie zachowany).

A teraz user story:

• wyświe­tla­nie pro­duk­tów to pre­zen­ta­cja Oferty,
• nie wiem czym się róż­ni wyszu­ki­wa­nie od fil­tro­wa­nia, jed­nak warian­to­wa pre­zen­ta­cja Oferty to cały czas pra­ca z Ofertą, sor­to­wa­nie także,
• zarzą­dza­nie koszy­kiem to try­wial­na pra­ca z for­mu­la­rzem Koszyk, nie rozu­miem sen­su tego podzia­łu (patrz przy­kład z młotkiem),
• kon­fi­gu­ra­cja dosta­wy to dane na for­mu­la­rzu Zamówienie, czy na praw­dę ma on powsta­wać w kawał­kach? I tak do nicze­go nie posłu­ży jeże­li nie bez­ie kompletny, 
• płat­no­ści są albo na stro­nie, albo poza stro­ną, czy­li samodzielnie,
• nie wiem jak i po co moż­na roz­dzie­lić wypeł­nia­nie Zamówienia od pre­zen­ta­cji wypeł­nio­ne­go zamówienia. 

Moje wra­że­nia:

• każ­dy pro­ces to pra­ca i jej efekt w posta­ci popraw­nie wypeł­nio­ne­go formularza
• roz­bi­ja­nie opi­su na user sto­ry, któ­re tak na praw­de jest albo kolej­nym kon­tek­stem użyt­kow­ni­ka, albo wręcz wypeł­nia­niem kon­kret­nej czę­ści for­mu­la­rza (np. wpro­wa­dza­nie adres, a może be tego???) nie ma więk­sze­go sensu. 

Co obser­wu­ję na ryn­ku? Nie tak daw­no mia­łem w ręku wyce­nę pew­nej apli­ka­cji opra­co­wa­ną przez pew­ne­go deve­lo­pe­ra: naj­pierw ​„sto­ry map” (ok. 60 user sto­ry!) potem wyce­na na ok. 300 tys. zł. pro­blem w tym, że apli­ka­cja (dosta­li pro­jekt ode mnie) mia­ła 6 (sześć!) for­mu­la­rzy po maks. 20 pól każ­dy, na moje pyta­nie skąd u nich tyle user sto­ry (bo w wyce­nie poda­li koszt za user sto­ry) nie ode­zwa­li się do do dzisiaj.

Tak więc user sto­ry, zasto­so­wa­ne w opi­sa­ny wyżej spo­sób, nie wno­szą żad­nej war­to­ści do pro­jek­tu a kom­pli­ku­ją postrze­ga­nie zakre­su. Analiza i opra­co­wa­nie sfor­ma­li­zo­wa­ne­go mode­lu pro­ce­su będą zawsze prost­sze jako dia­gram. Specyfikacja apli­ka­cji opar­ta na for­mu­la­rzach i ich logi­ce jest znacz­nie wygod­niej­sza, bo zama­wia­ją­cy wie co dosta­nie, a deve­lo­per ma pre­cy­zyj­ną infor­ma­cję i nie ma moż­li­wo­ści zawy­ża­nia ceny. Pomijam, że user sto­ry to nie­ste­ty tyl­ko wyobra­że­nia zama­wia­ją­ce­go, któ­re potrak­to­wa­ne bez­kry­tycz­nie jako wyma­ga­nia, zaowo­cu­ją jedy­nie ​„szyb­szy­mi koń­mi” a nie samo­cho­dem. Dlatego User Story to dobry pomysł na zebra­nie potrzeb języ­kiem zama­wia­ją­ce­go i bar­dzo zły jako bez­po­śred­nia meto­da spe­cy­fi­ko­wa­nia wyma­gań wobec sys­te­mu. (Patrz: https://​it​-con​sul​ting​.pl/​c​z​y​m​-​p​r​a​c​u​j​e​-​c​z​y​l​i​-​v​i​s​u​a​l​-​p​a​r​a​d​i​g​m​/​#​S​p​e​c​y​f​i​k​a​c​j​a​-​p​o​t​r​zeb – User-Story)

Na koniec na popra­wę humo­ru sys­tem ocza­mi zama­wia­ją­ce­go (po lewej) i ocza­mi pro­jek­tan­ta ( po prawej):