Polecam lek­tu­rę cie­ka­wej Opinii Prawnej kan­ce­la­rii Maruta Wachta sp. j.. (dalej odpo­wied­nio Opinia i Kancelaria) na temat MOŻLIWOŚCI I SPOSOBU WYKORZYSTANIA METODYKI AGILE W PROJEKTACH INFORMATYCZNYCH REALIZOWANYCH Z ZASTOSOWANIEM USTAWY ? PRAWO ZAMÓWIEŃ PUBLICZNYCH.

Kluczowe pojęcia i definicje

Zanim się odnio­sę do Opinii, naj­pierw kli­ka słów na temat zwin­ne­go reali­zo­wa­nia pro­jek­tów. Jak rzad­ko, posłu­żę się Wikipedią, gdyż poję­cie ​„meto­dy zwin­ne” nie ma ści­słej defi­ni­cji, Manifest Agile zaś jest na tyle ogól­ny, że nie jest moż­li­we uży­cie go jako defi­ni­cji. Po dru­gie Wikipedia jest powszech­nie przy­wo­ły­wa­na jako źró­dło w śro­do­wi­skach zwią­za­nych ze sto­so­wa­niem metod zwin­nych dla­te­go uzna­łem, że defi­ni­cje tam umiesz­cza­ne będą tu naj­bar­dziej ade­kwat­ne. Przypomnę, że oso­bi­ście nie uży­wam poję­cia ​„agi­le” w swo­ich pro­jek­tach, gdyż uwa­żam, że obec­ne słow­nic­two i meto­dy w obsza­rze inży­nie­rii zupeł­nie wystar­czą i są znacz­nie pre­cy­zyj­niej­sze i od lat sto­so­wa­ne z powo­dze­niem. Poniżej pró­ba upo­rząd­ko­wa­nia tych pojęć na potrze­by dal­szych rozważań.

Za Wikipedią (cyta­ty):

Programowanie zwin­ne (ang. agi­le softwa­re deve­lop­ment) ? gru­pa metod wytwa­rza­nia opro­gra­mo­wa­nia opar­te­go na pro­gra­mo­wa­niu ite­ra­cyj­no-przy­ro­sto­wym, powsta­łe jako alter­na­ty­wa do tra­dy­cyj­nych metod typu water­fall. Najważniejszym zało­że­niem meto­dyk zwin­nych jest obser­wa­cja, że wyma­ga­nia odbior­cy (klien­ta) czę­sto ewo­lu­ują pod­czas trwa­nia pro­jek­tu. Oprogramowanie wytwa­rza­ne jest przy współ­pra­cy samo­za­rzą­dzal­nych zespo­łów, któ­rych celem jest prze­pro­wa­dza­nie pro­ce­sów wytwa­rza­nia opro­gra­mo­wa­nia. Pojęcie zwin­ne­go pro­gra­mo­wa­nia zosta­ło zapro­po­no­wa­ne w 2001 w Agile Manifesto.

Komentarz: rynek się zmie­nia w coraz szyb­szym tem­pie, oto­cze­nie ryn­ko­we wpły­wa na orga­ni­za­cje, te zaś pod jego wpły­wem zmie­nia­ją swo­je stra­te­gie i tak­ty­ki. Jeżeli opro­gra­mo­wa­nie jest ich narzę­dziem pra­cy, to zmia­ny te prze­nio­są się wyma­ga­nia wobec tego opro­gra­mo­wa­nia. Jest to nie­unik­nio­ne. Nie jest to ​„ewo­lu­cja wyma­gań” a ich natu­ral­ny cykl życia (pomi­jam tu kwe­stie zmia­ny pomy­słów po stro­nie zama­wia­ją­ce­go, ale to inny temat).

