Dom bez planów
Największy drew­nia­ny budy­nek zbu­do­wa­ny bez planów

Ciesze się, gdy poja­wia­ją się pole­mi­ki z moimi arty­ku­ła­mi, to zna­czy, że ktoś je czy­ta i budzą one emo­cje. Czytamy na pew­nym blo­gu (któ­ry gorą­co pole­cam jako całość):

Zacznę od drob­nej zło­śli­wo­ści. W maju, jako że się­gną­łem też do star­szych wpi­sów, autor napi­sał: ?[…] ja już wyro­słem ze spo­łecz­nych źró­deł wie­dzy jakim jest Wikipedia i przy­to­czę defi­ni­cję z ksią­żek mają­cych kon­kret­ne­go auto­ra […]?. A dzi­siaj czy­tam, jak autor kry­ty­ku­je prak­ty­ki Agile ? czer­piąc wie­dzę na ich temat z tego spo­łecz­ne­go źró­dła wie­dzy. Kończąc zło­śli­wość dodam adre­su­jąc to do auto­ra, że Wiki i Wikipedia to nie to samo i mają się do sie­bie tak ja kla­sa do obiek­tu. (źr. Zwinna ana­li­za ? TouK).

Cóż, pro­blem w tym, że Agile jest głów­nie na spo­łecz­nych stro­nach defi­nio­wa­ne więc nie mia­łem wiel­kie­go wybo­ru: spo­łecz­na meto­dy­ka to i spo­łecz­na wie­dza o niej.… (wiem czym jest i wiki i wiki­pe­dia, nie sądzę by tu tkwił problem).

Po dru­gie nie jestem wro­giem zwin­no­ści (agi­le a małej lite­ry) bo sam dosto­so­wu­ję meto­dy pra­cy do pro­jek­tu. Jednak jak by nie było mani­fest Agile mówi:

Poprzez wytwa­rza­nie opro­gra­mo­wa­nia oraz poma­ga­nie innym w tym zakre­sie odkry­wa­my lep­sze spo­so­by reali­zo­wa­nia tej pra­cy. W wyni­ku tych doświad­czeń zaczę­li­śmy przedkładać:

  1. Ludzi i ich wza­jem­ne inte­rak­cje(współ­dzia­ła­nie) ponad pro­ce­du­ry i narzędzia.
  2. Działające opro­gra­mo­wa­nie nad wyczer­pu­ją­cą dokumentację.
  3. Współpracę z klien­tem nad nego­cja­cję umów.
  4. Reagowanie na zmia­ny nad reali­zo­wa­nie planu.

Oznacza to, że wpraw­dzie doce­nia­my to co wymie­nio­no po pra­wej stro­nie, to jed­nak bar­dziej ceni­my to co wymie­nio­no po lewej.

Ciekaw jestem np. pra­cy bez dobrze wyne­go­cjo­wa­nej umo­wy (świat jest dla nie­któ­rych ide­al­ny… zazdro­ścić) i tego jak moż­ńa coś więk­sze­go zbu­do­wać bez pla­nu (doku­men­ta­cji). Kolejny argu­ment – IBM i czytamy:

według fir­my IBM wydłu­ża­nie jej cza­su przed fazą imple­men­ta­cji, tyl­ko sto­so­wa­nie zwin­nych (agi­le) meto­dyk i choć­by w takim kie­run­ku zmie­rza sztan­da­ro­wy zestaw pro­duk­tów tej fir­my wspie­ra­ją­cych pro­ces two­rze­nia opro­gra­mo­wa­nia ? IBM Rational

Popatrzyłem w opi­sy i cóż: Scott Ambler pisze, że trze­ba pró­bo­wać bo klu­czo­wa faza pętli szu­ka­nia roz­wią­za­nia” to Produce a poten­tial­ly con­su­ma­ble solu­tion” czy­li two­rze­nie cze­goś poten­cjal­nie przy­dat­ne­go… (poten­cjal­nie). Idąc dalej, autor pole­mi­ki cytuje:

Scott Ambler (chief metho­do­lo­gist for Agile at IBM Rational) napi­sał kie­dyś, że ?ana­li­za jest tak waż­na dla prak­ty­ków Agile, że robi­my ją każ­de­go dnia?

