User story – kłopoty

Tego rodza­ju meto­dy­ki, słow­ne opi­sy zama­wia­ją­ce­go, są czę­sto sto­so­wa­ne przez zespo­ły pro­gra­mi­stów chcą­cych unik­nąć lub ogra­ni­czyć dotych­cza­so­we swo­je kło­po­ty (ryzy­ka) zwią­za­ne z komu­ni­ka­cją pomię­dzy zama­wia­ją­cym a wyko­naw­cą. Kluczowym pro­ble­mem jest fakt ogrom­nej róż­ni­cy pomię­dzy dome­na­mi poję­cio­wy­mi zama­wia­ją­ce­go (zarzą­dza­nie i mar­ke­ting) a wyko­naw­cy (inży­nie­ria pro­gra­mo­wa­nia, mode­lo­wa­nie i pro­jek­to­wa­nie obiek­to­we, inne). Nie jest to abso­lut­nie kry­ty­ka inży­nie­rów a tyl­ko tej ścież­ki roz­wią­zy­wa­nia tego pro­ble­mu. Myślę, że dosko­na­łym obra­zem i meta­fo­rą tego zja­wi­ska jest aneg­do­ta o sło­niu ana­li­zo­wa­nym po ciem­ku. Przytoczę ją w całości.

Grupa osób natknę­ła się w nocy na sło­nia, dwaj prze­wod­ni­cy, każ­dy po ciem­ku, ręko­ma tra­fił na inną cześć cia­ła sło­nia. Jako że musie­li pod­jąć decy­zje o dal­szej dro­dze i postę­po­wa­niu zebra­li swo­je opi­nie. Osoba, któ­ra tra­fi­ła na nogę uzna­ła, że dotknę­ła jakiejś kolum­ny, zapew­ne są u pro­gu jakiejś świą­ty­ni więc musza ją obejść, zaś by nie nie­po­ko­ić jej kapła­na pro­po­nu­je by zro­bić to od razu i nad­ro­bić dro­gi. Druga oso­ba tra­fi­ła na trą­bę, szyb­ko uzna­ła, że to duży wąż i zale­ci­ła natych­mia­sto­wy odwrót i wybór innej dro­gi. W efek­cie stra­ci­li wie­le cza­su, ogra­ni­czo­ne zaso­by wody i jedze­nia spo­wo­do­wa­ły, że kil­ka osób zmar­ło z powo­du prze­dłu­ża­ją­ce­go się marszu.

Wszyscy mie­li dobre chę­ci, burza mózgów zale­ca­na jako meto­da roz­wią­zy­wa­nia takich pro­ble­mów zosta­ła pra­wi­dło­wo wyko­rzy­sta­na, na bazie posia­da­nej wie­dzy i wnio­sków pod­ję­to racjo­nal­ną decy­zję (uni­ka­nie zagro­że­nia), więc gdzie błąd? Byli dosko­na­ły­mi pie­chu­ra­mi, mie­li ogrom­ne doświad­cze­nie w survi­va­lu, widzie­li nie jed­ną pusty­nię i nie jed­no pustyn­ne zwie­rze, jed­nak idąc do dżun­gli nie mie­li w swo­im gro­nie zoo­lo­ga, któ­ry zna­jąc swo­ją dzie­dzi­nę po zebra­niu tych infor­ma­cji mógł­by odkryć, że to słoń i nale­ży tyl­ko w spo­ko­ju dać mu przejść. Nie zabra­li zoo­lo­ga gdyż uzna­li, że taka wypra­wa wyma­ga tyl­ko kon­dy­cji a tę posia­da­ją. W życiu nie widzie­li sło­nia wiec nie zapla­no­wa­li tego ryzy­ka, nie­ste­ty zigno­ro­wa­li cen­na radę: zabierz­cie kogoś kto zna się na stwo­rze­niach żyją­cych w dżun­gli i na pustyni.

Co praw­da podob­no wystar­czy­ło by zapa­lić świa­tło ale nie ma latar­ni w dżun­gli, po dru­gie zoba­czy­li by sło­nia pierw­szy raz w życiu i praw­do­po­dob­nie tak­że by uciekli.

plac budowy źródło: http://www.geotor.pl/przemysl.htm

