Nie jest tu, na moim blogu, tajemnicą, że preferuję naukowe metody analizy. Nie chodzi o „gmatwanie świata” a o proste a skuteczne podejście. Codzienna lektura blogów zaprowadziła mnie dziś na strony programisty, który napisał:

Czego moglibyśmy się nauczyć od naukowców? A być może tego jak ważną rolę i jak bardzo czaso- i kosztochłonne jest samo planowanie eksperymentu, jak ważne jest zrozumienie czynników zewnętrznych które mogą mieć wpływ na przebieg eksperymentu. Być może warto się zanurzyć w ten świat i spróbować.

Zapowiada się nieźle. osobiście uważam, że eksperyment jest generalnie tańszy i bezpieczniejszy od ćwiczeń na żywym ciele, te ostatnie są zresztą nie raz wręcz zabronione. Zanurzanie się w „świat rzeczywisty” wiec nie raz jest możliwe tylko raz: oddają gotowe rozwiązanie (w zasadzie jak samolot, gotowy jest oblatywany już z człowiekiem na pokładzie).

Bardzo podoba mi się osobiście idea eksperymentu. W moim, tak uwielbianym wątku architektury, analizy biznesowej i zarządzania projektami czasami zbyt często zawierzamy teoriom, manifestom, wzorom i skomplikowanym mechanizmom wyliczania poprawności złożoności wszechświata. Naukowcy w sytuacji gdy złożoność problemu uniemożliwia jego rozwiązania metodami analitycznymi zwracają się ku „eksperymentowi”. Dlatego błagam was architekci i analitycy, następnym razem gdy będziecie próbowali zaprojektować złożony system wykorzystajcie siłę jaką daje eksperyment. Wszelkiej maści „prototypy”, „testy” czy też Agile’owe „spike” są lepsze niż UML’e, diagramy, workflow’y i rysuneczki z procesami biznesowymi. Programiści was polubią za ciekawe zadania, a wy będziecie się mogli pochwalić działającymi systemami.

I tu zaczynają się schody. Bo jeżeli rozumiem programistów, że lubią się bawić na koszt klienta, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu…

Jak mam sobie wyobrazić tworzenie samolotu w postaci podstawianych na lotnisko pasażerskie kolejnych prototypów? Czy każdy projekt IT to samoloty? Tak! Tam pracują ludzie, płacą za to i cierpi ich biznes jak oprogramowanie nie zadziała od razu jak trzeba!

Czy prototypy kodu są lepsze o niż modele procesów i projektu UML? Ja zapytam: opracowanie i przetestowanie mapy prostego procesu, potem przypadku użycia, kawałka modelu dziedziny i testowanie tego diagramem sekwencji to praca dla mnie, jednej osoby, na kartce papieru, koszt to jakieś np. 1000zł. Oddaje produkt (projekt) nie wymagający niczego poza implementacją. Czy za 1000zł ktoś posadzi człowieka lub ludzi, napisze i przetestuje kod kilkunastu klas plus dziesiątków technicznych, mając do dyspozycji jakąś platformę by to uruchomić? I klient odbierze i użyje to za pierwszym razem?

Naukowe metody, szczególnie te zdarzeniowe, polegające na stawianiu tezy i próbie jej falsyfikacji, to po pierwsze skuteczne metody, po drugie nieinwazyjne, po trzecie relatywnie tanie (w relacji do pracy na żywym ciele/kodzie). Po co workflow? Po to by przetestować, czy to co opowiada nieudolnie i mozolnie klient jest logiczne, jest prawdą (tak!). Przetestowany proces biznesowy to nic innego jak makieta, dobry plan miasta do planowania wycieczki. UML? Cóż, można wpuścić tabun murarzy na budowę bez projektu architektonicznego, i metodą  „prototypy”, „testy” czy też Agile’owe „spike” postawią wieżowiec ale nie jestem pewien czy to będzie tanio i nie wiem czy odważył bym bym się w tym czymś zamieszkać. Po drugie zapytam: skoro te UML’e głupie to dlaczego książki o wzorcach projektowych i architekturze systemów są nimi nafaszerowane?

