Bo najważniejsi Panie są Aktorzy…

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi, w któ­rych użyt­kow­ni­cy narze­ka­ją na dostaw­cę opro­gra­mo­wa­nia, uwa­ża­ją że pro­gram nie cał­kiem speł­nia ich ocze­ki­wa­nia (wyma­ga­nia pod­pi­sa­li… ale to nie roz­wią­zu­je tego pro­ble­mu). Problem pole­ga na czę­sto spo­ty­ka­nym podej­ściu: ana­li­za wyma­gań tyl­ko w posta­ci wywia­dów i w kon­se­kwen­cji nie­peł­ne zro­zu­mie­nie spe­cy­fi­ki biz­ne­so­wej oraz fakt, że deve­lo­per ma skłon­no­ści do uprosz­czeń i nor­ma­li­za­cji”. Innym, moim zda­niem jesz­cze gor­szym podej­ściem, jest roz­po­czę­cie kodo­wa­nia jesz­cze w trak­cie trwa­nia wywia­dów i two­rze­nie opro­gra­mo­wa­nia meto­dą codzien­nych, lub co tygo­dnio­wych spo­tkań z użyt­kow­ni­kiem opi­su­ją­cym kolej­ne aspek­ty sys­te­mu. Zbyt póź­ne odkry­wa­nie (a nie raz nawet nie­do­strze­ga­nie tego), tego że pew­ne rze­czy są «tymi samy­mi rze­cza­mi” ale w innych kon­tek­stach, pro­wa­dzi do bar­dzo wie­lu pro­ble­mów z imple­men­ta­cją. Ale po kolei.

Wymaganie: system ma pozwalać na wystawianie faktur VAT

Wyobraźmy sobie pozor­nie pro­sty pro­blem: opro­gra­mo­wa­nie CRM zawie­ra­ją­ce mię­dzy inny­mi funk­cjo­nal­ność fak­tu­ro­wa­nia. Z regu­ły z wywia­dów (ana­li­za) dowie­my się, że w kil­ku miej­scach róż­ne oso­by wysta­wia­ją fak­tu­ry. Wzór fak­tu­ry będzie załącz­ni­kiem, z kil­ku tak zwa­nych user sto­ry” zosta­nie opra­co­wa­ny jeden (nor­ma­li­za­cja user sto­ry) przy­pa­dek uży­cia Wystawienie fak­tu­ry VAT”, jego imple­men­ta­cja z regu­ły jest kom­pi­la­cją tre­ści kil­ku wywia­dów (user sto­ry). Kilka róż­nych osób (role) dosta­nie pro­to­typ do oce­ny, każ­dy zgło­si inne zmia­ny i ocze­ki­wa­nia, powo­li powsta­je bar­dzo zło­żo­ny sce­na­riusz przy­pad­ku uży­cia obło­żo­ny warun­ko­wy­mi ścież­ka­mi sce­na­riu­sza reali­za­cji tego przy­pad­ku uży­cia. Nie raz moż­na spo­tkać bar­dzo skom­pli­ko­wa­ny model pro­ce­su” wysta­wia­nia fak­tu­ry z wie­lo­ma warun­ka­mi… Diagram przy­pad­ków uży­cia jed­nak, po czymś w rodza­ju nor­ma­li­za­cji, naj­czę­ściej przed­sta­wiał by jed­no wyma­ga­nie – wysta­wia­nie fak­tur VAT – i wyglą­dał by tak:

Analiza biznesowa krok po kroku

Model procesów biznesowych

Pierwszym kro­kiem powin­na być jed­nak ana­li­za pole­ga­ją­ca na opra­co­wa­niu mode­li pro­ce­sów biz­ne­so­wych. Celem tego mode­lo­wa­nia jest wykry­cie, udo­ku­men­to­wa­nie i zro­zu­mie­nie każ­de­go kon­tek­stu wysta­wie­nia fak­tu­ry, wery­fi­ka­cja tre­ści wywia­dów (ludzie mają natu­ral­ne ten­den­cje do pomi­ja­nia rze­czy oczy­wi­stych i uwy­pu­kla­nia swo­jej roli w pro­ce­sie) oraz upew­nie­nia się, że zna­my wszyst­kie sytu­acje, w któ­rych wysta­wia­na jest fak­tu­ra VAT. Dlatego nie­za­leż­nie od zakre­su pro­jek­tu war­to zawsze opra­co­wać model pro­ce­sów biz­ne­so­wych całej organizacji.

