wtorek, 18 listopada 2008

UP-DDD in Action: Planowanie jest nieodzowne, Sir!

Prezydent Dwight Eisenhower tak oto wspominał czasy gdy był generałem armii amerykańskiej:
"In preparing for battle I have always found that plans are useless, but planning is indispensable."

Dziś kolejny post z serii Unified Process & Domain Driven Design in Action. Prace nad projektem wciąż w fazie analizy biznesowej więc post będzie raczej wypełniaczem (podtrzymującym serię) o charakterze "filozoficznym".

Jaką rolę w projekcie spełnia UML (dokumentacja w ogólności)? Są różne podejścia...

Może na przykład nie mieć żadnej roli. Organizacja może radośnie postępować według metodyki chałupniczo-garażowej. Metodyka ta zakłada 3-etapowy proces:

radosna twórczość - po podpisaniu kontraktu następuje pięciominutowa odprawa sześciopaku programistów po czym rzucają się oni na klawiaturę (jak nie przymierzając marynarz atomowego okrętu podwodnego na kozę w porcie) i klepanie na wyścigi. Nikt nie wiec po co, na co i jak, ale to nie szkodzi... byle się wyżyć.

kosy racławickie - wiadomo... burdel rośnie, projekt się sypie, co raz jakaś eskalacja. Najlepszym rozwiązaniem jest pospolite ruszenie: nadgodziny + "ochotnicy" do pomocy. Jak wiemy z doświadczenia jest to oczywisty antywzorzec zarządzania ponieważ nowi ludzie jedynie spowalniają pracę, ale kto by się nad tym zastanawiał - przecież każdy brakujący diagram UML można zastąpić skończoną liczbą studentów...

stawanie na kancie tego no... nosa! - tydzień do release. Ludzie funkcjonują w trybie zombie. Każdy brakujący diagram UML można zastąpić skończoną ilością sznurka do snopowiązałki...

Jeżeli opisana metodyka chałupniczo-garażowa sprawdza się wyśmienicie - na co wskazuje na przykład sam fakt istnienia organizacji (że o systematycznym zwiększaniu zysków nie wspomnę) to oczywiście jak najbardziej jest słuszna i nie powinno się jej zmienić bo jeszcze kruchy stan równowagi się posypie. Biznes to biznes - doskonale to rozumiem.

Na drodze logicznego rozumowania można z czasem uświadomić sobie, że jednak wydanie paru groszy na dokumentację zwróci się wielokrotnie w przyszłości. Metodyka chałupniczo-garażowa owszem przynosi świetne dochody, ale okazuje się, że mogłaby przynosić jeszcze większe gdyby nie tracić czasu na zmaganie się z burdelem i po prostu udokumentować wszystko. Pycha pomysł!

I tu pojawia się kolejna możliwa rola dokumentacji: kula u nogi. Po radosnym zaimplementowaniu trzeba jeszcze zrobić te cholerne rysuneczki i posiedzieć nad wordem. A tu nad głową stoi poganiacz i zadaje najgłupsze pytanie jakie istnieje: "na kiedy będzie gotowy następny moduł?". Na szczęście wspaniałe narzędzia mają funkcję wstecznej inżynierii - dwa kliki i zestaw pięknych prostokątów gotowy. Teraz jeszcze tylko wkleić to jakoś do worda, dokleić jakiś schemat bazy i z dyni. Hmmm nie tak szybko... za mało tej dokumentacji... ale wystarczy wkleić jeszcze trochę kodu źródłowego i bedzie. No dobra, nie odwalajmy chały - tylko same nagłówki klas i metod. Jak wciąż mało to można dokleić trochę reguł biznesowych z jakiś roolsów. Ktoś kazał robić dokumentację to się zrobi - "będzie Pan zadowolony"

Istnieją różne dewiacje w tym podejściu. Można na przykład analizą nazwać projekty ekranów - co prowadzi do ciekawej paranoi. Innym skrzywieniem jest traktowanie schematu bazy danych jako projektu systemu - również ciekawa paranoja.

W sumie to dokumentacja tworzona po fakcie ma jednak swoją wartość - oczywiście pod warunkiem, że ktoś ją aktualizuje:P



A gdyby tak potraktować diagramy UML jako narzędzie do eksperymentowania? Nie chodzi o sam fakt posiadania dokumentacji, ale proces jej tworzenia. Wysiłek umysłowy włożony w zastanowienie się o co w ogóle chodzi. Skupienie się na tym CO a nie JAK. Eksperymentowania, które polega na najpierw na notowaniu wyników analizy biznesowej. Później poddaniu ich wnikliwej i rzetelnej analizie systemowej, czyli odfiltrowaniu chaosu wprowadzone przez ekspertów biznesowych i wyciągnięciu z tego czystego ekstraktu. W wyniku otrzymamy diagramy Use Caseów i Obiektów Biznesowych - stąd już blisko do warstw logiki aplikacji i biznesowej. I nie chodzi bynajmniej o to aby jedynie przepisać bełkot klienta na jajeczka z ludzikami i cieszyć się, że mamy diagramiki Use Case. Tworząc diagramy warto się zastanowić nad każdą kreską i jajeczkiem - czy dany element ma sens, czy nie da się czegoś uogólnić i wyłonić reużywalnej abstrakcji, czy nie da się tego zrobić prościej - właśnie o to upraszczanie chodzi. Upraszczanie na etapie "eksperymentowania" w UML zwróci się na etapie kodowania.

