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ą.

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?