Wokół metod zwin­nych nara­sta wie­le mitów, szcze­gól­nie tych o sku­tecz­no­ści w dużych pro­jek­tach. Dzisiaj kolej­ne kil­ka słów o popu­lar­nym narzę­dziu jakim jest tak zwa­ne ​„user sto­ry” czy­li histo­ryj­ka użyt­kow­ni­ka, o ich ewo­lu­cji i o tym, że mogą być przy­dat­ne i kiedy.

Co praw­da, jako źró­dło infor­ma­cji wolę doku­men­ty, ale bywa, że tym źró­dłem infor­ma­cji są jed­nak użyt­kow­ni­cy, bo doty­czy to pro­jek­to­wa­nia np. nowych por­ta­li biz­ne­so­wych. Tu nie­ste­ty nie ma ani ustaw z wzo­ra­mi doku­men­tów ani ​„dotych­cza­so­we­go papie­ro­we­go obie­gu doku­men­tów”. Bardzo podob­nie wyglą­da­ją start-up’y w obsza­rze ope­ra­cyj­nym. Podobnie wyglą­da ana­li­za i pro­jek­to­wa­nie sys­te­mów wspie­ra­ją­cych obsłu­gę klien­tów (CRM i podob­ne). Dlaczego? Bo tej sfe­ry nie regu­lu­ją ani prze­pi­sy ani żad­ne nor­my. Nie licząc ele­men­tów pra­wa cywil­ne­go, są cał­ko­wi­cie uznaniowe.

User Story

Historyjki użyt­kow­ni­ka, mają swój rodo­wód w EX (pro­gra­mo­wa­nie eks­tre­mal­ne) i są z regu­ły defi­nio­wa­ne tak:

In softwa­re deve­lop­ment and pro­duct mana­ge­ment, a user sto­ry is a descrip­tion con­si­sting of one or more sen­ten­ces in the eve­ry­day or busi­ness lan­gu­age of the end user or user of a sys­tem that cap­tu­res what a user does or needs to do as part of his or her job func­tion (źr. ang. wiki).

Scott Ambler pisze:

User sto­ries are one of the pri­ma­ry deve­lop­ment arti­facts for Scrum and Extreme Programming (XP) pro­ject teams. A user sto­ry is a very high-level defi­ni­tion of a requ­ire­ment, con­ta­ining just eno­ugh infor­ma­tion so that the deve­lo­pers can pro­du­ce a reaso­na­ble esti­ma­te of the effort to imple­ment it. ^?1?

Generalnie jest to opis w potocz­nym języ­ku, ten – z uwa­gi na nie­jed­no­znacz­ność – jako wyma­ga­nie, stwa­rza pro­ble­my. Podejmowane są pró­by for­ma­li­zo­wa­nia tych histo­ry­jek. Pisze o tym autor blo­ga QAgile (poda­jąc przy­kła­dy, pole­cam cały artykuł):

W podej­ściu agi­le takim jak Scrum wyma­ga­nia defi­niu­je­my na ogól w posta­ci User Story. Prosta for­ma, któ­ra ma adre­so­wać ocze­ki­wa­nia i potrze­by użyt­kow­ni­ków czę­sto zespo­łom przy­spa­rza dużo pro­ble­mów w imple­men­ta­cji.^?2?

Swego cza­su ja tak­że pisa­łem o efek­tach sto­so­wa­nia tej meto­dy z zbyt­nią ufno­ścią w jej skuteczność:

Niedawno po raz kolej­ny widzia­łem nega­tyw­ne skut­ki tego podej­ścia, tym razem był to wdra­ża­ny i zakoń­czo­ny poraż­ką (pro­jekt prze­rwa­no) obieg doku­men­tów, nie tyl­ko kosz­to­wych, więc posta­no­wi­łem do tam­te­go arty­ku­łu dodać coś jesz­cze: wyma­ga­nia zbie­ra­no tu z w posta­ci ​„user story”.[…]

