Czego moglibyśmy się nauczyć od naukowców?

Nie jest tu, na moim blo­gu, tajem­ni­cą, że pre­fe­ru­ję nauko­we meto­dy ana­li­zy. Nie cho­dzi o gma­twa­nie świa­ta” a o pro­ste a sku­tecz­ne podej­ście. Codzienna lek­tu­ra blo­gów zapro­wa­dzi­ła mnie dziś na stro­ny pro­gra­mi­sty, któ­ry napisał:

Czego mogli­by­śmy się nauczyć od naukow­ców? A być może tego jak waż­ną rolę i jak bar­dzo cza­so- i kosz­to­chłon­ne jest samo pla­no­wa­nie eks­pe­ry­men­tu, jak waż­ne jest zro­zu­mie­nie czyn­ni­ków zewnętrz­nych któ­re mogą mieć wpływ na prze­bieg eks­pe­ry­men­tu. Być może war­to się zanu­rzyć w ten świat i spróbować.

Zapowiada się nie­źle. oso­bi­ście uwa­żam, że eks­pe­ry­ment jest gene­ral­nie tań­szy i bez­piecz­niej­szy od ćwi­czeń na żywym cie­le, te ostat­nie są zresz­tą nie raz wręcz zabro­nio­ne. Zanurzanie się w świat rze­czy­wi­sty” wiec nie raz jest moż­li­we tyl­ko raz: odda­ją goto­we roz­wią­za­nie (w zasa­dzie jak samo­lot, goto­wy jest obla­ty­wa­ny już z czło­wie­kiem na pokładzie).

Bardzo podo­ba mi się oso­bi­ście idea eks­pe­ry­men­tu. W moim, tak uwiel­bia­nym wąt­ku archi­tek­tu­ry, ana­li­zy biz­ne­so­wej i zarzą­dza­nia pro­jek­ta­mi cza­sa­mi zbyt czę­sto zawie­rza­my teo­riom, mani­fe­stom, wzo­rom i skom­pli­ko­wa­nym mecha­ni­zmom wyli­cza­nia popraw­no­ści zło­żo­no­ści wszech­świa­ta. Naukowcy w sytu­acji gdy zło­żo­ność pro­ble­mu unie­moż­li­wia jego roz­wią­za­nia meto­da­mi ana­li­tycz­ny­mi zwra­ca­ją się ku eks­pe­ry­men­to­wi”. Dlatego bła­gam was archi­tek­ci i ana­li­ty­cy, następ­nym razem gdy będzie­cie pró­bo­wa­li zapro­jek­to­wać zło­żo­ny sys­tem wyko­rzy­staj­cie siłę jaką daje eks­pe­ry­ment. Wszelkiej maści pro­to­ty­py”, testy” czy też Agile’owe spi­ke” są lep­sze niż UML’e, dia­gra­my, work­flo­w’y i rysu­necz­ki z pro­ce­sa­mi biz­ne­so­wy­mi. Programiści was polu­bią za cie­ka­we zada­nia, a wy będzie­cie się mogli pochwa­lić dzia­ła­ją­cy­mi systemami.

I tu zaczy­na­ją się scho­dy. Bo jeże­li rozu­miem pro­gra­mi­stów, że lubią się bawić na koszt klien­ta, to nie rozu­miem dla­cze­go od razu chcą latać na pro­to­ty­pach samo­lo­tów, gorzej, nie chcą cze­kać na pro­jekt i te śmiesz­ne rysun­ki tech­nicz­ne. Dlaczego inży­nier mecha­nik chce zaj­mo­wać się pro­jek­to­wa­niem tego jak ma wyglą­dać i latać samo­lot sko­ro jego rola i kom­pe­ten­cje to kon­stru­owa­nie a nie np. bada­nie satys­fak­cji klien­ta z lotu na wygod­nym fotelu…

Jak mam sobie wyobra­zić two­rze­nie samo­lo­tu w posta­ci pod­sta­wia­nych na lot­ni­sko pasa­żer­skie kolej­nych pro­to­ty­pów? Czy każ­dy pro­jekt IT to samo­lo­ty? Tak! Tam pra­cu­ją ludzie, pła­cą za to i cier­pi ich biz­nes jak opro­gra­mo­wa­nie nie zadzia­ła od razu jak trzeba!

