W jakim miejscu obecnie stoi architektura? Mo偶na powiedzie膰, 偶e mamy dwa klasyczne podej艣cia:
• klasyczne, kt贸re ka偶e starannie zaplanowa膰 mo偶liwie wiele szczeg贸艂贸w (up-front);
• zwinne, kt贸re ka偶e podejmowa膰 decyzje najp贸藕niej, jak to mo偶liwe i rozwija膰 architektur臋 poprzez refaktoring.
Jak to najcz臋艣ciej si臋 odbywa w projektach? W du偶ej cz臋艣ci przypadk贸w tworzy si臋 projekt mniej lub bardziej szczeg贸艂owy (w stylu up-front) i tak ju偶 zostaje.
Z drugiej strony liczenie na to, 偶e uda si臋 rozwin膮膰 dobr膮 architektur臋 tylko i wy艂膮cznie organicznie, poprzez naturaln膮 ewolucj臋, te偶 zazwyczaj si臋 nie udaje. W du偶ych projektach jest to wr臋cz niezwykle ryzykowne, gdy偶 prowadzi cz臋sto do rozwi膮za艅 lokalnych, kt贸re w pewnym momencie nale偶a艂oby ca艂kowicie przepisa膰 (co najcz臋艣ciej si臋 nie dzieje).
W praktyce zdecydowanie najlepiej sprawdza si臋 mieszane podej艣cie tzn. na pocz膮tku projektu, releasu, iteracji, tworzy si臋 koncept i projekt rozwi膮zania, kt贸ry stanowi baz臋 i punkt odniesienia do prac projektowych. Nie musi, a nawet nie powinien by膰 to niezwykle szczeg贸艂owy projekt. Z drugiej strony nie nale偶y zak艂ada膰 偶e to, co zosta艂o wymy艣lone na pocz膮tku, b臋dzie doskona艂ym rozwi膮zaniem, dlatego w ramach prac projektowych, dokonujemy bie偶膮cej lokalnej modyfikacji za艂o偶e艅 projektowych poprzez refaktoryzacj臋.
Dzi臋ki temu uzyskujemy naturalny proces rozwoju architekury, z jednej strony jest ona wst臋pnie zaprojektowana, dzi臋ki czemu nie stracimy czasu i zasob贸w na ewolucyjne b艂膮dzenie. Ewolucj臋 wykorzystujemy, to poprawienia pierwotnego projektu. Je艣li powi膮偶emy to z procesem Naturalnego Porz膮dku refaktoryzacji to jeste艣my w domu! Wi臋cej w kolejnych wpisach.
Szkic procesu wygl膮da nast臋puj膮co:
niedziela, 5 lutego 2012
艣roda, 1 lutego 2012
Tagged under: agile, efektywno艣膰, my艣lenie systemowe, proces, zarz膮dzanie projektami
W艂a艣ciwo艣膰 z艂o偶onych system贸w
Dzisiaj rano jad膮c samochodem do pracy natkn膮艂em si臋 na du偶o d艂u偶szy korek ni偶 zwykle. "No tak, przy takim mrozie pewnie wszyscy jad膮 szczeg贸lnie ostro偶nie" - pomy艣la艂em i powoli si臋 turla艂em Tras膮 艁azienkowsk膮. Po kilkunastu minutach, w pewnym momencie zauwa偶y艂em z daleka, 偶e na jezdni w przeciwnym kierunku by艂 wypadek i policja oraz pogotowie robi艂y, co swoje. Na moim pasie nic si臋 szczeg贸lnego nie dzia艂o. Niby nic, a jednak... Kierowcy najzwyczajniej w 艣wiecie zwalniali, 偶eby zobaczy膰 co si臋 dzieje na drugim pasie. Nikt si臋 nie zatrzymywa艂, tylko patrzyli, co si臋 dzieje. I z tego powodu fragment, kt贸ry zazwyczaj przemierza艂em w 5 minut, zaj膮艂 mi tym razem 20 minut. Po przejechaniu tego punktu ruch znacz膮co przyspieszy艂 i przebiega艂 normalnie.
Dlaczego o tym pisz臋? Od razu dostrzeg艂em analogi臋 do projekt贸w programistycznych :) Przedsi臋wzi臋cia programistyczne - ludzie, architektura, procesy - to z艂o偶ony system. Cz臋sto niewielkie zmiany, pozornie nieistotne elementy maj膮 ogromny, kaskadowy wp艂yw na to co si臋 dzieje w projektach.
By膰 mo偶e o jeden punkt decyzyjny za du偶o, za ma艂o, brak lub nadmiar dokumentacji, brak asertywno艣ci lub przyzwolenia o m贸wieniu o b艂臋dach, brak 艣cis艂ej wsp贸艂pracy lub zbyt swobodna wsp贸艂praca bez ustalonych regu艂 mog膮 znacz膮co zmniejsza膰 efektywno艣膰 ca艂ego procesu. Warto o tym pami臋ta膰!
W przypadku ruchu drogowego sytuacja jest nieco prostsza, bo 艂atwiej j膮 zmierzy膰 - jest to pr臋dko艣膰 i czas przejazdu na tej samej trasie. Nie mamy tego luksusu w projektach, gdzie zazwyczaj to, co jest realizowane nie jest tak powtarzalne. Jednak mo偶emy przybli偶a膰 si臋 do oszacowania i por贸wnywania. Szacuj膮c zadania oraz dodaj膮c relatywn膮 miar臋 z艂o偶ono艣ci zada艅 (funkcjonalno艣ci).
Mniej formaln膮 metod膮 s膮 punkty (points, story points), kt贸re s膮 jednostk膮 wzgl臋dn膮, s艂u偶膮c膮 raczej do por贸wnania z艂o偶ono艣ci r贸偶nych funkcjonalno艣ci, ni偶 do dok艂adnej analizy z艂o偶ono艣ci (kt贸ra jest niezwykle pracoch艂onna, a i tak pozostanie tylko prognoz膮). Bardziej formaln膮 metod膮 (gdzie du偶o precyzyjniej nale偶y argumentowa膰 podane szacowania) mog膮 by膰 kilkuczynnikowe metody szacowania i pomiar zada艅 za pomoc膮 punkt贸w funkcyjnych.
Wtedy mo偶emy obserwowa膰 czy nasza pr臋dko艣膰 si臋 zmienia, jak wprowadzane zmiany maj膮 na ni膮 wp艂yw.
Dlaczego o tym pisz臋? Od razu dostrzeg艂em analogi臋 do projekt贸w programistycznych :) Przedsi臋wzi臋cia programistyczne - ludzie, architektura, procesy - to z艂o偶ony system. Cz臋sto niewielkie zmiany, pozornie nieistotne elementy maj膮 ogromny, kaskadowy wp艂yw na to co si臋 dzieje w projektach.
By膰 mo偶e o jeden punkt decyzyjny za du偶o, za ma艂o, brak lub nadmiar dokumentacji, brak asertywno艣ci lub przyzwolenia o m贸wieniu o b艂臋dach, brak 艣cis艂ej wsp贸艂pracy lub zbyt swobodna wsp贸艂praca bez ustalonych regu艂 mog膮 znacz膮co zmniejsza膰 efektywno艣膰 ca艂ego procesu. Warto o tym pami臋ta膰!
W przypadku ruchu drogowego sytuacja jest nieco prostsza, bo 艂atwiej j膮 zmierzy膰 - jest to pr臋dko艣膰 i czas przejazdu na tej samej trasie. Nie mamy tego luksusu w projektach, gdzie zazwyczaj to, co jest realizowane nie jest tak powtarzalne. Jednak mo偶emy przybli偶a膰 si臋 do oszacowania i por贸wnywania. Szacuj膮c zadania oraz dodaj膮c relatywn膮 miar臋 z艂o偶ono艣ci zada艅 (funkcjonalno艣ci).
Mniej formaln膮 metod膮 s膮 punkty (points, story points), kt贸re s膮 jednostk膮 wzgl臋dn膮, s艂u偶膮c膮 raczej do por贸wnania z艂o偶ono艣ci r贸偶nych funkcjonalno艣ci, ni偶 do dok艂adnej analizy z艂o偶ono艣ci (kt贸ra jest niezwykle pracoch艂onna, a i tak pozostanie tylko prognoz膮). Bardziej formaln膮 metod膮 (gdzie du偶o precyzyjniej nale偶y argumentowa膰 podane szacowania) mog膮 by膰 kilkuczynnikowe metody szacowania i pomiar zada艅 za pomoc膮 punkt贸w funkcyjnych.
Wtedy mo偶emy obserwowa膰 czy nasza pr臋dko艣膰 si臋 zmienia, jak wprowadzane zmiany maj膮 na ni膮 wp艂yw.
Subskrybuj:
Posty (Atom)