Czego jeszcze możemy się nauczyć od naukowców? A to że „Dobry eksperyment musi być jak najprostszy w wykonaniu i jednocześnie dawać jak najbardziej jednoznaczną odpowiedź potwierdzającą lub falsyfikującą daną teorię” (Wikipedia). Czyli Keep Your Tests Simple. (źr. cytatów: primitive.jogger.pl.)

A tu proszę, same rozsądne rzeczy (może dlatego że przepisane z WIKI). Oczywiście: model procesu dobry, to prosty model, jego testowanie także nie jest skomplikowane, a odpowiedź zerojedynkowa: działa albo nie działa.

Autor pisze na poczatku swojego artykułu, że stworzenie programu to teza:

1. przy założonym czasie (t) oraz założonym budżecie (b) dostarczymy system (S)
2. który dane wejściowe (i) przekształci w dane wyjściowe (o)

Haczyk tu tkwi, w tym, że większość programistów rzuca się na takie coś mimo, że nie dysponuje opisem „czym jest (S). Bo nie są nim ani przypadki użycia ani user story anie notatki z sesji JAD. Po drugie czym jest tenże „system”? Bez jego projektu nie da się określić ani terminu ani budżetu ani czasu wykonania. To tak jak by ktoś napisał, że „przy założonym czasie i budżecie zbuduje hotel wiedząc jedynie ilu gości będzie musiał przyjąć w ciągu doby”.

Podejrzewam, że autor po prostu miał tego pecha, że dostawał jakieś kiepskie analizy i projekty, bełkot, którego niestety jest masa. Wtedy jak najbardziej ma prawo mieć rację (trochę). ale co dalej znajdujemy na tym blogu:

Estymaty projektów przy zastosowaniu zasady 200% buforu bezpieczeństwa nadal rozpadają się jak zamki z piasku. Jak to kolega ujął próbując zamknąć definicję Agile w jednym zdaniu „klient nadal nie wie co chce, a my dostarczymy co mamy” (źr. Slow coding).

Proponuje mu albo jego kierownikom projektów (w sumie to nie wiem kogo tu oceniać…) więc poczytać:

1. opis analizy metodą naukową: Analiza systemowa – analiza biznesowa i projektowanie systemów
2. oraz IIBA czyli jak to robią…

oraz: książki Fowlera, Yourdona, Evansa czy tak zwanego Gangu Czworga.

Nie są to może jakieś wypasione projekty ale co do zasady są to owe workflowły i juemele do zapoznania się…:

Na zakończenie

Co mogę po tym powiedzieć? Państwo sami zdecydujcie co wolicie w swoich projektach: 200% narzutu na swobodne podejście dostawców oprogaramowania czy 20% na dobrego analityka projektanta i drugie 20% jakie uczciwy dostawca doda mając dobry projekt …

Autor napisał swoją odpowiedź i dobrze, bo polemika kształci:

Autor napisał: „Po dogłębnym zapoznaniu się z pracami autora dzielę się moimi przemyśleniami i czekam na równie ciętą ripostę „, którą napisałem i niezbyt ciętą (nie to było celem)  szkoda jednak, że tenże autor nie tylko stosuje tanie erystyczne chwyty w swoich wypowiedziach (np. przyrównywanie prawdziwości swoich tez do pewności odkrycia Kopernika: „postanowiłem trwać przy mej teorii iż to jednak Ziemia krąży wokół Słońca” co jest dość duża zarozumiałością, bo jeśli w kwestii układu słonecznego faktycznie nie mamy wątpliwości to można je mieć w kwestii wywodów tegoż autora),  a w końcu usunął ze swojej strony (dlaczego?) po pewnym czasie moją krótką odpowiedź i link do jej pełnej wersji na tym blogu:

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