O user sto­ry pisa­łem nie raz od ponad deka­dy, i w zasa­dzie zawsze powo­dem jest to samo: kolej­ny rato­wa­ny pro­jekt, gdzie powo­dem dra­ma­tu było sto­so­wa­nie user sto­ry jako wyma­gań. Kiedy user sto­ry jest sto­so­wa­ne jako wyma­ga­nie? W zasa­dzie zawsze tam, gdzie pomi­nię­to etap ana­li­zy i pro­jek­to­wa­nia. Jakie są skut­ki? Kilkukrotnie wyż­sza pra­co­chłon­ność, czy­li znacz­nie wyż­sze kosz­ty i dłuż­szy ter­min dostar­cze­nia opro­gra­mo­wa­nia. Niestety, nie raz, tak reali­zo­wa­ne pro­jek­ty koń­czą się wstrzy­ma­niem prac zanim powsta­nie peł­na funk­cjo­nal­ność apli­ka­cji, z powo­du znacz­ne­go prze­kro­cze­nia budże­tu i ter­mi­nu. Co jest przyczyną?

User Story

W 2010 roku pisałem:

A co robią fir­my pro­gra­mi­stycz­ne? Analityka i archi­tek­ta się pomi­ja jako zbęd­ny koszt, zaś nie­wie­dza zama­wia­ją­ce­go gra na korzyść wyko­naw­cy. Proponuję same­mu sobie odpo­wie­dzieć na pyta­nie jak pro­wa­dzić takie pro­jek­ty i pody­sku­to­wać nad potrze­bą pra­cy ana­li­ty­ka i archi­tek­ta. Wyobraźcie sobie Państwu remont swo­jej łazien­ki (albo co gor­sza budo­wę dom­ku jed­no­ro­dzin­ne­go), któ­ry zle­ca­cie od razu mura­rzom a to jak ma wyglą­dać efekt koń­co­wy opi­su­je­cie mura­rzo­wi słow­nie, ten spi­su­je to pro­zą w umo­wie. Efekt zoba­czy­cie dopie­ro po tym jak mura­rze skoń­czą i zapła­ci­cie im za roboczogodziny.

Source: User sto­ry – kło­po­ty – Jarosław Żeliński IT-Consulting

Jako auto­ra user sto­ry wska­zu­je się Ronalda E Jeffries’a . Pisze on tak:

Samo wyma­ga­nie jest prze­ka­zy­wa­ne od klien­ta do pro­gra­mi­stów poprzez roz­mo­wę: wymia­nę myśli, opi­nii i odczuć. Ta roz­mo­wa odby­wa się w cza­sie, szcze­gól­nie gdy histo­ryj­ka jest sza­co­wa­na (zwy­kle pod­czas pla­no­wa­nia wyda­nia), i ponow­nie na spo­tka­niu pla­no­wa­nia ite­ra­cji, gdy histo­ryj­ka jest zapla­no­wa­na do wdro­że­nia. Rozmowa jest w dużej mie­rze słow­na, ale może być uzu­peł­nio­na o doku­men­ty. Najlepszymi uzu­peł­nie­nia­mi są przy­kła­dy; naj­lep­sze przy­kła­dy są wyko­ny­wal­ne, Przykłady te nazy­wa­my potwierdzeniem.

Co do jako­ści i odpo­wie­dzial­no­ści pisze on:

Historyjki użyt­kow­ni­ka zapi­sy­wa­ne są na kart­kach. Karta nie zawie­ra wszyst­kich infor­ma­cji, któ­re skła­da­ją się na wyma­ga­nie. Zamiast tego, kar­ta ma tyl­ko tyle tek­stu, by ziden­ty­fi­ko­wać wyma­ga­nie i przy­po­mnieć wszyst­kim, czym jest histo­ria. Karta jest żeto­nem repre­zen­tu­ją­cym wyma­ga­nie. Jest uży­wa­na pod­czas pla­no­wa­nia. Notatki są na niej zapi­sy­wa­ne, odzwier­cie­dla­jąc prio­ry­tet i koszt. Często jest wrę­cza­na pro­gra­mi­stom, gdy histo­ria jest zapla­no­wa­na do wdro­że­nia, i odda­wa­na klien­to­wi, gdy histo­ria jest ukończona.

Wniosek nasu­wa sie jeden: 100% odpo­wie­dzial­no­ści za uzy­ska­ny efekt spa­da na Zamawiającego, któ­ry jest auto­rem tych histo­ry­jek. Z Uwagi na bała­gan i pro­ble­my z nimi, poja­wi­ły sie szyb­ko pró­by for­ma­li­za­cji tre­ści tych ​„kar­te­czek”:

Jako <rola> mogę <zdolność>, dzięki czemu <otrzymuję korzyść>
lub
Aby <otrzymać korzyść> jako <rola>, mogę <celować/chcieć>

Gdzie jako prze­śmiew­czy przy­kład takiej sfor­ma­li­zo­wa­nej histo­ryj­ki nawet wiki (https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​U​s​e​r​_​s​t​ory) poda­je:

Jako niezadowolony pracownik chcę wymazać bazę danych użytkowników, aby zaszkodzić firmie 

W sie­ci dość popu­lar­ny jest żart na temat skut­ków sto­so­wa­nia user sto­ry jako wyma­ga­nia do imple­men­ta­cji: (1) Jako kie­row­ca chcę móc skrę­cać w lewo by dotrzeć do celu, (2) Jako kie­row­ca chcę móc skrę­cać w pra­wo by dotrzeć do inne­go celu, (3) Jako kie­row­ca chcę móc jechać pro­sto do dotrzeć do pew­ne­go celu. W efek­cie, w tygo­dnio­wych odstę­pach cza­su, powsta­ły – każ­dy osob­nym kosz­tem – trzy modu­ły: do skrę­tu w pra­wo, w lewo i jaz­dy pro­sto. Jak się nie trud­no domy­śleć nale­ża­ło raczej nie­co dłu­żej pomy­śleć (etap pra­cy inży­nie­ra) i opra­co­wać jeden moduł zmia­ny kie­run­ku jaz­dy (kie­row­ni­ca).

Kilka lat po publi­ka­cji Ronalda E Jeffries’a podej­mo­wa­ne były nawet pró­by unau­ko­wie­nia histo­ry­jek użytkownika:

Inny przy­kład:

Powyższe podej­ście jest wspie­ra­ne przez nie­któ­re narzę­dzia CASE, tak­że Visual Paradigm. O tym jak takie podej­ście mon­stru­al­nie pod­no­si kosz­ty pro­jek­tu pisa­łem w arty­ku­le User Story i Story Mapping czy­li jak pod­nieść kosz­ty.