Czy pro­to­ty­py kodu są lep­sze o niż mode­le pro­ce­sów i pro­jek­tu UML? Ja zapy­tam: opra­co­wa­nie i prze­te­sto­wa­nie mapy pro­ste­go pro­ce­su, potem przy­pad­ku uży­cia, kawał­ka mode­lu dzie­dzi­ny i testo­wa­nie tego dia­gra­mem sekwen­cji to pra­ca dla mnie, jed­nej oso­by, na kart­ce papie­ru, koszt to jakieś np. 1000zł. Oddaje pro­dukt (pro­jekt) nie wyma­ga­ją­cy nicze­go poza imple­men­ta­cją. Czy za 1000zł ktoś posa­dzi czło­wie­ka lub ludzi, napi­sze i prze­te­stu­je kod kil­ku­na­stu klas plus dzie­siąt­ków tech­nicz­nych, mając do dys­po­zy­cji jakąś plat­for­mę by to uru­cho­mić? I klient odbie­rze i uży­je to za pierw­szym razem?

Naukowe meto­dy, szcze­gól­nie te zda­rze­nio­we, pole­ga­ją­ce na sta­wia­niu tezy i pró­bie jej fal­sy­fi­ka­cji, to po pierw­sze sku­tecz­ne meto­dy, po dru­gie nie­in­wa­zyj­ne, po trze­cie rela­tyw­nie tanie (w rela­cji do pra­cy na żywym ciele/kodzie). Po co work­flow? Po to by prze­te­sto­wać, czy to co opo­wia­da nie­udol­nie i mozol­nie klient jest logicz­ne, jest praw­dą (tak!). Przetestowany pro­ces biz­ne­so­wy to nic inne­go jak makie­ta, dobry plan mia­sta do pla­no­wa­nia wyciecz­ki. UML? Cóż, moż­na wpu­ścić tabun mura­rzy na budo­wę bez pro­jek­tu archi­tek­to­nicz­ne­go, i meto­dą pro­to­ty­py”, testy” czy też Agile’owe spi­ke” posta­wią wie­żo­wiec ale nie jestem pewien czy to będzie tanio i nie wiem czy odwa­żył bym bym się w tym czymś zamiesz­kać. Po dru­gie zapy­tam: sko­ro te UML’e głu­pie to dla­cze­go książ­ki o wzor­cach pro­jek­to­wych i archi­tek­tu­rze sys­te­mów są nimi nafaszerowane?

Czego jesz­cze może­my się nauczyć od naukow­ców? A to że Dobry eks­pe­ry­ment musi być jak naj­prost­szy w wyko­na­niu i jed­no­cze­śnie dawać jak naj­bar­dziej jed­no­znacz­ną odpo­wiedź potwier­dza­ją­cą lub fal­sy­fi­ku­ją­cą daną teo­rię” (Wikipedia). Czyli Keep Your Tests Simple. (źr. cyta­tów: pri​mi​ti​ve​.jog​ger​.pl.)

A tu pro­szę, same roz­sąd­ne rze­czy (może dla­te­go że prze­pi­sa­ne z WIKI). Oczywiście: model pro­ce­su dobry, to pro­sty model, jego testo­wa­nie tak­że nie jest skom­pli­ko­wa­ne, a odpo­wiedź zero­je­dyn­ko­wa: dzia­ła albo nie działa.

Autor pisze na poczat­ku swo­je­go arty­ku­łu, że stwo­rze­nie pro­gra­mu to teza:

  1. przy zało­żo­nym cza­sie (t) oraz zało­żo­nym budże­cie (b) dostar­czy­my sys­tem (S)
  2. któ­ry dane wej­ścio­we (i) prze­kształ­ci w dane wyj­ścio­we (o)

Haczyk tu tkwi, w tym, że więk­szość pro­gra­mi­stów rzu­ca się na takie coś mimo, że nie dys­po­nu­je opi­sem czym jest (S). Bo nie są nim ani przy­pad­ki uży­cia ani user sto­ry anie notat­ki z sesji JAD. Po dru­gie czym jest ten­że sys­tem”? Bez jego pro­jek­tu nie da się okre­ślić ani ter­mi­nu ani budże­tu ani cza­su wyko­na­nia. To tak jak by ktoś napi­sał, że przy zało­żo­nym cza­sie i budże­cie zbu­du­je hotel wie­dząc jedy­nie ilu gości będzie musiał przy­jąć w cią­gu doby”.

Podejrzewam, że autor po pro­stu miał tego pecha, że dosta­wał jakieś kiep­skie ana­li­zy i pro­jek­ty, beł­kot, któ­re­go nie­ste­ty jest masa. Wtedy jak naj­bar­dziej ma pra­wo mieć rację (tro­chę). ale co dalej znaj­du­je­my na tym blogu:

Estymaty pro­jek­tów przy zasto­so­wa­niu zasa­dy 200% bufo­ru bez­pie­czeń­stwa nadal roz­pa­da­ją się jak zam­ki z pia­sku. Jak to kole­ga ujął pró­bu­jąc zamknąć defi­ni­cję Agile w jed­nym zda­niu klient nadal nie wie co chce, a my dostar­czy­my co mamy” (źr. Slow coding).

