Trzy lata temu tak zaczy­na­łem arty­kuł o wyma­ga­niach i pra­wach autorskich:

Od cza­su do cza­su mie­wam dys­ku­sje na temat tego, kto i co powi­nien wytwo­rzyć w pro­jek­cie dostar­cza­nia opro­gra­mo­wa­nia. Pojawia się pro­blem: czym jest ów pro­jekt. Po dru­gie: kto jest auto­rem i cze­go. Po trze­cie: czym jest ta doku­men­ta­cja. Problem w tym, że w pro­jek­tach IT w wyni­ku ana­liz powsta­ją ?jakieś wyma­ga­nia? i tak na praw­dę nie wia­do­mo czym one są? Dziwne? Czym jest pro­dukt, któ­re­go ?cechą funk­cjo­nal­ną jest moż­li­wość wbi­ja­nia gwoź­dzi?? Otoczakiem, pneu­ma­tycz­nym mło­tem czy może pro­stym ręcz­nym młot­kiem? (Prawo autor­skie, szpie­go­stwo prze­my­sło­we i pro­jek­to­wa­nie | Jarosław Żeliński IT-Consulting).

W ubie­gły Czwartek odby­ła się kon­fe­ren­cja Agile Management. Dokładnie tak samo zaczę­ła się jed­na z kulu­aro­wych dys­ku­sji na tej kon­fe­ren­cji. Nie będę tu powta­rzał tre­ści tego arty­ku­łu, kon­fe­ren­cja poka­za­ła, że nie zdez­ak­tu­ali­zo­wał się (zain­te­re­so­wa­nym pra­wem do kodu pole­cam jego lek­tu­rę). Prawo do powsta­ją­ce­go kodu raczej” ma autor pomy­sły, któ­ry potra­fił ten pomysł dobrze udokumentować.

Przedwczorajsza kon­fe­ren­cja, była bar­dzo cie­ka­wa tak­że z inne­go powo­du. Wśród wie­lu pre­zen­ta­cji, w moich oczach, dwie pre­zen­ta­cje były szcze­gól­nie cie­ka­we: Krystian Kaczor ? o swo­ich doświad­cze­niach i spraw­dzo­nych meto­dach ska­lo­wa­nia Agile do pozio­mu całe­go przed­się­bior­stwa i mec. Łukasz Węgrzyn ? o nowym mode­lu współ­pra­cy i koniecz­no­ści rede­fi­nio­wa­nia dotych­cza­so­we­go podej­ścia. (Konferencja Agile Management 2014 – kon­fe­ren­cja). Prezentacje te, każ­da w swo­im obsza­rze, wska­zy­wa­ły na moż­li­we spo­so­by roz­wią­zy­wa­nia pro­ble­mów pro­jek­tów nazy­wa­nych zwin­ny­mi. Zwinność zosta­ła okiełznana?
Obecnie zama­wia­ne opro­gra­mo­wa­nie jest coraz czę­ściej bar­dzo zło­żo­ne. Może to być opro­gra­mo­wa­nie two­rzo­ne na indy­wi­du­al­ne potrze­by lub two­rzo­ne z myślą o sprze­da­ży go na ryn­ku. W obu przy­pad­kach chce­my by powsta­ło. Rosnąca zło­żo­ność opro­gra­mo­wa­nia to kon­se­kwen­cja rosną­cej wiel­ko­ści i zło­żo­no­ści dzia­ła­nia orga­ni­za­cji takich jak pod­mio­ty ryn­ko­we czy insty­tu­cje publiczne.

Wodospad (water­fall) to nazwa pro­ce­su two­rze­nia opro­gra­mo­wa­nia pole­ga­ją­ca na opra­co­wa­niu szcze­gó­ło­we­go pro­jek­tu by następ­nie roz­po­cząć jego reali­za­cję. Właśnie w tym momen­cie oglą­dam jeden z moich ulu­bio­nych pro­gra­mów w TV: Jak to jest zro­bio­ne. Tym razem jest to tan­ko­wiec, któ­re­go kon­struk­cja skła­da się z ok. 100.000 ele­men­tów (tak sto tysię­cy ele­men­tów!). Muszą one być wszyst­kie zapro­jek­to­wa­ne przed roz­po­czę­ciem budo­wa­nia stat­ku. Powód jest oczy­wi­sty: ryzy­ko całe­go pro­jek­tu za duże, by pozwo­lić sobie na odkry­cie pro­ble­mu z ele­men­ta­mi skła­do­wy­mi w toku mon­ta­żu lub w morzu. Sam mon­taż (budo­wa tan­kow­ca) to ok. 16 mie­się­cy, pro­jek­to­wa­ny jest znacz­nie dłu­żej i tu nie­ba­ga­tel­ną rolę, w skró­ce­niu tego pro­ce­su (pro­jek­to­wa­nie od zera wszyst­kie­go trwa­ło by kil­ka­na­ście lat) odgry­wa­ją wzor­ce pro­jek­to­we (o czym innym razem). Czy to moż­na coś zro­bić zwin­nie? Nie bar­dzo, ryzy­ko jest zbyt duże, oku­pu­je­my to jed­nak tym, że czas od pomy­słu do otrzy­ma­nia goto­we­go pro­duk­tu to, łącz­nie z pro­jek­to­wa­niem, kil­ka lat.