Niestety prak­ty­ka poka­zu­je, że poza sfor­ma­li­zo­wa­niem pra­co­chłon­no­ści dewe­lo­pe­ra, powyż­sze w niczym nie popra­wi­ło sku­tecz­no­ści tak poj­mo­wa­nych user sto­ry (patrz np.: WHY USER STORIES FAIL at: https://​www​.roman​pi​chler​.com/​b​l​o​g​/​u​s​e​r​-​s​t​o​r​i​e​s​-​f​a​i​l​u​re/ Copyright © Pichler Consulting). 

Czy User Story są z gruntu złe?

Generalnie same user sto­ry jako takie nie są złe, bo użyt­kow­nik, jako nie­pro­fe­sjo­na­li­sta w bran­ży inży­nie­rii opro­gra­mo­wa­nia, nie jest w sta­nie ina­czej opi­sać swo­ich potrzeb. Gdzie więc problem? 

Otóż przy­czy­ną pro­ble­mów jest uzna­nie, że user sto­ry to wyma­ga­nie, wobec opro­gra­mo­wa­nia, któ­re nale­ży bez­po­śred­nio zaimplementować. 

A efek­tyw­ne podej­ście pole­ga na uzna­niu, że:

User Story to opis pro­ble­mu do roz­wią­za­nia, a nie funk­cjo­nal­ność do implementacji!

Pojmowanie user sto­ry w agi­le wg. opi­su ich auto­ra naj­czę­ściej pro­wa­dzi do imple­men­to­wa­nia pro­ble­mów, a nie do ich roz­wią­zy­wa­nia. Rozwiązywanie pro­ble­mów to pra­ca inży­nie­ra. Implementacja tych roz­wią­zań to pra­ca dewe­lo­pe­ra (patrz arty­kuł: Software Engineer Vs. Programmer: What’s the Difference?):

Jak wyglą­da róż­ni­ca? Implementowanie kolej­nych user sto­ry jako odręb­nych ele­men­tów kodu, pro­wa­dzi do sytu­acji opi­sa­nej wyżej: do samo­cho­du mają­ce­go odręb­ne modu­ły do skrę­ca­nia w każ­dym kie­run­ku i jaz­dy pro­sto. Tak powsta­je mon­stru­al­ny, kosz­tow­ny kod aplikacji. 

Poniżej zilu­stro­wa­no to zja­wi­sko na przy­kła­dzie sys­te­mu dla biblioteki:

Mamy tu czte­ry user sto­ry: wypo­ży­cze­nie, zwrot, wery­fi­ka­cja sta­tu­su i nali­cze­nie kary. Typowy pro­ces agi­le zaowo­cu­je czte­re­ma odręb­ny­mi imple­men­ta­cja­mi. Biorąc pod uwa­gę fakt, że nadal zna­ko­mi­ta licz­ba dewe­lo­pe­rów sto­su­je archi­tek­tu­ry budo­wa­ne na jed­nej, cen­tral­nej rela­cyj­nej bazie danych, otrzy­mu­je­my efekt w posta­ci ogrom­nej ilo­ści kodu w ośmiu czę­ściach: czte­ry razy kod + zapy­ta­nie SQL do wie­lo­ta­bli­co­wej bazy danych.

Jeżeli jed­nak ​„wstrzy­ma­my się chwi­lę i pomy­śli­my” (pra­ca inży­nie­ra-pro­jek­tan­ta) to może­my dojść do efek­tyw­ne­go rozwiązania:

1. Projektujemy for­mu­larz Karta Wypożyczenia
2. Na for­mu­la­rzu Karta Wypożyczenia doda­je­my pole Data Zwrotu
3. Bez żad­nej dodat­ko­wej pra­cy użyt­kow­nik może spraw­dzić sta­tus książ­ki: obec­ność daty zwro­tu na Karcie Wypożyczenia (wyszu­ki­wa­nie nie jest osob­ną funkcjonalnością!) 
4. Na for­mu­la­rzu Karta Wypożyczenia doda­je­my pole Kara za prze­trzy­ma­nie: ten for­mu­larz plus Regulamin Wypożyczeń zawie­ra­ją wszyst­kie dane by nali­czyć tę karę.

Jeżeli dodat­ko­wo zre­zy­gnu­je­my z mono­li­tycz­nej rela­cyj­nej bazy danych na rzecz repo­zy­to­rium doku­men­to­we­go, to oka­że się że apli­ka­cja powsta­nie nie­mal­że ośmio­krot­nie mniej­szym nakła­dem pra­cy i znacz­nie szyb­ciej. Taka apli­ka­cja będzie tak­że znacz­nie tań­sza w utrzy­ma­niu i roz­wo­ju. Detaliczny pro­jekt apli­ka­cji zarzą­dza­ją­cej wypo­ży­cze­nia­mi opi­sa­łem w arty­ku­le Biblioteka.

Aby zilu­stro­wać powyż­szy pro­blem, poni­żej struk­tu­ra zapy­ta­nia SQL do rela­cyj­nej bazy danych mają­cej ok. 100 tabel (dla porów­na­nia typo­wy sys­tem ERP ma nawet 1500 rela­cyj­nie powią­za­nych tabel). Takie poje­dyn­cze zapy­ta­nie słu­ży to ​„wydo­by­cia” z tej bazy śred­nio zło­żo­ne­go doku­men­tu jakim jest np. Faktura czy paragon.

To dla­te­go ponad 20 lat temu opra­co­wa­no (i są na ryn­ku) nieSQLowe bazy danych zwa­ne NoSQL, w tym doku­men­to­we sys­te­my baz danych.

Podsumowanie

User Story, ale jako mate­riał uzu­peł­nia­ją­cy regu­la­mi­ny i doku­men­ty ope­ra­cyj­ne, otrzy­ma­ny od Zamawiającego opro­gra­mo­wa­nie jest bar­dzo dobrym mate­ria­łem dla inży­nie­ra, któ­ry zapro­jek­tu­je roz­wią­za­nie (czy­li mecha­nizm opi­su­ją­cy logi­kę dzia­ła­nia apli­ka­cji, patrz arty­kuł o ICONIX). User Story uży­te jako kolej­ne imple­men­to­wa­ne potrze­by użyt­kow­ni­ka pro­wa­dzi do znacz­nie więk­szej pra­co­chłon­no­ści, czy­li znacz­nie więk­sze­go kosz­tu całe­go rozwiązania. 

Pamiętajmy więc, że: 

User Story to opis pro­ble­mu do roz­wią­za­nia, a nie funk­cjo­nal­ność do implementacji!

Jestem wła­śnie na eta­pie koń­cze­nia pro­jek­to­wa­nia apli­ka­cji wspie­ra­ją­cej reali­za­cje pew­ne­go duże­go pro­gra­mu lojal­no­ścio­we­go. Poprzednie podej­ście moje­go klien­ta to zle­ce­nie tego dewe­lo­pe­ro­wi sto­su­ją­ce­mu zwin­ne meto­dy, wie­lo­let­nie pasmo kosz­tow­ne­go grze­ba­nia i roz­bu­do­wy­wa­nia apli­ka­cji o kolej­ne ​„potrze­by”. W efek­cie powsta­ły ogrom­ne ilo­ści kodu i baza danych, któ­rej obec­nie chy­ba już nikt rozu­mie (dostaw­ca odma­wia udzia­łu w migra­cji danych do nowej apli­ka­cji, brak doku­men­ta­cji powo­du­je, że help desk dostaw­cy od kil­ku mie­się­cy musi się kon­tak­to­wać z byłym pra­cow­ni­kiem). Aplikacja for­mal­nie nigdy nie zosta­ła ukoń­czo­na (przej­ście z eta­pu two­rze­nia do eta­pu utrzy­ma­nia i roz­wo­ju) i zapa­dła decy­zja o jej porzu­ce­niu i utwo­rze­niu nowej ale już meto­dą jak wyżej. 

Co cie­ka­we, zebra­ne spi­sa­ne user sto­ry („jako użyt­kow­nik chciał­bym móc .….”) , pogru­po­wa­ne na przy­pad­ki uży­cia (czy­li przy­po­rząd­ko­wa­ne do pozy­cji w menu apli­ka­cji) auto­ma­tycz­nie utwo­rzy­ły bar­dzo dobry pod­ręcz­nik użytkownika. 

Na zakoń­cze­nie pole­cam inte­re­su­ją­cy refe­rat na podob­ny temat:

Źródła