O opi­so­wych meto­dach zbie­ra­nia wyma­gań napi­sa­no wie­le, eks­pe­ry­men­tu­ję cza­sa­mi z tek­sta­mi” i nabie­ram pew­ne­go prze­ko­na­nia: jako opis wyma­gań, czy­li jak chce to robić” (np. przy­pad­ków uży­cia) raczej nie, jako opis celu dzia­ła­nia, czy­li co chce osiągnąć/po co mi to” jak naj­bar­dziej. Tak więc opis z ręki zama­wia­ją­ce­go jako wsad do ana­li­zy” jak naj­bar­dziej, ale user sto­ry jako wyma­ga­nia”, raczej na pew­no nie (czy­taj User Story – kło­po­ty)…

User Story jaki jak” z regu­ły nie­ste­ty stwa­rza pro­ble­my i słusz­nie zauwa­żo­no, że:

User Story w posta­ci: Obsługa błę­dów i ich logo­wa­nie powin­no się odby­wać poprzez wspól­ny mecha­nizm” jest kiep­skim pomy­słem. Co praw­da widzi­my dość jasno, że to wyma­ga­nie jest war­to­ścio­we, ale czy użytkownik/klient będzie potra­fił oce­nić jego war­tość? Dodatkowo taki zapis zawie­ra w sobie suge­stię na temat imple­men­ta­cji spo­so­bu obsłu­gi błę­dów – czy z punk­tu widze­nia klien­ta ma to zna­cze­nie? Pamiętajmy też, że jako ana­li­ty­cy (lub jako pro­duct owner w Scrumie) nie chce­my suge­ro­wać roz­wią­za­nia pro­gra­mi­stom, któ­rzy czę­sto lepiej od nas zna­ją się na tech­no­lo­gii, któ­rej będą uży­wać. My powin­ni­śmy napi­sać, co chce osią­gnąć użyt­kow­nik i pozwo­lić pro­gra­mi­stom wybrać naj­lep­szy spo­sób imple­men­ta­cji roz­wią­za­nia. (Wartościowe User Stories ? O wymaganiach).

Moim zda­niem tak zwa­ne user sto­ry powin­no być napi­sa­ne: po pierw­sze języ­kiem zama­wia­ją­ce­go, po dru­gie wyłącz­nie o tym co zama­wia­ją­cy rozu­mie. Dlaczego? Bo tyl­ko wte­dy autor tego tek­stu – tego wyma­ga­nia”, zama­wia­ją­cy – jest w sta­nie sam oce­nić jego sens i praw­dzi­wość” a tak­że przy­dat­ność. Gdzie tu rola ana­li­ty­ka? Analiza to spro­wa­dze­nie tych opi­sów do okre­ślo­nej struk­tu­ry wraz z okre­ślo­ną logi­ką – for­ma­li­za­cja. Rolą ana­li­ty­ka jest na tym eta­pie usu­wa­nie nie­jed­no­znacz­no­ści. Kolejny etap to dopro­wa­dze­nie doku­men­tu wyma­gań do spój­no­ści. Jeżeli uzna­my, że wyma­ga­nia to testy, to rolą ana­li­ty­ka jest wyspe­cy­fi­ko­wa­nie wyma­gań w posta­ci testów (przy­po­mi­nam, że wyma­ga­nia to warun­ki jakie musi speł­nić coś, by było przy­dat­ne do okre­ślo­ne­go celu), wszę­dzie tam, że wyma­ga­na jest jakaś logi­ka biz­ne­so­wa”, nale­ży ją tak­że udokumentować.

Jak słusz­nie powy­żej zauwa­żył autor cyta­tu, nale­ży pozwo­lić pro­gra­mi­stom wybrać naj­lep­szy spo­sób imple­men­ta­cji roz­wią­za­nia”, ale tu waż­na uwa­ga: imple­men­ta­cja to nie roz­wią­zy­wa­nie pro­ble­mów biz­ne­so­wych. Innymi sło­wy, pro­gra­mi­sta nie może dostać wyma­ga­nia w posta­ci sprze­daż towa­ru to pobra­nie go z maga­zy­nu”, bo po pierw­sze nie wie co to jest towar” po dru­gie nie zawsze jest to pobra­nie z maga­zy­nu. Należy mieć świa­do­mość, że towar” z per­spek­ty­wy pro­gra­mi­sty to struk­tu­ral­ny opis” i nie on ten opis powi­nien robić. Kto? Analityk.