Generalnie gru­pa meto­dyk opar­ta jest na zdy­scy­pli­no­wa­nym zarzą­dza­niu pro­jek­tem, któ­re zakła­da czę­ste inspek­cje wyma­gań i roz­wią­zań wraz z pro­ce­sa­mi adap­ta­cji (zarów­no spe­cy­fi­ka­cji jak i opro­gra­mo­wa­nia). Najczęściej znaj­du­ją zasto­so­wa­nie w małych zespo­łach pro­gra­mi­stycz­nych, w któ­rych nie wystę­pu­je pro­blem komu­ni­ka­cji, przez co nie trze­ba two­rzyć roz­bu­do­wa­nej doku­men­ta­cji kodu. Kolejne eta­py wytwa­rza­nia opro­gra­mo­wa­nia zamknię­te są w ite­ra­cjach, w któ­rych za każ­dym razem prze­pro­wa­dza się testo­wa­nie wytwo­rzo­ne­go kodu, zebra­nie wyma­gań, pla­no­wa­nie roz­wią­zań itd. Nastawiona są na szyb­kie wytwa­rza­nie opro­gra­mo­wa­nia wyso­kiej jakości.

Niestety ten frag­ment opi­su agi­le mówią­cy o dys­cy­pli­nie i czę­stym prze­glą­da­niu sta­nu prac samo­rza­rzą­dzal­nych zespo­łów przy­wo­dzi na myśl sta­ry żart o tym, że her­ba­ta robi się słod­ka nie od cukru a od mie­sza­nia. Tu waż­ne jest sło­wo ​„pla­no­wa­nie” a tak­że ​„zebra­nie wyma­gań”. Minus jest taki, że zbie­ra­nie ite­ra­cyj­ne wyma­gań ozna­cza, że odkry­wa­ne są one dopie­ro w toku reali­za­cji projektu.

Skład zespo­łów jest zazwy­czaj wie­lo­funk­cyj­ny oraz samo­za­rzą­dzal­ny, bez zasto­so­wa­nia jakiej­kol­wiek hie­rar­chii orga­ni­za­cyj­nej. Członkowie zespo­łu bio­rą odpo­wie­dzial­ność za zada­nia posta­wio­ne w każ­dej ite­ra­cji. Sami decy­du­ją jak osią­gnąć posta­wio­ne cele.

Metodyki zwin­ne dużą wagę przy­wią­zu­ją do bez­po­śred­niej komu­ni­ka­cji mię­dzy człon­ka­mi zespo­łu, mini­ma­li­zu­jąc potrze­bę two­rze­nia doku­men­ta­cji. Jeśli człon­ko­wie zespo­łu są w róż­nych loka­li­za­cjach, to pla­nu­je się codzien­ne kon­tak­ty za pośred­nic­twem dostęp­nych kana­łów komu­ni­ka­cji (wide­okon­fe­ren­cja, e‑mail itp.).

Tu powa­ża­ną wadą jest ​„nie­chęć” do two­rze­nia doku­men­tów. Skutkuje to ogrom­ny­mi pro­ble­ma­mi z odtwa­rza­niem ​„usta­leń” histo­rycz­nych (już choć­by cof­nię­cie się o jed­ną ite­ra­cję wstecz bywa pro­ble­mem, bo nie ma śla­du po tre­ści usta­leń, a pamięć ludz­ka jest jed­nak ograniczona).

Częstym błę­dem wystę­pu­ją­cym u osób i zespo­łów sto­su­ją­cych meto­dy­kę agi­le jest nad­in­ter­pre­ta­cja jej zało­żeń i cał­ko­wi­cie błęd­ne pomi­ja­nie bar­dzo waż­nych eta­pów pro­jek­tu tj. ​„zbie­ra­nia wyma­gań”, a następ­nie na ich pod­sta­wie ​„ana­li­zy” oraz ​„pla­no­wa­nia”. (Źródło: Programowanie zwin­ne ? Wikipedia, wol­na ency­klo­pe­dia) 

Tu, mam nadzie­ję, auto­rzy mie­li jed­nak na myśli jakieś dokumenty.….