Po pierw­sze meto­dyk od Agile w IBM (czyż­by moda na Agile? Jak by nie było piew­cy cięż­kie­go [[RUP]]«a będą­ce­go nadal pod­sta­wą w IBM)). Powyższe to tak jak bym napi­sał, że dla chi­rur­gów plan ope­ra­cji jest tak waż­ny, że pla­nu­ją co będą robić sta­le, nawet pod­czas trwa­nia operacji”…

Agile w lite­ra­tu­rze ma wie­le zna­czeń, jed­no to adap­ta­cyj­ność sto­so­wa­nej meto­dy­ki pra­cy, inne to np. odkry­wa­nie roz­wią­za­nia poprzez jego two­rze­nie. Jeżeli w tym pierw­szym rozu­mie­niu jestem Agile, to jed­nak mam zasa­dę: naj­pierw pro­jekt potem imple­men­ta­cja. Jakoś nie widzę się w pro­jek­cie, w któ­rym dru­gie pię­tro jest dopie­ro pla­no­wa­ne po wybu­do­wa­niu fun­da­men­tów, te zaś powsta­ły bez wie­dzy ile pię­ter powsta­nie. Owszem, na pew­no pro­jekt lepiej uszcze­gó­ła­wiać dopie­ro gdy są potrzeb­ne szcze­gó­ły, ale pra­ca bez zbu­do­wa­nia szkie­le­tu… to nie ja.

Na koniec zapy­tam: dla­cze­go zespo­ły Agile” bar­dzo czę­sto ręka­mi i noga­mi bro­nią się przed kon­trak­ta­mi fixed pri­ce” czy­li kla­sycz­ny trój­kąt: czas, budżet, zakres, gdzie jest to z góry okre­ślo­ne. Agile: zakres (to co powsta­nie) rodzi się pod­czas pra­cy? Czyli nie wie­my co powsta­nie … dopó­ki nie skończymy…

Cytat z komentarza:

Merry Poppendieck idzie w swo­ich roz­wa­ża­niach dalej. Po co w ogó­le robić ana­li­zę, pro­du­ko­wać doku­men­ty i dia­gra­my? Ich efek­tem będzie zamie­sza­nie. Lepiej wyzna­czyć cele i napi­sać dzia­ła­ją­cy kod.

Tak sobie pomy­sla­łem: co bym miał gdy­bym tak wła­śnie pod­szedł do budo­wy domu… cho­ciaż podob­no tak się wła­śnie budu­je na wsiach: bez pla­nów budow­la­nych, budu­je­my i pro­jek­tu­je­my w trak­cie … a powo­dzie uczą pokory…

Nie jestem wro­giem Agile, jestem zwo­len­ni­kiem inne­go auto­ry­te­tu: Yourdona, któ­ry napi­sał w swo­jej książ­ce o mode­lo­wa­niu UML:

bez pla­nów na pew­no moż­na z mar­szu zbić z desek np. budę dla psa bo jest mało skom­pli­ko­wa­na i ogar­nia ją wyobraź­nia prze­cięt­ne­go czło­wie­ka, ale dla­cze­go tak wie­lu ludzi pró­bu­je tą meto­dą budo­wać wiel­kie biurowce…

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Masz pytania to treści artykułu? Kliknij tu i umów się na krótkie konsultacje.