Tu mała uwa­ga, model pro­ce­su to nie algo­rytm pra­cy a model obra­zu­ją­cy czyn­no­ści i ich cele.Samo wysta­wia­nie fak­tur może mieć róż­ne kon­tek­sty, może to robić wię­cej niż jed­na oso­ba, a spo­sób w jaki to robi zale­ży od kom­pe­ten­cji tej oso­by. W opi­sy­wa­nym przy­pad­ku mamy dwa takie kon­tek­sty. Faktura VAT za usłu­gę wysta­wia­na przez oso­bę o wyso­kich kwalifikacjach:

oraz fak­tu­ra VAT za towar z maga­zy­nu wysta­wia­na przez oso­bę nie mają­cą wie­dzy lub upraw­nień pozwa­la­ją­cych na samo­dziel­ne wysta­wie­nie Faktury VAT – dla takiej oso­by powsta­ła dokład­na procedura:

Jak widać dia­gra­my nie są jest zbyt skom­pli­ko­wa­ne i takie powin­ny być. Model pro­ce­sów biz­ne­so­wych nie powi­nien zawie­rać w sobie wie­dzy z innych obsza­rów takich jak : pro­ce­du­ry, upraw­nie­nia, umie­jęt­no­ści. Proces biz­ne­so­wy ma ści­słą defi­ni­cję (czyn­ność lub czyn­no­ści prze­kształ­ca­ją­ce stan wej­ścia w pro­dukt pro­ce­su). Jak widać powy­żej, czyn­no­ści pro­ce­su są koja­rzo­ne z pro­ce­du­ra­mi (tu komen­tarz) i rola­mi (tor ma mode­lu pro­ce­sów). W powyż­szych przy­kła­dach pro­ce­du­ry jaw­nie umiesz­czo­no na dia­gra­mie (to jed­na z moż­li­wych kon­wen­cji). W pierw­szym przy­pad­ku pro­ce­du­ra jest try­wial­na, wpi­sa­łem ją tyl­ko dla zobra­zo­wa­nia jej pro­sto­ty co wyni­ka z fak­tu, że kie­row­nik pro­jek­tu (PM) to oso­ba o wyso­kich kom­pe­ten­cjach, od któ­rej wyma­ga­my (CV, rekru­ta­cja) wie­dzy o tym jak wysta­wiać fak­tu­ry VAT. Informacja taka powin­na być w doku­men­ta­cji sko­ja­rzo­na z rolą PM.

Na dia­gra­mach ozna­czo­no czyn­no­ści zwią­za­ne z fak­tu­ro­wa­niem jako «przy­pa­dek uży­cia» (przy­ję­ta tu kon­wen­cja, nie jest to ele­ment nota­cji BPMN, w któ­rej wyko­na­no te diagramy).

Jak widać mamy więc dwa zupeł­nie róż­ne kon­tek­sty wysta­wia­nia fak­tur w tej fir­mie. Oba są istot­ne i było by dużym błę­dem two­rze­nie dla nich jed­ne­go uni­wer­sal­ne­go scenariusza.

Model przypadków użycia

Jak pora­dzić sobie z fak­tu­ro­wa­niem na dwa spo­so­by? Błędem było by pro­ste uzna­nie, że mamy dwa przy­pad­ki użycia:

Powyższe suge­ru­je wyko­na­nie dwóch imple­men­ta­cji, zapew­ne z powie­le­niem czę­ści kodu. Pojawienie się kolej­ne­go nowe­go kon­tek­stu, to tu kolej­ny przy­pa­dek uży­cia, będzie to wyma­ga­ło dopi­sa­nia kolej­ne­go kodu. Powyższy dia­gram to nie naj­lep­szy pomysł. Więc jak?

Tu poja­wia się rola mode­lu dzie­dzi­ny jako ele­men­tu doku­men­ta­cji wyma­gań. Nazywa się to cza­sem wyma­ga­nia dzie­dzi­no­we” w ana­li­zie biz­ne­so­wej czy­li zro­zu­mie­nia i udo­ku­men­to­wa­nie biz­ne­so­wych aspek­tów narzę­dzia (a nim jest zama­wia­ne opro­gra­mo­wa­nie), na któ­re wyma­ga­nia mają zostać wyspecyfikowanie.

Moim zda­niem model przy­pad­ków uży­cia, jako tak zwa­na czar­na skrzyn­ka, nie roz­wią­zu­je żad­ne­go pro­ble­mu poza oczy­wi­ście wyspe­cy­fi­ko­wa­niem wyma­gań funk­cjo­nal­nych (co jest bar­dzo ważne!).

Dobry pro­jekt będzie zawie­rał jed­nak, moim zda­niem, jeden przy­pa­dek uży­cia ale tak­że kon­tek­sty ról. Nieco nad­mia­ro­wy dia­gram przy­pad­ków uży­cia z kontekstami:

Powyższy dia­gram mode­lu­je pomysł” z kon­tek­sta­mi. Oprogramowanie ma jeden przy­pa­dek uży­cia (sys­tem ma być pro­sty i łatwy w uży­ciu!). Diagram przed­sta­wia dwóch akto­rów (dwie role), jeden przy­pa­dek uży­cia (w pro­jek­tach wole oso­bi­ście poję­cie usłu­ga sys­te­mu”, któ­re jest łatwiej­sze w komu­ni­ka­cji z użyt­kow­ni­kiem), oraz jego dwie spe­cja­li­za­cje po jed­nej dla każ­de­go akto­ra (aktor jest połą­czo­ny z wła­ści­wym przy­pad­kiem uży­cia związ­kiem uży­cia). Powyższy dia­gram był­by trud­ny do zro­zu­mie­nia przez Zamawiającego nie zna­ją­ce­go dobrze nota­cji UML, różo­we ele­men­ty umie­ści­łem nad­mia­ro­wo dla zilu­stro­wa­nia tego arty­ku­łu). W doku­men­ta­cji dla klien­ta ele­men­tów ozna­czo­nych na różo­wo nie umieszczam.

Nadal jest to jed­nak czar­na skrzyn­ka, któ­ra nie deter­mi­nu­je logi­ki biz­ne­so­wej sys­te­mu. Czy powin­na? Myślę, że tak, gdyż wyzna­ję zasa­dę, że rolą deve­lo­pe­ra jest imple­men­ta­cja a nie mode­lo­wa­nie logi­ki orga­ni­za­cji , któ­rej nie zna. Zostawiając deve­lo­pe­ra tyl­ko z powyż­szym dia­gra­mem, bar­dzo ryzy­ku­je­my, że wyko­na co praw­da opro­gra­mo­wa­nie w sta­nie na dzi­siaj”, ale jego roz­wój, wyni­ka­ją­cy z logi­ki biz­ne­so­wej orga­ni­za­cji (np. pla­no­wa­ne­go jej roz­wo­ju) może być trud­ny, kosz­tow­ny a nawet cza­sem niemożliwy.

Model dziedziny systemu

Dlatego jed­nak two­rzy­my model dzie­dzi­ny sys­te­mu, nie narzu­ca­jąc (tu zga­dzam się z pro­gra­mi­sta­mi) metod roz­wią­zy­wa­nia pro­ble­mów imple­men­ta­cji (czy­li na tym eta­pie nie prak­ty­ki DDD a raczej model ana­li­tycz­ny BCE).

Nie umiesz­cza­my więc na dia­gra­mie przy­pad­ków uży­cia kon­tek­stów (powy­żej przy­pad­ki uży­cia ozna­czo­ne kolo­rem różo­wym) a two­rzy­my model wewnętrz­nej logi­ki zawie­ra­ją­cej infor­ma­cję o tych kon­tek­stach. Model ten powi­nien być tak opra­co­wa­ny, by moż­li­we było łatwe doda­wa­nie nowych kon­tek­stów, bo to wyni­ka ze spe­cy­fi­ki biz­ne­su. Dodatkowo ele­men­tem biz­ne­so­wym jest tak­że to, że Zamawiający na dziś ocze­ku­je moż­li­wo­ści pra­cy z pomo­cą kom­pu­te­ra i table­tu, nie wyklu­cza w przy­szło­ści innych urzą­dzeń koń­co­wych. Wymaganie to nie powin­no pro­wa­dzić do powie­le­nia przy­pad­ków uży­cia, nie powin­no tak­że kom­pli­ko­wać ele­men­tów typo­wo dzie­dzi­no­wych np. zarzą­dza­nia kon­tek­sta­mi przy­pad­ku użycia.

Proponowany tu model dzie­dzi­ny to kom­plet­na logi­ka dzie­dzi­no­wa (kom­po­nent Model wzor­ca MVC, dia­gram klas w kon­wen­cji BCE/ICONIX)):

Powyższy model zawie­ra dwa dedy­ko­wa­ne ele­men­ty, każ­dy dla kon­kret­ne­go urzą­dze­nia koń­co­we­go, bez inge­ren­cji w sam mecha­nizm fak­tu­ro­wa­nia (kla­sa WystawienieFakturyVAT). To wzo­rzec archi­tek­to­nicz­ny MVVM. Klasa ta (jed­na dla przy­pad­ku uży­cia!) zawie­ra odpo­wied­nie sce­na­riu­sze dla każ­de­go kon­tek­stu (kla­sy skom­po­no­wa­ne o nazwach takich jak akto­rzy, tu np. wzo­rzec pro­jek­to­wy stra­te­gia). Faktury VAT są zarzą­dza­ne przez repo­zy­to­rium faktur.