Tak więc opi­so­we user sto­ry może być wyma­ga­niem biz­ne­so­wym, testem ale raczej nie spe­cy­fi­ka­cją tego co ma powstać. Bez ana­li­zy pozwa­la­ją­cej wyspe­cy­fi­ko­wać wyma­ga­nia dzie­dzi­no­we (logi­kę wewnętrz­ną) nie mamy szans na spraw­ne stwo­rze­nie opro­gra­mo­wa­nia wykra­cza­ją­ce­go poza pro­sty zestaw kar­to­tek i reje­strów.^?3?

User sto­ry to opis z per­spek­ty­wy użyt­kow­ni­ka. Najlepszą chy­ba meta­fo­rą będzie tu zna­na aneg­do­ta z opi­sy­wa­niem słonia:

Każdy z tych okrzy­ków to odręb­ne 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 opisów.

I tu wpa­da­my w efekt ?krę­ce­nia fil­mu?. Najczęściej tak zwa­na ana­li­za wyglą­da tak, że pra­cow­ni­cy ana­li­zo­wa­nej fir­my, w toku warsz­ta­tów lub wywia­dów, opo­wia­da­ją z jaki­mi to sytu­acja­mi mają do czy­nie­nia, co robią, kie­dy i jak, opi­su­jąc kon­kret­ne przy­pad­ki z jaki­mi mie­li do czy­nie­nia i to, jak sobie z nimi pora­dzi­li. Do tego docho­dzą przy­pad­ki, w któ­rych sobie sła­bo pora­dzi­li, przy­pad­ki tego jak sobie radzą z tym, że cze­goś nie rozu­mie­ją, a to wszyst­ko jest okra­szo­ne spo­so­ba­mi pra­cy wyni­ka­ją­cy­mi nie raz z nie­wie­dzy, nie­zna­jo­mo­ści pra­wa czy wewnętrz­nych regu­la­cji. Na domiar złe­go, nie raz moż­na się spo­tkać z przy­pad­ka­mi, w któ­rych opo­wia­da­ją­cy o swo­jej pra­cy wpla­ta ele­men­ty pozwa­la­ją­ce mu na dzia­ła­nia nie­po­żą­da­ne takie jak uprasz­cza­nie pro­ce­dur lub wręcz łama­nie pra­wa (np. swe­go cza­su pewien urzęd­nik na moich oczach w trak­cie warsz­ta­tów zgło­sił jako wyma­ga­nie wobec sys­te­mu obie­gu doku­men­tów, moż­li­wość pod­pi­sa­nia orze­cze­nia sędzie­go prze­ter­mi­no­wa­nym pod­pi­sem elek­tro­nicz­nym!).^?4?

Historyjki użyt­kow­ni­ka mają sens, jed­nak nie jako ​„kom­plet­ny opis wyma­gań na apli­ka­cję” (wczo­raj usły­sza­łem, że w pew­nej dużej insty­tu­cji zebra­no już ok. tysią­ca (!) takich histo­ry­jek i pro­ces ten nadal trwa). Mają jed­nak sens jako ​„sam­ple” do ana­li­zy. Przekazywanie takich histo­ry­jek bez­po­śred­nio deve­lo­pe­ro­wi jest ogrom­nym ryzy­kiem. Dlaczego? Historyjka, nawet w sfor­ma­li­zo­wa­nej for­mie, nie­sie tyl­ko subiek­tyw­ne ​„spoj­rze­nie z zewnątrz”, a pro­gra­mi­sta zaczy­na domy­ślać się i gdy­bać, nie­jed­no­krot­nie prze­kra­cza­jąc dozwo­lo­ne granice:

…?jako sprze­daw­ca, dosta­ję od klien­tów zamó­wie­nia, na pod­sta­wie któ­rych muszę wysta­wiać fak­tu­ry VAT?, do tego ana­li­tyk doda, np. po ana­li­zie otrzy­ma­nej par­tii doku­men­tów, struk­tu­rę zamó­wie­nia i fak­tu­ry VAT oraz ?algo­rytm? wyli­cze­nia podat­ków. Jeżeli pro­gra­mi­sta zaczy­na ?lepiej wie­dzieć? od zama­wia­ją­ce­go, for­su­jąc np. prost­szą imple­men­ta­cję, to zna­czy, że prze­kro­czył swo­je kom­pe­ten­cje, sam sobie ? jako deve­lo­pe­ro­wi ? robi krzyw­dę psu­jąc to opro­gra­mo­wa­nie bo klient i tak prę­dzej czy póź­niej na tych uprosz­cze­niach ?pole­gnie?.^?3? 