Proponuje mu albo jego kie­row­ni­kom pro­jek­tów (w sumie to nie wiem kogo tu oce­niać…) więc poczytać:

  1. opis ana­li­zy meto­dą nauko­wą: Analiza sys­te­mo­wa – ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie systemów
  2. oraz IIBA czy­li jak to robią…

oraz: książ­ki Fowlera, Yourdona, Evansa czy tak zwa­ne­go Gangu Czworga.

Nie są to może jakieś wypa­sio­ne pro­jek­ty ale co do zasa­dy są to owe work­flow­ły i jueme­le do zapo­zna­nia się…:

Na zakończenie

Co mogę po tym powie­dzieć? Państwo sami zde­cy­duj­cie co woli­cie w swo­ich pro­jek­tach: 200% narzu­tu na swo­bod­ne podej­ście dostaw­ców opro­ga­ra­mo­wa­nia czy 20% na dobre­go ana­li­ty­ka pro­jek­tan­ta i dru­gie 20% jakie uczci­wy dostaw­ca doda mając dobry projekt …

Autor napi­sał swo­ją odpo­wiedź i dobrze, bo pole­mi­ka kształci:

http://​pri​mi​ti​ve​.jog​ger​.pl/​2​0​1​1​/​0​5​/​2​3​/​p​o​r​z​a​d​n​i​e​-​m​i​-​s​i​e​-​o​b​e​r​w​a​lo/

Autor napi­sał: Po dogłęb­nym zapo­zna­niu się z pra­ca­mi auto­ra dzie­lę się moimi prze­my­śle­nia­mi i cze­kam na rów­nie cię­tą ripo­stę „, któ­rą napi­sa­łem i nie­zbyt cię­tą (nie to było celem) szko­da jed­nak, że ten­że autor nie tyl­ko sto­su­je tanie ery­stycz­ne chwy­ty w swo­ich wypo­wie­dziach (np. przy­rów­ny­wa­nie praw­dzi­wo­ści swo­ich tez do pew­no­ści odkry­cia Kopernika: posta­no­wi­łem trwać przy mej teo­rii iż to jed­nak Ziemia krą­ży wokół Słońca” co jest dość duża zaro­zu­mia­ło­ścią, bo jeśli w kwe­stii ukła­du sło­necz­ne­go fak­tycz­nie nie mamy wąt­pli­wo­ści to moż­na je mieć w kwe­stii wywo­dów tegoż auto­ra), a w koń­cu usu­nął ze swo­jej stro­ny (dla­cze­go?) po pew­nym cza­sie moją krót­ką odpo­wiedź i link do jej peł­nej wer­sji na tym blogu:

https://it-consulting.pl//index.php/2011/05/24/polemika/

Inne artykuły na podobny temat