Tak więc są pod­sta­wy by uznać, że obec­nie meto­dy zwinne:

1. znaj­du­ją zasto­so­wa­nie w małych zespo­łach programistycznych.
2. człon­ko­wie zespo­łu sami decy­du­ją o spo­so­bie reali­za­cji projektu.
3. są eta­py zbie­ra­nia wyma­gań, ana­li­zy, pla­no­wa­nia jed­nak nie spre­cy­zo­wa­no co i w jakiej posta­ci zawie­ra­ją te ​„doku­men­ty”.
4. opro­gra­mo­wa­nie powsta­je meto­dą iteracyjno-przyrostową.
5. nadal ​„raczej”, poza kodem, nie powsta­je żad­na dokumentacja.

Kolejny waż­ny ter­min to SCRUM:

Scrum – ite­ra­cyj­ne i przy­ro­sto­we ramy postę­po­wa­nia zgod­ne z mani­fe­stem Agile. W ramach tego postę­po­wa­nia roz­wój pro­duk­tu podzie­lo­ny jest na mniej­sze, trwa­ją­ce mak­sy­mal­nie jeden mie­siąc kalen­da­rzo­wy ite­ra­cje, zwa­ne sprin­ta­mi nastę­pu­ją­cy­mi bez­po­śred­nio po sobie. Po każ­dym sprin­cie zespół pra­cu­ją­cy nad roz­wo­jem pro­duk­tu jest w sta­nie dostar­czyć dzia­ła­ją­cą jego wer­sję. Scrum jest czę­sto sto­so­wa­ny pod­czas two­rze­nia i roz­wi­ja­nia opro­gra­mo­wa­nia, nie jest jed­nak ogra­ni­czo­ny tyl­ko do tej dzie­dzi­ny. Ogólne zało­że­nia podej­ścia zosta­ły zapre­zen­to­wa­ne przez Hirotakę Takeuchiego i Ikujiro Nonakę w arty­ku­le The New Product Development Game, opu­bli­ko­wa­nym w Harvard Business Review w stycz­niu 1986 roku. Definicja Scruma w zasto­so­wa­niu do pro­duk­cji opro­gra­mo­wa­nia zosta­ła sfor­ma­li­zo­wa­na przez Kena Schwabera w 1995. Scrum czę­sto omył­ko­wo nazy­wa­ny jest meto­dy­ką. (Źródło: Scrum ? Wikipedia, wol­na ency­klo­pe­dia).

SCRUM to ​„ramy postę­po­wa­nia”, nie jest to ​„meto­dy­ka” (meto­dy­ka to ​„zbiór zasad doty­czą­cych spo­so­bów wyko­ny­wa­nia jakiejś pra­cy lub try­bu postę­po­wa­nia pro­wa­dzą­ce­go do okre­ślo­ne­go celu”), jed­nak sta­no­wi sobą opis zarzą­dza­nia reali­za­cją projektu.

Popatrzmy na inży­nie­rię opro­gra­mo­wa­nia jak na inży­nie­rię w ogó­le. Generalnie coś co ma kon­struk­cję, archi­tek­tu­rę, mecha­nizm dzia­ła­nia i funk­cjo­nal­ność jest pro­duk­tem ​„inży­nie­rii”. Słownik j.. pol­skie­go mówi, że:

inży­nie­ria: pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych

Tak więc mamy dwa klu­czo­we eta­py pro­ce­su two­rze­nia: pro­jek­to­wa­nie i kon­stru­owa­nie. Podsumowując mamy pra­wo uznać, że two­rze­nie opro­gra­mo­wa­nia, jeże­li uzna­my ten pro­ces za inży­nie­rię opro­gra­mo­wa­nia, skła­da się z pro­jek­to­wa­nia i kon­stru­owa­nia (kodo­wa­nia).