Model sterowania interakcją

Uzupełnieniem powyż­sze­go, dia­gram przy­pad­ków uży­cia i model dzie­dzi­ny, powi­nien być model sce­na­riu­sza reali­za­cji przy­pad­ku uży­cia – dia­gram sekwen­cji (któ­re­go już tu nie pre­zen­tu­ję, był nie raz opi­sy­wa­ny) oraz dia­gram ste­ro­wa­nia inte­rak­cją (nie jest to dia­gram aktywności!):

Powyższy dia­gram poka­zu­je, kolej­ne ekra­ny (ich makie­ty powin­na zawie­rać doku­men­ta­cja wyma­gań). Mam nadzie­ję, że nie powyż­sze­go szcze­gó­ło­wo wyjaśniać.

Na zakończenie

Powyższe to kom­plet­ne wyma­ga­nia dla deve­lo­pe­ra, któ­re nie narzu­ca­ją imple­men­ta­cji a jedy­nie ocze­ki­wa­ną logi­kę two­rzo­ne­go opro­gra­mo­wa­nia. Jeżeli w wyma­ga­niach doda­my, że ele­men­ty Entities (tu kape­lu­sik” FakturyVAT) mają być roz­dziel­ne, a w wypad­ku wąt­pli­wo­ści (nie­ste­ty) narzu­ca­my [[wzo­rzec acti­ve records]] (cza­sem [[wzo­rzec acti­ve table]]), to zabez­pie­cza­my się przed bar­dzo czę­stą i szko­dli­wą prak­ty­ką wie­lu deve­lo­pe­rów, pole­ga­ją­cą na pro­jek­to­wa­niu repo­zy­to­rium w posta­ci jed­nej dużej rela­cyj­nej bazy danych dla całe­go sys­te­mu i sto­so­wa­niu bar­dzo zło­żo­ne­go mapo­wa­nia ORM (mapo­wa­nie obiek­to­wo-rela­cyj­ne), któ­re w zasa­dzie zabi­je wszyst­kie korzy­ści z obiek­to­wej ([[para­dyg­mat OOAD]]) her­me­ty­za­cji (utrzy­ma­nie peł­nej nie­za­leż­no­ści wszyst­kich ele­men­tów archi­tek­tu­ry). Drugim tego efek­tem jest z regu­ły dra­stycz­ny spa­dek wydaj­no­ści z powo­du bar­dzo wie­lu skom­pli­ko­wa­nych zapy­tań do bazy danych.

Tak więc, war­to pro­wa­dzić ana­li­zę rze­tel­nie, bez nad­mia­ru zwin­no­ści” i z peł­nym zro­zu­mie­niem pro­ble­mu. Pochopne decy­zje, roz­po­czy­na­nie imple­men­ta­cji bez posia­da­nia pro­jek­tu cało­ści, to naj­częst­sze przy­czy­ny nie­uda­nych pro­jek­tów, pro­jek­tów trwa­ją­cych i kosz­tu­ją­cych znacz­nie wię­cej niż planowano…

Bo naj­waż­niej­si w ana­li­zie, Panie, są Aktorzy…

Inne artykuły na podobny temat

