Wstęp

Zostałem nie­daw­no zapy­ta­ny czy pomo­gę bo ​„mamy już ponad 150 przy­pad­ków uży­cia w doku­men­ta­cji…”. Myślę sobie, to nie­moż­li­we, nie ma tak wiel­kich sys­te­mów (wyce­na oka­za­ła się w efek­cie pię­cio­krot­nie zawy­żo­na tyl­ko dla­te­go, że uży­to meto­dy zorien­to­wa­nej na ​„user story”). 

Tak więc user sto­ry 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 samochodem.

(źr.: User Story i Story Mapping czy­li jak pod­nieść kosz­ty)

Przypomniałem sobie tak­że, jak pra­wie 10 lat temu, w pew­nym pro­jek­cie, doty­czą­cym jedy­nie obie­gu doku­men­tów w pew­nej insty­tu­cji publicz­nej, dosta­łem doku­men­ta­cję gdzie przy­pad­ków uży­cia było nie­co ponad 400! Tu już nawet deve­lo­per odmó­wił współpracy… 

…Siedem lat temu pisałem: 

Analizy biz­ne­so­we wyma­ga­ją ode­rwa­nia się od tech­no­kra­cji, nie ma cze­goś takie­go jak dzie­siąt­ki przy­pad­ków uży­cia dla jed­nej fak­tu­ry, nie ma sys­te­mo­wych przy­pad­ków uży­cia (nawet w spe­cy­fi­ka­cji UML ich nie znaj­dzie­cie), są kom­plet­ne (dają­ce jako efekt przy­dat­ne pro­duk­ty) usłu­gi apli­ka­cyj­ne i korzy­sta­ją­cy z tych usług akto­rzy, w tym inne apli­ka­cje lub kom­po­nen­ty. Dokumentacje zawie­ra­ją­ce set­ki przy­pad­ków uży­cia to nie­po­ro­zu­mie­nie, tech­no­kra­tycz­ni zabój­cy pro­jek­tów. Warto się zasta­no­wić zanim powie­rzy­cie ana­li­zę i pro­jekt logi­ki sys­te­mu tech­no­kra­tycz­ne­mu deve­lo­pe­ro­wi? (źr.: Wzorzec CRUD dla przy­pad­ków uży­cia i mikro­ser­wi­sy).

Rok póź­niej:

Generalnie moż­na pod­su­mo­wać to tak: meto­dy wyce­ny bazu­ją­ce na sta­ty­sty­kach pocho­dzą­cych ze zre­ali­zo­wa­nych pro­jek­tów są opar­te na zało­że­niu, że wyce­nia­ny pro­jekt będzie reali­zo­wa­ny tymi samy­mi lub ana­lo­gicz­ny­mi meto­da­mi co samo z sie­bie jest zaprze­cze­niem postę­pu tech­nicz­ne­go i roz­wo­ju metod inży­nie­rii opro­gra­mo­wa­nia. Praktyka poka­zu­je, że wyce­ny tymi meto­da­mi są prak­tycz­nie pra­wie zawsze zawy­żo­ne a obsza­ry nowa­tor­skie moc­no nie­do­sza­co­wa­ne lub prze­sza­co­wa­ne (bo nowa funk­cjo­nal­ność z zasa­dy nie ma historii).

(źr.: Wymiarowanie opro­gra­mo­wa­nia)

Skąd sie bio­rą tak mon­stru­al­ne listy ​„histo­ry­jek użyt­kow­ni­ka” nazy­wa­nych potem ​„przy­pad­ka­mi uży­cia” i tak mon­stru­al­ne wyce­ny na począt­ku pro­jek­tu? Dzisiaj o kolej­nym wcie­le­niu powyż­szych metod: gherkin.

Gherkin

