User story czyli nic nie poprawić a może nawet bardziej skomplikować

W więk­szo­ści chy­ba firm, z powo­dów histo­rycz­nych, nie­mal­że każ­dy kie­row­nik i dyrek­tor ma nie­co inny próg kwo­to­wy samo­dziel­nej akcep­ta­cji ponie­sio­ne­go koszu. Zapisanie w posta­ci wyma­gań a potem imple­men­ta­cja, takie­go sys­te­mu prze­pły­wu doku­men­tów kosz­to­wych, bywa kosz­ma­rem. Koszmar ten jest bar­dzo kosz­tow­ny z uwa­gi na swo­ją zło­żo­ność i brak ogól­nych zasad. Powoduje to, że zamiast uzy­ska­nia auto­ma­ty­za­cji i znacz­ne­go wzro­stu efek­tyw­no­ści uzy­sku­je się bar­dzo zło­żo­ny i pra­co­chłon­ny (kosz­tow­ny) sys­tem zamra­ża­ją­cy zasta­ny stan rze­czy, jedy­ną korzy­ścią cza­sa­mi bywa to, że z rapor­tów wie­my, że to na praw­dę dłu­go trwa. A to tyl­ko jeden aspekt opi­su orga­ni­za­cji i wyma­gań na oprogramowanie.

Czytaj dalej User story czyli nic nie poprawić a może nawet bardziej skomplikować

Stosowane metody analizy biznesowej i projektowania

Jeżeli czegoś nie potrafisz narysować, to znaczy, że nadal tego nie rozumiesz, jeżeli coś jest trudne do narysowania, to tym bardziej będzie to trudne do realizacji.(JarosŁaw Żeliński) Wprowadzenie Podstawowe pojęcie…

Czytaj dalej Stosowane metody analizy biznesowej i projektowania

Produkty w procesie analizy wymagań

Konkluzja praw­ni­ka, by zawie­rać umo­wy o dzie­ło jeże­li tyl­ko jest to moż­li­we, jest moim zda­niem słusz­na. Tam gdzie nie mamy wystar­cza­ją­cej wie­dzy by zawie­rać takie umo­wy, war­to zain­we­sto­wać czas by okre­ślić jed­nak przed­miot umo­wy, gdyż umo­wa zle­ce­nia z eks­per­tem (dostaw­cą opro­gra­mo­wa­nia) powo­du­je, że Zamawiający kom­plet­nie nie panu­je nad umo­wą: nie wie jakie­go pro­duk­tu ocze­ki­wać, satys­fak­cja z wyko­na­nej pra­cy może nadejść w trud­nym do prze­wi­dze­nia czasie.

Druga uwa­ga: jeże­li cały pro­ces, od pierw­szej ana­li­zy do dostar­cze­nia pro­duk­tu, reali­zu­je jed­na fir­ma, mamy do czy­nie­nia z sytu­acją, w któ­rej dostaw­ca sam kon­tro­lu­je sta­wia­ne mu wyma­ga­nia bo sam sobie defi­niu­je to co ma następ­nie wytwo­rzyć. Taki brak kon­tro­li rodzi poważ­ne ryzy­ko nierzetelności. 

Czytaj dalej Produkty w procesie analizy wymagań

Wycena analizy i projektowania

Tak więc war­to zawsze roz­wa­żać udział fazy ana­li­zy i pla­no­wa­nia w cało­ści pro­jek­tu, mieć świa­do­mość kon­se­kwen­cji tej decy­zji oraz w szcze­gól­no­ści, pla­nu­jąc budżet oraz czas na ana­li­zę i pro­jek­to­wa­nie, przy­jąć, że doku­men­ta­cja ana­li­tycz­no- pro­jek­to­wa jest obję­to­ścio­wo naj­szczu­plej­szym arte­fak­tem” w całym pro­jek­cie (naj­więk­szym arte­fak­tem jest kod) mimo, że nie najtańszym.

Na koniec przy­to­czę sło­wa jed­ne­go z moich klien­tów, dobrze doświad­czo­ne­go kie­row­ni­ka pro­jek­tów: każ­da oszczę­dzo­na godzi­na ana­li­ty­ka pro­jek­tan­ta, to dodat­ko­wy tydzień pra­cy zespo­łu programistów. 

Czytaj dalej Wycena analizy i projektowania

Modelowanie struktury organizacyjnej – widać światełko w tunelu

Na kon­fe­ren­cjach i forach toczą się sta­le dys­ku­sje na ten temat. Większość firm dorad­czych, infor­ma­tycz­nych i ich ana­li­ty­cy bro­nią tezy, że celem ana­li­zy jest zebra­nie infor­ma­cji w posta­ci doku­men­tów i zesta­wień. Niestety takie doku­men­ty są kom­plet­nie nie­przy­dat­ne, mają war­tość nagra­nia (patrz wyżej zdję­cie lot­ni­cze), nie da się na ich posta­wie wycią­gać żad­nych pozwa­la­ją­cych na dowo­dze­nie ich słusz­no­ści, wnio­sków nie licząc może oce­ny este­ty­ki edy­tor­skiej. Niewątpliwą zale­tą takiej ana­li­zy” jest to, że nie wyma­ga ona abso­lut­nie żad­nych kom­pe­ten­cji poza umie­jęt­no­ścią komu­ni­ka­cji. Takim ana­li­ty­kiem może być nie­mal­że każ­dy (łatwa rekru­ta­cja, niski koszt), ale czy taki jest cel ana­liz poprze­dza­ją­cych pro­jek­ty, war­te set­ki tysię­cy zło­tych a nie raz miliony?