Tak wiec powyż­sze, cyto­wa­ne user sto­ry raczej powin­no mieć postać: celem admi­ni­stra­to­ra opro­gra­mo­wa­nia jest śle­dze­nie zacho­wa­nia sys­te­mu i wychwy­ty­wa­nie zaist­nia­łych błę­dów w jego zacho­wa­niu, infor­ma­cje o błę­dach powi­nien otrzy­my­wać natych­miast” oraz dodat­ko­wo (robo­ta ana­li­ty­ka) powi­nien ist­nieć słow­nik biz­ne­so­wy z defi­ni­cją poję­cia błąd opro­gra­mo­wa­nia” oraz natych­miast”. Rolą pro­gra­mi­sty jest prze­ło­że­nie tego na język uży­te­go narzę­dzia (języ­ka pro­gra­mo­wa­nia) oraz zapew­nie­nie by powsta­łe opro­gra­mo­wa­nie było zgod­ne z ocze­ki­wa­ny­mi wyma­ga­nia­mi jako­ścio­wy­mi (wyma­ga­nie poza-funk­cjo­nal­ne: natychmiast).

Tak więc pro­gra­mi­sta imple­men­tu­je logi­kę biz­ne­so­wą, tę musi jed­no­znacz­nie udo­ku­men­to­wać ana­li­tyk, oraz zapew­nia uzgod­nio­ną jakość (wyma­ga­nia poza­funk­cjo­nal­ne). Ma więc dużo pra­cy… ale nie powi­nien podej­mo­wać prób wpły­wu na imple­men­to­wa­ną logi­kę biznesową.

miecz dwa ostrza dwustronny

Czyli np. 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 podatkó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”. Rolą ana­li­ty­ka są tak­że ewen­tu­al­ne nego­cja­cje z zama­wia­ją­cym, uprosz­czeń lub roz­wi­nięć tego opi­su. Czy ana­li­tyk może być pra­cow­ni­kiem” dostaw­cy? Jak sądzicie?

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 2 komentarzy

  1. Dorzucę jesz­cze 2 gro­sze na temat US w kon­tek­ście DDD.
    US jak nazwa wska­zu­je jest z pozio­mie użyt­kow­ni­ka. Jeżeli dba­my o usa­bi­li­ty, to dąży­my do mak­sy­mal­ne­go uprosz­cze­nia UI.
    Zatem w zło­żo­nym sys­te­mie w US nie znaj­dzie­my szcze­gó­łów (ani nawet wska­zó­wek) na temat tego jaki jest model domenowy.

    Do tego potrze­ba Domain Story, dla któ­rych źró­dłem wie­dzy jest Ekspert Domenowy.

    Po pro­stu czę­sto nie chce­my aby model men­tal­ny Usera był tak głę­bo­ki jak model men­tal­ny Eksperta Domenowego.

    1. Jarek Żeliński

      Należy się z tym zgo­dzić. Mój błąd to pew­ne nie­za­mie­rzo­ne uprosz­cze­nie: sku­pi­łem na cyta­cie a fak­tycz­nie jest tak, że kil­ka (niech będzie kil­ka­na­ście, ale raczej nie dzie­siąt­ki) stron opi­su np. z ręki spon­so­ra pro­jek­tu i dyrek­to­ra han­dlo­we­go na temat sprze­da­ży, jej stra­te­gii celu jaki ma dział sprze­da­ży i celu two­rze­nia tego nowe­go opro­gra­mo­wa­nia, daje moc­ne fun­da­men­ty dla pro­jek­tu. Dużo lep­sze niż zbyt szcze­gó­ło­we (cza­sa­mi wła­śnie dzie­siąt­ki stron i tabel) histo­ryj­ki przy­szłych użyt­kow­ni­ków, któ­rych, z moje­go doświad­cze­nia, raczej nale­ży na począt­ku trzy­mać z dale­ka od pro­jek­tu. Przyszli użyt­kow­ni­cy z natu­ry rze­czy sta­ra­ją się wyobra­zić” sobie nowe opro­gra­mo­wa­nie w szcze­gó­łach, mając za całą swo­ją wie­dzę, dotych­czas uży­wa­ne opro­gra­mo­wa­nie i jego wady…i tyl­ko to.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.