Komentarze

  1. Maciej Gawinecki 4 czerwca 2011 at 13:44

    Kilka słów z moje­go doświad­cze­nia jako meda­dżer pro­jek­tu i po tro­chu pro­jek­tan sys­te­mu. Dla mnie mode­lo­wa­nie sys­te­mu i pro­to­ty­po­wa­nie nie sa kon­ku­ren­cyj­ny­mi meto­da­mi pro­jek­to­wa­nia, ale uzupełniającymi. 

    Modelowaniem sys­tem for­ma­li­zu­je­my wyma­ga­nia funk­cjo­nal­ne (user requ­ire­ments). Ta for­ma­li­za­cja peł­ni kil­ka ról w pro­ce­sie powsta­wa­nia sys­te­mu (nie wymie­niam wszystkich).
    * Po pierw­sze, spraw­dze­nia czy wyma­ga­nia funk­cjo­nal­ne są jasne i moż­li­we do wyko­na­nia. Na przy­kład w trak­cie pro­jek­to­wa­nia, odkry­li­śmy, że pla­no­wa­na poli­ty­ka praw dostę­pu do pro­jek­to­wa­nej apli­ka­cji jest nie­ja­sna i wyma­ga doprecyzowania.
    * Po dru­gie, pozwa­la­ją nad osza­co­wa­nie licz­by rze­czy do zrobienia.
    * Po trze­cie, umoż­li­wia­ją podział sys­te­mu na w mia­rę nie­za­leż­ne czę­ści, któ­re będą mógły być wyko­ny­wa­ne w mia­rę nie­za­leż­nie przez odziel­ne gru­py pro­gra­mi­stów (for­ma­li­za­cja przy­da się zwłasz­cza na sty­ku tych czę­ści, czy­li inter­fej­sy). Idealnie, ten podział umoż­li­wi zrów­no­le­gle­nie zadań pro­gra­mi­stycz­nych, a zatem przy­bli­ży moment dosta­wy programu.

    Prototypowanie jest bar­dzo sze­ro­kim ter­mi­nem. Po pierw­sze, moż­na pro­to­ty­po­wać róż­ne czę­ści sys­te­mu: inter­fejs użyt­kow­ni­ka, inte­rak­cje mię­dzy jaki­miś kom­po­nen­ta­mi, czy obsłu­gę biblio­te­ki. Po dru­gie, moż­na pro­to­ty­po­wać cały sys­tem albo tyl­ko jego new­ral­gicz­ne punk­ty. Po trze­cie, moż­na pro­to­ty­po­wać w róż­nej for­mie, zaczy­na­jąc od pro­to­ty­pów na kart­ce (ktoś powie, że to jesz­cze model), a koń­cząc na dzia­ła­ją­cym podsystemie. 

    Dla mnie cel jest jeden. Prototypowanie jest dla mnie uzu­peł­nia­ją­co meto­dą, bo pozwa­la uzy­skać infor­ma­cje potrzeb­ne przy pro­jek­to­wa­niu, żeby spraw­dzić czy mój pro­jekt jest moż­li­wy i dobry. Np. testy mock-upów pozwo­li­ły nam popra­wić pro­jek­ty inter­fej­su użyt­kow­ni­ka. Mały lab z pro­to­ty­pem apli­ka­cji pozwo­lił nam odpo­wie­dzieć czy nasz pro­jekt pro­to­ko­łu sin­gle-sign on współ­dzia­ła z obec­ny­mi tech­no­lo­gia­mi dla Web ser­wi­sów, czy też trze­ba ten pro­jekt zmie­nić. Gdybyśmy tego nie wie­dzie­li, mogło­by się oka­zać, że przy fina­li­za­cji pro­jek­tu będzie­my musie­li zmu­sić klien­tów do pew­nych ustępstw w kwe­stiach technicznych.

    Dla mnie wła­ści­we pyta­nia to raczej:
    1) kie­dy mode­lo­wać, a kie­dy prototypowac?
    2) co modelować/prototypować, np. ile deta­li umiesz­czać w modelu/prototypie albo czy np. mode­lo­wać tyl­ko nie­try­wial­ne czę­ści sys­te­mu, czy raczej całość?

    Na te pyta­nia nie ma jed­nej uni­wer­sal­nej odpo­wie­dzi. Wszystko zale­ży od kil­ku czyn­ni­ków. Po pierw­sze, ile mamy pie­nię­dzy, i jak ile jeste­śmy goto­wi zapła­cić za ogra­ni­cze­nie ryzy­ka nie­wie­dzy. Po dru­gie, ponie­waż spe­cy­fi­ka­cja jest ele­men­tem komu­ni­ka­cja mię­dzy pro­jek­ta­na­mi a pro­gra­mi­sta­mi, wszyst­ko zale­ży od tego, czy pro­gra­mo­wać będzie ktoś inny niż ten, kto pro­jek­to­wał. I pododb­nie, czy utrzy­ma­niem sys­te­mu będzie się zaj­mo­wa­ła ta sama oso­ba co pro­jek­to­wał czy ktoś inny. 

    Chętnie bym poczy­tał o doświad­cze­niach i pró­bach odpo­wie­dzi na te pytania.

    • Jarek Żeliński 4 czerwca 2011 at 19:49

      1) kie­dy mode­lo­wać, a kie­dy prototypowac?
      Moim zda­niem, zawsze, bo war­to spraw­dzić czy spo­sób postrze­ga­nia pro­ble­mu jest jasny” i jego roz­wią­za­nie jest logicz­ne i kom­plet­ne. Warto tu jed­nak zde­fi­nio­wać czym jest pro­to­typ a czym model. Jeśli uznać, że model w posta­ci dia­gra­mu jest jakimś uprosz­cze­niem a model w posta­ci kodu jest tak­że mode­lem ale mniej abs­trak­cyj­nym” to w obu przy­pad­kach mamy do czy­nie­nia a pro­to­ty­pem. Kiedy któ­ry sto­so­wać? Diagram jest zawsze o rząd tań­szy ale tez ogól­niej­szy, to oce­na ryzy­ka decy­du­je jakim kosz­tem się zabezpieczamy.

      2) co modelować/prototypować, np. ile deta­li umiesz­czać w modelu/prototypie albo czy np. mode­lo­wać tyl­ko nie­try­wial­ne czę­ści sys­te­mu, czy raczej całość?
      Moim zda­niem na to pyta­nie odpo­wiedź zawar­ta jest powy­żej: oce­nia­my ryzy­ko, koszt jego niwe­lo­wa­nia i podej­mu­je­my decyzje.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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