Agile w PZP

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:

Scrumite­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.

Projekt mają­cy jeden etap ana­li­zy i projektowania.
Projekt w któ­rym na począt­ku pro­jek­tu­je się archi­tek­tu­rę a szcze­gó­ły dopre­cy­zo­wu­je się w toku kolej­nych eta­pów (ite­ra­cji).

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.

Inne artykuły na podobny temat

Komentarze

  1. Marek Bisztyga 16 lutego 2017 at 10:28

    W samo sedno !!!

  2. Hania 16 lutego 2017 at 10:52

    Bardzo dobre pyta­nie. Co to zna­czy Sukces w pro­jek­cie Agile/Scrum? Tradycyjnie mówi­ło się o wyko­na­niu pro­jek­tu w okre­ślo­nym budże­cie, cza­sie, zakre­sie, jako­ści. Niektórzy szli dalej mówiąc o war­to­ści dla odbior­cy, osią­gnię­ciu jego celu biz­ne­so­we­go w odróż­nie­niu od jedy­nie dostar­cze­nia zamó­wio­ne­go opro­gra­mo­wa­nia. Jak oce­nić, czy pro­jekt agi­le odniósł suk­ces? Sprawdzając czy został osią­gnię­ty cel biz­ne­so­wy? Zakres, rozu­miem, to rzecz dru­go­rzęd­na w tym kon­tek­ście. Ale budżet na pew­no jest inte­re­su­ją­cy. Czyli może­my porów­nać wydat­ki rze­czy­wi­ste­go pro­jek­tu z wydat­ka­mi pla­no­wa­ny­mi albo ponie­sio­ny­mi w innym podej­ściu i w ten spo­sób dowie­dzieć się czy to był suk­ces osią­gnię­ty bar­dziej opty­mal­nym sposobem?

    • Jaroslaw Zelinski 16 lutego 2017 at 11:00

      Najprościej jest doko­nać porów­na­nia tego co wie­dzia­no o pro­jek­cie przed jego roz­po­czę­ciem z tym co uzy­ska­no. Nie mniej jed­nak w zarzą­dza­niu liczy się ren­tow­ność pro­jek­tu, ta do jej poli­cze­nia wyma­ga zna­jo­mo­ści war­to­ści inwe­sty­cji i ter­mi­nu jej uzy­ska­nia. Bez tego pro­jekt sta­je czymś w rodza­ju R&D na koszt Zamawiającego. Co cie­ka­we, w żad­nej innej inży­nie­rii na świe­cie nie ma mowy o meto­dach zwin­nych :), tyl­ko w IT gdzie nie widać odpa­dów”, czy­li mar­no­traw­stwa… Czy ktoś roz­sąd­ny zapła­cił by za uzy­ska­ny w koń­cu drew­nia­ny fotel widząc na rachun­ku war­tość mate­ria­łu, hał­dy wió­rów i ścin­ków po kolej­nych ite­ra­cjach, pro­to­ty­pach i refaktoringach?

    • Marek Bisztyga 16 lutego 2017 at 11:02

      To, co jest suk­ce­sem dla zespo­łu agi­lo­we­go, nie­ko­niecz­nie jest suk­ce­sem biz­ne­su, i odwrot­nie. Czasami suk­ce­sem jest pod­ję­cie decy­zji o prze­rwa­niu pro­jek­tu, czy­li nie­spa­le­nie” dużej kasy.

    • Marek Bisztyga 16 lutego 2017 at 11:15

      … ale z dru­giej stro­ny, cza­sa­my ryzy­ko może się opła­cić. Poza tym pro­jekt agi­lo­wy może dotar­czyć bez­cen­nej wie­dzy, któ­rej nigdy nie zgłę­bio­no by , gdy­by ktoś nie pod­jął złej” decy­zji o roz­po­czę­ciu pro­jek­tu. Z każ­dej poraż­ki moż­na wydo­być jakąś korzyść. Oby tyl­ko na siłę pro­pa­gan­do­wo nie prze­ku­wać jej w suk­ces albo wsty­dli­wie zamia­tać pod dywan, oraz zawsze war­to pamię­tać , że głu­pi uczy się na błę­dach wła­snych, mądry na cudzych”. Niech żyje zatem ana­li­za porażek !

    • Jaroslaw Zelinski 16 lutego 2017 at 12:02

      ale nie wbu­do­wuj­my pora­żek na sta­łe w PZP 🙂

    • Marek Bisztyga 16 lutego 2017 at 12:38

      [Jarek] … ale jak pamię­tasz, wg. E.Yourdona („Marsz ku klę­sce ?”) wszyst­kie pro­jek­ty są mar­szem ku klę­sce, a tyl­ko gar­st­ce nie­świa­do­mych tego sza­leń­ców uda­je się przez przy­pa­dek nie polec 😉

    • Jaroslaw Zelinski 16 lutego 2017 at 13:43

      Aż tak zły ten opis nie był 😉

  3. Hania 16 lutego 2017 at 11:37

    Mam jesz­cze jed­ną zagwozd­kę. Wygląda na to, że dostrze­żo­no pro­blem z pro­jek­ta­mi publicz­ny­mi i szu­ka się spo­so­bów popra­wy sytu­acji, co jest jak naj­bar­dziej na plus. Jednak rodzi się zało­że­nie, że agi­le roz­wią­że pro­ble­my. Wydaje mi się, że nie. Problemów jest cała dłu­ga lista i mają róż­ne powody.
    Agile zakła­da sil­ne poczu­cie odpo­wie­dzial­no­ści za two­rzo­ny pro­dukt. Product Owner powi­nien wie­dzieć dokład­nie co jest do osią­gnię­cia. Powinien podej­mo­wać decy­zje. Być nasta­wio­ny na cią­głą komu­ni­ka­cję i dostęp­ny. Zły PO to duży pro­blem. Podstawowy. Może mam nie­ty­po­we doświad­cze­nia, ale wyda­je mi się, że w publicz­nych pro­jek­tach wła­śnie bar­dzo trud­no jest zna­leźć oso­bę bio­rą­cą odpo­wie­dzial­ność za kon­cep­cję i chęt­ną do podej­mo­wa­nia decy­zji. Więc nie wiem czy zasto­so­wa­nie tego podej­ścia wyeli­mi­nu­je problemy.

    • Jaroslaw Zelinski 16 lutego 2017 at 12:01

      Zgadzam się z Tobą. Problem z pro­jek­ta­mi dla GOC jest. Potocznie poj­mo­wa­ny Agile żad­ne­go pro­ble­mu tu nie roz­wią­zu­je, to aż i tyl­ko umo­wa sta­ran­ne­go dzia­ła­nia” a nie reali­za­cja pro­jek­tu. PO to klu­czo­wa rola i nie powi­nien to być czło­nek zespo­łu dostaw­cy. Nadal uwa­żam, że nale­ża­ło by obec­ne Prawo Budowlane i usta­wy pokrew­ne, roz­cią­gnąć na wszel­kie pro­jek­ty z zakre­su inży­nie­rii. Wtedy powsta­je poję­cie obli­ga­to­ryj­ne­go wydzie­le­nia eta­pu pro­jek­to­wa­nia, potem reali­za­cja, autor pro­jek­tu jest z zasa­dy wyłą­czo­ny z postę­po­wa­nia o wyko­na­nie ba ma Nadzór Autorski (jest PO). Niestety rynek IT jest nieregulowany…

    • Marek Bisztyga 16 lutego 2017 at 12:49

      [Hania] Poruszasz pro­blem (temat-rze­ka): zarzą­dza­nie nie­pew­no­ścią vs. zarzą­dza­nie ryzy­kiem. Ja to widzę nastę­pu­ją­co: zarzą­dza­nie nie­pew­no­ścią pole­ga na nada­wa­niu cech adap­ta­cyj­nych ?pro­duk­tom? ( w tym orga­ni­za­cjom) , a zarzą­dza­nie ryzy­kiem to decy­zje w reak­cji na zda­rze­nia, z wyko­rzy­sta­niem owych cech adap­ta­cyj­nych. Zarządzanie nie­pew­no­ścią to decy­zje stra­te­gicz­ne, zarzą­dza­nie ryzy­kiem – ope­ra­cyj­ne. Budowanie pro­duk­tów zdol­nych do adap­ta­cji to CAPEX, a zarzą­dza­nie ryzy­kiem to OPEX.
      [Jarek] ?umo­wa sta­ran­ne­go dzia­ła­nia? – dobre określenie.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

System komentarzy służy także do uzyskania konsultacji u autora tekstu, w przedmiocie treści artykułu.

Identyfikator *
E-mail *
Witryna internetowa

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