Jaki z tego wnio­sek? Moim zda­niem taki, że nie­za­leż­nie od doświad­cze­nia pro­gra­mi­ści (oso­by odpo­wie­dzial­ne za powsta­nie kodu pro­gra­mu) nie powin­ni reali­zo­wać czę­ści ana­li­tycz­nej (pro­jek­to­wa­nie roz­wią­za­nia) pro­jek­tów w obsza­rze spe­cy­fi­ka­cji wyma­gań. Po raz kolej­ny oka­zu­je się, że wypra­co­wa­ne przez tysiąc­le­cia meto­dy pra­cy w budow­nic­twie i inży­nie­rii lądo­wej się spraw­dza­ją i war­to je prze­no­sić na pole inży­nie­rii oprogramowania.

Pomysłodawca (inwe­stor) pre­cy­zu­je swój cel archi­tek­to­wi, ten ana­li­zu­je ocze­ki­wa­nia, wyko­nu­je poglą­do­wy pro­jekt (makie­tę), któ­ry zatwier­dza zama­wia­ją­cy. Po uzy­ska­niu akcep­ta­cji pro­jek­tu­je kon­struk­cję. Opis kon­struk­cji prze­ka­zu­je spe­cja­li­stom inży­nie­rom do opra­co­wa­nia szcze­gó­łów i zbu­do­wa­nia budow­li. Jakież to pro­ste? Zamawiający zatwier­dza kolo­ry ścian, układ pomiesz­czeń, doświad­czo­ny archi­tekt reali­zu­je życze­nia ale tak­że dba by się to nie zawa­li­ło i radzi jak ewen­tu­al­nie popra­wić funk­cjo­nal­ność pomiesz­czeń, pro­po­nu­je nowo­cze­sne roz­wią­za­nia. Gotowy pro­jekt dosta­je deve­lo­per, któ­ry już nie podej­mu­je dys­ku­sji czy ścia­ny mają być tam gdzie są, bo nie zna­jąc inten­cji i gustu zama­wia­ją­ce­go nie ma pod­staw by takie uwa­gi czy­nić, co naj­wy­żej może z archi­tek­tem dys­ku­to­wać dostęp­ność uży­tych w pro­jek­cie mate­ria­łów i technologii.

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

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.

Podam przy­kład z jed­naj z kon­fe­ren­cji na ten temat. Podczas tej kon­fe­ren­cji wyra­zi­łem wąt­pli­wo­ści co do potrze­by bez­względ­ne­go sto­so­wa­nia bez­piecz­ne­go pod­pi­su elek­tro­nicz­ne­go w komu­ni­ka­cji z urzę­da­mi (i nie tyl­ko). Pewien inży­nier odparł, że tech­no­lo­gia uży­ta i wyma­ga­na w usta­wie daje nie­mal­że 100% gwa­ran­cję itp. Owszem, tego nie negu­ję bo to praw­da. Jednak to ja usta­lam ryzy­ko moje­go pisma. Paradoksalnie, powszech­nie sto­so­wa­ny, pod­pis odręcz­ny jest sto­sun­ko­wo łatwy do pod­ro­bie­nia, urzę­dy nie zatrud­nia­ją gra­fo­lo­gów więc fał­szer­stwo jest pro­ste i łatwe a mimo to nad­użyć z tego powo­du jest co kot napła­kał a do tego są one łatwo wykry­wal­ne, bo spraw­dze­nie pisma po obu stro­nach (u nadaw­cy i u odbior­cy) od razu wyka­że różnice.