Nazwa wywo­dzi się z narzę­dzia Cucumber, to zaś opar­te jest na, się­ga­ją­cej koń­ca lat 90-tych i wskrze­szo­nej nie­daw­no jako ​„Ogórek”, idei Behaviour Driven Design (BDD) (patrz np.: http://​dan​north​.net/​i​n​t​r​o​d​u​c​i​n​g​-​b​dd/). Na jed­nej z wie­lu stron poświę­co­nej tej tech­ni­ce czytamy:

What is Gherkin? Gherkin is a lan­gu­age that deve­lo­pers use to defi­ne tests in Cucumber. Since this lan­gu­age uses pla­in English, it?s meant to descri­be use cases for a softwa­re sys­tem in a way that can be read and under­sto­od by almost anyone.This syn­tax pro­mo­tes beha­vior-dri­ven deve­lop­ment becau­se it allows deve­lo­pers, mana­gers, busi­ness ana­ly­sts and other par­ties invo­lved to under­stand the requ­ire­ments of the pro­ject and the life-cycle.The lan­gu­age makes it easy to cre­ate sim­ple docu­men­ta­tion of the code that?s being writ­ten. Gherkin also pro­vi­des scripts for test auto­ma­tion and sup­ports dozens of lan­gu­ages. (źr.: What Is Gherkin + How Do You Write Gherkin Tests?)

[Co to jest Gherkin? Gherkin to język, któ­re­go pro­gra­mi­ści uży­wa­ją do defi­nio­wa­nia testów w Cucumberze. Ponieważ język ten uży­wa pro­ste­go angiel­skie­go, jest on prze­zna­czo­ny do opi­sy­wa­nia przy­pad­ków uży­cia dla sys­te­mu opro­gra­mo­wa­nia w spo­sób, któ­ry może być odczy­ta­ny i zro­zu­mia­ny przez pra­wie każ­de­go. Składnia ta pro­mu­je roz­wój ste­ro­wa­ny zacho­wa­niem, ponie­waż pozwa­la pro­gra­mi­stom, mene­dże­rom, ana­li­ty­kom biz­ne­so­wym i innym zaan­ga­żo­wa­nym stro­nom zro­zu­mieć wyma­ga­nia pro­jek­tu i cyklu życia. Język ten uła­twia two­rze­nie pro­stej doku­men­ta­cji pisa­ne­go kodu. Gherkin dostar­cza rów­nież skryp­ty do auto­ma­ty­za­cji testów i obsłu­gu­je dzie­siąt­ki języków.]

Przykład na stro­nie opi­su­ją­cej samą technikę:

Generalnie są to dopre­cy­zo­wa­ne ​„user sto­ry” opar­te na szablonie: 

• Nazwa funk­cjo­nal­no­ści
• Kontekst
  • waru­nek początkowy
  • jeże­li (zaj­dzie)
  • to (efekt)

przy­kład 1 (źr.: https://​sup​port​.smart​be​ar​.com/​c​u​c​u​m​b​e​r​s​t​u​d​i​o​/​d​o​c​s​/​b​d​d​/​w​r​i​t​e​-​g​h​e​r​k​i​n​-​s​c​e​n​a​r​i​o​s​.​h​tml):

Ogólnie: (źr.: https://​mvwi​.co/​p​o​s​t​s​/​g​h​e​r​k​i​n​-​c​u​c​u​m​ber):

Scenario: Some determinable business situation
  Given some precondition
    And some other precondition
  When some action by the actor
    And some other action
    And yet another action
  Then some testable outcome is achieved
    And something else we can check happens too

Całość bazu­je na kon­kret­nych zacho­wa­niach użyt­kow­ni­ka rozu­mia­nych jako jego ​„cel biz­ne­so­wy” (a gene­ral­nie cel). Idea ta bazu­je na zało­że­niu, że każ­dy biz­ne­so­wy kon­tekst (histo­ryj­ka) to osob­na funk­cjo­nal­ność, wyma­ga­ją­ca jej imple­men­ta­cji i napi­sa­nia testu. Prowadzi to do efek­tu, w któ­rym kon­stru­owa­ny w cza­sie samo­chód miał­by np. trzy odręb­ne pod­ze­spo­ły: do skrę­tu w lewo, do skrę­tu w pra­wo, do jaz­dy pro­sto. Nie przy­pad­kiem tak reali­zo­wa­ne pro­jek­ty mają ogrom­ny nad­miar kodu, trud­ne­go do zarzą­dza­nia, jeże­li do tego doda­my ​„ubie­ra­nie” każ­de­go ele­men­tu w mikro­ser­wi­sy, będzie koszmar. 

Przypadek Użycia w notacji UML

Kluczowa defi­ni­cja w opi­sy­wa­nej meto­dzie brzmi:

A featu­re is a Use Case that descri­bes a spe­ci­fic func­tion of the softwa­re being tested. There are three parts to a Feature. [Cecha jest Przypadkiem Użycia, któ­ry opi­su­je kon­kret­ną funk­cję testo­wa­ne­go oprogramowania.]

(źr.: https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​C​u​c​u​m​b​e​r​_​(​s​o​f​t​w​are))

Jest ona nie­zgod­na z defi­ni­cją przy­pad­ku uży­cia w UML. Notacja UML ope­ru­je poję­ciem Przypadek Użycia (UC), defi­nio­wa­nym jako zacho­wa­nie się sys­te­mu, rozu­mia­ny jako usłu­ga apli­ka­cyj­na (usłu­gą apli­ka­cji jest co do zasa­dy np. gene­ro­wa­nie popraw­nej Faktury VAT a nie: ​„wsta­wia­nie nume­ru NIP z roz­wi­jal­nej listy pod­mio­tów”). UC to ​„zestaw [kon­tek­sto­wo powią­za­nych] zacho­wań mają­cych okre­ślo­ny cel. Po dru­gie UC nie repre­zen­tu­je (nie odno­si się do) kon­kret­nych ele­men­tów wewnętrz­nej struk­tu­ry (to nie jest model archi­tek­tu­ry sys­te­mu a opis sys­te­mu jako ​„czar­nej skrzyn­ki”): to abs­trak­cyj­ny model, umo­wa, WYMAGANIA wyra­żo­ne jako potrze­by. UC to dopie­ro mate­riał wej­ścio­wy na opra­co­wa­nie imple­men­ta­cji (a wcze­śniej archi­tek­tu­ry czy­li pro­jek­tu sys­te­mu). Innymi sło­wy zawar­tość hipo­te­tycz­ne­go głów­ne­go menu.

Powyżej frag­ment ory­gi­nal­nej spe­cy­fi­ka­cji UML oraz ilu­stra­cja UC i moż­li­wych kon­tek­stów pra­cy akto­ra. Łatwo sobie wyobra­zić, co będzie gdy poka­za­ne po lewej kon­tek­sty (cele) akto­ra potrak­tu­je­my jako osob­ne ele­men­ty do imple­men­ta­cji. Każdy przy­pa­dek uży­cia może mieć kil­ka alter­na­tyw­nych (kon­tek­sto­wych) sce­na­riu­szy jed­nak reali­zo­wa­nych z uży­ciem okre­ślo­nej archi­tek­tu­ry jego imple­men­ta­cji (patrz tak­że: Use Case 2.0 i Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny).

Analiza i projektowanie

To trud­na sztu­ka odkry­cia isto­ty rze­czy (epi­ste­mo­lo­gia). Wbrew pozo­rom nie da się tego pro­ce­su zal­go­ryt­mi­zo­wać czy spro­wa­dzić do listy kon­tro­l­nej. Uważam, że zro­zu­mie­nie (odkry­cie) mecha­ni­zmu dzia­ła­nia (orga­ni­za­cji, ludzi) i opi­sa­nie go (mode­lo­wa­nie), jako wyma­ga­nia wobec opro­gra­mo­wa­nia, to klu­czo­wy cel ana­li­zy (odkry­wa­nie) i pro­jek­to­wa­nia (two­rze­nie). Co moż­na tak uzyskać? 

Poniżej prak­tycz­nie jedy­na (poza ekra­nem kon­fi­gu­ra­cji) for­mat­ka ekra­no­wa Google Calendar. 

Zapewne każ­dy czy­tel­nik, korzy­sta­ją­cy z tego, lub podob­ne­go, kalen­da­rza jest w sta­nie napi­sać dzie­siąt­ki ​„histo­ry­jek” o tym jak i po co uży­wa­ją kalen­da­rza, czy one napraw­dę wszyst­kie wyma­ga­ją, każ­da, nowe­go kawał­ka kodu i testów? To jeden kom­po­nent obsłu­gu­ją­cy zawar­tość tej for­mat­ki, wraz z reali­zu­ją usług takich jak np. wysy­ła­nie moni­tów czy dublo­wa­nie wpi­su w cudzym kalen­da­rzu (dodaj uczestnika).

Tu moż­na napi­sać: Planowanie zada­nia, Planowanie ter­mi­nu, Określanie cza­su zajęty/wolny, Dodanie gościa, Uprzedzanie (noty­fi­ka­cja), Dodawanie opi­su, ale też Sprawdzanie cza­su wol­ne­go. Każdy taki kon­tekst mogę opi­sać jako osob­ne ​„user sto­ry” („kor­ni­szon”). Po co? To raczej wyma­ga­nia biz­ne­so­we, potrze­by ale nie pro­jekt architektury!

Nawet naj­bar­dziej roz­bu­do­wa­ny sklep inter­ne­to­wy ma prak­tycz­nie tyl­ko: ekran pre­zen­ta­cji ofer­ty i zara­zem wyszu­ki­wa­nia, ekran z opi­sem pro­duk­tu (po jego wska­za­niu), ekran z koszy­kiem i moż­li­wo­ścią zapła­ty oraz ekran pro­fi­lu użyt­kow­ni­ka: CZTERY USE CASY (usłu­gi apli­ka­cji). Wszystko to co może­my zro­bić na tych stro­nach to nasze kon­tek­sty (histo­ryj­ki, kor­ni­szo­ny), i nie jest praw­dą, że każ­de user sto­ry to musi być kolej­ny kawa­łek kodu do napi­sa­nia i prze­te­sto­wa­nia. Każda księ­gar­nia inter­ne­to­wa może mi posłu­żyć do spraw­dze­nia ​„kto napi­sał okre­ślo­ną książ­kę” czy ​„co napi­sał okre­ślo­ny autor”, czyż nie? Czy to kolej­ne kom­po­nen­ty? Nie!

Podsumowanie

Obawiam się, że opi­sa­ne ​„narzę­dzie” (meto­da) to kolej­ne ​„lekar­stwo” na brak ana­li­zy i zro­zu­mie­nia logi­ki biz­ne­so­wej. Problem w tym, że tak powsta­ją mon­stru­al­nie nad­mia­ro­we doku­men­ty i potem apli­ka­cje… Audytorzy kodu apli­ka­cji czę­sto stwier­dza­ją, że taka apli­ka­cja ma o rząd wiel­ko­ści więk­szą ilość kodu niż mogła­by mieć, a to ozna­cza tak­że podob­ne rela­cje cza­su i kosz­tu jej powsta­nia. Jeżeli do tego doda­my pró­by napi­sa­nia dla całej takiej apli­ka­cji jed­nej bazy danych w mode­lu rela­cyj­nym, to otrzy­ma­my kosz­mar cyklicz­nej migra­cji danych na eta­pie pro­to­ty­pów a potem roz­wo­ju z powo­du ogrom­ne­go ​„pają­ka” czy­li mode­lu jed­nej, współ­dzie­lo­nej bazy danych, a to kla­sycz­ny mono­lit a nie mikro­ser­wi­sy.

Niestety nie jest praw­dą, że tą meto­dą opro­gra­mo­wa­nie powsta­je szyb­ciej, niż w wer­sji poprze­dzo­nej ana­li­zą i pro­jek­to­wa­niem. Prawdą jest zaś, że ta meto­da nie raz przy­spo­rzy pro­ble­mów z har­mo­no­gra­mem i budżetem.

Rok temu prze­pro­wa­dzi­łem pre­zen­ta­cję i potem napi­sa­łem arty­kuł: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? przy­kła­do­wy pro­jekt. Celem było poka­za­nie jak to moż­na robić inaczej. 

Np. Wypożyczenie Książki, Zwrot Książki i ewen­tu­al­ne Naliczenie Kary za Przetrzymanie, to nie trzy User Story, to jed­na Karta Wypożyczenia, mają­ca tak­że pola: Data Zwrotu oraz Kara za Przetrzymanie. Jest to jeden Przypadek Użycia (Karty Wypożyczeń – jeden for­mu­larz) i róż­ne kon­tek­sty pra­cy biblio­te­ka­rza z uży­ciem tej usłu­gi apli­ka­cyj­nej. Dodać mogę jesz­cze np. Sprawdzenie Dostępności Książki (czy jest Karta Wypożyczenia bez Daty Zwrotu) i wie­le innych, podob­nych ​„celów akto­ra”. Poprawna archi­tek­tu­ra to będzie jeden mikro­ser­wis (micro apli­ka­cja) zarzą­dza­ją­cy Kartami Wypożyczeń (jed­no repo­zy­to­rium tych kart). Artykuł ten zawie­ra tak­że, dla porów­na­nia, link do roz­wią­za­nia powsta­łe­go jako efekt event stor­min­gu, mają­cy chy­ba wszyst­kie opi­sa­ne tu wady. 

Które z tych roz­wią­zań jest lep­sze? To czę­ste pyta­nie na moich szko­le­niach. Poprawna odpo­wiedź: ​„księ­go­wy praw­dę Ci powie”, czy­li łącz­ny nakład pra­cy na powsta­nie, utrzy­ma­nie i roz­wój sys­te­mu w cią­gu 3 – 5 lat mini­mum. Innymi sło­wy liczy się koszt cyklu życia sys­te­mu. A skąd to wie­my” np. z dobrej prak­ty­ki Open Closed Principle (OCP), mówią­cej że dobra archi­tek­tu­ra jest otwar­ta na roz­sze­rze­nia i zamknię­ta na zmia­ny, i raczej nie cho­dzi tu o dokła­da­nie ​„a teraz moduł skrę­tu w pra­wo”, tyl­ko o zro­zu­mie­nie isto­ty rze­czy i zapro­jek­to­wa­nie raz, jed­ne­go modu­łu ukła­du kie­row­ni­cze­go, potem moż­na dodać układ hamo­wa­nia (Chce Zmniejszyć Prędkość, Chcę Zatrzymać Samochód, Chcę Utrzymać Stałą Prędkość Jadąc z Górki).

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.

(źr.: User Story i Story Mapping czy­li jak pod­nieść kosz­ty)