Bywa bar­dzo czę­sto, że pro­gra­mi­sta bez żad­ne­go opo­ru przyj­mu­je histo­ryj­kę: ​„ja jako sprze­daw­ca, chcę umie­ścić na fak­tu­rze towar, któ­re­go nie ma jesz­cze w maga­zy­nie, w celu zali­cze­nia sprze­da­ży w danym dniu” … (Komentarz zbędny…)

Czy to zna­czy, że nale­ży odejść cał­ko­wi­cie od tego narzę­dzia? Moim zda­niem nie. Wystarczy uznać , że ​„user sto­ry” to WYŁĄCZNIE opis z per­spek­ty­wy użyt­kow­ni­ka, swo­iste ​„jed­no spoj­rze­nie z setek możliwych”.

Swego cza­su opi­sa­łem tak­so­no­mię pojęć sto­so­wa­nych w ana­li­zie wymagań:

U szczy­tu tej hie­rar­chii mamy wyma­ga­nia biz­ne­so­we. Są to w zasa­dzie owe histo­ryj­ki użyt­kow­ni­ka. To wyra­żo­ne języ­kiem zama­wia­ją­ce­go, ocze­ki­wa­nia w sto­sun­ku do opro­gra­mo­wa­nia. Rolą ana­li­ty­ka jest takie prze­ana­li­zo­wa­nie i prze­two­rze­nie tych opi­sów, by dopro­wa­dzić do powsta­nia sfor­ma­li­zo­wa­ne­go opi­su (np. w posta­ci mode­li UML: przy­pad­ki uży­cia, model dzie­dzi­ny, ogra­ni­cze­nia, inne) czy­li do posta­ci spe­cy­fi­ka­cji usług apli­ka­cji i logi­ki (mecha­ni­zmu) dzia­ła­nia tej aplikacji.

Kolekcjonowanie wyma­gań biz­ne­so­wych w posta­ci np. user sto­ry, ma sens jako zbie­ra­nie ​„sam­pli”, przy­kła­do­wych sytu­acji. Na ich pod­sta­wie, w toku ana­li­zy, moż­na two­rzyć mode­le i testo­wać te histo­ryj­ki (sta­ją się sce­na­riu­sza­mi testo­wy­mi). Tu pole­cam mię­dzy inny­mi blog i książ­ki Scotta Amblera:

In this epi­so­de, Scott Ambler helps us to under­stand the power of using models and how to use models in an agi­le envi­ron­ment.^?5?

Wspominałem nie raz o nim i o jego książ­kach na tym blogu:

Co praw­da książ­ka ma 12 lat i trze­ba brać na to lek­ka popraw­kę, jed­nak jest to war­to­ścio­wa, nafa­sze­ro­wa­na dia­gra­ma­mi UML, książ­ka trak­tu­ją­ca o tym, że zwin­ność nie ozna­cza bała­ga­nu i pospo­li­te­go rusze­nia. Scott Ambler to kolej­ny auto­ry­tet w inży­nie­rii opro­gra­mo­wa­nia. I mimo, że niko­go nie ma sen­su mał­po­wać, na pew­no war­to się uczyć? ^?6?

Ostatnio popu­lar­ność zdo­by­wa podej­ście sfor­ma­li­zo­wa­ne do histo­ry­jek użyt­kow­ni­ka, bazu­ją­ce na kon­cep­cji Scott’a Amblera (mode­lo­wa­nie) i Rona Jeffries’a, zwo­len­ni­ka porząd­ko­wa­nia, nie tyl­ko tre­ści wywia­dów ;). Tu posłu­żę się ilu­stra­cja­mi z arty­ku­łu na stro­nie Visual Paradigm.

User sto­ry is one of the most impor­tant tool for agi­le deve­lop­ment. They are often used for iden­ti­fy­ing the featu­res of a sys­tem under deve­lo­ped. User sto­ries are well com­pa­ti­ble with the other agi­le softwa­re deve­lop­ment tech­ni­qu­es and methods, such as scrum and extre­me programming. […]

Concept of 3C’s

