Słabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

SCRUM

Nie jestem zwo­len­ni­kiem kla­sycz­ne­go, kaska­do­we­go pro­ce­su pro­jek­to­wa­nia i wytwa­rza­nia opro­gra­mo­wa­nia. Preferuje pro­ces podob­ny do kaska­do­we­go, z pro­to­ty­pa­mi odrzu­ca­ny­mi, jed­nak pro­to­ty­pem jest u model (pro­jekt) a nie żywy kod. Proces taki opi­su­je np. meto­dy­ka MDA (wię­cej na stro­nie OMG, przyj­dzie pora i na nie­go tu). Jednak pro­pa­gan­da mówi, że jak powszech­nie wiadomo”…

…model kaska­do­wy ska­zu­je klien­ta na dłu­gi czas ocze­ki­wa­nia na efekt koń­co­wy. Bardzo dużo cza­su pochła­nia­ją ana­li­zy przed­wdro­że­nio­we i szcze­gó­ło­we pro­jek­ty, a ich wynik jest widocz­ny wyłącz­nie ?na papie­rze?. (za Scrum eli­mi­nu­je sła­bo­ści tra­dy­cyj­nych metod wytwa­rza­nia IT).

I od razu do rze­czy. Powyższe nie jest praw­dą. Badania pro­jek­tów poka­zu­ją coś zupeł­nie odwrotnego:

Statystyka pracochłonności projektów IT

Jak widać, popraw­na (o takiej tu mowa) ana­li­za wyma­gań, skra­ca czas imple­men­ta­cji (pro­jek­to­wa­nie i wyko­na­nie) o ponad poło­wę. Po dru­gie owe zwin­ne ite­ra­cje to nic inne­go jak odkry­wa­nie wyma­gań meto­dą prób i błę­dów, co jest cza­so­chłon­ne i kosz­tow­ne, co widać na powyż­szym dia­gra­mie (poka­zu­je on sta­ty­sty­ki ukoń­czo­nych projektów).

A co jest prawdą?

To, że ów czas trwa­nia pro­jek­tu jest dłu­gi, to naj­czę­ściej efekt zbyt duże­go zakre­su tego pro­jek­tu a nie tej czy innej meto­dy­ki. Po pro­stu sys­tem mają­cy 200 pla­no­wa­nych cech funk­cjo­nal­nych będzie budo­wa­ny dłu­go nie dla­te­go, że wybra­no kaska­do­wą meto­dy­kę” tyl­ko dla­te­go, że jest duży”.

Cytowany arty­kuł (zachwa­la­ją­cy meto­dy­kę SCRUM) wska­zu­je na kil­ka wad” ana­li­zy i pro­jek­to­wa­nia, zobacz­my co tu jest wadą…

Ryzyko uzy­ska­nia nie­ade­kwat­ne­go roz­wią­za­nia ? model kaska­do­wy ska­zu­je klien­ta na dłu­gi czas ocze­ki­wa­nia na efekt koń­co­wy. Bardzo dużo cza­su pochła­nia­ją ana­li­zy przed­wdro­że­nio­we i szcze­gó­ło­we pro­jek­ty, a ich wynik jest widocz­ny wyłącz­nie ?na papierze?.

  • Z punk­tu widze­nia klien­ta, ana­li­zy to bar­dzo istot­ny koszt, któ­ry dłu­go się zwra­ca ? klient pła­ci za doradz­two, czę­sto nie widząc żad­ne­go real­ne­go rezul­ta­tu poza doku­men­ta­mi. Skomplikowane i zło­żo­ne pro­jek­ty to dla orga­ni­za­cji wiel­ka odpo­wie­dzial­ność, tym­cza­sem w podej­ściu kaska­do­wym im bar­dziej zło­żo­ne pro­jek­ty, tym moc­niej rośnie ryzy­ko zwią­za­ne z rezul­ta­tem końcowym.
  • Przy zasto­so­wa­niu Scrum takie ryzy­ko prak­tycz­nie nie ist­nie­je. Obie stro­ny wie­dzą, że w okre­sie współ­pra­cy mogą wypra­co­wać roz­wią­za­nie, któ­re­go nie moż­na było prze­wi­dzieć na począt­ku pro­jek­tu. Przy tym zwin­nym podej­ściu coś takie­go jak osta­tecz­na defi­ni­cja final­nej wer­sji pro­duk­tu na począt­ku pro­jek­tu nie ist­nie­je.

I to jest ten moment, gdy ja pytam: na co zawar­to umo­wę i z cze­go jest roz­li­cza­ny dostaw­ca? Tak więc dostaw­ca jest prak­tycz­nie bez­kar­ny, bo może dostar­czyć cokol­wiek… jak nazwać to ryzy­ko? Po dru­gie kry­ty­ka pro­ce­su ana­li­zy jako zbęd­ne­go poże­ra­cza cza­su i środ­ków wyma­gań nijak się ma do prak­ty­ki, co poka­zu­je przy­to­czo­ny na począt­ku wynik badań.

I dalej:

Opóźniony rezul­tat ? celem IT bar­dziej niż kie­dy­kol­wiek wcze­śniej jest dziś wspie­ra­nie biz­ne­su w jego codzien­nych dzia­ła­niach i szyb­kie reago­wa­nie na dyna­micz­ne zmia­ny w oto­cze­niu biz­ne­so­wym. W mode­lu kaska­do­wym na rezul­tat pro­jek­tu cze­ka się dłu­go, ponie­waż okre­śla go peł­na, final­na wer­sja produktu.

Dobry pro­jekt ma wizję i eta­py. Każdy etap to ogra­ni­czo­na licz­ba funk­cjo­nal­no­ści, moż­li­wych do dostar­cze­nia w cza­sie wyma­ga­nym przez biz­nes. Nie widzę powo­dów, by dzia­ła­ją­ce pod­sys­te­my dostar­czać np. kwar­tal­nie, i tak się dzieje.

Bardzo mała ela­stycz­ność pod­czas pro­jek­tu ? biz­nes ule­ga cią­głym zmia­nom, co w oczy­wi­sty spo­sób pocią­ga za sobą zmia­ny ocze­ki­wań doty­czą­cych funk­cjo­nal­no­ści zama­wia­ne­go opro­gra­mo­wa­nia. Model kaska­do­wy kon­trak­tu­je pro­jekt na eta­pie ana­liz (lub nawet wcze­śniej), po czym obu stro­nom trud­no jest bez ryzy­ka wno­sić istot­ne zmia­ny do zapla­no­wa­nych prac.