W 2013 roku pisałem:

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) (Źródło: Mega pro­jek­ty czy­li jak zjeść sło­nia | | Jarosław Żeliński IT-Consulting).

Artykuł ten zawie­ra tak­że dwa dia­gra­my: tak zwa­ny wodo­spa­do­wy oraz ite­ra­cyj­no-przy­ro­sto­wy, spo­sób zarzą­dza­nia zakre­sem projektu.

Drugi dia­gram to wła­śnie w inży­nie­rii ite­ra­cyj­no-przy­ro­sto­we wytwa­rza­nie (tak­że opro­gra­mo­wa­nia). Jeżeli pro­dukt jaki ma powstać jest ​„mały” spro­wa­dzi się prak­tycz­nie do pierw­szych dwóch czę­ści: ana­li­za i opra­co­wa­nie archi­tek­tu­ry oraz pro­jek­to­wa­nie i reali­za­cja. Jeżeli pro­jekt (zakres) jest na tyle duży, że ryzy­ko pro­jek­to­wa­nia cało­ści jest zbyt duże (patrz pierw­szy dia­gram), nale­ży wybrać meto­dę ite­ra­cyj­no-przy­ro­sto­wą, jed­nak wyma­ga to na począt­ku zawsze opra­co­wa­nia (zapro­jek­to­wa­nia) wizji cało­ści, jaką jest archi­tek­tu­ra kom­po­nen­to­wa całe­go roz­wią­za­nia a przy naj­mniej stra­te­gia two­rze­nia apli­ka­cji. Co tu jest opi­sem przed­mio­tu zamó­wie­nia (OPZ)? OPZ – dla doko­na­nia wyce­ny – musi mieć skoń­czo­ny zakres, musi sta­no­wić coś co pozwo­li na ​„odbiór pro­duk­tu”. Dlatego dla dużych pro­jek­tów wygod­nie jest opra­co­wać w ramach OPZ:

1. biz­ne­so­wy kon­tekst pro­jek­tu zawie­ra­ją­cy mode­le pro­ce­sów biznesowych,
2. na bazie mode­li pro­ce­sów, skoń­czo­ną licz­bę przy­pad­ków uży­cia apli­ka­cji (czy­li Przedmiotu Zamówienia),
3. archi­tek­tu­rę i stra­te­gię budo­wy aplikacji,
4. uni­kać deta­li implementacyjnych.

Z taką doku­men­ta­cją mamy: zakres pro­jek­tu oraz narzę­dzie do zarzą­dza­nia ite­ra­cja­mi: każ­dy kolej­ny etap to jeden przy­pa­dek uży­cia. Powinno więc być moż­li­we stwo­rze­nie doku­men­tu OPZ mają­ce­go zamknię­ty zakres, meto­dę roz­li­cze­nia (odbiór jako testy przy­pad­ków uży­cia) i otwar­tą dro­gę dla pra­cy ​„zwin­ne­go” zespo­łu, czy­li miej­sce na kolej­ne ite­ra­cje pro­jek­to­wa­nia deta­li implementacji.

Uwagi na temat Opinii Prawnej … 