The 3C’s refer to the three cri­ti­cal aspects of good user sto­ries. The con­cept was sug­ge­sted by Ron Jeffries, the co-inven­tor of the user sto­ries prac­ti­ce. Nowadays, when we talk abo­ut user sto­ries, we usu­al­ly are refer­ring to the kind of user sto­ries that are com­po­sed of the­se three aspects:
Card – User sto­ries are writ­ten as cards. […]
Conversation – Requirements are found and re-fined thro­ugh a con­ti­nu­ous conver­sa­tions betwe­en custo­mers and deve­lop­ment team thro­ugho­ut the who­le softwa­re pro­ject. […]
Confirmation – or also known as Acceptance cri­te­ria of the user sto­ry. […]^?7?

W dużym skró­cie: histo­ryj­ki dzie­li­my na jed­nost­ko­we ele­men­tar­ne (nie­po­dziel­ne) opi­sy w posta­ci ​„kart”, zawie­ra­ją­cych opis tego cze­go zama­wia­ją­cy ocze­ku­je od apli­ka­cji, zapis uwag (kon­wer­sa­cja) doty­czą­cych kolej­nych dys­ku­sji z zama­wia­ją­cym na temat danej histo­ryj­ki to histo­ria usta­leń, opis ocze­ki­wa­ne­go uzy­ska­ne­go efek­tu czyn­no­ści opi­sa­nych w danej histo­ryj­ce potwier­dze­nie uzy­ska­nia ocze­ki­wa­ne­go efek­tu. Idąc zaś za wska­zów­ka­mi Amblera, imple­men­ta­cję poprze­dza­my pra­cą nad kon­cep­cją imple­men­ta­cji posłu­gu­jąc się mode­la­mi na dość wyso­kim pozio­mie abstrakcji.

Karta histo­ryj­ki to pro­sty zapis utrzy­ma­ny w kon­wen­cji ​„ja jako «aktor», chcę «nazwa czyn­no­ści» w celu «ocze­ki­wa­ny efekt». Osobiście w pro­jek­tach dopusz­czam bar­dziej ​„luź­ną” for­mę takiej histo­ryj­ki, jed­nak pil­nu­je co do zasa­dy, by doty­czy­ła wyłącz­nie jed­ne­go ​„uzy­ska­ne­go efek­tu koń­co­we­go”. Każda kar­ta ma uni­kal­ne ozna­cze­nie, jest bowiem uży­wa­na jako jed­no zada­nie, w bac­klo­gu i sprin­tach (kan­ban). W doku­men­ta­cji (wspo­mnia­ne narzę­dzie VP) user sto­ry wyglą­da to tak:

Historyjki mają swój cykl życia i dobrą prak­ty­ką jest reje­stro­wa­nie wszel­kich kolej­nych uzgod­nień w toku pracy:

Tak zapi­su­je­my ​„sło­wo­tok” zama­wia­ją­ce­go na temat jego wizji reali­za­cji danej usłu­gi apli­ka­cyj­nej. Analogicznie zapi­su­je­my opis ocze­ki­wa­ne­go efek­tu końcowego:

Do tego momen­tu mamy ​„kla­sycz­ne” zwin­ne pro­wa­dze­nie pro­jek­tu z jego wada­mi opi­sa­ny­mi powyżej.

Wymagania powinny być ​„spójne, kompletne i niesprzeczne”

Jak to osią­gnąć? Analityk zaczy­na zbie­rać te histo­ryj­ki i zaczy­na skła­dać z nich kom­plet­ny pro­ces biz­ne­so­wy. Stanowi on wery­fi­ka­tor, czy całość (zestaw takich histo­ry­jek) sta­no­wi jakąś spój­ną, kom­plet­ną i nie­sprzecz­ną logi­kę biz­ne­so­wą w ska­li całej fir­my. Zmorą pro­jek­tów są wyma­ga­nia odkry­wa­ne w toku wdro­że­nia, dla­te­go war­to poświę­cić czas na wery­fi­ka­cję pomy­słu na całość sys­te­mu i zwe­ry­fi­ko­wać spój­ność i kom­plet­ność tej cało­ści z pomo­cą utwo­rze­nia mode­lu każ­de­go całe­go procesu:

Warto mode­lo­wać pro­ces gdyż wte­dy widać, że nie zawsze praw­dą jest, że jed­na (każ­da) histo­ryj­ka jest odręb­nym przy­pad­kiem uży­cia. Przypadki uży­cia wypro­wa­dza się z ele­men­tar­nych aktyw­no­ści jeden do jed­ne­go, co z uza­sad­nie­niem opi­sy­wa­łem w arty­ku­le Transformacja…. Model pro­ce­su biz­ne­so­we­go daje kon­tekst, pozwa­la lepiej zro­zu­mieć ​„sens” cało­ści. Czy powyż­szy model pro­ce­su (nota­cja BPMN) z nanie­sio­ny­mi histo­ryj­ka­mi, nie przy­po­mi­na Wam wyni­ków bada­nia sło­nia? Tu słoń został przez ana­li­ty­ka odkry­ty: to pro­ces biz­ne­so­wy (jego model w nota­cji BPMN). Przypadkami uży­cia będą ele­men­tar­ne aktyw­no­ści w pro­ce­sie. Więcej na temat zwin­ne­go pro­wa­dze­nia pro­jek­tu z uży­ciem user sto­ry moż­na zna­leźć w tuto­ria­lu Agile hand­bo­ok.

Na zakończenie…

We are cal­led ?ana­ly­sts? for a reason! We don?t mere­ly hear sto­ries and convert them into ?requ­ire­ments?. Our inte­gra­ted value lies in going abo­ve and bey­ond the sto­ry and expan­ding bey­ond engen­de­ring deli­ve­ra­bles. We coale­sce cri­ti­cal thin­king and intel­lec­tu­al curio­si­ty to trans­form sto­ries into abs­tracts and to pro­po­se the needs as well as what the pro­blem real­ly is.^?1?

[2022 – 12-03] Niedawno zna­la­złem te pre­zen­ta­cję, polecam:

___

1. 1.

   Alami A. Requirement Elicitation: Stories Are Not Requirements. Modern Analyst. https://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​5​2​3​6​/​R​e​q​u​i​r​e​m​e​n​t​-​E​l​i​c​i​t​a​t​i​o​n​-​S​t​o​r​i​e​s​-​A​r​e​-​N​o​t​-​R​e​q​u​i​r​e​m​e​n​t​s​.​a​spx. Accessed May 9, 2019.
2. 2.

   Kaczor K. Najczęstsze błę­dy popeł­nia­ne przy pisa­niu User Story. QAgile. https://​www​.qagi​le​.pl/​s​c​r​u​m​/​n​a​j​c​z​e​s​t​s​z​e​-​b​l​e​d​y​-​p​o​p​e​l​n​i​a​n​e​-​p​i​s​a​n​i​u​-​u​s​e​r​-​s​t​o​ry/. Accessed May 9, 2019.
3. 3.

   Żeliński J. User sto­ry czy­li nic nie popra­wić a może nawet bar­dziej skom­pli­ko­wać. IT-Consulting. https://it-consulting.pl//2013/09/11/user-story-czyli-nic-nie-poprawic-a-moze-bardziej-skomplikowac/. Accessed May 9, 2019.
4. 4.

   Żeliński J. Warsztaty ana­li­tycz­ne ? czy­li malo­wa­nie tra­wy. IT-Consulting. https://it-consulting.pl//2014/12/21/warsztaty-analityczne-czyli-malowanie-trawy/. Accessed May 9, 2019.
5. 5.

   Ambler S. MBA084: Agile Modeling with Scott Ambler. Mastering Business Analysis. . Accessed May 9, 2019.
6. 6.

   Żeliński J. Agile Modeling. Effective Practices for Modeling and Documentation. IT-Consulting. https://it-consulting.pl//2015/05/27/agile-modeling-effective-practices-for-modeling-and-documentation/. Accessed May 9, 2019.
7. 7.

   Visual-Paradigm. User Story. Visual_paradigm. https://​www​.visu​al​-para​digm​.com/​l​e​a​r​n​i​n​g​/​h​a​n​d​b​o​o​k​s​/​a​g​i​l​e​-​h​a​n​d​b​o​o​k​/​u​s​e​r​-​s​t​o​r​y​.​jsp. Accessed May 9, 2019.