Po pierw­sze nie wiem skąd autor wziął tezę o tym, że Model kaska­do­wy kon­trak­tu­je pro­jekt na eta­pie ana­liz (lub nawet wcze­śniej”. Model kaska­do­wy nie ma tu nic do rze­czy. Dobra umo­wa zawie­ra zakres pro­jek­tu, a pro­jekt ma cel biz­ne­so­wy, i nie powin­no nim być zatrud­nie­nie pro­gra­mi­stów na kwar­tał po jakiejś staw­ce, a wytwo­rze­nie cze­goś kon­kret­ne­go i nazwa­ne­go w kon­kret­nym czasie.

System, w któ­rym imple­men­ta­cję poprze­dza ana­li­za i pro­jek­to­wa­nie dzie­li się na eta­py jak każ­dy inny. Po dru­gie nie praw­dą jest, że kon­trak­tu­je się od razu całość. Dobry pro­jekt ma oddzie­lo­ny etap pro­jek­to­wa­nia od wyko­na­nia, klu­czem jest raczej to na jaki zakres rzu­ca się”, zamawiający.

Potencjalnie więk­sze kosz­ty ? w pro­jek­tach IT liczy się nie tyl­ko zwrot z inwe­sty­cji (ROI), ale też czas, w jakim ponie­sio­ne inwe­sty­cje zaczy­na­ją się zwracać.

Tu odno­szę wra­że­nie, że autor nie rozu­mie co napi­sał albo jest to błąd redak­cyj­ny… zwrot z inwe­sty­cji to zysk w cza­sie, więc nie ma zna­cze­nia nic poza cał­ko­wi­tym kosz­tem i cza­sem w jakim go liczymy.

Biznes jest dziś tak dyna­micz­ny, że dużą korzy­ścią jest dla nie­go względ­nie szyb­ki dostęp do dosta­tecz­nie dobrych roz­wią­zań. W podej­ściu kaska­do­wym czas ocze­ki­wa­nia na final­ny pro­dukt jest bar­dzo długi.

Kolejna nie­praw­da, czas ocze­ki­wa­nia jest dokład­nie taki jaki zapla­no­wa­no… moż­na pla­no­wać podział duże­go pro­jek­tu na pod­sys­te­my (jak wyżej).

Duże ryzy­ko złych rela­cji ? model kaska­do­wy z zało­że­nia dzie­li obie stro­ny kon­trak­tu na dwa obo­zy: dostaw­cy i odbior­cy rozwiązania.

To cie­ka­wost­ka, nie wiem skąd autor wysnuł taki wniosek.…

Marnotrawstwo cza­su i pie­nię­dzy przez biu­ro­kra­cję ? pra­ca opar­ta na czę­stych ite­ra­cjach i powta­rzal­nym pro­ce­sie (sprin­tach) pozwa­la bar­dzo szyb­ko iden­ty­fi­ko­wać nie­do­sko­na­ło­ści spe­cy­fi­ka­cji i luki w pier­wot­nej kon­cep­cji. Strony mogą szyb­ko zorien­to­wać się, że na eta­pie przy­go­to­waw­czym np. nie wzię­to pod uwa­gę istot­nych kom­po­nen­tów lub inter­fej­sów. W mode­lu wodo­spa­do­wym wno­sze­nie zmian wią­że się naj­czę­ściej z pisa­niem anek­sów i rene­go­cjo­wa­niem kontraktu.

Kolejna nie­praw­da. czę­ste ite­ra­cje to czę­ste popraw­ki pro­jek­tu w poszu­ki­wa­niu wła­ści­we­go roz­wią­za­nia”. Takie same ite­ra­cje robi ana­li­tyk na eta­pie ana­li­zy i pro­jek­to­wa­nia, two­rząc pro­jekt na papie­rze”, rzecz w tym, że ana­li­tyk na papie­rze robi to sam w cią­gu poje­dyn­czych godzin a zespół pro­gra­mi­stów robi to kil­ka dni kosz­tem kil­ku­na­stu oso­bod­nió­wek” tego zespo­łu. Koszty i czas łatwo sobie porównać…

W Scrum wszyst­kie nie­do­pa­trze­nia moż­na natych­miast uwzględ­nić na każ­dym eta­pie reali­za­cji pro­jek­tu, bez koniecz­no­ści uru­cha­mia­nia nie­wy­god­nej dla obu stron, i czę­sto burzą­cej rela­cje biz­ne­so­we, pro­ce­du­ry obsłu­gi zmian (Change Requests). Jeśli podej­ście słu­ży pro­jek­to­wi, a tak jest w przy­pad­ku Scrum, dostaw­ca i odbior­ca ela­stycz­nie dopa­so­wu­ją się do sie­bie nie­za­leż­nie od tego, jak dale­ce zmie­nia­ją się ocze­ki­wa­nia i potrze­by biznesowe.

Jeżeli autor uwa­ża, że wpro­wa­dza­nie ad-hoc nie­for­mal­nych zmian w zakre­sie pro­jek­tu czy­ni pro­jekt lep­szym, to pozo­sta­wiam go z tym przeświadczeniem.

Scrum pole­ga na wspól­nym widze­niu celu, jakim jest roz­wią­za­nie kon­kret­ne­go pro­ble­mu biz­ne­so­we­go. Jest to czę­sto dale­kie odej­ście od sztyw­nej inter­pre­ta­cji zapi­sów kon­trak­to­wej spe­cy­fi­ka­cji wyma­gań, któ­re same w sobie narzu­ca­ją zespo­łom pro­jek­to­wym ogra­ni­cze­nia reali­za­cyj­ne (tech­nicz­ne) nie­za­leż­nie od pro­ble­mu jaki jest rze­czy­wi­ście do roz­wią­za­nia. Zaletą Scrum jest przej­rzy­stość i wyso­ka ela­stycz­ność projektu.

Tu przy­to­czę sło­wa moje­go kole­gi prawnika:

Największym pro­ble­mem spo­rów przed sądem, w spo­rach z fir­ma­mi pro­gra­mi­stycz­ny­mi jest to, że wie­le tych firm nicze­go nie doku­men­tu­je i tak na praw­dę nie wia­do­mo o co toczy się spór. Większość takich spraw zakła­da­ją pokrzyw­dzo­ne fir­my, nabyw­cy usług pro­gra­mi­stycz­nych. W zasa­dzie więk­szość tych spraw, te fir­my wła­śnie prze­gry­wa­ją, bo nie wia­do­mo co mia­ło powstać a wia­do­mo ile mia­ło kosz­to­wać. Tu sądy są bez­sil­ne… wygry­wa­ją pro­gra­mi­ści, mając pie­nią­dze mimo, że nie osią­gnię­to celu zama­wia­jąc. Ale win­ni są sobie wyłącz­nie zama­wia­ją­cy, godzą­cy się na taką treść tych umów…

A co mówią statystyki?

Analysts report that as many as 71 per­cent of softwa­re pro­jects that fail do so becau­se of poor requ­ire­ments mana­ge­ment, making it the sin­gle big­gest reason for pro­ject failure?bigger than bad tech­no­lo­gy, mis­sed deadli­nes or chan­ge mana­ge­ment fia­sco­es. ( źr. Fixing the Software Requirements Mess CIO​.com).

Parząc na powyż­sze (wytłusz­cze­nie: w więk­szo­ści z ponad 71% złych pro­jek­tów pro­gra­mi­stycz­nych, powo­dem kło­po­tów było złe zarzą­dza­nie wyma­ga­nia­mi, co czy­ni­ło więk­sze szko­dy niż pozo­sta­łe powo­dy, takie jak tech­no­lo­gie, napię­te ter­mi­ny czy zarzą­dza­nie zmia­na­mi, razem wzię­te). I niech nikt mi nie mówi, że 29% to same SCRUM’y a pozo­sta­łe 71% to kaska­do­we” pro­jek­ty bo to nieprawda.

Na zakończenie

Tak więc zasta­nów­my się czy aby na pew­no brak pro­jek­tu i spe­cy­fi­ka­cji wyma­gań to dobry spo­sób na pro­jekt IT. Czy meto­dy wytwa­rza­nia bazu­ją­ce na bra­ku pier­wot­ne­go pro­jek­tu, fak­tycz­nie są zba­wie­niem pro­jek­tów pro­gra­mi­stycz­nych… Państwo sami muszą wybrać… Dodam na koniec, że powyż­sze doty­czy w takim samym stop­niu sys­te­mów dedy­ko­wa­nych jak i goto­wych a wyma­ga­ją­cych kasto­mi­za­cji” bo to (nowe funk­cjo­nal­no­ści sys­te­mu) tak­że pro­jekt dedykowany.

Dilbert wymagania na oprogramowanie

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. jacek2v 10 października 2011 at 22:29

    Z więk­szo­ścią Pana komen­ta­rzy nie zga­dzam się, ale 🙂 też cyto­wa­ny arty­kuł nie jest do koń­ca trafny.
    Zgadzam się cał­ko­wi­cie z tym : 71 per­cent of softwa­re pro­jects that fail do so becau­se of poor requ­ire­ments mana­ge­ment, ..” i uwa­żam, że pro­blem leży po stro­nie klien­ta – któ­ry czę­sto nie wie cze­go chce – i dostaw­cy – któ­ry pra­wie zawsze nie potra­fi pomóc klien­to­wi. I nie pomo­gą stwier­dze­nia : Dobry pro­jekt ma oddzie­lo­ny etap pro­jek­to­wa­nia od wyko­na­nia, klu­czem jest raczej to na jaki zakres ?rzu­ca się?, zama­wia­ją­cy” jeśli obie stro­ny rozu­mie­ją ina­czej”. Jedynie co poma­ga to pro­to­ty­po­wa­nie, a w pro­jek­tach pro­wa­dzo­nych zwin­nie pro­to­ty­po­wa­nie dziej się ciągle 🙂

    Przy pew­nym kon­flik­cie” inte­re­sów mię­dzy dostaw­cą (chce zro­bić to na co się umó­wił) i zama­wia­ją­ce­go (chce pro­dukt, któ­ry będzie dzia­łał) model kaska­do­wy słu­ży jedy­nie temu pierw­sze­mu, ponie­waż poru­sza się w zna­nej sobie ter­mi­no­lo­gii i tech­no­lo­gii, a dla zama­wia­ją­ce­go to czę­sto coś pra­wie jak magia 🙂 – jak to bodaj­że A.Clark napi­sał: Każda dosta­tecz­nie zaawan­so­wa­na tech­no­lo­gia niczym szcze­gól­nym nie róż­ni się od magii”. Zamawiający zaś może w łatwy spo­sób zwe­ry­fi­ko­wać czy pro­to­typ odpo­wia­da jego wyobra­że­niom i potrze­bom. Znaczna więk­szość klien­tów nie chce pro­jek­tu, nawet nie chce ana­li­zy oni ocze­ku­ją dzia­ła­ją­ce­go produktu.

    • Jarek Żeliński 10 października 2011 at 23:00

      Parafrazując ostat­nie zda­nie: znacz­na więk­szość pacjen­tów nie chce cho­dzić do leka­rza i badać się, chcą od razu wła­ści­we piguł­ki i być zdrowi …

      Ponawiam pyta­nie: co jest przed­mio­tem umo­wy na wyko­na­nie opro­gra­mo­wa­nia? Na co się umó­wił dostawca”?

    • jacek2v 11 października 2011 at 11:10

      Moim zda­niem porów­na­nie do leka­rza nie jest traf­ne – chy­ba, że rze­czy­wi­ście klient upadł na gło­wę” i chce kupić co jest mu nie potrzeb­ne :). Mimo to posta­ram się na tym porów­na­niu wyja­śnić. Znacznej więk­szo­ści pacjen­tów nie cho­dzi o robie­nie badań (mówię tu o zdro­wych na umy­śle :)) i odwie­dza­niu szpi­ta­li, nawet nie chcą wła­ści­wej piguł­ki, ale chcą być zdro­wi. Nauczyliśmy się, że pewien trud trze­ba wyko­nać (bada­nia), aby lekarz mógł wyko­nać swo­ją pra­cę dobrze, ale kie­dyś wie­rzy­li­śmy, że upusz­cza­nie krwi jest koniecz­ne :). Ja twier­dzę, że podej­ście z twar­dą” umo­wą, kaska­do­we, czy też z roz­bu­do­wa­ną doku­men­ta­cją są upusz­cza­niem krwi”.
      Jeszcze ina­czej – jako, że znam bli­sko kil­ku leka­rzy to jestem na bie­żą­co 🙂 – pew­na ilość pacjen­tów koniecz­nie pro­si o wyko­na­nie pew­nych badań, bo tak sobie wymy­śli­ła, albo im ktoś powie­dział, że trze­ba je zro­bić – lubią ten trud (two­rze­nia doku­men­ta­cji). Dobry lekarz odma­wia, tłu­ma­czy, edu­ku­je, czy też wręcz opier­da­la za głu­po­tę :), zły kasu­ję kasę z uśmie­chem na ustach :).

      Ad.?Na co się umó­wił dostawca??
      Jak się umó­wił na zro­bie­nie papie­ra to niech robi i klient ma pro­blem bo celem jest papier, a nie dzia­ła­ją­cy sys­tem i tyle. Jak obie stro­ny chcą się umó­wić na dzia­ła­ją­cy sys­tem to spi­su­ją funk­cje, zało­że­nia, opis efek­tu koń­co­we­go i jedzie­my. Po co gene­ro­wać tony doku­men­ta­cji? Nie lepiej wery­fi­ko­wać pro­to­ty­pem? Mitem jest, że każ­da zmia­na opro­gra­mo­wa­nia jest kosz­tow­na. Najbardziej kosz­tow­na zmia­na wyni­ka z nie­zro­zu­mie­nia przy opi­sie funk­cji, zało­żeń, czy efek­tu koń­co­we­go w umo­wie. Dlatego robi się pro­to­ty­py i pilo­ty. Dokumentacja w niczym nie pomo­że, ponie­waż trze­ba ją zro­zu­mieć. A nawet jeśli zama­wia­ją­cy wło­ży ten wysi­łek i prze­czy­ta ją, i nie­za­leż­nie od tego ile wysił­ku wło­ży to i tak zro­zu­mie ina­czej niż my 🙂
      Koszt zmia­ny zale­ży od kom­pe­ten­cji dostaw­cy i jako­ści wyko­na­nia opro­gra­mo­wa­nia. Czym bar­dziej doświad­czo­ny wyko­naw­ca tym lepiej i wcze­śniej prze­wi­dzi pro­ble­my. Czym lep­szy kod tym bar­dziej ela­stycz­ny. Czym wyż­szy poziom kul­tu­ry tech­nicz­nej tym spraw­niej idzie pro­jekt. I baro­ko­wa doku­men­ta­cja nic tu nie pomo­że, a wręcz będzie prze­szka­dzać i opóźniać.
      Podsumowując: Uważam doku­men­ta­cję za nie­zbęd­ną, ale w stop­niu koniecz­nym do zapla­no­wa­nia i wyko­na­nia opro­gra­mo­wa­nia oraz z ogra­ni­cze­niem narzu­co­nym na czas i obję­tość. 🙂 Czyli jak wycho­dzi za duża to coś jest źle. Wolę jeden dobrze prze­my­śla­ny (ale bez wszyst­kich szcze­gó­li­ków) dia­gram, niż 200 stro­ni­co­wy szcze­gó­ło­wy opis. A sła­bość w tra­dy­cyj­nych meto­dach wytwa­rza­nia w IT widzę wła­śnie w nie­zwra­ca­nie uwa­gi ma ludzi, któ­ry w tym pro­ce­sie uczest­ni­czą. Nie bra­ne są pod uwa­gę jakie moż­li­wo­ści per­cep­cji mają two­rzą­cych doku­men­ty i czy­ta­ją­cych doku­men­ty, jak poj­mu­ją pew­ne spra­wy ludzie po stro­nie biz­ne­su i po stro­nie IT (np. programiści).
      Te wszyst­kie ele­men­ty są uwzględ­nia­ne w meto­dy­kach zwin­nych – nietradycyjnych 🙂

    • Jarek Żeliński 11 października 2011 at 11:23

      Co do leka­rza, bada­nia są nie po to by je wyko­nać a po to by lekarz zyskał wie­dzę o tym z czym wal­czy” (wywiad z pacjen­tem nie zastą­pi bada­nia krwi…). Ale do rze­czy: sko­ro jed­nak nale­ży opi­sać funk­cje, zało­że­nia, opis efek­tu koń­co­we­go” to jed­nak doku­ment wyma­gań powsta­je, pyta­nie brzmi: jak powsta­je ten doku­ment? Wracając do pole­ga­nia tyl­ko na ludziach: co powsta­nie i jak prze­ży­je to fir­ma jeże­li np. nowy sys­tem wyna­gro­dzeń powsta­nie na bazie wywia­dów i życzeń pra­cow­ni­ków? Związki zawo­do­we tu to pikuś…

    • jacek2v 11 października 2011 at 11:33

      Ad.„jak powsta­je ten dokument?”
      A czy to ma zna­cze­nie? Ważne jest, aby obie stro­ny tak samo go rozu­mia­ły i podpisały.
      Ad.„Wracając do pole­ga­nia tyl­ko na ludziach”
      Nie tyl­ko”, ale głów­nie – to różnica.
      co powsta­nie i jak prze­ży­je to fir­ma jeże­li np. nowy sys­tem wyna­gro­dzeń powsta­nie na bazie wywia­dów i życzeń pracowników?”
      Pyta się zama­wia­ją­ce­go (spon­so­ra, inwe­sto­ra), a nie pracownika 🙂
      Odnosząc się do przy­kła­du powtó­rzę jesz­cze raz: jeśli zama­wia­ją­cy chce byśmy sami zna­li prze­pi­sy, popy­ta­li pra­cow­ni­ków i przy­go­to­wa­li papier – no to robi­my to i tyle. Jeśli zama­wia­ją­cy mówi zrób­cie sys­tem nali­cza­ją­cy pła­ce i załóż­my, że ma być to tak jak teraz. No to pro­si­my o doku­men­ta­cję tego teraz” i/lub eks­per­ta od klien­ta, któ­ry zezna jak jest teraz i co jest istot­ne. Mamy notat­kę ze spo­tka­nia (lub spo­tkań) i to jest wkład do umowy.

    • Jarek Żeliński 11 października 2011 at 11:39

      Jest bar­dzo waż­ne jak powstał ten doku­ment” bo spo­sób jego wytwo­rze­nia świad­czy o jego wia­ry­god­no­ści… Widzę świa­teł­ko w tune­lu: Pyta się zama­wia­ją­ce­go (spon­so­ra, inwe­sto­ra), a nie pra­cow­ni­ka”. Kolejne pyta­nie: któ­ry plan mia­sta będzie wia­ry­god­niej­szy: ten na bazie wywia­dów z jego miesz­kań­ca­mi (nawet jeśli jed­nym z nich będzie Burmistrz, spon­sor pro­jek­tu) czy ten ba bazie pomia­rów i zdjęć lotniczych?

      Pytanie dodat­ko­we: spon­sor zamó­wił kor­bę”. Co jest lep­szym załącz­ni­kiem do umo­wy na jej wyko­na­nie: rysu­nek kor­by czy jej słow­ny opis (pro­po­nu­ję w ramach ćwi­cze­nia wyko­nać słow­ny opis kor­by bez uży­cia sło­wa KORBA).

  2. jacek2v 11 października 2011 at 11:52

    któ­ry plan mia­sta będzie wia­ry­god­niej­szy: ten na bazie wywia­dów z jego mieszkańcami”
    Nie rozu­miem związ­ku ale oczy­wi­ście ten ostatni 🙂
    Co jest lep­szym załącz­ni­kiem do umo­wy na jej wyko­na­nie: rysu­nek kor­by czy jej słow­ny opis”
    Nie wiem czy dobrze zro­zu­mia­łem przy­to­czo­ne przykłady:
    Czyżby się Pan zaczy­nał ze mną zgadzać?
    W rewan­żu pro­szę zro­bić zdję­cie kor­by od stro­ny rącz­ki i spraw­dze­nie na ile jest war­te 🙂 Podpowiem: widać będzie kół­ko i drążek.
    Przykład z kor­bą, ćwi­czy­łem wie­le lat temu i moim zda­niem w kon­tek­ście dys­ku­sji nicze­go nie dowo­dzi. No cóż dla mnie tru­izm: obraz wię­cej zna­czy niż opis i … dzia­ła­nie znacz­nie wię­cej zna­czy niż opis działania 😛

    • Jarek Żeliński 11 października 2011 at 12:18

      Dochodzę do wnio­sku, że zga­dza­my się co do tego, że jed­nak coś jest pla­no­wa­ne, że jed­nak rysu­nek lep­szy od pro­zy. Problem chy­ba tu jest taki, że jeże­li ktoś (być może Pan) miał do czy­nie­nia z opi­sa­mi wyma­gań w posta­ci ste­ku nie­spój­nej pro­zy pisa­nej ręka­mi zama­wia­ją­ce­go lub będą­ce­go zapi­sem (dyk­ta­fon?) wywia­dów to moż­na takie ana­li­zy znie­na­wi­dzić. Jeżeli miał Pan do czy­nie­nia ze ster­ta­mi bez­sen­sow­nych dia­gra­mów to tak­że moż­na moż­na je znie­na­wi­dzić. Co do kor­by, owszem dla­te­go każ­dy pro­jekt robi się z kil­ku per­spek­tyw (prze­kro­je) i wte­dy jest OK. Co do zaś dzia­ła­nie znacz­nie wię­cej zna­czy niż opis dzia­ła­nia” to ja jed­nak wyzna­ję zasa­dę: naj­pierw pomyśl potem rób”… Być może się nawet zga­dza­my.… pro­po­nu­je spoj­rzeć na to https://​it​-con​sul​ting​.pl/​2​0​2​0​/​1​2​/​1​1​/​a​n​a​l​i​z​a​-​b​i​z​n​e​s​o​w​a​-​o​d​-​z​l​e​c​e​n​i​a​-​d​o​-​k​o​m​p​l​e​t​n​e​g​o​-​p​r​o​j​e​k​t​u​-​t​e​c​h​n​i​c​z​n​e​g​o​-​z​-​u​z​y​c​i​e​m​-​n​a​r​z​e​d​z​i​a​-​c​a​se/ to mała namiast­ka cze­goś co moim zda­niem jest jed­nak lep­sze od dzia­ła­nia zamiast pisania”.…

    • jacek2v 11 października 2011 at 13:38

      Ad.”…postaci ste­ku nie­spój­nej pro­zy pisa­nej ręka­mi zama­wia­ją­ce­go…” „… ze ster­ta­mi bez­sen­sow­nych diagramów…”
      Miałem do czy­nie­nia, (nie dzi­wi­łem się :)) nie cho­dzi­ło mi o tego rodza­ju doku­men­ta­cję. Chodziło mi np. o doku­men­ta­cje, któ­rej przy­go­to­wa­nie trwa­ło kil­ka-kil­ka­na­ście mie­się­cy, wie­lo­stro­ni­co­wą, do któ­rej dosta­ję dopi­sek, ale to już się u nas zmie­ni­ło” 🙂 Albo doku­men­ta­cję, wg któ­rej apli­ka­cję klient skwi­to­wał stwier­dze­niem: no tak pod­pi­sa­łem papier, ale ja to sobie wyobra­ża­łem ina­czej, czy­ta­jąc ten papier”.Zaglądamy w papier i rze­czy­wi­ście moż­na to też zro­zu­mieć w spo­sób w jaki zro­zu­miał klient 🙂
      Ad.http://modelowaniebiznesowe.biz.pl/CaseStudy%20Biblioteka.pdf ta doku­men­ta­cja nie wyda­je mi się moc­no nad­mia­ro­wa (na eta­pie już uru­cho­mio­ne­go pro­jek­tu), ale ‑z moje­go doświad­cze­nia – nie­straw­na dla więk­szo­ści zama­wia­ją­cych. Ale widzę jej zasto­so­wa­nie w komu­ni­ka­cji w zespole.
      Aby powie­dzieć, czy jest ona ok. bra­ku­je tu ele­men­tu cza­su, tzn. ile cza­su zaję­ło przy­go­to­wa­nie tego rodza­ju doku­men­tu. Czas jest bar­dzo waż­nym ele­men­tem w meto­dach zwin­nych, ponie­waż decy­du­je czę­sto o przy­ję­tej strategii.

    • Jarek Żeliński 11 października 2011 at 14:34

      No to widzę nic poro­zu­mie­nia :). Po pierw­sze zga­dzam się, że jeśli doku­men­ta­cja powsta­je dłu­żej niż kwar­tał jest z zasa­dy bez­u­ży­tecz­na. Zgadzam się, że jeże­li jej koszt dorów­nu­je kosz­to­wi sys­te­mu nie war­ta jest wyko­na­nia. Tu mogę powo­łać się na sło­wa tre­ne­ra jed­ne­go ze szko­leń: dobrze opra­co­wa­ny sys­tem jest odda­wa­ny jako pierw­sza ite­ra­cja, jego imple­men­ta­cja (lub jeden uży­tecz­ny kom­po­nent) powin­na mie­ścić się w kwar­ta­le, opra­co­wa­nie pro­jek­tu zaś powin­no trwać nie dłu­żej niż kwar­tał i kosz­to­wać nie wię­cej niż 20% cało­ści (nie mówię tu o kosz­tach uzy­ska­nia wydaj­no­ści czy nie­za­wod­no­ści). Co do doku­men­tu Biblioteka to mam mini­mal­ne ocze­ki­wa­nia od zespo­łu imple­men­tu­ją­ce­go: zna­jo­mość i rozu­mie­nie obiek­to­wych narzę­dzi, zna­jo­mość UML, zna­jo­mość wzor­ców pro­jek­to­wych, ktoś musi być tam dobrym archi­tek­tem. Czas opra­co­wa­nia doku­men­tu takie­go (obję­tość) jak owa Biblioteka dla mnie jed­ne­go to jeden dzień na wywia­dy i jed­ne na opra­co­wa­nie. Po dro­dze ma miej­sce pre­zen­ta­cja dla klien­ta (ten nie zna ani UML ani innych rze­czy) wiec ja recy­tu­ją a klient słu­cha, zgła­sza uwa­gi lub akceptuje.

    • jacek2v 11 października 2011 at 21:08

      Kluczowe jest: ocze­ki­wa­nia od zespo­łu imple­men­tu­ją­ce­go” i dla klien­ta (ten nie zna ani UML ani innych rzeczy)”
      Przykład jest try­wial­ny :), dla­te­go sztu­ką jest robić w takich ramach cza­so­wych pro­jek­ty nie­try­wial­ne. A to umoż­li­wia podej­ście zwin­ne – nie­tra­dy­cyj­ne. Przy podej­ściu tra­dy­cyj­nym, trze­ba uda­wać, że dzie­li­my pro­jekt na pod­pro­jek­ty lub eta­py itp.

    • Jarek Żeliński 11 października 2011 at 22:28

      rozu­miem, że 100 przy­pad­ków uży­cia SCRUM zała­twia w dwa dni?

  3. jacek2v 12 października 2011 at 10:10

    rozu­miem, że 100 przy­pad­ków uży­cia SCRUM zała­twia w dwa dni?”
    To jest prze­sad­ne uprosz­cze­nie wręcz zło­śli­we spły­ce­nie :). Odpowiem krót­ko: nie 🙂

    • Jarek Żeliński 12 października 2011 at 18:22

      To pró­ba testo­wa­nia tezy na skraj­nych danych…

    • jacek2v 13 października 2011 at 12:00

      Taki dziw­ny test. Tak jak­by Pan chciał testo­wać odpor­ność zegar­ka na wstrzą­sy pod­kła­da­ją pod pra­cę o naci­sku 1T/cm2 i zdzi­wił się, że nie wytrzy­mał 🙂 Ani to nie wstrząs, ani nie ade­kwat­ne obcią­że­nie do rzeczywistość.
      Ani SCRUM (czy inna meto­dy­ka) nicze­go nie zała­twia, ani też nie ade­kwat­ne jest to rze­czy­wi­sto­ści pro­jek­to­we. Jak dla mnie czy­sta złośliwość 😛

    • Jarek Żeliński 13 października 2011 at 13:36

      ten test to co inne­go: jeże­li testu­je sys­tem to w ramach sce­na­riu­szy testo­wych pod­rzu­cam tak­że dane nie­lo­gicz­ne, sprzecz­ne itp. któ­ry sys­tem powi­nien odrzu­cić bez zawie­sza­nia się”, jeśli tego nie zro­bi to nie prze­szedł testów… tak więc proś­ba wysta­wie­nia fak­tu­ry VAT (lub prze­le­wu w ban­ku) w sys­te­mie na kwo­tę 3 mld. powin­na wyge­ne­ro­wać co naj­mniej kil­ka dodat­ko­wych pytań… to nie zło­śli­wość tyl­ko testo­wa­nie hipo­tez (dobra teo­ria powin­na defi­nio­wać sytu­acje, któ­re ją oba­la­ją jeśli wystą­pią, pole­cam Karl Popper i falsyfikację).

    • jacek2v 13 października 2011 at 13:39

      któ­ry sys­tem powi­nien odrzu­cić bez ?zawie­sza­nia się?, ”
      Metodyka to nie system.
      BTW: W tra­dy­cyj­nych meto­dy­kach nie ma scenariuszy.

    • Jarek Żeliński 13 października 2011 at 23:54

      są w tych, któ­re ja stosuję…

  4. jacek2v 14 października 2011 at 10:10

    są w tych, któ­re ja stosuję?”
    Niestety nie znam takiej. Czy mógł­by się Pan podzie­lić o jakiej meto­dy­ce Pan mówi?

    • Jarek Żeliński 14 października 2011 at 14:25

      pro­po­nu­ję spraw­dzać ter­mi­ny szko­leń i kon­fe­ren­cji na jakich mam refe­ra­ty.. tu nie­ste­ty nie widzę miej­sca na szko­le­nie a i czas nie pozwala…

    • jacek2v 14 października 2011 at 14:34

      Mhh, jeśli jest to nie­stan­dar­do­wa meto­dy­ka, to w takim razie to nie jest żaden argument:?są w tych, któ­re ja stosuję?? 🙂
      Ponieważ przy takim podej­ściu, moż­na sobie wyobra­zić dowol­ną kom­bi­na­cję ele­men­tów z dowol­nej puli meto­dyk i w ten spo­sób udo­wod­nić dowol­ną teo­rię prze­ma­wia­ją­cą za lub prze­ciw tra­dy­cyj­nych czy też nie­tra­dy­cyj­nych metodyk.
      W tym przy­pad­ku zasto­so­wał Pan ele­men­ty (sce­na­riu­sze) meto­dyk nie­tra­dy­cyj­nych to Pana meto­dy­ka na pew­no nie jest tra­dy­cyj­na 🙂 Dowolność sto­so­wa­nia lub nie sto­so­wa­nia róż­nych ele­men­tów meto­dyk jest wła­ści­wa meto­dy­kom nie­tra­dy­cyj­nym (zwin­nym) 😛

    • Jarek Żeliński 14 października 2011 at 22:44

      to nie jest nic nie­stan­dar­do­we­go… pro­po­nu­ję http://www.omg.rog/mda oraz lite­ra­tu­rę na temat pro­to­ty­pow­nia z pomo­cą modeli …

    • jacek2v 15 października 2011 at 10:48

      MDA nie jest meto­dy­ką i nie ma sce­na­riu­szy. Opierając się w dużej czę­ści na UML, posia­da Use Case, ale to coś inne­go niż sce­na­riusz. Nie jest moją inten­cją popy­cha­nie dys­ku­sji w kie­run­ku spie­ra­nia się o wyż­szość świąt …”. Właściwie to nie wiem jaki jest cel tej dys­ku­sji 🙂 Ja twier­dzę, że tra­dy­cyj­ne meto­dy­ki są nie­do­bre (głów­nie z powo­du kaska­do­we­go roz­ło­że­nia w cza­sie ), a Pan też wypo­wia­da się o nich nie­po­chleb­nie w pierw­szych sło­wach arty­ku­łu 🙂 Mylące jest tyl­ko to, że MDA nie jest meto­dy­ką. MDA naj­bar­dziej bra­ku­je metod zarzą­dza­nia pro­ce­sem (w cza­sie) i zespołem.

    • Jarek Żeliński 15 października 2011 at 21:23

      moim zda­niem kaska­do­wość czy agil­ność to nie pro­blem, jak się to robi, pro­blem w tym czy robi się to w spo­sób sfor­ma­li­zo­wa­ny czy nie­for­mal­mal­ny-swo­bod­ny… meto­dy nie­for­mal­ne są nie­we­ry­fi­ko­wal­ne, skut­ki zna­my dopie­ro widzą pro­dukt, w meto­dach sfor­ma­li­zo­wa­nych poten­cjal­ne skut­ki widać na mode­lach, czy­li szyb­ciej i taniej.…

    • jacek2v 15 października 2011 at 16:33

      Dziwne ostat­ni mój post nie poja­wił się 🙂
      Krótko: MDA to nie meto­dy­ka i tu jest pies pogrze­ba­ny 🙂 Brakuje w niej zarzą­dza­nia pro­ce­sem (w cza­sie) i zespołem.

    • Jarek Żeliński 15 października 2011 at 21:19

      Metodyka to zbiór metod, MDA jest meto­dą… zarzą­dza­nie pro­ce­sem a pro­ces… gdzie gra­ni­ca? Proponuje zapo­znać się z pro­ce­sem ana­li­zy sys­te­mo­wej”. Proces ten zawie­ra etap budo­wa­nia i testo­wa­nia mode­li, a model w ana­li­zie sys­te­mo­wej jest hipo­te­zą takie roz­wią­za­nie speł­ni wyma­ga­nia”, budu­je­my sce­na­riu­sze testo­we i bada­my model. Model (tu np. sto­sow­ne dia­gra­my UML), któ­ry przej­dzie testy sta­je się pro­jek­tem opro­gra­mo­wa­nia, któ­re ma powstać. Więcej o tym napi­sa­łem w jed­nym z poprzed­nich postów.

  5. jacek2v 16 października 2011 at 11:47

    Metodyka to zbiór metod, MDA jest meto­dą? zarzą­dza­nie pro­ce­sem a pro­ces? gdzie gra­ni­ca? Proponuje zapo­znać się z ?pro­ce­sem ana­li­zy systemowej?.”
    Proszę nie ucie­kać w teoretyzowanie 🙂
    Odwołuje się Pan do kaska­do­we­go pro­ce­su pro­jek­to­wa­nia i wytwa­rza­nia opro­gra­mo­wa­nia”, a nie moż­na mówić o MDA w tym kon­tek­ście, ponie­waż ten spo­sób pro­jek­to­wa­nia apli­ka­cji nie posia­da w sobie opi­sów zarzą­dza­nia pro­ce­sa­mi wytwa­rza­nia jak i same­go pro­ce­su wytwarzania.
    Nie mam nic prze­ciw­ko MDA – śle­dzi­łem i kibi­co­wa­łem jej powsta­niu 🙂 – nawet zro­bi­łem jeden, czy dwa pro­jek­ty sto­su­jąc MDA. Ale to cał­ko­wi­cie coś inne­go niż np. Price, PMBok, Scrum, Kanban.
    Proszę spoj­rzeć na trój­kąt pro­jek­to­wy zakres+budżet+czas. MDA wspie­ra czę­ścio­wo zakres” i budżet”. Częściowo zakres” ponie­waż nie wspie­ra dys­try­bu­cji zakre­su w zespo­le. Oczywiście moż­na się jakoś uma­wiać kto co robi, ale tego nie ma w tych meto­dach”. budżet” wspie­ra ponie­waż jest on w dużej czę­ści pochod­ną zakre­su”.

    • Jarek Żeliński 16 października 2011 at 20:41

      pro­ces zarzą­dza­nia pro­jek­tem to pro­ces, pro­ces ana­li­zy sys­te­mo­wej to tak­że pro­ces… nie spro­wa­dzał bym wszyst­kie­go do pro­ce­su zarzą­dza­nia i świę­te­go trój­ką­ta”. Czego nie ma w «tych meto­dach” a powin­no? Po dru­gie dzie­le­nie wszyst­kie­go na zarzą­dza­nie pro­jek­tem” i jakieś inne mało waż­ne rze­czy” pro­wa­dzi na manow­ce, naj­lep­szy kie­row­nik pro­jek­tu i pro­ces zarzą­dza­nia nim nie stwo­rzy ani pro­jek­tu ani opro­gra­mo­wa­nia, bo robią to ana­li­ty­cy, pro­jek­tan­ci, archi­tek­ci i pro­gra­mi­ści. Kierownik pro­jek­tu i pro­ject mana­ge­ment” są waż­ni ale oni są dla pro­jek­tu a nie odwrot­nie. Jeżeli jest moż­li­we by pro­gra­mi­sta napi­sał pro­gram bez PM’a, tak w dru­gą stro­nę to nie dzia­ła. Po dru­gie, całym sza­cun­kiem ale MDA ma się PMI czy Prince2 jak pięść do nosa…

    • jacek2v 16 października 2011 at 21:39

      pro­ces zarzą­dza­nia pro­jek­tem to pro­ces, pro­ces ana­li­zy sys­te­mo­wej to tak­że pro­ces? nie spro­wa­dzał bym wszyst­kie­go do pro­ce­su zarzą­dza­nia i ?świę­te­go trójkąta?”
      Nie spro­wa­dzam. Jedynie sta­ram się Panu poka­zać, że pro­ces ana­li­zy to tyl­ko jeden z ele­men­tów meto­dy­ki pro­wa­dze­nia pro­jek­tów. Nie moż­na porów­ny­wać zie­lo­nych samo­cho­dów z ogór­ka­mi 🙂 – narzę­dzi do ana­li­zy (np.MDA) i meto­dyk zarządzania/prowadzenia pro­jek­tów (meto­dy­ki zwin­ne, kaskadowe).

      Po dru­gie dzie­le­nie wszyst­kie­go na ?zarzą­dza­nie pro­jek­tem? i ?jakieś inne mało waż­ne rzeczy?”
      Nigdzie tego nie dzie­lę – rozróżniam.

      Kierownik pro­jek­tu i ?pro­ject mana­ge­ment? są waż­ni ale oni są dla pro­jek­tu a nie odwrotnie.”
      Nie mie­szaj­my jesz­cze PMów 🙂 to inna bajka.

      Po dru­gie, całym sza­cun­kiem ale MDA ma się PMI czy Prince2 jak pięść do nosa?”
      I tu się z Panem zga­dzam – o to mi cho­dzi­ło. Dodam, że podob­nie MDA ma się do meto­dyk Agile (np.SCRUM, Kanban, MSF for Agile) 😛 I jeśli nie ma Pan nic prze­ciw­ko, to może­my tym pod­su­mo­wa­niem skoń­czyć dyskusję 🙂

    • Jarek Żeliński 16 października 2011 at 22:39

      pro­ces ana­li­zy to tyl­ko jeden z ele­men­tów meto­dy­ki pro­wa­dze­nia pro­jek­tów” Nie, ana­li­za to, jak każ­de inne eks­perc­kie dzia­ła­nie, jakaś pra­ca, nie raz pro­ces cią­gły. Może być ele­men­tem pro­jek­tu (w rozu­mie­niu zakre­su, ter­mi­nu i budże­tu) ale nie musi. W szcze­gól­no­ści ana­li­zy pro­wa­dzo­ne na zasa­dzie czas i mate­riał (np. w dzia­łach R&D), nie mają ter­mi­nu i zakre­su (cza­sa­mi mają ter­min). Większość ana­liz to bada­nie do skut­ku” a nie pro­jek­ty. O pro­jek­cie moż­na mówić jak posia­da­my jego zakres (co nale­ży dostar­czyć), budżet i ter­min. Analiza i pro­jek­to­wa­nie to pro­ces, któ­re­go pro­duk­tem jest zakres dla pro­jek­tu. Mam wra­że­nie, że mylo­ne tu jest zarzą­dza­nie pro­jek­ta­mi, któ­re to jest czyn­no­ścią mene­dżer­ską, z ana­li­zą i pro­jek­to­wa­niem co jest czyn­no­ścią bliż­szą nauce. MDA nie ma nic wspól­ne­go z zarzą­dza­niem pro­jek­ta­mi. Podobnie jak pro­ces zale­wa­nia fun­da­men­tów beto­nem nie jest pro­jek­tem, pro­jek­tem jest zada­nie wyla­nia kon­kret­ne­go fun­da­men­tu w kon­kret­nym cza­sie i budże­cie. Stąd moje zdzi­wie­nie z porów­na­nia MDA z zarzą­dza­niem pro­jek­ta­mi i cały ten spór (wymia­na zdań ;)) i to fak­tycz­nie może spo­koj­nie zakoń­czyć ten dialog 🙂

  6. Zosia Tomaszewska 7 lutego 2012 at 13:50

    Dzień dobry. Na wstę­pie pra­gnę szep­nąć dobre sło­wo o tym blo­gu, uwa­żam, że miło czy­ta się zamiesz­cza­ne tu arty­ku­ły. Nieduża licz­ba ludzi piszą­cych w podob­nym tema­cie umie pisać języ­kiem, któ­ry potra­fi przy­cią­gnąć mnie do rzu­ce­nia okiem i sko­men­to­wa­nia arty­ku­łu. SĹ?aboĹ?ci tra­dy­cyj­nych metod wytwa­rza­nia IT – czy na pew­no sĹ?aboĹ?ci? | Analiza biz­ne­so­wa i pro­jek­to­wa­nie – JarosĹ?aw Ĺ?eliĹ?ski – blog” – ten napis już wid­nie­je wśród moich zakła­dek :). Jestem pew­na, że jesz­cze tu wró­cę. Akurat chcę posta­wić wła­sne­go blo­ga i zbie­ram wszyst­kie wska­zów­ki, któ­re mogą mi to uła­twić. Największym moim pro­ble­mem jest część tech­nicz­na i opty­ma­li­za­cja blo­ga, któ­ra ma pomóc w tym, żeby mój blog został uzna­ny w oczach Google. 

    Pozdrawiam ser­decz­nie – Zosia Tomaszewska

    P.S. Podoba mi się ta skór­ka blo­ga, skąd mogę ją ściągnąć?

  7. jutrzenka 6 kwietnia 2014 at 17:15

    Witam,

    Dziękuję za arty­kuł. Szkoda, że nie tra­fi­łem na nie­go, kie­dy moja fir­ma posta­no­wi­ła zaapli­ko­wać sobie scru­ma, być może, przy­naj­mniej do pew­ne­go stop­nia, uda­ło­by się ogra­ni­czyć licz­bę błę­dów oraz kosz­ty tej meto­dy. Korzystając zatem z popu­lar­no­ści Pana blo­ga pozwa­lam sobie za pomo­cą tego krót­kie­go komen­ta­rza prze­strzec wszyst­kich przed tą meto­dycz­ną katastrofą ;-). 

    Z per­spek­ty­wy moich wie­lo­let­nich doświad­czeń, scrum, to nic inne­go jak mar­ke­tin­go­wo opa­ko­wa­ny garaż” – tak na począt­ku nasze­go wie­ku okre­śla­no w peł­ni spon­ta­nicz­ny spo­sób two­rze­nia opro­gra­mo­wa­nia (w scur­mie nazy­wa się to samo­or­ga­ni­za­cją), gdzie pro­gra­mi­ści na bazie spo­tkań z klien­ta­mi, dostar­czo­nych mate­ria­łów w bar­dzo przy­pad­ko­wy spo­sób, pró­bo­wa­li przy­go­to­wać roz­wią­za­nie. Mieli o tyle trud­niej w sto­sun­ku do dzi­siej­szych agi­low­ców, że budżet był okre­ślo­ny z góry, więc klient mie­wał dość sil­ne narzę­dzie wywie­ra­nia wpły­wu, któ­re bywa­ło czę­sto nad­uży­wa­ne – odbiór sys­te­mów potra­fił trwać mie­sią­ca­mi. Nie było sprin­tów, ale były fazy pro­jek­tów, któ­re póź­niej zaczę­to roz­bi­ja­jąc na ite­ra­cje. W tym sen­sie tzw. feed­back nie poja­wiał się po dwóch tygo­dniach, ale jeśli ktoś prze­śle­dził­by scru­mo­we review, to szyb­ko zorien­to­wał­by się, że uwa­gi, któ­re się na nim poja­wia­ją są czę­sto try­wial­ne ? ten przy­cisk powi­nien nazy­wać się ina­czej, a ta ety­kie­ta jest nie w tym miej­scu. Z per­spek­ty­wy meto­dy a?la RUP to po pro­stu dra­stycz­ny regres. 

    Co wyni­ka z mojej tzw. obser­wa­cji uczestniczącej”?

    1. Scrum jest moc­no zide­olo­gi­zo­wa­ny. Ludzie nie chcą widzieć ogra­ni­czeń tej meto­dy. Każdego, któ­ry zwra­ca uwa­gę na choć­by potrze­bę defi­nio­wa­nia wyma­gań, mode­lo­wa­nia itp. natych­miast wrzu­ca się do wor­ka wodo­spa­do­wiec” i koń­czy dys­ku­sję. W tym sen­sie jest to meto­da nie­podat­na na myśle­nie kry­tycz­ne i istot­ne korek­ty. Teoretycznie są retro­spek­ty­wy, któ­re powin­ny kory­go­wać pro­ces, jed­nak w prak­ty­ce rama scru­mo­wa jest bar­dzo sztyw­na (typy spo­tkań są okre­ślo­ne, ich prze­bieg oraz moż­li­wy out­put rów­nież), a dodat­ko­wo zabez­pie­cza­ją ją tzw. scrum but’y” – czy­li nie­ak­cep­to­wal­ne odej­ścia od scru­ma (trud­no oprzeć się wra­że­niu, że takie zabie­gi mają pod­ło­że bar­dzie reto­rycz­ne niż merytoryczne).

    2. Scruma i cały agi­le sprze­da­je się” jako deve­lo­per­ski raj. Developerzy, czy lepiej powie­dzieć zespół” są w cen­trum uwa­gi, kreu­ją, osią­ga­ją cele, są w peł­ni zmo­ty­wo­wa­ni i w dużym stop­niu auto­no­micz­ni – inny­mi sło­wy za cudze pie­nią­dze” robią star­tup. Niestety duża fir­ma, to nie jest zbiór star­tu­pów. Spośród wszyst­kich deve­lo­pe­rów, myślę, że jakieś 5 – 10% fak­tycz­nie żyje tym, co robi, resz­ta po 7 godzi­nach w pra­cy moc­no spo­glą­da na zegar­ki i chce jak naj­szyb­ciej wró­cić do domu. Być może dla kogoś, to mało istot­ny argu­ment, ale chcę w ten spo­sób poka­zać jak nie­ade­kwat­ne są zało­że­nia agi­le w sto­sun­ku do rze­czy­wi­sto­ści. Utrzymanie moty­wa­cji, to sta­ra i zło­żo­na kwe­stia – nie­ste­ty w scru­mie spro­wa­dza się ją czę­sto do wymu­szo­ne­go” entu­zja­zmu, czy spo­so­bu sta­nia na stand-up’ach – uwa­ga! naj­lep­sza jest posta­wa zasadnicza.

    3. Odkrywanie mode­li meto­dą prób i błę­dów, to nie­mal zasa­da w scru­mie. Do tego celu sto­su­je się gro­omin­gi. Przez 1,5 godzi­ny spo­ty­ka się 7 – 8 osób i w try­bie burzo-mózgo­wym roz­k­mi­nia­ją” jakiś zło­żo­ny temat. Oczywiście wcze­śniej nikt się do nich spe­cjal­nie nie przy­go­to­wu­je – przy­go­to­wa­nie ozna­cza­ło­by wodo­spad ;-). Jak to z burza­mi mózgów bywa – aktyw­ne są 2 – 3 oso­by o spe­cy­ficz­nych cechach cha­rak­te­ru (nie zawsze są to oso­by naj­bar­dziej prze­ni­kli­we ;-)), resz­ta sie­dzi i się nudzi. Po zakoń­cze­niu spo­tka­nia poza jakimś szki­cem roz­wią­za­nia nikt już za bar­dzo się nad nim nie pochy­la do cza­su imple­men­ta­cji. Powstały pomysł nie jest w żaden spo­sób testo­wa­ny. To, co zespół ma w gło­wach wystar­cza, by zre­ali­zo­wać cały temat. Jeśli są zależ­no­ści z inny­mi zespo­ła­mi, to zapra­sza się ludzi z innych zespo­łów i tłu­ma­czy w 5 min. co chce­my zro­bić i na zasa­dzie wiel­kiej impro­wi­za­cji” powsta­je roz­wią­za­nie. Nikomu nie przy­cho­dzi do gło­wy, że w ten spo­sób moż­na tyl­ko zbu­do­wać przy­sło­wio­wą budę dla psa. Istnieje oczy­wi­ście zawsze świet­na wymów­ka – biz­nes nie inte­re­su­ją dobrze zapro­jek­to­wa­ne roz­wią­za­nia, liczy się tyl­ko to, by dana funk­cjo­nal­ność dzia­ła­ła. W prak­ty­ce, po kil­ku mie­sią­cach dzia­ła­nia scru­ma moż­na spo­dzie­wać się nie­złe­go ?baj­zlu? w sys­te­mie. W czy­stym scru­mie nie ma oczy­wi­ście roli archi­tek­ta ? to wodo­spa­do­wy relikt. Jeśli cały sys­tem roz­wi­ja­ny jest przez jeden nie­wiel­ki zespół, to pół­bie­dy, jeśli jed­nak zespo­łów jest kil­ka to poja­wia się efekt roz­pro­szo­nej wizji roz­wią­za­nia ? tj. nikt tak napraw­dę nie wie jak na koń­cu coś powin­no być zre­ali­zo­wa­ne. Jeśli mamy ?czy­ste­go? scru­ma, to jed­no jest dla mnie pew­ne, o Domain Driven Design może­my zapomnieć.
    Warto dodać, że to co doświad­czo­ne­mu ana­li­ty­ko­wi może zająć 2 tygo­dnie pra­cy, zespo­ły mogą odkry­wać przez 2 – 3 sprin­ty. Różnica jest taka, że 10 oso­bod­ni prze­kształ­ca się w 7*10 oso­bod­ni. Pomijam efekt jako­ści. Niestety z moich obser­wa­cji wyni­ka, że pro­gra­mi­ści, to na ogół bar­dzo sła­bi ana­li­ty­cy. Interesują ich naj­czę­ściej tyl­ko ścież­ki pozy­tyw­ne albo prze­ciw­nie mają pre­dy­lek­cję do kom­pli­ko­wa­nia świata.

    4. Na koniec kil­ka uwag na temat uber-kom­pe­ten­cji, któ­re zakła­da się w scru­mie. W scru­mie wyróż­nia się 3 role: pro­duct-owne­ra, scrum-maste­ra i deve­lo­pe­rów. Product owner to tzw. rola nie moż­li­wa 😉 ? skrzy­żo­wa­nie: eks­per­ta dzie­dzi­no­we­go, research?era, spe­cja­li­sty od uży­tecz­no­ści, do pew­ne­go stop­nia ana­li­ty­ka. W prak­ty­ce bar­dzo trud­no zna­leźć takie oso­by więc pro­duct owne­rów rekru­tu­je się spo­śród ana­li­ty­ków, pm?ów, biz­ne­sow­ców. Niestety rzad­ko tego typu oso­by czu­ją w jakim kie­run­ku ich ?kawa­łek? sys­te­mu powi­nien się roz­wi­jać nawet na pozio­mie funk­cjo­nal­nym. Często nawet nie czu­ją potrze­by, żeby wyobra­zić sobie roz­wią­za­nie w dłuż­szej per­spek­ty­wie (uwa­ga! zno­wu wkra­da się wodo­spad). Ostatecznie zatem sys­tem sta­je się ?zlep­kiem? featu­res. Niestety PO rzad­ko mają wie­dzę na temat budo­wy sys­te­mów by być part­ne­rem dla zespo­łu. W zdy­scy­pli­no­wa­nych meto­dy­kach roz­róż­nia się wie­le ról, któ­re mają dobrze zde­fi­nio­wa­ne kom­pe­ten­cje i dopie­ro z ich zbio­ru two­rzy się zespół pro­jek­to­wy. Jeśli kogoś bra­ku­je w zespo­le np. archi­tek­ta, to łatwo ziden­ty­fi­ko­wać takie ryzy­ko. Z dru­giej stro­ny cza­sa­mi ktoś może łączyć wie­le ról, ale wia­do­mo, że jest to dla pro­jek­tu pro­blem, bo trze­ba znać się czę­sto na bar­dzo róż­nych obsza­rach i dodat­ko­wo taka oso­ba bywa na ogół prze­cią­żo­na. W scru­mie nie dostrze­ga się tego – wie­rzy się w nie­ogra­ni­czo­ne moż­li­wo­ści kolektywu.
    O scrum maste­rach nie­ste­ty nic dobre­go nie mogę powie­dzieć. Głównie zaj­mu­ją się rezer­wa­cją salek i wypo­wia­da­niem jed­ne­go sło­wa ?time­bo­xing?. Choć muszę przy­znać, że jeśli jest kon­flikt w zespo­le, to sta­ra­ją się pomóc. Pytanie tyl­ko, czy dla czyn­no­ści, któ­re zaj­mu­ją 15 min. dzien­nie potrzeb­ny jest etat ;-).
    Z rolą deve­lo­per jest podob­ny pro­blem jak z PO. Każdy, bez wzglę­du na doświad­cze­nie, musi być w okre­ślo­nych przy­pad­kach archi­tek­tem, pro­jek­tan­tem, pro­gra­mi­stą i teste­rem. Jeśli ktoś jest od wszyst­kie­go, to, wia­do­mo jak to się koń­czy. Poza tym, liczy się na samo­or­ga­ni­za­cję w obsza­rze róż­nych decy­zji pro­jek­to­wych. Jeśli nie ma con­sen­su­su, to oczy­wi­ście deba­ty na dany temat mogą trwać tygo­dnia­mi. PO oczy­wi­ście nie ma pra­wa się mie­szać, poza pyta­nie, ile coś będzie trwa­ło jest nie na miejscu. 

    Kończąc, od razu wyja­śnię, że powyż­sze uwa­gi doty­czą scru­ma w posta­ci opi­sa­nej w scrum-guide ? nie­ste­ty tę ?meto­dycz­ną zabaw­kę? pró­bu­je się wdra­żać tu i tam ;-). W prak­ty­ce prę­dzej, czy póź­niej (zwłasz­cza jak jeste­śmy po ścia­ną, bo małe tema­ty reali­zu­je się mie­sią­ca­mi) po cichu zaczy­na się uzbra­jać tę meto­dę w róż­ne dodat­ki, któ­re nie­ste­ty do niej nie pasu­ją np. archi­tek­tów, spe­cy­fi­ko­wa­nie wyma­gań przez przy­kład, czy DDD. Efekty tych hybryd są nie­ste­ty dość mizer­ne, bo nie są one ?zabez­pie­czo­ne? pro­ce­so­wo ? wszyst­kim ste­ru­je samo­or­ga­ni­za­cja (to taki patent pocho­dzą­cy od mró­wek ;-)) + świę­ty cykl spo­tkań: plan­ning (defi­nio­wa­nie kar­te­czek), review (oglą­da­nie ekra­nów), retro (jak lepiej testo­wać, albo kró­ciej się spo­ty­kać) i gro­oming (burze mózgów, któ­rych efek­tyw­ność zosta­ła zakwe­stio­no­wa­na już w tylu bada­niach, że aż nie wypa­da tego powtarzać). 

    Na koniec link poka­zu­ją­cy, że nawet entu­zja­ści z cza­sem tra­cą zapał 😉

    http://​loste​chies​.com/​j​i​m​m​y​b​o​g​a​r​d​/​2​0​1​2​/​0​9​/​1​2​/​w​h​y​-​i​m​-​d​o​n​e​-​w​i​t​h​-​s​c​r​um/

    • Jaroslaw Zelinski 7 kwietnia 2014 at 07:58

      Mogę tyl­ko dodać, że tam gdzie tra­fi­ło mi się roz­po­czy­nać jesz­cze raz po tym, jak zwin­ne meto­dy pole­gły, opro­gra­mo­wa­nie było dostar­cza­ne znacz­nie taniej i szybciej.

    • jacek2v 9 kwietnia 2014 at 12:26

      I podob­ne jest moje spoj­rze­nie na scru­ma, któ­re opi­sał­bym jed­nym zda­niem: Próba «wodo­spa­do­we­go» podej­ścia do agi­le” 😛 Z defi­ni­cji nie ma pra­wa się udać.
      Mam wąt­pli­wo­ści co do nie­kom­pa­ty­bil­no­ści” scru­ma z DDD, czy ze spe­cy­fi­ko­wa­niem wyma­gań przez przy­kład” (wła­ści­wie to jest zale­ca­na meto­da spec. wyma­gań w agi­le). W posia­da­niu archi­tek­ta też nie widzę nic złe­go. Ten scrum-guide musi być napraw­dę dziw­ny” 🙂

  8. Kamil Jackiewicz 9 kwietnia 2014 at 08:53

    Niestety, to co zosta­ło opi­sa­ne przez Jutrzenkę, to punkt po punk­cie wska­za­ne przy­kła­dy nie­wła­ści­we­go podej­ścia do wyko­rzy­sty­wa­nia zwin­ne­go zarzą­dza­nia pro­jek­ta­mi. Przede wszyst­kim, opi­sa­na sytu­acja poka­zu­je, że ktoś sku­pił się na meto­dach, zupeł­nie odci­na­jąc kwe­stie kul­tu­ry orga­ni­za­cyj­nej i pryn­cy­piów Agile, od któ­rych powin­no się roz­po­cząć jakie­kol­wiek dzia­ła­nia ze zwin­no­ścią. Nie doing agi­le”, a being agi­le”. Zdarzają się oso­by, któ­re moc­no trzy­ma­ją się metod water­fal­lo­wych, a któ­re są agi­le, ale czę­sto zda­rza się też sytu­acja odwrotna.
    W opi­sa­nym przy­kła­dzie nie zadba­no o wła­ści­we zbu­do­wa­nie zespo­łu, o dobra­nie ludzi wła­ści­wych do ról scrum-owych. Nikt nie mówi, że jest to łatwe – wręcz prze­ciw­nie, sam Scrum mówi o tym, że jest to łatwe do zro­zu­mie­nia, ale bar­dzo trud­ne do zasto­so­wa­nia. Kolejny raz wycho­dzi to, że ludzie pod­cho­dzą do wsze­la­kich meto­dyk jako do kom­plet­ne­go algo­ryt­mu postę­po­wa­nia. W prak­ty­ce to tyl­ko wska­zów­ki dla świa­do­mych osób, któ­re mają uła­twić, bądź wska­zać co jesz­cze war­to zro­bić, aby dopro­wa­dzić pro­jekt do suk­ce­su. Nie bar­dzo rozu­miem jak prak­ty­cy ana­li­zy, czy zarzą­dza­nia pro­jek­ta­mi, potra­fią tak spie­rać się na temat szcze­gó­ło­wych zwro­tów uży­tych w opi­sie meto­dyk, zupeł­nie zapo­mi­na­jąc o naj­waż­niej­szym czyn­ni­ku: kom­pe­ten­cjach ludzi, któ­rzy pro­ces wyko­nu­ją. Bez tego nie da się, lub jest to pra­wie nie­moż­li­we, osią­gnąć wyzna­czo­nych celów (chy­ba, że przy­pad­ko­wo, ale wte­dy to bar­dziej opła­ca się zagrać w tot­ka). To oso­by bio­rą­ce udział w reali­za­cji skom­pli­ko­wa­nych pro­ce­sów, jakim jest na przy­kład dostar­cze­nie roz­wią­za­nia infor­ma­tycz­ne­go, są naj­waż­niej­szym źró­dłem decy­zji, nie zaś sam algo­rytm postę­po­wa­nia, czy meto­dy­ka. Jeśli ktoś podą­ża śle­po za wytycz­ny­mi meto­dy­ki, podej­mu­jąc decy­zje sto­ją­ce w sprzecz­no­ści z zasta­ną sytu­acją (bo prze­cież tak każe meto­dy­ka), to zacho­wa­nie takie ma swo­ją nazwę – głupota.
    I tak jest z każ­dym podej­ściem, czy zwin­nym, czy nie. Opisana tutaj sytu­acja jest przy­kła­dem nie­wła­ści­we­go podej­ścia do tema­tu orga­ni­za­cji w ogó­le, a nie przy­kła­dem na sła­bość agi­le, czy Scruma (choć nie są one pozba­wio­ne wad, podob­nie zresz­tą jak water­fall, z tym nie zamie­rzam dyskutować).
    Jest jed­nak rów­nie wie­le, jeśli nie wię­cej, przy­kła­dów na orga­ni­za­cje, któ­re z suk­ce­sem dzia­ła­ją zwin­nie, a zatem moż­na. Wystarczy podejść do tema­tu z otwar­tym umy­słem i we wła­ści­wej kolejności.

    • Jaroslaw Zelinski 9 kwietnia 2014 at 09:38

      Jeżeli uzna­my, że meto­da pra­cy to zbiór reguł oraz, że ist­nie­je wie­le sytu­acji, w któ­rych reguł tych nie nale­ży restryk­cyj­nie sto­so­wać” to wnio­sek jest jeden: meto­da jest do kitu (reguł się albo prze­strze­ga albo się je zmienia). 

      Druga rzecz: Nie bar­dzo rozu­miem jak prak­ty­cy ana­li­zy, czy zarzą­dza­nia pro­jek­ta­mi, potra­fią tak spie­rać się na temat szcze­gó­ło­wych zwro­tów uży­tych w opi­sie meto­dyk”, w moich oczach słow­nik pojęć to nic inne­go jak pre­cy­zyj­ne usta­le­nie zna­cze­nia poję­cia”, to jedy­ny spo­sób na jed­no­znacz­ność prze­ka­zu (komu­ni­ka­cji), bez tego każ­dy mówi to samo czy­li co inne­go”. Kompetencje ludzi są jak naj­bar­dziej waż­ne ale one nie mogą być narzę­dziem łama­nia reguł”, bo doj­dzie­my do wnio­sku, że na dro­dze publicz­nej wszy­scy muszą prze­strze­gać reguł Kodeksu Drogowego za wyjąt­kiem meda­li­stów w wyści­gach samo­cho­do­wych, co jest bzdu­rą (rolą sta­no­wie­nia reguł jest tak­że uzy­ska­nie prze­wi­dy­wal­no­ści zacho­wań). Uznanie jakiejś dro­gi za publicz­ną, obli­gu­je do jed­na­ko­wych zacho­wań wszyst­kich, dro­gi nie­pu­blicz­ne pozwa­la­ją na nie­prze­strze­ga­nie tych zasad ale ryzy­ko pono­si kie­row­ca. W zarzą­dza­niu pro­jek­ta­mi mamy to samo: albo pro­jekt jest typo­wy” (czy­li zakres, ter­min i budżet, kie­row­nik pro­jek­tu, usta­lo­ne regu­ły itp…) albo są to bada­nia i roz­wój” (lub sturt-up) i wte­dy świa­do­mie łamie­my zasa­dy i rozu­mie­my ryzyka. 

      W moich, i nie tyl­ko, oczach agile/scrum” to trak­to­wa­nie wszyst­kich pro­jek­tów jak bada­nia i roz­wój” (na koszt spon­so­ra – bar­dzo wygod­ne dla wykow­naw­cy). Co do przy­kła­dów i pojęć: pro­ble­mem Agile jest to, że tego poję­cia nikt do tej pory nie zde­fi­nio­wał a wszy­scy go uży­wa­ją” (słow­ni­ko­we zwin­ny” ozna­cza wyłącz­nie wyko­nu­ją­cy szyb­kie, zręcz­ne ruchy”), w efek­cie udo­wod­nić moż­na każ­dą tezę o Agile bo to sło­wo tak na praw­dę nic, ponad słow­nik, nie zna­czy. Nie jestem wro­giem” Agile, po pro­stu od każ­de­go wyko­naw­cy ocze­ku­ję poprze­dza­nia każ­dej pra­cy dekla­ra­cją co zro­bi (i nie mam na myśli dekla­ra­cji: popra­cu­je jesz­cze kil­ka dni”) albo zali­czam pro­jekt do prac badawczych”. 

      Jutrzenka opi­sał to co spo­ty­kam w więk­szo­ści przy­pad­ków. Co do stra­sze­nia meto­da­mi water­fall” to jest to jakiś bzdur­ny mit o trwa­ją­cych lata­mi ana­li­zach o zamro­żo­nych wyni­kach, tak zwa­ny wodo­spad” to wyłącz­nie utrzy­ma­nie pro­stej kolej­no­ści: ana­li­za i pro­jekt (dekla­ra­cja), wyko­na­nie (w tym test), zarzą­dza­nie zakre­sem, odbiór. Problemem jest raczej zbyt duży zakres na jeden taki cykl” (pro­jekt) a nie sam cykl jako taki. To dla­te­go powsta­ły meto­dy kom­po­nen­to­we w IT i zarzą­dza­nie zakre­sem (WBS) w meto­dy­kach zarzą­dza­nia pro­jek­ta­mi i pro­gra­ma­mi. Co cie­ka­we, źró­dłem wiel­kich i cało­ścio­wych ana­liz” jest, nie wodo­spad jako meto­da, a nadal sto­so­wa­ne meto­dy struk­tu­ral­ne, wyma­ga­ją­ce roz­po­czę­cia pro­jek­tu od ana­li­zy i opra­co­wa­nie peł­ne­go rela­cyj­ne­go mode­lu bazy danych, co cie­ka­we, tak zaczy­na pra­wie każ­dy pro­gra­mi­sta, Ci zwin­ni tak­że. Z wła­snej obser­wa­cji mogę potwier­dzić doświad­cze­nie Jutrzenki: pro­jek­ty zwin­ne zawsze pro­du­ku­ją kosz­tow­ny kod zwa­ny kupa bło­ta” (chy­ba, że poja­wi się w pro­jek­cie archi­tekt ale to jest pas­se). Metody obiek­to­we (owszem trud­ne) powsta­ły mię­dzy inny­mi po to, by wiel­kie pro­jek­ty dzie­lić na her­me­ty­zo­wa­ne małe (a nie jak twier­dzi więk­szość pro­gra­mi­stów jakich spo­ty­kam: po to by reu­ży­wać kod). 

  9. jutrzenka 9 kwietnia 2014 at 22:41

    Witam,

    Nie spo­dzie­wa­łem się aż takie­go rezo­nan­su na mój wpis. Dziękuję Panu Jarosławowi za redy­stry­bu­cję moje­go komen­ta­rza oraz bar­dzo traf­ną opi­nię, z któ­rą w peł­ni się zga­dzam. W szcze­gól­no­ści zga­dzam się, że agi­le jako poję­cie jest nie­zwy­kle mgli­ste. Oczywiście takie poję­cia funk­cjo­nu­ją w języ­ku natu­ral­nym i kie­dy roz­ma­wia­my o wra­że­niach este­tycz­nych, lite­ra­tu­rze może­my obejść się bez jed­no­znacz­no­ści. Jednak w IT ? dys­cy­pli­nie mimo wszyst­ko dość ści­słej ? moż­na było­by się spo­dzie­wać cze­goś dobrze okre­ślo­ne­go i zde­fi­nio­wa­ne­go. Rozumiem, że meto­dy­ki pro­jek­to­wa­nia funk­cjo­nu­ją na sty­ku IT i nauk spo­łecz­nych, ale to co ludzie pod­sta­wia­ją pod hasło agi­le jest wyjąt­ko­wo męt­ne i nie­pre­cy­zyj­ne. Najczęściej kie­dy pada hasło agi­le, to poja­wia się nawią­za­nie do mani­fe­stu ? czy­li zbio­ru war­to­ści podzie­la­nych przez ?wspól­no­tę? ;-). Gdyby na chłod­no przyj­rzeć się zapi­som mani­fe­stu, to moż­na powie­dzieć, że jest to zbiór bana­łów, jed­nak wśród zwo­len­ni­ków te kil­ka zdań funk­cjo­nu­je nie­mal jak tekst auto­rów natchnionych.
    Wpis jackav2 jest dla mnie bar­dzo symp­to­ma­tycz­ny – scrum to ?wodo­spa­do­we? podej­ście do agi­le. Jak rozu­miem wodo­spad jest jak wirus, któ­ry nie­po­strze­że­nie ata­ku­je zespo­ły scru­mo­we, pomi­mo tego, że ota­cza je kor­don scrum­ma­ste­rów, scrum-coachów, a nawet bez­kry­tycz­nie wspie­ra­ją­cych to podej­ście top-mana­ge­rów. Nie poma­ga nawet prze­szko­le­nie wszyst­kich osób w orga­ni­za­cji, dosto­so­wa­nie struk­tu­ry orga­ni­za­cyj­nej, cią­głe przy­po­mi­na­nie zasad z mani­fe­stu, maso­wy udział w kon­fe­ren­cjach, wypo­wia­da­nie jak man­tra ? ?jaką war­tość biz­ne­so­wą pre­zen­tu­je to, co zosta­ło zre­ali­zo­wa­ne w ostat­nim sprin­cie? itd. Czyżby do dys­po­zy­cji pozo­sta­wa­ło już tyl­ko pra­nie mózgu ;-).

    Oczywiście nie moż­na zaprze­czyć, że są zespo­ły, w któ­rych scrum lub inna meto­dy­ka zwin­na ?nie prze­szka­dza?. Wydaje mi się jed­nak, że mamy w takich przy­pad­kach z typo­wym efek­tem przy­pad­ko­wej kore­la­cji. Ponieważ zespół jest sil­ny ? skła­da się z osób z dużym doświad­cze­niem wie­dzą­cych, co nale­ży zro­bić w danym przy­pad­ku, dys­po­nu­ją­cy sze­re­giem tech­nik pra­cy, któ­re nale­ży w danym kon­tek­ście zasto­so­wać, to efekt jest taki, że scrum dzia­ła. Sam widzia­łem taki zespół, któ­ry na wej­ściu otrzy­my­wał dobrze okre­ślo­ne wyma­ga­nia (reali­zo­wa­na była kla­sycz­na ana­li­za), dobrze okre­ślo­ną archi­tek­tu­rę, a tyl­ko imple­men­ta­cja i testy odby­wa­ły się w scru­mie ? w efek­cie zespół dowo­ził bar­dzo wyso­kiej jako­ści roz­wią­za­nia co do dnia w pro­jek­cie 3 – 4 mie­sięcz­nym (wiem, wiem ? to nie agi­le, tyl­ko prze­klę­ty wodo­spad ;-), ale to po pro­stu dzia­ła­ło i mimo wszyst­ko było w czę­ści nazy­wa­ne scru­mem. Dla kogoś ze świa­ta agi­le to dowód, że scrum dzia­ła, a dla mnie to przy­pad­ko­wa kore­la­cja. Ten sam zespół mógł­by dzia­łać bez wszyst­kich cere­mo­nii scru­mo­wych i nad­bu­do­wy agi­lo­wej i był­by praw­do­po­dob­nie rów­nie spraw­ny. Kiedy jed­nak weź­mie­my pod uwa­gę zespól osób bez duże­go doświad­cze­nia, bez szcze­gól­nej moty­wa­cji i samo­dy­scy­pli­ny natych­miast wyj­dą opi­sa­ne prze­ze mnie scrum-efek­ty np. odkry­wa­nie wszyst­kie­go bojem, sła­be mode­le, niska jakość, cią­gnię­cie pro­stych tema­tów mie­sią­ca­mi. Zdaję sobie spra­wę, że agi­le moc­no pod­kre­śla waż­ność osób (ludzie waż­niej­si od pro­ce­sów), w prak­ty­ce jed­nak nie­wie­le z tego wyni­ka, bo krzy­wa Gaussa jest nie­ubła­ga­na ;-). Inaczej jest w meto­dy­kach zdy­scy­pli­no­wa­nych, gdzie mówi się wprost: na tym eta­pie pro­jek­tu musisz przy­go­to­wać to, to i to. Oczywiście zawsze moż­na trak­to­wać to mecha­nicz­nie i w efek­cie robić rze­czy nie­po­trzeb­ne, ale tu przy­naj­mniej mamy jakąś pod­po­wiedź, ktoś bazu­jąc na doświad­cze­niach z setek pro­jek­tów pro­po­nu­je nam by się nad tym przy­naj­mniej zasta­no­wić i pod­jąć decy­zję, czy jest nam to potrzeb­ne, czy nie. W agi­le ist­nie­je prze­ko­na­nie, że zespół zawsze wie co w danej sytu­acji nale­ży zro­bić ? żad­ne pod­po­wie­dzi meto­dycz­ne nie są mu potrzeb­ne. Jeśli jed­nak przyj­rzeć się pomy­słom Scotta Amblera, cenio­ne­go prze­ze mnie agi­le­ow­ca, to moż­na było­by je spo­koj­nie porów­nać do uprosz­czo­ne­go RUP?a w wer­sji dla małych pro­jek­tów. Startujemy od opra­co­wa­nia naj­waż­niej­szych przy­pad­ków uży­cia, two­rzy­my kil­ku szki­ców archi­tek­to­nicz­nych i szyb­ko prze­cho­dzi­my do imple­men­ta­cji oraz testów. Wodospad jak w pysk strze­lił ;-). Tam, gdzie choć­by naj­luź­niej­sze sko­ja­rze­nie z wodo­spa­dem i faza­mi pro­jek­tu jest zaka­za­ne, tam poja­wia się prze­ko­na­nie, że moż­na być mistrzem sza­cho­wym myśląc jed­ne ruch do przo­du. Uważam, że naj­więk­szym grze­chem scru­ma jest jego wręcz meto­dycz­ne blo­ko­wa­nie myśle­nia w dłuż­szym hory­zon­cie – stąd mój scep­ty­cyzm wobec łącze­nia DDD i scru­ma. DDD wyma­ga zasto­so­wa­nia dogłęb­nej ana­li­zy dzie­dzi­ny – nie­mal zży­cia się z pro­ble­mem – patrz efekt bre­ak ‑thro­ugh opi­sa­ny przez Evansa. Naprawdę trud­no mi to sobie wyobra­zić kie­dy tema­ty gro­omo­wa­ne są przez 2 – 3 godzi­ny przez cały zespół z PO, a nie eks­per­ta­mi dzie­dzi­no­wy­mi. Takie skra­ca­nie hory­zon­tu, to dla mnie zaprze­cza­nie zło­żo­no­ści. Obawiam się, że wszy­scy, któ­rzy pró­bu­ją iść tą dro­gą będą musie­li wydat­ko­wać znacz­nie wię­cej ener­gii niż Ci, dla któ­rych ety­kie­ty meto­dycz­ne są mniej istot­ne, a waż­niej­sze jest by dobrze zro­zu­mieć pro­blem, pre­cy­zyj­nie usta­lić wyma­ga­nia, przy­go­to­wać dobrą archi­tek­tu­rę i pro­jekt i wresz­cie zaim­ple­men­to­wać to co zosta­ło wymy­ślo­ne ? jak poka­zu­je RUP aktyw­no­ści te reali­zo­wa­ne są nie­mal w całym cyklu życia pro­jek­tu, nie­mal w każ­dej ite­ra­cji, a nie tak jak chcie­li­by agi­le­ow­cy tyl­ko sekwencyjnie.

    Na koniec pole­cam lek­tu­rę arty­ku­łu ? wyglą­da to tro­chę na luź­ną aso­cja­cję, ale poka­zu­je jak nasze prze­ko­na­nia wpły­wa­ją na postrze­ga­nie świata.

    Pozdrawiam.
    P.S. Dziękuję uczest­ni­kom za spo­koj­ną debatę.

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.