Nikt (mam takie wra­że­nie) nie wyko­nał ana­li­zy ren­tow­no­ści i oce­ny ryzy­ka czy­li nie zasta­no­wił się nad tym jakie stra­ty może spo­wo­do­wać poten­cjal­ne fał­szer­stwo czy­li nie okre­ślił mak­sy­mal­nej sen­sow­nej war­to­ści inwe­sty­cji w zapo­bie­że­nie temu fał­szer­stwu. W efek­cie pod­pis i sam prze­pis są w zasa­dzie mar­twe bo mało kto chce zain­we­sto­wać w posia­da­nie bez­piecz­ne­go pod­pi­su (a podob­no z fak­ta­mi nie dys­ku­tu­je­my). Testem tej hipo­te­zy może być kwiet­nio­wa (2009 rok) decy­zja o moż­li­wo­ści zło­że­nia dekla­ra­cji PIT bez pod­pi­su elek­tro­nicz­ne­go. Ponad 80 tys. dekla­ra­cji zło­żo­nych tą dro­gą przez zwy­kłych oby­wa­te­li w trzy tygo­dnie, to chy­ba wię­cej niż wszyst­kie for­mal­ne doku­men­ty wysła­ne do urzę­dów w wer­sji elek­tro­nicz­nej razem wzię­te od począt­ku obo­wią­zy­wa­nia usta­wy (nie licząc tych do ZUS?a). Zabezpieczenie było bar­dzo pro­ste: nale­ża­ło podać dane wery­fi­ku­ją­ce, w tym pew­ną war­tość z dekla­ra­cji z poprzed­nie­go roku zna­ną prak­tycz­nie tyl­ko jej nadawcy.

Dlaczego aku­rat ten przy­kład? Po pierw­sze boli mnie wyrzu­ce­nie pań­stwo­wych (więc i moich) pie­nię­dzy w bło­to czy­li inwe­sty­cje w e‑podpis . Po dru­gie jest to moim zda­niem dosko­na­ły przy­kład wyma­gań na sys­tem opra­co­wa­ny przez dosko­na­łych inży­nie­rów. Zabrakło jed­nak wie­dzy biznesowej?

Spójrzmy na nasze drzwi do miesz­kań i to jakie mamy w nich zam­ki? powta­rza­jąc opi­nie bie­głych z poli­cji: typo­wy zamek w drzwiach chro­ni nas wyłącz­nie przed chu­li­ga­na­mi bo wpraw­ny wła­my­wacz otwo­rzy go w cza­sie od pię­ciu do pięt­na­stu minut zależ­nie od kla­sy zam­ka. Używanie sztab antyw­ła­ma­nio­wych jest bez sen­su bo żaden zło­dziej przy zdro­wych zmy­słach, nie będzie czy­nił wiel­kie­go hała­su wywa­rza­niem drzwi, a mimo to fir­my ubez­pie­cze­nio­we wyma­ga­ją takich zabez­pie­czeń. Dobry zło­dziej jak już, to krad­nie tyl­ko milio­ny ? bo to dopie­ro jest war­te tego ryzy­ka. Kto trzy­ma w domu miliony?

Tak więc wyma­ga­nia na opro­gra­mo­wa­nie powin­ny być okre­ślo­ne przez dia­log biz­ne­so­wy zaś spe­cy­fi­ka­cja opro­gra­mo­wa­nia przez dia­log tech­no­lo­gicz­ny. I tu łyż­ka dzieg­ciu: wie­le razy byłem świad­kiem gdy to zama­wia­ją­cy psuł pro­jekt uwa­ża­jąc, że wie lepiej jak się two­rzy opro­gra­mo­wa­nie. Zjawisko to (tu bar­dzo nie­bez­piecz­ne dla życia ludzi) tak­że zna inży­nie­ria budow­la­na dla­te­go pra­wo budow­la­ne wyma­ga pro­jek­tu archi­tek­ta a jego pro­jekt chro­ni nie tyl­ko pra­wo budow­la­ne ale tak­że i autorskie.

Nie zmie­nia to jed­nak fak­tu, że wie­le pro­jek­tów pro­gra­mi­stycz­nych to nadal pro­jek­ty, w któ­rych to inży­nie­ro­wie budow­la­ni decy­du­ją o tym jak ma wyglą­dać dom, roz­li­cza­ją się za czas pra­cy i budu­ją tak dłu­go aż spodo­ba się inwe­sto­ro­wi. Co cie­ka­we ich odpo­wie­dzial­ność gdy się potem coś zawa­li mają bar­dzo ogra­ni­czo­ną. Cytując E. Yourdona, guru inży­nie­rii opro­gra­mo­wa­nia i mode­lo­wa­nia: bar­dzo wie­le firm [pro­gra­mi­stycz­nych] nadal budu­je ogrom­ne biu­row­ce zabie­ra­jąc się do tego jak do zbi­ja­nia budy dla psa.

