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:
- przy założonym czasie (t) oraz założonym budżecie (b) dostarczymy system (S)
- 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ć:
- opis analizy metodą naukową: Analiza systemowa – analiza biznesowa i projektowanie systemów
- 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:
Nie byłbym sobą gdybym nie odpowiedział, zapowiada się ciekawa dyskusja :), http://primitive.jogger.pl/2011/05/23/porzadnie-mi-sie-oberwalo/
http://it-consulting.pl/autoinstalator/wordpress/index.php/2011/05/24/polemika/
Kilka słów z mojego doświadczenia jako medadżer projektu i po trochu projektan systemu. Dla mnie modelowanie systemu i prototypowanie nie sa konkurencyjnymi metodami projektowania, ale uzupełniającymi.
Modelowaniem system formalizujemy wymagania funkcjonalne (user requirements). Ta formalizacja pełni kilka ról w procesie powstawania systemu (nie wymieniam wszystkich).
* Po pierwsze, sprawdzenia czy wymagania funkcjonalne są jasne i możliwe do wykonania. Na przykład w trakcie projektowania, odkryliśmy, że planowana polityka praw dostępu do projektowanej aplikacji jest niejasna i wymaga doprecyzowania.
* Po drugie, pozwalają nad oszacowanie liczby rzeczy do zrobienia.
* Po trzecie, umożliwiają podział systemu na w miarę niezależne części, które będą mógły być wykonywane w miarę niezależnie przez odzielne grupy programistów (formalizacja przyda się zwłaszcza na styku tych części, czyli interfejsy). Idealnie, ten podział umożliwi zrównoleglenie zadań programistycznych, a zatem przybliży moment dostawy programu.
Prototypowanie jest bardzo szerokim terminem. Po pierwsze, można prototypować różne części systemu: interfejs użytkownika, interakcje między jakimiś komponentami, czy obsługę biblioteki. Po drugie, można prototypować cały system albo tylko jego newralgiczne punkty. Po trzecie, można prototypować w różnej formie, zaczynając od prototypów na kartce (ktoś powie, że to jeszcze model), a kończąc na działającym podsystemie.
Dla mnie cel jest jeden. Prototypowanie jest dla mnie uzupełniająco metodą, bo pozwala uzyskać informacje potrzebne przy projektowaniu, żeby sprawdzić czy mój projekt jest możliwy i dobry. Np. testy mock-upów pozwoliły nam poprawić projekty interfejsu użytkownika. Mały lab z prototypem aplikacji pozwolił nam odpowiedzieć czy nasz projekt protokołu single-sign on współdziała z obecnymi technologiami dla Web serwisów, czy też trzeba ten projekt zmienić. Gdybyśmy tego nie wiedzieli, mogłoby się okazać, że przy finalizacji projektu będziemy musieli zmusić klientów do pewnych ustępstw w kwestiach technicznych.
Dla mnie właściwe pytania to raczej:
1) kiedy modelować, a kiedy prototypowac?
2) co modelować/prototypować, np. ile detali umieszczać w modelu/prototypie albo czy np. modelować tylko nietrywialne części systemu, czy raczej całość?
Na te pytania nie ma jednej uniwersalnej odpowiedzi. Wszystko zależy od kilku czynników. Po pierwsze, ile mamy pieniędzy, i jak ile jesteśmy gotowi zapłacić za ograniczenie ryzyka niewiedzy. Po drugie, ponieważ specyfikacja jest elementem komunikacja między projektanami a programistami, wszystko zależy od tego, czy programować będzie ktoś inny niż ten, kto projektował. I pododbnie, czy utrzymaniem systemu będzie się zajmowała ta sama osoba co projektował czy ktoś inny.
Chętnie bym poczytał o doświadczeniach i próbach odpowiedzi na te pytania.
1) kiedy modelować, a kiedy prototypowac?
Moim zdaniem, zawsze, bo warto sprawdzić czy sposób postrzegania problemu jest „jasny” i jego rozwiązanie jest logiczne i kompletne. Warto tu jednak zdefiniować czym jest prototyp a czym model. Jeśli uznać, że model w postaci diagramu jest jakimś uproszczeniem a model w postaci kodu jest także modelem ale „mniej abstrakcyjnym” to w obu przypadkach mamy do czynienia a prototypem. Kiedy który stosować? Diagram jest zawsze o rząd tańszy ale tez ogólniejszy, to ocena ryzyka decyduje jakim kosztem się zabezpieczamy.
2) co modelować/prototypować, np. ile detali umieszczać w modelu/prototypie albo czy np. modelować tylko nietrywialne części systemu, czy raczej całość?
Moim zdaniem na to pytanie odpowiedź zawarta jest powyżej: oceniamy ryzyko, koszt jego niwelowania i podejmujemy decyzje.