Oprogramowanie to co praw­da mate­ria” bar­dzo łatwo mody­fi­ko­wal­na (tyl­ko korek­ta tek­stu pro­gra­mu) ale nie zna­czy to, że mody­fi­ka­cje te odby­wa­ją się niskim kosz­tem” (dobry pro­gra­mi­sta zara­bia nawet dwa razy wię­cej niż dobry spa­wacz w stocz­ni, po dru­gie znacz­na część spa­wa­nia jest zauto­ma­ty­zo­wa­na, kodo­wa­nia jesz­cze nie zauto­ma­ty­zo­wa­no). Rynek jed­nak zmu­sza fir­my do sta­łe­go podej­mo­wa­nia prób uzy­ska­nia potrzeb­ne­go im opro­gra­mo­wa­nia szyb­ko”. I tak powsta­ła idea zwin­ne­go” two­rze­nia opro­gra­mo­wa­nia: zacząć two­rzyć bez żmud­ne­go i cza­so­chłon­ne­go pro­jek­to­wa­nia bo nie ma cza­su”. Poniżej kil­ka prze­my­śleń z konferencji.

Agile

Uznano, że pro­jekt moż­na roz­po­cząć nie mając peł­ne­go zro­zu­mie­nie pro­ble­mu ani pro­jek­tu. Jeżeli roz­po­czy­na­my bez zro­zu­mie­nia pro­ble­mu i pomy­słu na jego roz­wią­za­nie, jeste­śmy ska­za­ni na bar­dzo zwin­ne” podej­ście, pole­ga ono w tra­dy­cyj­nym zwin­nym” podej­ściu, na two­rze­niu opro­gra­mo­wa­nia z dużym udzia­łem zama­wia­ją­ce­go (jedy­ne źró­dło wie­dzy o tym co i jak chce­my uzy­skać) meto­dą kolej­nych pro­to­ty­pów. Niestety wynik jest nieprzewidywalny.

W takim przy­pad­ku pozo­sta­je zaufa­nie, i bywa że ma to szan­se powo­dze­nia ale zespół zwin­nych pro­gra­mi­stów” to muszą być bar­dzo dobrzy spe­cja­li­ści, tacy, któ­rym moż­na zaufać, że moż­na uwie­rzyć to, że powsta­ją­ce kolej­ne przy­bli­że­nia nowe­go pro­duk­tu są naj­lep­sze z moż­li­wych. Jak nie trud­no się domy­śleć: taka sytu­acja to rzadkość.

Alternatywą jest mniej zwin­ne” podej­ście czy­li jed­nak wyko­na­nie ana­li­zy przed roz­po­czę­ciem pro­jek­tu, któ­rej celem jest zro­zu­mie­nie pro­ble­mu i opra­co­wa­nie kon­cep­cji roz­wią­za­nie, ale nie spe­cy­fi­ko­wa­nie szcze­gó­łów roz­wią­za­nia. Powodem, dla któ­re­go nie pró­bu­je­my pro­jek­to­wać szcze­gó­łów jest, zbyt duża zło­żo­ność tych pro­ble­mów i brak czasu.

Kolejna waż­na rzecz w dużych pro­jek­tach (Krystian Kaczor): śred­ni i więk­szy pro­jekt powi­nien jed­nak mieć archi­tek­ta, żeby ktoś mimo wszyst­ko miał pomysł na całość. Bez pla­nu i wizji cało­ści nawet naj­lep­szy zespół zwin­ny, nie da rady bez opi­sa­nej i zarzą­dza­nej wizji cało­ści. Rzucanie się na duży pro­jek­ty bez uzgod­nio­nej archi­tek­tu­ry cało­ści, kon­cep­cji inte­gra­cji, pro­wa­dzi to nie­usta­ją­cych i bar­dzo kosz­tow­nych zmian, przy każ­dej lokal­nej zmia­nie zwią­za­nej z integracją.

Dlatego klu­czo­we jest roz­po­zna­nie rodza­ju pro­jek­tu na samym jego począt­ku. Ocena ryzy­ka i okre­śle­nie rodza­ju pro­jek­tu: bun­ga­low czy dra­pacz chmur”. Mając dość roz­le­gły teren moż­na poku­sić się o budo­wę par­te­ro­we­go domu, efekt doce­lo­wy moż­na potrak­to­wać jako wizję, w toku prac moż­na dość swo­bod­nie zmie­niać wie­le wyma­gań, wręcz two­rzyć je w mia­rę trwa­nia budo­wy. Rozległy par­te­ro­wy dom z regu­ły nie wyma­ga wybu­rze­nia dotych­cza­so­wych efek­tów pra­cy gdy poja­wi się nowy pomysł na pozo­sta­łą do zbu­do­wa­nia część domu. Gorzej jest w przy­pad­ku dra­pa­cza chmur. Tu budo­wa idzie w górę a całość stoi na jed­nym fun­da­men­cie. Zmiana kon­cep­cji w toku budo­wy jest nie­moż­li­wa bez prze­bu­do­wy tego co poni­żej a to może być po pro­stu, z przy­czyn cza­so­wych i kosz­to­wych, już nie­moż­li­we. Bardzo waż­ne jest więc jak naj­wcze­śniej­sze odkry­cie tego czy tak na praw­dę budu­je­my wie­żo­wiec czy roz­le­gły bun­ga­low. Niskie pła­skie budow­le nie stwa­rza­ją ryzy­ka koniecz­no­ści wybu­rze­nia cało­ści w przy­pad­ku błę­du lub zmia­ny koncepcji.