Komentarze

  1. jacek2v 3 listopada 2012 at 22:19

    @„rozpoczynanie imple­men­ta­cji bez posia­da­nia pro­jek­tu całości”
    Często docho­dzę do wnio­sku, że podej­ście opi­sa­ne powyż­szym zda­niem bar­dzo czę­sto szyb­ciej i taniej pro­wa­dzi do zado­wo­le­nia klien­ta i dostaw­cy – tak mi wycho­dzi z projektów 🙂
    Odnosząc się do przy­kła­du: dostar­cze­nie apli­ka­cji do fak­tu­ro­wa­nia w 50% (a może i 80% :)) speł­nia­ją­cej ocze­ki­wa­nia klien­ta w <20% cza­su (budże­tu) wraz z pro­me­są na ulep­sza­nie w ramach budże­tu to bar­dzo czę­sto dro­ga do sukcesu.
    Kluczem są:
    1. lek­kie i wydaj­ne narzę­dzia pro­gra­mi­stycz­ne, np. języ­ki skryp­to­we lub też języ­ki specjalizowane
    2. komu­ni­ka­cja w zespo­le; współ­pra­ca eks­per­tów (ana­li­ty­ków) z pro­gra­mi­sta­mi wycho­dzą­ca poza for­mal­ne dokumentacje.
    3. kon­cen­tra­cja zespo­łu – moż­li­wa dzię­ki krót­szej taśmie pro­duk­cyj­nej” i szyb­szym cza­som dostar­cza­nia poszcze­gól­nych funkcjonalności

    • Jarek Żeliński 4 listopada 2012 at 10:59

      Owszem ?roz­po­czy­na­nie imple­men­ta­cji bez posia­da­nia pro­jek­tu cało­ści? nie raz spraw­dza się i tak jest. 

      Jednak nie raz mam moż­li­wość widzieć ten sam pro­jekt reali­zo­wa­ny dwie­ma meto­da­mi” (jestem czę­sto anga­żo­wa­ny do pro­jek­tów nie­uda­nych by zacząć jesz­cze raz to samo). Z moich obser­wa­cji i wyli­czeń wyni­ka, że pro­jek­ty zwin­ne” zaczy­na­ją mieć kło­po­ty gdy war­tość pra­cy prze­kra­cza 75/100 tys. zł. Drugi przy­pa­dek, to pro­jek­ty, w któ­rych logi­ka sys­te­mu nie była zna­na i zro­zu­mia­na w momen­cie roz­po­czę­cia i jej zło­żo­ność zasko­czy­ła wszystkich.

      Warto tu dodać, że owe mitycz­ne 80% funk­cjo­nal­no­ści dostar­czo­ne w 20% cza­su to naj­czę­ściej pro­ste, z mini­mal­ną logi­ką, CRUD’y. Schody zaczy­na­ją się gdy trze­ba zaim­ple­men­to­wać skom­pli­ko­wa­ną logi­kę. Nie jest pro­ble­mem imple­men­ta­cja usłu­gi wysta­wie­nie fak­tu­ry, scho­dy się zaczy­na­ją, gdy np. cen­nik pro­duk­tów prze­sta­je być zbio­rem war­to­ści wpi­sy­wa­nych z pal­ca” a zaczy­na być pew­na logi­ka pro­mo­cji, kosz­tów, cen bazo­wych i limi­tów kupu­ją­ce­go… wte­dy zwin­ne meto­dy naj­czę­ściej się kończą…

  2. jacek2v 5 listopada 2012 at 09:35

    80/20 nie wyni­ka z łatwo­ści imple­men­ta­cji – bo CRUDy są prze­waż­nie dostęp­ne z pudeł­ka” i imple­men­ta­cja to 90% budże­tu – i to nie były pro­jek­ty trud­ne, nie­bez­piecz­ne itp.
    Wydaje mi się, że bar­dzo czę­sto pro­ble­mem nie jest sam poziom kom­pli­ka­cji tyl­ko JAKOŚĆ eks­per­tów i ewen­tu­al­ne spo­so­by na pod­nie­sie­nie tej jako­ści: np. ana­li­za, doku­men­to­wa­nie lub lep­sza komunikacja.
    W pro­jek­tach, w któ­rych bra­łem udział bar­dzo czę­sto na wiel­kość budże­tu pro­jek­tu mia­ła znacz­nie więk­szy wpływ ilość zain­te­re­so­wa­nych osób (pro­por­cjo­nal­nie) ze stro­ny klien­ta niż poziom kom­pli­ka­cji problemu 🙂

    • Jarek Żeliński 5 listopada 2012 at 11:02

      W pro­jek­tach, w któ­rych bra­łem udział bar­dzo czę­sto na wiel­kość budże­tu pro­jek­tu mia­ła znacz­nie więk­szy wpływ ilość zain­te­re­so­wa­nych osób.” Jak budżet zale­ży od licz­by zain­te­re­so­wa­nych osób??? Co do Jakości eks­per­tów” po stro­nie Klienta to ona NIGDY nie będzie lep­sza bo to nie ana­li­ty­cy… Moim zda­niem to kolej­ny MIT AGILE: Użytkownik spe­cy­fi­ku­je (arty­ku­łu­je, potra­fi to zro­bić) wymagania.

  3. jacek2v 5 listopada 2012 at 11:18

    Wynika to głów­nie ze zwięk­szo­ne­go nakła­du na komu­ni­ka­cję: szcze­gó­ło­we doku­men­to­wa­nie i wyja­śnia­nie doku­men­ta­cji, spo­tka­nia, mailo­wa­nie, kon­sul­to­wa­nie, czym wię­cej głów” tym wię­cej genial­nych pomy­słów” zmie­nia­ją­cych kon­cep­cję itd.
    Same spo­tka­nia kil­ku­/kil­ku­na­sto-oso­bo­we mogą poże­rać budżet w tem­pie sprinterskim 🙂
    Zbyt duże zespo­ły eks­per­tów i decy­den­tów roz­my­wa­ją” kom­pe­ten­cje i odpowiedzialność.

    • Jarek Żeliński 5 listopada 2012 at 11:29

      To kolej­ne potwier­dze­nie tezy, że sesje JAD, per­ma­nent­ne spo­tka­nia z przy­szły­mi użyt­kow­ni­ka­mi itp. pod­no­szą kosz­ty i wpro­wa­dza­ją cha­os… Zacytuje pew­ne­go pro­gra­mi­stę z pew­ne­go forum: Przerabiałem _zręczne_ meto­do­lo­gie. Staram się od nich trzy­mać jak naj­da­lej, wpro­wa­dza­ją tyl­ko cha­os i iry­tu­ją. Muszę wie­dzieć co ma być na końcu.”

  4. jacek2v 5 listopada 2012 at 11:53

    Upraszcza Pan: to nie jest potwier­dze­nie tej tezy 🙂
    JAD to co inne­go niż nad­miar ekspertów/decydentów po stro­nie klienta.
    Ja znam pro­gra­mi­stów o cał­ko­wi­cie odmien­nych poglądach 🙂

    • Jarek Żeliński 5 listopada 2012 at 12:03

      To nie uprosz­cze­nie a fak­ty… ja zmie­ni­łem poglą­dy po tym, jak zaczą­łem te same pro­jek­ty reali­zo­wać w dwóch meto­dy­kach”: zwin­nych i for­mal­nych. Od pew­ne­go pozio­mu wiel­ko­ści pro­jek­ty zwin­ne zawsze dawa­ły znacz­nie gor­sze wyni­ki i fak­tycz­nie jed­nym z klu­czo­wych powo­dów tych pora­żek był czas zja­da­ny na spo­tka­nia z użyt­kow­ni­ka­mi, per­ma­nent­ne zmia­ny wyma­gań i brak odpo­wie­dzial­no­ści za wyma­ga­nia czy­li zupeł­ny brak pano­wa­nia nad zakre­sem pro­jek­tu. To tyl­ko sta­ty­sty­ki a nie widzimisię…

      Znam wie­lu pro­gra­mi­stów, któ­rzy po pra­cy w pro­jek­tach bar­dziej sfor­ma­li­zo­wa­nych (ale nie cięż­ki­mi meto­dy­ka­mi) ode­szli od zami­ło­wa­nia” do Agile, tych co zmie­ni­li się w odwrot­na stro­nę ja oso­bi­ście nie znam. Po dru­gie pro­jek­ty fixed pri­ce” bar­dzo uczą poko­ry zwin­ne zespoły”. 

  5. jacek2v 5 listopada 2012 at 14:18

    Agile nie ozna­cza bra­ku pano­wa­nia nad pro­jek­tem”. Agile nie ozna­cza czę­stych spo­tkań z klien­tem, per­ma­nent­nych zmian i bra­ku odpo­wie­dzial­no­ści. Problemy, któ­re Pan opi­sał nie są zwią­za­ne z meto­dy­ką, tyl­ko się zda­rza­ją na każ­dym pro­jek­cie nie­za­leż­nie od meto­dy­ki – spo­ty­ka się je czę­sto w pro­jek­tach pro­wa­dzo­nym wg meto­dyk tra­dy­cyj­nych”. Niezależnie od meto­dy­ki jeśli klient zmie­nia wyma­ga­nia to budżet się roz­jeż­dża, a czy np. do zmia­ny potrze­ba sto­su kwi­tów i spo­tkań komi­te­tu ste­ru­ją­ce­go czy też wystar­czy mail to insza inszość 🙂

    Paradoksalnie wię­cej kon­tro­lo­wa­nia nie ozna­cza więk­szej kon­tro­li nad projektem 🙂

    Co do pro­gra­mi­stów, to każ­dy jest inny. Widocznie polu­bi­li papier­ki zamiast pro­gra­mo­wa­nia :). Ale na serio: sto­so­wa­nie Agile bar­dzo moc­no zale­ży od narzę­dzi pro­gra­mi­stycz­nych, któ­re się sto­su­je. Narzędzia muszą wspie­rać Agile – głów­nie cho­dzi o pro­to­ty­po­wa­nie i szyb­kość zmian. Przy narzę­dziach – nazwij­my je wol­ny­mi” – Agile może się nie spraw­dzić, bo zwin­ność” jest zabi­ja­na ocię­ża­ło­ścią” np. języ­ka pro­gra­mo­wa­nia i zamiast zysków jest stra­ta i znie­chę­ce­nie. Drugi pro­blem to mie­sza­nie ról na pro­jek­cie. Agile nie ozna­cza likwi­da­cji roli ana­li­ty­ka, a to czę­sto się zda­rza. Mówiąc wprost, spo­ro świet­nych pro­gra­mi­stów, nie­zbyt lubi gadać z klien­ta­mi – nie wszy­scy też mają ku temu predyspozycje.
    Agile róż­ni się bar­dzo od innych meto­dyk, ponie­waż nie daje dokład­ne­go prze­pi­su na dzia­ła­nie, a zakła­da, że sto­su­ją­cy tę meto­dy­kę będą się zwin­nie adap­to­wać w zależ­no­ści od potrzeb – BTW: jak dla mnie SCRUM obrósł w tłuszcz i prze­stał być Agile 🙂
    Fakt Agile nie trzy­ma klien­ta za jaja” kwi­ta­mi zakła­da podej­ście win-win (chy­ba już nie tren­dy :)) – takie podej­ście uwa­żam za bar­dziej efek­tyw­ne, bo i tak w osta­tecz­nym roz­ra­chun­ku obie stro­ny dążą do porozumienia.

    Ja patrzę na pro­jek­ty przez pry­zmat efek­tyw­no­ści wyra­żo­nej w budże­cie i cza­sie (zado­wo­le­nie dostaw­cy) oraz zado­wo­le­niu klien­ta z pro­duk­tu. A ten współ­czyn­nik jest w pro­jek­tach Agile, któ­rych bra­łem udział znacz­nie wyż­szy niż np. pro­wa­dzo­nych meto­dy­kach tradycyjnych.

    • Jarek Żeliński 5 listopada 2012 at 15:25

      Podejście win-win jest jak naj­bar­dziej słusz­ne (u mnie nadal ;)). Ogólnie idea Agile sama w sobie nie jest zła, ona jest po pro­stu zbyt opty­mi­stycz­na i ufna w zało­że­niach (zary­zy­ku­je nawet sło­wo; uto­pij­na): klient w spój­ny, kom­plet­ny i zro­zu­mia­ły dla nas spo­sób, powie co potrze­bu­je, my go dobrze zro­zu­mie­my i stwo­rzy­my opro­gra­mo­wa­nie, któ­re mu pomoże. 

      Problem w tym, że ryzy­ko w tak pro­wa­dzo­nym pro­jek­cie jest bar­dzo duże… (sta­ty­sty­ki!). Te mini­mum doku­men­tów to nawet nie tyle doku­men­ty jako d…pochrony a prze­my­śla­ne i zwe­ry­fi­ko­wa­ne pro­jek­ty. Programiści, któ­rzy prze­szli na ciem­na stro­nę mocy water-fall” to efekt tego, że pra­ca z klien­tem, któ­ry jed­nak nie potra­fi w spój­ny, kom­plet­ny i zro­zu­mia­ły dla nas spo­sób powie co potrze­bu­je” jest po pro­stu fru­stru­ją­ca… (wspo­mnia­ny nad­miar pra­co­chłon­no­ści z winy klienta).… 

      Ja nie mam nic prze­ciw­ko Agile, ja jedy­nie widzę, że to w 75% przy­pad­kach nie dzia­ła… :(, oczy­wi­ście mowa o pro­jek­tach powy­żej pew­nej ska­li (budże­ty ponad 75/100 tys. zł)

  6. jacek2v 5 listopada 2012 at 17:36

    …klient w spój­ny kom­plet­ny i zro­zu­mia­ły dla nas spo­sób, powie co potrze­bu­je, my go dobrze zro­zu­mie­my i stwo­rzy­my opro­gra­mo­wa­nie, któ­re mu pomoże.”
    Jest wła­śnie odwrot­nie 🙂 Główną inten­cją Agile jest, że klient nie wie cze­go chce, nie jest wsta­nie pra­co­wać na abs­trak­cji (doku­men­ta­cji), nie rozu­mie nota­cji, że biz­nes szyb­ko się zmie­nia itd.
    Mam wra­że­nie, że obaj mówi­my o cał­ko­wi­cie INNYCH Agile 🙂
    Agile to nie wol­na amerykanka”,ale narzu­ca myśle­nie, jest bar­dziej skon­cen­tro­wa­ny na celu (win-win) niż meto­dy­ki tradycyjne.

    • Jarek Żeliński 5 listopada 2012 at 19:10

      Główną inten­cją Agile jest, że klient nie wie cze­go chce,”, więc jak te wyma­ga­nia odkryć”?

  7. jacek2v 5 listopada 2012 at 21:38

    Ha, tu jest pies pogrzebany ! 🙂
    Są dwie szko­ły: jed­na mówi, pytaj i pisz, a dru­ga pytaj i działaj.

    • Jarek Żeliński 5 listopada 2012 at 22:25

      Ile kosz­tu­je i trwa dzia­ła­nie a ile pisanie?

  8. jacek2v 6 listopada 2012 at 09:05

    Paradoksalnie roz­po­czę­cie od dzia­ła­nia kosz­tu­je prze­cięt­nie 2x mniej 🙂

  9. jacek2v 6 listopada 2012 at 15:25

    Budowanie budyn­ków i apli­ka­cji jest podob­ne… tyl­ko w podob­nym słow­nic­twie 🙂 poza tym róż­ni się kolo­sal­nie. Czy mogę w budyn­ku w kil­ka sekund zmie­nić miej­sce okna, drzwi, czy prze­su­nąć ścia­ny? Czy budu­jąc wie­żo­wiec mogę jed­no­cze­śnie sko­pio­wać go w inne miej­sce? Czy mogę wró­cić do poprzed­niej wer­sji z repozytorium?
    Wręcz karal­ne” porów­na­nie i uproszczenie 🙂
    Potem nastę­pu­je łatwe prze­nie­sie­nie tego myśle­nia do np. sta­nu suro­we­go”, co wycho­dzi przy poka­zy­wa­niu pro­to­ty­pu. Pojawiają złe” myśli w gło­wie klien­ta: cze­mu ja tak dużo pła­cę, jeśli to w dzień/dwa jest goto­we (stan suro­wy i to zamknięty) 🙂
    I zaczy­na się pro­sto­wa­nie myśle­nia”, że to tyl­ko prototyp/wydmuszka, że trze­ba dopi­sać kod pod spodem, że obsłu­gę błę­dów i odpor­ność na użyt­kow­ni­ka” zaim­ple­men­to­wać, że opty­ma­li­zo­wać trze­ba itd. A wszyst­ko wyni­ka z pro­ste­go porów­na­nia do budownictwa 😀

    • Jarek Żeliński 6 listopada 2012 at 15:45

      Budynki i opro­gra­mo­wa­nie nie róż­nią się – są dzie­dzi­na­mi inży­nie­rii, to że coś moż­na w kil­ka sekund zmie­nić to tyl­ko efekt tech­no­lo­gii, podob­nie jak kie­dyś w sta­rym pro­gra­ma­to­rze pral­ki nie dało się szyb­ko zmie­nić nic a teraz pro­gra­ma­tor to pro­gra­mo­wa­ny pro­ce­sor i moż­na go zmie­nić w sekun­dę, ale pro­blem jako­ści pra­nia pozo­sta­je taki sam…

      Co do pła­ce­nia dużo”… jeże­li ktoś nie potra­fi przed roz­po­czę­ciem pra­cy jej wyce­nić i opi­sać tego co dostar­czy, to zna­czy że roz­po­czy­na­jąc pra­cę nie ma poję­cia za co się łapie… Statystyki pro­jek­tów (tych więk­szych oczy­wi­ście) są bez­li­to­sne: pro­jek­ty bez ana­li­zy wyma­gań i opra­co­wa­nia pro­jek­tu cało­ści kosz­tu­ją wię­cej (śr. 60%) i trwa­ją dłu­żej (śr. o 200%)…

      Proponuje zakoń­czyć dia­log, tak na praw­dę nie mają zna­cze­nia zwin­ne argu­men­ty”, zna­cze­nie mają kon­kret­ne pro­jek­ty i sytu­acje gdy anga­żo­wa­ni są na życze­nie klien­tów ana­li­ty­cy i pro­jek­tan­ci… a zapew­niam, że ich – klien­tów – celem nie jest trwo­nie­nie pie­nię­dzy a coś wręcz odwrot­ne­go. Drugi para­doks: wie­lu deve­lo­pe­rów mozol­nie sprze­da­je” swo­je zwin­ne meto­dy pra­cy wła­śnie argu­men­ta­mi w rodza­ju będzie szyb­ciej i taniej. Pracy ana­li­ty­ka, podob­no zbęd­ne­go kosz­tu w pro­jek­cie” nikt nie sprze­da­je, doświad­cze­ni klien­ci sami przy­cho­dzą z zamó­wie­niem”: tym razem chce­my mieć przed pod­pi­sa­niem umo­wy z pro­gra­mi­sta­mi opis tego co mają dostar­czyć. I pro­szę ich prze­ko­ny­wać a nie mnie, bo ja tak na praw­dę reali­zu­je proś­by klien­tów, nicze­go im nie wmuszam.

  10. jacek2v 6 listopada 2012 at 16:46

    Ciekawe tyl­ko cze­mu pro­jek­ty infor­ma­tycz­ne pro­wa­dzo­ne tra­dy­cyj­nie (przed poja­wie­niem się Agile) mia­ły taką niską skuteczność? 🙂
    Zatem zamykamy.

    • Jarek Żeliński 6 listopada 2012 at 19:13

      ich sku­tecz­ność wca­le nie wzro­sła od 30 lat :), EOT

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.