Na zakoń­cze­nie dodam, że naj­gor­szym spo­so­bem jaki znam i jaki nie­ste­ty czę­sto spo­ty­kam, na mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej, jest uży­cie dia­gra­mu klas lub dia­gra­mu przy­pad­ków uży­cia i mode­lo­wa­nie z zasto­so­wa­niem dzie­dzi­cze­nia (klas lub aktorów).

Czytaj dalej Modelowanie struktury organizacyjnej – widać światełko w tunelu

Tablice decyzyjne – fakty a nie procesy

Tak więc, regu­ły biz­ne­so­we to ogól­no-orga­ni­za­cyj­ne ogra­ni­cze­nia. Tablice decy­zyj­ne to rodzaj wie­dzy” wpi­sa­nej w punk­ty podej­mo­wa­nia decy­zji. Na mode­lach (dia­gra­mach) pro­ce­sów biz­ne­so­wych mode­lu­je­my jedy­nie skut­ki, czy­li reak­cje na pod­ję­te – zgod­nie z tabli­cą – decyzje.

Gdyby mode­lo­wać powyż­sze na dia­gra­mie np. BPMN, mie­li­by­śmy bram­kę z czte­re­ma wyj­ścia­mi, każ­de wyj­ście repre­zen­to­wał by wiersz Działań. Jak widać spo­dzie­wać się nale­ży tu bra­mek XOR (alter­na­ty­wa wyłącz­na) lub OR (alter­na­ty­wa zwy­kła”). Na dia­gra­mach BPMN za bram­ką były­by czyn­no­ści nazwa­ne tak jak dzia­ła­nia w wier­szach. Aby nie kom­pli­ko­wać nazew­nic­twa tych dia­gra­mów, tabli­ca decy­zyj­na uży­ta z dia­gra­mem BPMN mia­ła by wier­sze Działań nazwa­ne np. odpo­wied­nio Wariant‑1, Wariant‑2 itd. a czyn­no­ści były by umiesz­czo­ne już na diagramie.

Tego typu tabli­ce dosko­na­le nada­ją się do mode­lo­wa­nia sys­te­mów raba­to­wych, lojal­no­ścio­wych, war­to­ści kre­dy­tów kupiec­kich, wag sco­rin­gu kre­dy­tów i wie­lu innych, w któ­rych kom­bi­na­cje skoń­czo­nej licz­by czyn­ni­ków two­rzą deter­mi­ni­stycz­ną, skoń­czo­ną licz­bę dopusz­czal­nych zacho­wań. Na dia­gra­mie pro­ce­su powo­łu­je­my się wyłącz­nie na nazwę tabli­cy (np. koja­rząc ją z kon­kret­ną czyn­no­ścią) zamiast mode­lo­wać skom­pli­ko­wa­ne prze­bie­gi. Dlaczego? Bo war­to pamię­tać, że

decy­zja – nawet bar­dzo skom­pli­ko­wa­na – nie jest pro­ce­sem a zaist­nia­łym fak­tem, odpo­wie­dzią na zasta­ne warunki

Jak widać, reak­cja kie­row­cy na sygna­li­za­tor, to nie pro­ces a fakt. Jest to kon­kret­na reak­cja na kon­kret­ną kom­bi­na­cję kolo­rów świa­teł na sygnalizatorze.

W przy­pad­ku ana­li­zy wyma­gań, sto­so­wa­nie tablic decy­zyj­nych, jako narzę­dzia spe­cy­fi­ko­wa­nia pew­nych zacho­wań sys­te­mu, jest bar­dzo wygod­ne bo po pierw­sze: jest jed­no­znacz­ne, po dru­gie tabli­ce decy­zyj­ne to już stan­dar­do­we narzę­dzie w inży­nie­rii opro­gra­mo­wa­nia i nie trze­ba wymy­ślać ich imple­men­ta­cji (np. w posta­ci maszy­ny sta­no­wej: regu­ły to zda­rze­nia a dzia­ła­nia do przejścia).

Czytaj dalej Tablice decyzyjne – fakty a nie procesy

Analiza oddziaływania i jakość modelowania

Model zawie­ra­ją­cy wyżej opi­sa­ne śla­do­wa­nia (i tyl­ko taki!) pozwa­la na ana­li­zę zale­zno­ści, np. chce­my dowie­dzieć się na co ma wpływ Proces_2, wte­dy powi­nien powstać np. taki diagram:

Jak widać, śla­do­wa­nie jest tu warun­kiem koniecz­nym dla­cze­go? Taki model może powstać auto­ma­tycz­nie” (narzę­dzie do mode­lo­wa­nia musi posia­dać taka funk­cjo­nal­ność). jed­nak to nie jedy­ny waru­nek: model musi zacho­wy­wać for­mal­na popraw­ność, czy­li nie uży­wa­my poję­cia Rola (pas na mode­lu pro­ce­sów) do symu­lo­wa­nia sys­te­mu” któ­ry coś robi, bo opro­gra­mo­wa­nie to narzę­dzie czło­wie­ka (rola w pro­ce­sie), spe­cy­fi­ka uży­cia dane­go narzę­dzia to umie­jęt­no­ści akto­ra (użyt­kow­ni­ka) i jest to co naj­wy­żej pro­blem sko­ja­rze­nia danej czyn­no­ści (pro­ce­su) z doku­men­tem opi­su­ją­cym pro­ce­du­rę lub instruk­cję użyt­kow­ni­ka (to tak­że narzę­dzie powin­no umożliwiać).

Wszelkie łama­nie for­ma­li­zmów nota­cji odno­si taki sam sku­tek jak np. wyko­rzy­sty­wa­nie pól w bazie danych do prze­cho­wy­wa­nia innych danych niż te z nagłów­ka np. wpi­sy­wa­nie dru­gie­go imie­nia do pola Nazwisko czy nazwy dziel­ni­cy w pole Miasto. Z takiej bazy danych żaden sen­sow­ny raport już nie powsta­nie. Jeżeli na mode­lu pro­ce­sów uży­to sym­bo­li w innych zna­cze­niach niż to wyni­ka z uży­tej nota­cji żad­nej sen­sow­nej infor­ma­cji też nie uzy­ska­my… to już nie mode­le tyl­ko zwy­kłe obrazki.

Czytaj dalej Analiza oddziaływania i jakość modelowania

Sprzedam Ci prawa do kodu czyli wielka ściema

A może chce­cie pra­wa do kodu źródłowego?

A jasne, może­my chcieć. No to zapłać­cie za to pra­wo”. A prze­pra­szam za co teraz? Kod, któ­ry powstał to utwór zależ­ny, jest więc chro­nio­ny i już mamy na nie­go wyłącz­ność, nie musi­my eks­tra za to pła­cić. Ale nie chce­my tego sami pisać (kodo­wać) jesz­cze raz. No dobrze, patrzy­my na fak­tu­ry, a tam jest kil­ka­set godzin pro­gra­mi­stów. Czyli co? Już zapła­ci­li­śmy za ich pra­cę, za ten kod! Wystarczy!

Kiedy poja­wia się problem?

W więk­szo­ści przy­pad­ków z jaki­mi się nie­ste­ty spo­ty­kam to pro­jek­ty, w któ­rych nie powsta­ła opi­sa­na tu doku­men­ta­cja. Jaki mamy efekt? No jest kod, wszel­kie pra­wa do nie­go i jego logi­ki ma wyko­naw­ca (jest auto­rem cało­ści). Specyfikacja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych pod­le­ga wyłącz­nie ochro­nie jako dzie­ło lite­rac­kie, jed­nak nie­ste­ty to-co-pro­gram-ma-robić to tyl­ko idea, a ta nie pod­le­ga ochro­nie (stwier­dze­nie fak­tu, że wysta­wia­my fak­tu­ry, jako treść, nie sta­no­wi żad­ne­go zdat­ne­go do ochro­ny tajem­ni­cą fir­my know-how). Tak więc wszel­kie pra­wa do kodu ma w takim wypad­ku pro­gra­mi­sta bo sam od zera to napi­sał (kod).

Pada pro­po­zy­cja: za dodat­ko­we pie­nią­dze sprze­da­my pra­wa mająt­ko­we do kodu, będzie­cie się Państwo czu­li bez­piecz­nie. I teraz pyta­nie: jaką war­tość ma nie­udo­ku­men­to­wa­ny kod opro­gra­mo­wa­nia? Tysiące linii kodu pro­gra­mu, nie raz kil­ka milio­nów, pisa­ny bez pro­jek­tu w wie­lu ite­ra­cjach. Mamy któ­rąś tam jego wer­sję, w koń­cu powsta­wał w bólach, wie­lo­krot­nie mody­fi­ko­wa­ny, bez pro­jek­tu. Nakład pra­cy znacz­nie prze­wyż­sza­ją­cy jego prze­pi­sa­nie. Kto i jakim kosz­tem będzie ten kod ana­li­zo­wał by go zro­zu­mieć i roz­wi­jać? Ten kod, bez jego auto­ra, jest BEZWARTOŚCIOWY a My, bez tej opła­ty, nie mamy żad­nych praw do tego za co zapła­ci­li­śmy (poza licen­cją czy­li pra­wem do korzystania).

Tak więc nie­jed­no­krot­nie ofer­ta na sprze­daż praw do kodu to zwy­kła ściema!

Czytaj dalej Sprzedam Ci prawa do kodu czyli wielka ściema