A teraz kwestia tego na co się umawiamy czyli zwinna umowa na wykonanie usługi

Zasady współ­pra­cy to klu­czo­wy ele­ment umo­wy. Realizacja pro­jek­tu to nie tyl­ko obo­wiąz­ki dostaw­cy ale tak­że obo­wiąz­ki zama­wia­ją­ce­go, w koń­cu jest uczest­ni­kiem pro­jek­tu Agile. Tu klu­czem jest jed­nak pla­no­wa­nie, agi­le to nie powi­nien być nie­kon­tro­lo­wal­ny żywioł, to jed­nak umo­wa dwóch stron i obie te stro­ny mają obo­wiąz­ki. Dostawca jed­nak powi­nien się do cze­goś zobo­wią­zać i nie może to być wyłącz­nie będzie­my się sta­rać”. Kluczem zwin­nej umo­wy, mimo, że nie umiesz­cza­my w niej setek szcze­gó­łów wyma­gań, jest to jak stwier­dzi­my, że pro­jekt został zre­ali­zo­wa­ny. W tym miej­scu, jako kon­ty­nu­ację lek­tu­ry tego tek­stu pole­cam dosko­na­łą pre­zen­ta­cję mec. Łukasza Węgrzyna z kan­ce­la­rii Maruta o umo­wach Agile”:

Ta kon­fe­ren­cja prze­ko­na­ła mnie, że w sumie to jestem zwin­ny, bo: moje umo­wy mają zakres i har­mo­no­gram, pra­ca jest ite­ra­cyj­na, całość bazu­je na wizji, opi­su­ję jak stwier­dzi­my, że wyko­na­łem swo­ją pra­ce… a spe­cy­fi­ka­cje wyma­gań jakie opra­co­wu­ję, mają nie set­ki i tysią­ce pozy­cji, a góra kil­ka­dzie­siąt. Swego cza­su opi­sa­łem to tu:

Pamiętajmy, że zarzą­dza­nie zakre­sem pro­jek­tu jest tym kosz­tow­niej­sze im wię­cej szcze­gó­łów ten zakres posia­da. Projekt o 30 wyma­ga­niach vs. pro­jekt o 300 wyma­ga­niach to nie pro­jekt o 10-krot­nie więk­szym kosz­cie, ta róż­ni­ca będzie znacz­nie więk­sza (pomi­jam to jak w ogó­le zde­fi­niu­je­my wyma­ga­nie). (Mega pro­jek­ty czy­li jak zjeść sło­nia | Jarosław Żeliński IT-Consulting).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. jacek2v

    Cieszę się, że Pan prze­ko­nał się do Agile, a nawet odna­lazł ją w swo­jej działalności 🙂

    Jedno prze­my­śle­nie: uwa­żam za błąd porów­ny­wa­nie stat­ków do budo­wy opro­gra­mo­wa­nia, ponie­waż pro­ces budo­wy stat­ku jest skon­stru­owa­ny na cał­ko­wi­cie odmien­nych zasa­dach niż budo­wa opro­gra­mo­wa­nia i pod­le­ga cał­ko­wi­cie inne­mu ryzy­ku. Np. jed­ną z róż­nic jest, że woda i zasa­dy pły­wa­nia nie zmie­nia­ją się tak czę­sto, są ogól­nie zna­ne i z punk­tu widze­nia kil­ku­let­nie­go pro­ce­su budo­wa­nia nie jest to ryzy­ko dla pro­jek­tu. Zaś oto­cze­nie, pro­ce­sy i potrze­by biz­ne­so­we są czę­sto (jeśli nie zawsze) cał­ko­wi­cie inne w każ­dym przed­się­bior­stwie i pod­le­ga­ją zmia­nie pod­czas two­rze­nia opro­gra­mo­wa­nia (nie tyl­ko same­go programowania).

    1. Jaroslaw Zelinski

      Biznes plan stat­ku tez może ulec zmia­nie.… 😉 sta­tek jest zło­żo­ny, sys­tem ERP też… 😉 … ale to co potra­fi cza­sem zabić pro­jekt to uzna­nie, że użyt­kow­nik na kom­pe­ten­cje (ma pra­wo) brać udział w projektowaniu 🙂

  2. dunja

    ale to co potra­fi cza­sem zabić pro­jekt to uzna­nie, że użyt­kow­nik na kom­pe­ten­cje (ma pra­wo) brać udział w projektowaniu”

    +10

Dodaj komentarz

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