Ten post ma 7 komentarzy

  1. jacek2v

    1.„Ciekaw jestem np. pra­cy bez dobrze wyne­go­cjo­wa­nej umo­wy” – nego­cjo­wa­nie umów nie jest czę­ścią pro­jek­tu – na pew­no w czę­ści zwią­za­nej z budże­tem. Jak dla mnie to sprze­daż. Wydaje mi się dobrą prak­ty­ką oddzie­lić MD od staw­ki za MD.
    2.„najpierw pro­jekt potem imple­men­ta­cja” – w agi­le nie cho­dzi o to, że imple­men­tu­je­my bez pro­jek­tu, tyl­ko zatrzy­mu­je­my się z pro­jek­to­wa­niem w odpo­wied­nim” momencie 🙂
    3.„dlaczego zespo­ły ?Agile? bar­dzo czę­sto ręka­mi i noga­mi bro­nią się przed kon­trak­ta­mi ?fixed pri­ce? czy­li kla­sycz­ny trój­kąt: czas, budżet, zakres, gdzie jest to z góry określone.”
    W moim przy­pad­ku to pro­ste. Z uwa­gi na dobro klien­ta. Projekt jest prze­waż­nie tań­szy i szyb­ciej dostarczany.

    1. Jarek Żeliński

      1. Umowa to tak­że zakres pro­jek­tu, a czym jest zakres jak nie spe­cy­fi­ka­cją tego co ma powstać?
      2. W jakim momen­cie się zatrzy­mu­je­my? Oprogramowanie to dzie­ło w rozu­mie­niu pra­wa autor­skie­go, jest ono przed­mio­tem umo­wy (ma zostać dostar­czo­ne) sko­ro jesz­cze nie wia­do­mo co ma powsta­nie to cze­go doty­czy umo­wa na Agile?
      3. Jak znam pro­jek­ty IT to prak­ty­ka, nie tyl­ko moja, prze­czy w 100% tej tezie, więk­szość pro­jek­tów zatrzy­ma­nych z powo­du wyczer­pa­nia cza­su lub budże­tu to były pro­jek­tu, któ­rych zakres to była jed­na stro­na umo­wy. Dlaczego mimo kil­ku tysię­cy lat budow­nic­two nie zaadap­to­wa­ło tej lep­szej dla klien­ta” metodyki?

  2. jacek2v

    Ad.1.Chodzi o budżet. Nawiązałem do postu. Zakres jest tyl­ko począt­kiem. Nie oszu­kuj­my się cho­dzi pie­nią­dze. Jak jest budżet to i zakres jest gumowy 🙂
    Ad.2.Wiadomo co powsta­nie – prze­cież to zakres. Projekt w tra­dy­cyj­nym rozu­mie­niu i tak powsta­je po pod­pi­sa­niu umowy.
    Ad.3.I teraz pyta­nie : dla­cze­go tra­dy­cyj­ne pro­jek­ty tak czę­sto pada­ją? A może zabra­kło ela­stycz­no­ści, a było za dużo for­ma­li­zmów? Papierologia bar­dzo czę­sto powo­du­je prze­dłu­że­nie cza­su pro­jek­tu, a biz­nes nie cze­ka zmie­nia się, co powo­du­je póź­niej­sze zmia­ny w zakre­sie. I mamy błęd­ne koło.
    Budownictwo i IT to dwie cał­ko­wi­cie róż­ne dzie​dzi​ny​.To że uży­wa­my czę­sto w nomen­kla­tu­rze IT słow­nic­twa z budow­nic­twa nie zna­czy, że te dwie dzie­dzi­ny są takie same.

    1. Joker

      masz racje sami ocenia

  3. Tomasz Wielga

    Na razie krót­ko. Kiedyś może poku­szę się o dłuż­szy tekst

    1. Co do chi­rur­gów, to są sytu­acje, że otwie­ra się” pacjen­ta w celu zoba­cze­nia, co jest w środ­ku. W trak­cie takiej ope­ra­cji podej­mu­je się decy­zje (pla­nu­je się), co zro­bić z pacjen­tem a i zda­rza się, że zaszy­wa się go bez żad­nych zmian. Zdarza się to zarów­no w przy­pad­kach nagłych jak wypad­ki, gdzie ofia­ra tra­fia na stół bez dłuż­sze­go pla­no­wa­nia, jak i w cho­ro­bach prze­wle­łych. Nie mogę w tym momen­cie napi­sać, że to więk­szość, albo spo­ra część, bo bazu­ję tyl­ko na przy­pa­dach, z któ­ry­mi ja sam mia­łem stycz­ność – i w nich jest aku­rat 100% agile.

    2. Nie jest tak, że wszy­stie zespo­ły Agile bro­nią się przed kon­trak­ta­mi fixed pri­ce. Kolega z TouK, Piotr Burdyło będzie o tym mówił na kon­fe­ren­cji AgileByExample.

    3. Eda Yourdona sobie bar­dzo cenię. Szczególnie za książ­kę Death March”. Jednak zno­wu powo­łu­je się Pan na auto­ry­tet, któ­ry roz­wi­ja swo­ją wiedzę.

    Można też zna­leźć jego pozy­tyw­ne zda­nie na temat burzy mózgów, czy JAD (to chy­ba nawet jest wła­śnie w Death March). 🙂

    1. Jarek Żeliński

      Nie chciał bym być, źle zro­zu­mia­ny: Yourdon czy Fowler to kla­sy­cy ana­li­zy i pro­jek­to­wa­nia”. Faktem jest, że bio­rą udział w ruchach Agile ale ja sta­le pod­kre­ślam, że zanim wypo­wie­my sło­wo Agile war­to przy­to­czyć jaką­kol­wiek jego defi­ni­cję. Bez niej mamy jed­no sło­wo i wie­le zna­czeń. Ja mam nawyk nie wymy­śla­nia” koła od nowa i posłu­gu­ję się sło­wem Agile mając na myśli wspo­mnia­ny Manifest Agile. Z dru­giej stro­ny, jeże­li rozu­mie­my Agile jako odej­ście od tak zwa­nych cięż­kich meto­dyk (RUP i podob­ne) na rzecz meto­dyk adap­ta­cyj­nych (ale jed­nak nie pomi­ja się w nich ana­li­zy, pro­jek­to­wa­nia i jakiejś okre­ślo­nej for­my doku­men­to­wa­nia pro­jek­tu co pod­kre­śla i Yourdon i Fowler – z któ­rym nawet wymie­ni­łem kil­ka maili) to jak naj­bar­dziej jestem za i tak poj­mu­ję zwin­ność w pro­jek­tach (świa­do­mie omi­jam sło­wo Agile ;)). 

      Podsumowując: ze swo­jej stro­ny jak naj­bar­dziej jestem za zwin­ny­mi meto­dy­ka­mi w rozu­mie­niu dobie­ra­nia metod i narzę­dzi (pla­no­wa­nia eta­pów pro­jek­tu) na bazie tego jakie są cele i ryzy­ka w pro­jek­cie. Nie wyobra­żam sobie jed­nak dobre­go pro­jek­tu bez udo­ku­men­to­wa­nej jego wizji, kon­cep­cji roz­wią­za­nia i udo­ku­men­to­wa­nia co naj­mniej archi­tek­tu­ry, klu­czo­wych ele­men­tów (kom­po­nen­tów) sys­te­mu i pro­to­ty­pów (reali­za­cji) nie­try­wial­nych przy­pad­ków użycia.

      Tak więc nale­ży się zgo­dzić z tym, że są przy­pad­ki gdy chi­rur­dzy otwie­ra­ją pacjen­ta ale to jest meto­da na total­ny brak wie­dzy gdy inne meto­dy zawio­dły, nie jest to stan­dar­do­wa pro­ce­du­ra dla każ­dej ope­ra­cji. Zgadzam się z tezą, że JAD bywa przy­dat­ne ale naj­czę­ściej wte­dy gdy nie ist­nie­ją już żad­ne inne źró­dła wie­dzy poza tym co mają w gło­wie klien­ci. Tu pra­gnę zwró­cić uwa­gę, że (moim zda­niem) 90% zależ­no­ści i reguł biz­ne­so­wych sie­dzi w pra­wie, zarzą­dze­niach i pro­ce­du­rach a nie w gło­wach użyt­kow­ni­ków (oni pra­cu­ją na bazie zakre­su obo­wiąz­ków, instruk­cji, pro­ce­dur, pole­ceń Zarządu itp.), Pozostałe 10% swo­bo­dy to wol­ność” z racji kom­pe­ten­cji i upraw­nień ale to wyma­ga po poro­stu dostar­cze­nia narzę­dzia dają­ce­go im pew­ną swobodę. 

      Nie widzę tu spo­ru mię­dzy nami, mam wra­że­nie, że pisze­my (i bro­ni­my go) o innym Agile” niż to z Manifestu.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.