Analogiczne eksperymenty w UML można przeprowadzać na etapie projektowania. Zanim zacznie się kodować warto przez chwilę popatrzeć z większej wysokości na całość bo można przypadkiem zauważyć uogólnienie prowadzące całkiem za darmo do reużywalności. Można też całkiem przypadkiem znaleźć miejsca dla jakiegoś wzorca projektowego i całkiem za darmo zapewnić w przyszłości większą giętkość systemu i jego otwartość na rozbudowę.

Z samego planowania może wyjść więcej dobrego niż z posiadania gotowych (wygenerowanych) planów...
No i jak by nie było - efektem ubocznym tworzenia dokumentacji jest jej posiadanie:)



//=================
UML sam w sobie jest po prostu jakimś tam pismem obrazkowym. Może ma nieco lepiej zdefiniowane reguły niż pismo jaskiniowców, ale wciąż - pismem obrazkowym;P

Sztuka stosowania UML nie polega na skrupulatnym rysowaniu prostokątów od ekierki i następnie ich kolorowaniu tak aby nie wyjść kredką poza kontur.

Nie chodzi o samą formę ale o proces myślowy, który zaszedł np. podczas obiektowej analizy domeny biznesowej. Prostokąty to tylko notatka z walki ze złożonością i chaosem.

2 komentarze:

maciuch pisze...

Witam,

Gratuluje zabawnego opisu chałupniczo garażowej (aka partyzanckiej) metodyki wytwarzania oprogramowania - czytając śmiałem się przez łzy - eh... skąd ja to znam ;). Powstaje pytanie co my maluczcy programiści możemy poradzić na taki stan rzeczy panujący w bardzo wielu firmach. Rozwiązaniem może być zmiana roboty, ale w kolejnych firmach prawdopodobnie natkniemy się na to samo - wystarczy że nam naściemniają na rozmowach rekrutacyjnych ;) Większość z nas zaciska zęby i wali młotkiem w takiej garażowej organizacji mimo świadomości albo chociażby przeczucia, że można robić inaczej, lepiej.

Pozdrawiam

Maciek

Aleksander pisze...

Witam,

Mi szczególnie spodobał się fragment dotyczący ścisłego wiązania od początku tematów tzw. analitycznych (zrozumieć domene) z technicznymi (zobrazować jak to wykonamy). Z resztą jest to temat DDD więc Sławku liczę na regularny update toich doświadczeń bo będzie można sprawdzić czy działa i jak działa.

Co do wymagań i metod partyzanckich to mimo wszytsko z moich doświadczeń z szeregiem, szpalerem czy kupą (== 12 ??) dostawców nie spotkałem się z takim podejściem. Oczywiście jest on o tyle naganny co po prostu śwadczy o tym że firmę założyli ludzie nie rozumiejący czy jest wytwarzanie oprogramowania.
Maciuch - jak jest aż tak źle to na prawde jest sporo fajnych firm i można spróbować zmiany.

Inaczej - chciałbym wyjść od typów realizacji projektów:

1) wsio fixed
2) projekt internal
3) hybryda czyl time & material

W większości miałem do czynenia z 1 będąc po stronie zamawjającego. W modelu tym zawsze feruje się twardy waterfall czyli analiza - projekt techniczny - dev. W efekcie pierwszego etapu powstaje analiza która później nie jest możliwa do realizacji bo - pewne fukcjonalności są za drogie do realizacji dla wykonawcy (tu wojna co jest a co nie CR), interfejsy do systemów działają bardzo dobrze ale na opak niż myśleli ich dokumentaliści, część w ogóle nie dzała (80% szansy jeśli nikt ich dotychczas nie używał)a wojna z dostawcą supportu trwa w zaparte a planowany termin zakończenia to przyszły rok ;).
Dostawca z kolei nie ma dostępnego klienta na stałe (klient jest zajęty i płaci by ne zawracać mu głowy szczegółami) a po drugie związany jest fixed price i nie zrobi czegoś nadmiarowo.
Jedyne wyjście z pułapki jakie na teraz rysuje mi się - to
1) angażować projektantów od razu 2) namówić klienta do zapłaty za proof of concept dla kluczowych punktów zapalnych.

Pozostałe typy projektów to już zawsze inna bajka. 2 daje możliwość ścisłej współpracy analityków i projektantów więc miodek. 3 to hybryda i bywa różnie ale i tak jest lepiej niż w 1.

Pozdrawiam
Alek