Na tym tle teraz popa­trz­my na doku­ment OPINIA PRAWNA SPORZĄDZONA NA ZLECENIE SKARBU PAŃSTWA W IMIENIU KTÓREGO DZIAŁA CENTRUM PROJEKTÓW POLSKA CYFROWA, opra­co­wa­ny przez kan­ce­la­rię Maruta Wachta sp. j. (do pobra­nia https://​cppc​.gov​.pl/​w​p​-​c​o​n​t​e​n​t​/​u​p​l​o​a​d​s​/​A​g​i​l​e​-​w​-​P​Z​P​_​f​i​n​a​l​_​c​z​y​s​t​a​.​pdf).

Dokument ma dla wygo­dy ponu­me­ro­wa­ne aka­pi­ty, odnio­sę do wybra­nych z nich (sek­cja Wnioski):

(1) Kancelaria odno­si się bar­dzo ogól­nie do agi­le, potwier­dza­jąc brak ści­słej defi­ni­cji, nie­ste­ty nie two­rzy wła­snej na uży­tek Opinii.

(2) Kancelaria wyra­ża opi­nię, że meto­dy te ​„są coraz powszech­niej wyko­rzy­sty­wa­ne, z powo­dze­niem, na kon­ty­nen­cie ame­ry­kań­skim oraz w Europie Zachodniej”, nie­ste­ty brak ści­słej defi­ni­cji agi­le oraz brak kry­te­riów ​„powo­dze­nia pro­jek­tu” (z jed­naj stro­ny powo­dze­niem jest pro­jekt ukoń­czo­ny przy zgo­dzie obu stron umo­wy, z dru­giej pro­jekt w któ­rym w ter­mi­nie i budże­cie wyko­na­no dekla­ro­wa­ny zakres) nie pozwa­la oce­nić tego wnio­sku, jest to nie­ste­ty spe­ku­la­cja auto­rów Opinii.

(5) Kancelaria pisze, że ” Zasadnicze zna­cze­nie ma w szcze­gól­no­ści świa­do­ma akcep­ta­cja przez zespół zama­wia­ją­ce­go decy­zji o reali­za­cji dane­go pro­jek­tu w oma­wia­nej for­mu­le [mój przyp.: nie zde­fi­nio­wa­no tej ​„for­mu­ły”] oraz kon­se­kwen­cji z tego pły­ną­cych”, jed­nak moja uwa­ga: inte­res Zamawiającego to mak­si­mum korzy­ści osią­gnię­ty naj­niż­szym kosz­tem, ryn­ko­wy inte­res Wykonawcy jest dokład­nie prze­ciw­staw­ny, z tego powo­du nie wyobra­żam sobie takie­go pro­jek­tu bez doku­men­ta­cji, któ­ra na począt­ku opi­su­je ​„Przedmiot Zamówienia”, nie może nim być jed­nak ​„edżaj­lo­wa usłu­ga pod­ję­cia starań”…

(6) tu Kancelaria zwra­ca jed­nak uwa­gę, że zwin­ne meto­dy moż­na sto­so­wać do pro­jek­tów ​„takich, któ­rych war­tość jest niż­sza niż tzw. pro­gi unij­ne lub takich, w któ­rych zasto­so­wa­nie znaj­du­je okre­ślo­ne wyłą­cze­nie sto­so­wa­nia prze­pi­sów Prawa zamó­wień publicznych”.

(7) ochro­na praw­na (Krajowa Izba Odwoławcza, sądy) moim zda­niem nie jest tu pro­ble­mem, pro­ble­mem jest jakość doku­men­ta­cji tech­nicz­nej, bo poja­wie­nie się spo­ru w pierw­szym rzę­dzie zaowo­cu­je żąda­nia­mi opi­nii rze­czo­znaw­ców a nie praw­ni­ków. Niestety z moje­go doświad­cze­nia wyni­ka, że rze­czo­znaw­cy w tej bran­ży rzad­ko mają kom­pe­ten­cje z zakre­su inży­nie­rii oprogramowania.

Opinia zawie­ra bar­dzo cen­ną część: Podstawa praw­na, któ­ra nie­ste­ty jed­nak nie zawie­ra bar­dzo waż­ne­go w moich oczach odnie­sie­nie do ochro­ny know-how (Dz.U. 1993 Nr 47 poz. 211 USTAWA z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji), choć­by z uwa­gi na to, że spół­ki skar­bu pań­stwa pod­le­ga­ją pod PZP i są pod­mio­ta­mi ryn­ko­wy­mi chro­nią­cy­mi swo­je tajem­ni­ce (wię­cej o tym napi­sa­łem w arty­ku­le Ochrona Know-how Zamawiającego).

Porównanie meto­dy kaska­do­wej i Agile

(1) Jestem tu zasko­czo­ny przy­ję­tą przez Kancelarię defi­ni­cją «kaska­do­wy” (tu auto­rom Opinii i czy­tel­ni­kom tego tek­stu gorą­co pole­cam tę uzna­ną już na świe­cie pozy­cję: SYSTEM ANALYSIS AND DESIGN Fifth Edition). To co nazy­wa­my ​„water­fall” to nie kaska­do­wy pro­ces a pro­ces dwu­eta­po­wy: ana­li­za i szcze­gó­ło­we pro­jek­to­wa­nie oraz imple­men­ta­cja pro­jek­tu. Zacytuję powyż­szą pozy­cję lite­ra­tu­ry przedmiotu:

Waterfall deve­lop­ment metho­do­lo­gies have the advan­ta­ges of iden­ti­fy­ing requ­ire­ments long befo­re pro­gram­ming begins and limi­ting chan­ges to the requ­ire­ments as the pro­ject pro­ce­eds. The key disa­dvan­ta­ges are that the design must be com­ple­te­ly spe­ci­fied befo­re pro­gram­ming begins, a long time elap­ses betwe­en the com­ple­tion of the sys­tem pro­po­sal in the ana­ly­sis pha­se and the deli­ve­ry of sys­tem, and testing is tre­ated almost as an after­tho­ught in the imple­men­ta­tion phase.

Polecam tu tak­że Kancelarii lek­tu­rę np. moje­go arty­ku­łu na ten temat: Cykl życia pro­jek­tu two­rze­nia opro­gra­mo­wa­nia .

(13) powo­ła­nie się na uży­cie Agile w Alegro nie do koń­ca jest tu rze­tel­ne. Na jed­nej z kon­fe­ren­cji (Quality of IT, 7 – 8 2015 r.) refe­rat Szefa IT Allegro nie potwier­dza tego. Owszem ode­szli od kla­sycz­ne­go ​„water­fall” z powo­dów jak wyżej, jed­nak wdro­że­nie agi­le dopro­wa­dzi­ło ich na skraj kata­stro­fy i wdro­żo­no meto­dy ite­ra­cyj­no-przy­ro­sto­we w tym pla­no­wa­nie, doku­men­to­wa­nie i zarzą­dza­nie zmianą.

(17) Kancelaria pisze: ​„Zgodnie z zasa­da­mi meto­dy­ki Agile, pro­duk­ty w pro­jek­cie były dostar­cza­ne mały­mi
czę­ścia­mi, po krót­kich ite­ra­cjach (co do zasa­dy trwa­ją­cych 3 tygo­dnie).” Problem w tym, że każ­dy doświad­czo­ny inży­nier powie, że nie jest moż­li­we spro­wa­dze­nie każ­dej dużej kon­struk­cji inży­nier­skiej do kom­po­nen­tów, któ­rych wytwo­rze­nie zmie­ści się w trzy­ty­go­dnio­wym odcin­ku cza­su. Ta zasa­da (3 tyg. sprin­ty) nie tyl­ko mnie wpra­wa w zakło­po­ta­nie bo np. zapew­ne moż­na w trzy tygo­dnie stwo­rzyć stro­nę któ­ra posłu­ży to wypeł­nia­nia wnio­sków o poli­sę czy kre­dyt, ale stwo­rze­nie w 3 tyg. kom­po­nen­tu sco­rin­go­we­go, przy­dat­ne­go do oce­ny zdol­no­ści kre­dy­to­wej wnio­sko­daw­cy jest nie­moż­li­we a odda­nie do użyt­ku, po 3 tyg. ​„nie­kom­plet­ne­go” takie­go modu­łu raczej przy­nie­sie szko­dy niż ​„korzy­ści dla klien­ta” (ta uwa­ga doty­czy tak­że następ­nej sek­cji Możliwość podzia­łu pro­duk­tu na krót­kie fazy, (3) str. 30).

Nie pod­wa­żam tego, że uży­cie ​„agi­le” pro­wa­dzi­ło gdzieś do suk­ce­sów, jed­nak bez zde­fi­nio­wa­nia poję­cia ​„suk­ces” pro­jek­tu, taka oce­na jest bez­war­to­ścio­wa, bo sam fakt, że pro­jekt w koń­cu został dopro­wa­dzo­ny do koń­ca nic tu nie zna­czy, liczy się to jak się miał pier­wot­ny plan do uzy­ska­ne­go efek­tu a tego tu nie napisano.

Nie była tu moim celem oce­na tego opra­co­wa­nia. Celem jest kon­fron­ta­cja opi­sa­ne­go prze­ze mnie ite­ra­cyj­no-przy­ro­sto­we pro­ce­su inży­nie­rii z opi­nia­mi auto­rów Opinii. Autorzy w ramach pod­su­mo­wa­nia na str. 83, umie­ści­li tabe­lę zawie­ra­ją­ce listę ​„czyn­ni­ków zwin­no­ści” i moż­li­wo­ści ich zasto­so­wa­nia w pro­jek­tach dla admi­ni­stra­cji. Wygląda na to, że jest to moż­li­we, co praw­da ja powy­żej sku­pi­łem się na opi­sie meto­dy ite­ra­cyj­no-przy­ro­sto­wej, tak­że uzna­wa­nej za ​„zwin­ną”, ale takich ​„uznań” mamy wie­le w lite­ra­tu­rze łącz­nie z tak zwa­nym ​„pro­gra­mo­wa­niem ekstremalnym”.

Sama opi­nia praw­na zawar­ta w Opinii jest bar­dzo cen­na i war­to­ścio­wa. Moim zda­niem jed­nak nie ma potrze­by budo­wa­nia skom­pli­ko­wa­nych mecha­ni­zmów praw­nych do prze­pro­wa­dze­nia ​„zwin­ne­go” pro­jek­tu na bazie PZP. Uważam, że klu­czem jest opi­sa­ne prze­ze mnie kla­sycz­ne inży­nier­skie podej­ście (eta­py i podział na kom­po­nen­ty – przy­pad­ki uży­cia) i dys­cy­pli­na w pro­jek­cie. Tu nale­ży zgo­dzić się, że – za SCRUM – klu­czo­wą jest rola Product Ownera, któ­ry – nie tyl­ko moim zda­niem – powi­nien być bez­względ­nie rolą po stro­nie Zamawiającego, oraz rola Kierownika Projektu po stro­nie Wykonawcy, któ­ry powi­nien utrzy­my­wać bar­dzo dużą dys­cy­pli­nę, mając w umo­wie bar­dzo dobrą pro­ce­du­rę komu­ni­ka­cji, zarzą­dza­nia zmia­ną i doku­men­ta­cją. Największym ryzy­kiem jest, w moim mnie­ma­niu, zało­że­nie wyma­ga­ne­go ​„zgod­ne­go dzia­ła­nia stron” (wiem, ze takie sfor­mu­ło­wa­nie jest w Kodeksie Cywilnym). Każdy kto spo­tkał się w sądzie ze spo­rem pomię­dzy Zamawiającym opro­gra­mo­wa­nie a jego Dostawcą wie, że naj­więk­szym pro­blem jest brak rze­tel­nej doku­men­ta­cji pro­jek­to­wej, w szcze­gól­no­ści pre­cy­zu­ją­cej ​„to co mia­ło powstać”.

(infor­ma­cja o arty­ku­le zosta­ła wysła­na 16.02.2017 na adres Kancelarii biuro@maruta.pl, nie otrzy­ma­łem żad­nych uwag z Kancelarii)

P.S.

jako ciąg dal­szy pole­cam wpis Wzorcowe klau­zu­le w umo­wach IT.