Słowa kluczowe: , , , , ,

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 8 komentarzy

  1. ZZ 23 kwietnia 2011 Odpowiedz

    Bardzo słusz­ny wywód, pro­gra­mi­stów trze­ba trzy­mać naj­da­lej jak się da od użyt­kow­ni­ków, ale co to ma wspól­ne­go z tematem?
    User sto­ry to świet­ne narzę­dzie do komu­ni­ka­cji pomię­dzy użyt­kow­ni­kiem a ana­li­ty­kiem (archi­tek­tem) bo za jaką karę użysz­kod­nik ma pozna­wać UML, BPML czy inne cuda tego typu?

    1. Jarek Żeliński 23 kwietnia 2011

      W moich oczach user sto­ry ma poważ­ną wadę: subiek­ty­wizm piszą­ce­go i jego nie­wie­dze na temat tego ​„co istot­ne”. Kłopoty z„user sto­ry” wyni­ka­ją z fak­tu, że cel spon­so­ra pro­jek­tu (z regu­ły zarząd fir­my) nie musi (i rzad­ko jest) zgod­ny z celem użyt­kow­ni­ka (pra­cow­ni­ka). To pro­blem zbli­ży­ony to tego ​„na ile związ­ki zawo­do­we poma­ga­ją pod­no­sić ryn­ko­wą war­tość firm”. 

      Co do nęka­nia użyt­kow­ni­ków nota­cja­mi BPMN czy UML to mode­le to nie są dla nich a dla ana­li­ty­ka i potem dla wyko­naw­cy. Analityk z pomo­cą popraw­nych mode­li jest w sta­nie zwe­ry­fi­ko­wać logi­kę i spój­ność wyma­gań. User sto­ry sta­no­wi co co naj­wy­żej wstęp­ne ocze­ki­wa­nia zama­wia­ją­ce­go, jego wizje tego co ma powstać, jed­nak pod­kre­ślam: wizję a nie spe­cy­fi­ka­cje wyma­gań. UML pozwa­la ana­li­ty­ko­wi prze­te­sto­wać logi­kę spe­cy­fi­ka­cji: listę przy­pad­ków uży­cia, model dzie­dzi­ny (kla­sy). Każdy przy­pa­dek uży­cia jest testo­wa­ny z pomo­cą dia­gra­mu sekwen­cji by spraw­dzić czy kla­sy (model dzie­dzi­ny) zre­ali­zu­ją je poprawnie.

      User sto­ry może się spraw­dzić w pro­jek­tach małych, gdzie liczy się szyb­ka imple­men­ta­cja apli­ka­cji nie­skom­pli­ko­wa­nych, moż­li­wych do spój­ne­go opi­sa­nia kil­ko­ma, kil­ku­na­sto­ma przy­pad­ka­mi uży­cia, któ­rych oce­na spój­no­ści jest moż­li­wa na warsz­ta­tach typu JAD, a dzie­dzi­na sys­te­mu nie jest zbyt skom­pli­ko­wa­na. Jednak meto­dy te są ryzy­kow­ne z uwa­gi na brak moż­li­wo­ści testo­wa­nia inne­go niż goto­we prototypy.

  2. ZZ 26 kwietnia 2011 Odpowiedz

    Tak, oczy­wi­ście że tak jeśli zakła­dać że może­my uży­wać tyl­ko jed­nej tech­ni­ki zbie­ra­nia wyma­gań i mamy w pro­jek­cie tyl­ko jed­ną gru­pę kon­tak­to­wą. Jeśli jed­nak potrak­to­wać User Story jako jed­no z narzę­dzi to zakres uży­cia jest więk­szy niż w Twoich zało­że­niach. Taki wyol­brzy­mio­ny przy­kład: spon­sor pro­jek­tu – dyr. finan­so­wy, zakres pro­jek­tu – Cash Flow. Proste, da się wszyst­ko opi­sać bez User Story na pod­sta­wie infor­ma­cji od spon­so­ra? Oczywiście nie, wie­le infor­ma­cji o funk­cjo­no­wa­niu obie­gu doku­men­tów trze­ba będzie zdo­być od innych osób i wte­dy US może się oka­zać znacz­nie bar­dziej wydaj­nym (szyb­szym, tań­szym) roz­wią­za­niem niż np. prototypowanie.
    Skłaniam się ku wnio­sko­wi że US jest dobrym narzę­dziem do pew­nych zasto­so­wań i każ­dy ana­li­tyk, pro­jek­tant, tester powi­nien je umieć we wła­ści­wym momen­cie użyć. Takie moje dwa grosze.

    1. Jarek Żeliński 26 kwietnia 2011

      Która infor­ma­cja o obie­gu doku­men­tów jest bliż­sza praw­dy: ​„praw­dzi­we” doku­men­ty z wszel­ki­mi adno­ta­cja­mi na nich po ich uży­ciu i zaksię­go­wa­niu czy też opo­wie­ści ludzi o tych doku­men­tach? Ja wycho­dzę z zało­że­nia, że doku­men­ty ​„są obiek­tyw­ne”, opo­wie­ści ludzi już nie koniecz­nie. Po dru­gie w Urzędach spo­ty­kam się raczej z ​„wyda­je mi się, bo tak robię od daw­na” co nie raz, jak się oka­zu­je, koli­du­je z pra­wem, instruk­cją kan­ce­la­ryj­ną i Kodeksem Postępowania Administracyjnego. W kwe­stii dzia­łów finan­so­wych, pra­cow­ni­cy pew­nej dużej fir­my opi­sa­li (user sto­ry) pro­ces sprze­da­ży, mię­dzy inny­mi to, że ​„od zawsze” sprze­da­ją towar na fak­tu­ry VAT a dopie­ro na koniec tygo­dnia go przyj­mu­ją ten towar for­mal­nie na maga­zyn. Byli szcze­rze zdzi­wie­ni jak im powie­dzia­łem, że to nie­le­gal­ne, oni na to, że księ­go­we księ­gu­ję to wstecz­nie. Stworzenie ​„takie­go sys­te­mu” to nic inne­go jak sank­cjo­no­wa­nie nie­wie­dzy pra­cow­ni­ków i ich nie­kom­pe­ten­cji oraz pozwo­le­nie by sys­tem przyj­mo­wał zda­rze­nia nie­zgod­ne z pra­wem. User Story tu pro­wa­dzi do pato­lo­gii, i nie tyl­ko tu. Jak się oka­za­ło, po kil­ku spo­rach, mam rację (a kon­kret­nie Biegły Rewident, któ­re­go popro­si­łem o opi­nię) . Takich kwiat­ków jest na pęcz­ki. Z pra­cow­ni­kiem („zwy­kłym use­rem”) roz­ma­wiam raczej jak poli­cjant szu­ka­jąc źró­deł nie­ści­sło­ści w doku­men­tach. Większość wdro­żeń, nie tyl­ko sys­te­mów obie­gu doku­men­tów, cier­pi z powo­du bez­kry­tycz­nej akcep­ta­cji przez dostaw­ców opro­gra­mo­wa­nia takich ​„opo­wie­ści” pra­cow­ni­czych. Jako ana­li­tyk był bym strasz­nym bra­ko­ro­bem gdy­bym akcep­to­wał takie specyfikacje.

      Prawdą jest, że User Story nale­ży uży­wać wła­ści­wie, ale nie jest to w moich oczach żad­na tech­ni­ka ana­li­tycz­na a raczej ​„głos ludu”, któ­ry zawsze nale­ży rozważyć…

  3. ZZ 26 kwietnia 2011 Odpowiedz

    Jak zwy­kle masz rację, ale jeśli we wszyst­kich pro­jek­tach pole­gasz na doku­men­tach lub opi­nii tyl­ko spon­so­ra to jesteś brakorobem.
    Aby ana­li­za była peł­na trze­ba zebrać infor­ma­cje ze wszyst­kich źró­deł (gdzie oka­zu­je się że trze­ba korzy­stać z róż­nych tech­nik pozy­ski­wa­nia infor­ma­cji), spoj­rzeć na wyma­ga­nia z góry, z dołu, z boku, doko­nać kon­fron­ta­cji i ana­li­zy. Mienisz się prze­cież ana­li­ty­kiem a nie skrybą.
    Z resz­tą spró­buj uży­wa­jąc wyłącz­nie opi­sów i mode­li UML/BPMN zapro­jek­to­wać por­tal dla użytkowników.

    1. Jarek Żeliński 26 kwietnia 2011

      Nie negu­ję tego, że infor­ma­cje nale­ży zbie­rać ze wszyst­kich dostęp­nych źró­deł. W kwe­stii skry­by owszem: to zły nawyk, ana­li­tyk nie powi­nien być dyk­ta­fo­nem, dla­te­go ​„waga” user sto­ry w doku­men­ta­cji zawsze będzie u mnie mniej­sza niż ​„twar­de dane”. Z zasa­dy uwa­żam, że w kwe­stii stra­te­gii biz­ne­so­wej, w star­ciu Prezes fir­my kon­tra jego pod­wład­ny – user, Prezes ma rację. Inna spra­wa to prze­ło­żo­ne celu biz­ne­so­we­go na funk­cjo­nal­ność opro­gra­mo­wa­nia. Jednak funk­cjo­nal­ność powin­na być reali­za­cją celu Prezesa a nie celu pra­cow­ni­ka, w prze­ciw­nym wypad­ku nara­ża­my się na coś co kie­dyś nazwa­łem ​„wyso­kość wyna­gro­dzeń usta­la­na przez zało­gę fir­my” czy­li pro­sta dro­ga do bankructwa.

      W kwe­stii por­ta­li tu masz jak naj­bar­dziej rację, jeśli mowa o stro­nie ​„jak user będzie korzy­stał z nowe­go por­ta­lu”, user sto­ry (tu raczej sce­na­riusz przy­szło­ści) jak naj­bar­dziej sta­je się wyznacz­ni­kiem, ale nie koniecz­nie do wyspe­cy­fi­ko­wa­nia ​„tego cze­go ocze­ku­je zama­wia­ją­cy tę stro­nę”. Do tego przy­zna­łem się na samym począt­ku. Mój duży opór budzi sto­so­wa­nie ​„metod por­ta­lo­wych” do two­rze­nia opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, bo ile razy mam z czymś takim do czy­nie­nia to są to pro­jek­ty nie­uda­ne a nie raz nieukończone. 

      Na koniec dodam, że opro­gra­mo­wa­nie dedy­ko­wa­ne to nie tyl­ko por­ta­le internetowe…

    2. ZZ 26 kwietnia 2011

      No to mamy kon­sen­sus, User Story (jak zwał tak zwał, ale mię­dzy nami ana­li­ty­ka­mi wia­do­mo o co cho­dzi) jest w pew­nych sytu­acjach uży­tecz­ne (nie tyl­ko por­ta­le mają zło­żo­ne inter­fej­sy użyt­kow­ni­ka i trud­ne do wyja­śnie­nia prze­bie­gi) a w pew­nych sytu­acjach nie. W każ­dym razie rady­kal­ne twier­dze­nie że są do nicze­go jest nieuprawnione.
      Jakbyś jed­nak w arty­ku­le zamiast US pisał pro­gra­mi­sta to mógł­bym tyl­ko przy­kla­snąć. Programistów od ana­li­zy w więk­szo­ści wypad­ków nale­ży trzy­mać tak dale­ko jak się da.

  4. Jaroslaw Zelinski 10 listopada 2013 Odpowiedz

    Bardzo cie­ka­wy arty­kuł Sławka Sobótki na temat DDD, rzu­ca­ją­cy nie­co świa­tła na powyższe:

    Dochodzimy tutaj do kolej­ne­go klu­czo­we­go pyta­nia. Tworząc model dome­ny będzie­my roz­ma­wiać z poten­cjal­ny­mi użyt­kow­ni­ka­mi czy może z kimś zupeł­nie innym – z kimś, to wie dla­cze­go sys­tem ma dzia­łać w ten spo­sób, ale sam nie koniecz­nie będzie ope­ra­to­rem sys­te­mu. W DDD oso­by te gra­ją rolę Ekspertów Domenowych. Oczywiście w szcze­gól­nym przy­pad­ku Ekspert może być rów­nież Operatorem. (źr. DDD…)

Dodaj komentarz

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