Polecam lekturę ciekawej Opinii Prawnej kancelarii Maruta Wachta sp. j.. (dalej odpowiednio 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ę odniosę do Opinii, najpierw klika słów na temat zwinnego realizowania projektów. Jak rzadko, posłużę się Wikipedią, gdyż pojęcie “metody zwinne” nie ma ścisłej definicji, Manifest Agile zaś jest na tyle ogólny, że nie jest możliwe użycie go jako definicji. Po drugie Wikipedia jest powszechnie przywoływana jako źródło w środowiskach związanych ze stosowaniem metod zwinnych dlatego uznałem, że definicje tam umieszczane będą tu najbardziej adekwatne. Przypomnę, że osobiście nie używam pojęcia “agile” w swoich projektach, gdyż uważam, że obecne słownictwo i metody w obszarze inżynierii zupełnie wystarczą i są znacznie precyzyjniejsze i od lat stosowane z powodzeniem. Poniżej próba uporządkowania tych pojęć na potrzeby dalszych rozważań.

Za Wikipedią (cytaty):

Programowanie zwinne (ang. agile software development) ? grupa metod wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym, powstałe jako alternatywa do tradycyjnych metod typu waterfall. Najważniejszym założeniem metodyk zwinnych jest obserwacja, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu. Oprogramowanie wytwarzane jest przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania. Pojęcie zwinnego programowania zostało zaproponowane w 2001 w Agile Manifesto.

Komentarz: rynek się zmienia w coraz szybszym tempie, otoczenie rynkowe wpływa na organizacje, te zaś pod jego wpływem zmieniają swoje strategie i taktyki. Jeżeli oprogramowanie jest ich narzędziem pracy, to zmiany te przeniosą się wymagania wobec tego oprogramowania. Jest to nieuniknione. Nie jest to “ewolucja wymagań” a ich naturalny cykl życia (pomijam tu kwestie zmiany pomysłów po stronie zamawiającego, ale to inny temat).

Generalnie grupa metodyk oparta jest na zdyscyplinowanym zarządzaniu projektem, które zakłada częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji (zarówno specyfikacji jak i oprogramowania). Najczęściej znajdują zastosowanie w małych zespołach programistycznych, w których nie występuje problem komunikacji, przez co nie trzeba tworzyć rozbudowanej dokumentacji kodu. Kolejne etapy wytwarzania oprogramowania zamknięte są w iteracjach, w których za każdym razem przeprowadza się testowanie wytworzonego kodu, zebranie wymagań, planowanie rozwiązań itd. Nastawiona są na szybkie wytwarzanie oprogramowania wysokiej jakości.

Niestety ten fragment opisu agile mówiący o dyscyplinie i częstym przeglądaniu stanu prac samorzarządzalnych zespołów przywodzi na myśl stary żart o tym, że herbata robi się słodka nie od cukru a od mieszania. Tu ważne jest słowo “planowanie” a także “zebranie wymagań”. Minus jest taki, że zbieranie iteracyjne wymagań oznacza, że odkrywane są one dopiero w toku realizacji projektu.

Skład zespołów jest zazwyczaj wielofunkcyjny oraz samozarządzalny, bez zastosowania jakiejkolwiek hierarchii organizacyjnej. Członkowie zespołu biorą odpowiedzialność za zadania postawione w każdej iteracji. Sami decydują jak osiągnąć postawione cele.

Metodyki zwinne dużą wagę przywiązują do bezpośredniej komunikacji między członkami zespołu, minimalizując potrzebę tworzenia dokumentacji. Jeśli członkowie zespołu są w różnych lokalizacjach, to planuje się codzienne kontakty za pośrednictwem dostępnych kanałów komunikacji (wideokonferencja, e-mail itp.).

Tu poważaną wadą jest “niechęć” do tworzenia dokumentów. Skutkuje to ogromnymi problemami z odtwarzaniem “ustaleń” historycznych (już choćby cofnięcie się o jedną iterację wstecz bywa problemem, bo nie ma śladu  po treści ustaleń, a pamięć ludzka jest jednak ograniczona).

Częstym błędem występującym u osób i zespołów stosujących metodykę agile jest nadinterpretacja jej założeń i całkowicie błędne pomijanie bardzo ważnych etapów projektu tj. “zbierania wymagań”, a następnie na ich podstawie “analizy” oraz “planowania”. (Źródło: Programowanie zwinne ? Wikipedia, wolna encyklopedia) 

Tu, mam nadzieję, autorzy mieli jednak na myśli jakieś dokumenty…..

Tak więc są podstawy by uznać, że obecnie metody zwinne:

1. znajdują zastosowanie w małych zespołach programistycznych.
2. członkowie zespołu sami decydują o sposobie realizacji projektu.
3. są etapy zbierania wymagań, analizy, planowania jednak nie sprecyzowano co i w jakiej postaci zawierają te “dokumenty”.
4. oprogramowanie powstaje metodą iteracyjno-przyrostową.
5. nadal “raczej”, poza kodem, nie powstaje żadna dokumentacja.

Kolejny ważny termin to SCRUM:

Scrum – iteracyjne i przyrostowe ramy postępowania zgodne z manifestem Agile. W ramach tego postępowania rozwój produktu podzielony jest na mniejsze, trwające maksymalnie jeden miesiąc kalendarzowy iteracje, zwane sprintami następującymi bezpośrednio po sobie. Po każdym sprincie zespół pracujący nad rozwojem produktu jest w stanie dostarczyć działającą jego wersję. Scrum jest często stosowany podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej dziedziny. Ogólne założenia podejścia zostały zaprezentowane przez Hirotakę Takeuchiego i Ikujiro Nonakę w artykule The New Product Development Game, opublikowanym w Harvard Business Review w styczniu 1986 roku. Definicja Scruma w zastosowaniu do produkcji oprogramowania została sformalizowana przez Kena Schwabera w 1995. Scrum często omyłkowo nazywany jest metodyką. (Źródło: Scrum ? Wikipedia, wolna encyklopedia).

SCRUM to “ramy postępowania”, nie jest to “metodyka” (metodyka to “zbiór zasad dotyczących sposobów wykonywania jakiejś pracy lub trybu postępowania prowadzącego do określonego celu”), jednak stanowi sobą opis zarządzania realizacją projektu.

Popatrzmy na inżynierię oprogramowania jak na inżynierię w ogóle. Generalnie coś co ma konstrukcję, architekturę, mechanizm działania i funkcjonalność jest produktem “inżynierii”. Słownik j.. polskiego mówi, że:

inżynieria: projektowanie i konstruowanie obiektów oraz urządzeń technicznych

Tak więc mamy dwa kluczowe etapy procesu tworzenia: projektowanie i konstruowanie. Podsumowując mamy prawo uznać, że tworzenie oprogramowania, jeżeli uznamy ten proces za inżynierię oprogramowania, składa się z projektowania i konstruowania (kodowania).

W 2013 roku pisałem:

Pamiętajmy, że zarządzanie zakresem projektu jest tym kosztowniejsze im więcej szczegółów ten zakres posiada. Projekt o 30 wymaganiach vs. projekt o 300 wymaganiach to nie projekt o 10-krotnie większym koszcie, ta różnica będzie znacznie większa (pomijam to, jak w ogóle zdefiniujemy wymaganie) (Źródło: Mega projekty czyli jak zjeść słonia | | Jarosław Żeliński IT-Consulting).

Artykuł ten zawiera także dwa diagramy: tak zwany wodospadowy oraz iteracyjno-przyrostowy, sposób zarządzania zakresem projektu.

Drugi diagram to właśnie w inżynierii iteracyjno-przyrostowe wytwarzanie (także oprogramowania). Jeżeli produkt jaki ma powstać jest “mały” sprowadzi się praktycznie do pierwszych dwóch części: analiza i opracowanie architektury oraz projektowanie i realizacja. Jeżeli projekt (zakres) jest na tyle duży, że ryzyko projektowania całości jest zbyt duże (patrz pierwszy diagram), należy wybrać metodę iteracyjno-przyrostową, jednak wymaga to na początku zawsze opracowania (zaprojektowania) wizji całości, jaką jest architektura komponentowa całego rozwiązania a przy najmniej strategia tworzenia aplikacji. Co tu jest opisem przedmiotu zamówienia (OPZ)? OPZ – dla dokonania wyceny – musi mieć skończony zakres, musi stanowić coś co pozwoli na “odbiór produktu”. Dlatego dla dużych projektów wygodnie jest opracować w ramach OPZ:

1. biznesowy kontekst projektu zawierający modele procesów biznesowych,
2. na bazie modeli procesów, skończoną liczbę przypadków użycia aplikacji (czyli Przedmiotu Zamówienia),
3. architekturę i strategię budowy aplikacji,
4. unikać detali implementacyjnych.

Z taką dokumentacją mamy: zakres projektu oraz narzędzie do zarządzania iteracjami: każdy kolejny etap to jeden przypadek użycia. Powinno więc być możliwe stworzenie dokumentu OPZ mającego zamknięty zakres, metodę rozliczenia (odbiór jako testy przypadków użycia) i otwartą drogę dla pracy “zwinnego” zespołu, czyli miejsce na kolejne iteracje projektowania detali implementacji.

Uwagi na temat Opinii Prawnej …

Na tym tle teraz popatrzmy na dokument OPINIA PRAWNA SPORZĄDZONA NA ZLECENIE SKARBU PAŃSTWA W IMIENIU KTÓREGO DZIAŁA CENTRUM PROJEKTÓW POLSKA CYFROWA, opracowany przez kancelarię Maruta Wachta sp. j. (do pobrania https://cppc.gov.pl/wp-content/uploads/Agile-w-PZP_final_czysta.pdf).

Dokument ma dla wygody ponumerowane akapity, odniosę do wybranych z nich (sekcja Wnioski):

(1) Kancelaria odnosi się bardzo ogólnie do agile, potwierdzając brak ścisłej definicji, niestety nie tworzy własnej na użytek Opinii.

(2) Kancelaria wyraża opinię, że metody te “są coraz powszechniej wykorzystywane, z powodzeniem, na kontynencie amerykańskim oraz w Europie Zachodniej”, niestety brak ścisłej definicji agile oraz brak kryteriów “powodzenia projektu” (z jednaj strony powodzeniem jest projekt ukończony przy zgodzie obu stron umowy, z drugiej projekt w którym w terminie i budżecie wykonano deklarowany zakres) nie pozwala ocenić tego wniosku, jest to niestety spekulacja autorów Opinii.

(5) Kancelaria pisze, że ” Zasadnicze znaczenie ma w szczególności świadoma akceptacja przez zespół zamawiającego decyzji o realizacji danego projektu w omawianej formule [mój przyp.: nie zdefiniowano tej “formuły”]  oraz konsekwencji z tego płynących”, jednak moja uwaga: interes Zamawiającego to maksimum korzyści osiągnięty najniższym kosztem, rynkowy interes Wykonawcy jest dokładnie przeciwstawny, z tego powodu nie wyobrażam sobie takiego projektu bez dokumentacji, która na początku opisuje “Przedmiot Zamówienia”, nie może nim być jednak “edżajlowa usługa podjęcia starań”…

(6) tu Kancelaria zwraca jednak uwagę, że zwinne metody można stosować do projektów “takich, których wartość jest niższa niż tzw. progi unijne lub takich, w których zastosowanie znajduje określone wyłączenie stosowania przepisów Prawa zamówień publicznych”.

(7) ochrona prawna (Krajowa Izba Odwoławcza, sądy) moim zdaniem nie jest tu problemem, problemem jest jakość dokumentacji technicznej, bo pojawienie się sporu w pierwszym rzędzie zaowocuje żądaniami opinii rzeczoznawców a nie prawników. Niestety z mojego doświadczenia wynika, że rzeczoznawcy w tej branży rzadko mają kompetencje z zakresu inżynierii oprogramowania.

Opinia zawiera bardzo cenną część: Podstawa prawna, która niestety jednak nie zawiera bardzo ważnego w moich oczach odniesienie do ochrony know-how (Dz.U. 1993 Nr 47 poz. 211 USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji), choćby z uwagi na to, że spółki skarbu państwa podlegają pod PZP i są podmiotami rynkowymi chroniącymi swoje tajemnice (więcej o tym napisałem w artykule Ochrona Know-how Zamawiającego).

Porównanie metody kaskadowej i Agile

(1) Jestem tu zaskoczony przyjętą przez Kancelarię definicją ‘kaskadowy” (tu autorom Opinii i czytelnikom tego tekstu gorąco polecam tę uznaną już na świecie pozycję: SYSTEM ANALYSIS AND DESIGN Fifth Edition). To co nazywamy “waterfall” to nie kaskadowy proces a proces dwuetapowy: analiza i szczegółowe projektowanie oraz implementacja projektu. Zacytuję powyższą pozycję literatury przedmiotu:

Waterfall development methodologies have the advantages of identifying requirements long before programming begins and limiting changes to the requirements as the project proceeds. The key disadvantages are that the design must be completely specified before programming begins, a long time elapses between the completion of the system proposal in the analysis phase and the delivery of system, and testing is treated almost as an afterthought in the implementation phase.

Polecam tu także Kancelarii lekturę np. mojego artykułu na ten temat: Cykl życia projektu tworzenia oprogramowania .

(13) powołanie się na użycie Agile w Alegro nie do końca jest tu rzetelne. Na jednej z konferencji (Quality of IT, 7-8 2015 r.) referat Szefa IT Allegro nie potwierdza tego. Owszem odeszli od klasycznego “waterfall” z powodów jak wyżej, jednak wdrożenie agile doprowadziło ich na skraj katastrofy i wdrożono metody iteracyjno-przyrostowe w tym planowanie, dokumentowanie i zarządzanie zmianą.

(17) Kancelaria pisze: “Zgodnie z zasadami metodyki Agile, produkty w projekcie były dostarczane małymi
częściami, po krótkich iteracjach (co do zasady trwających 3 tygodnie).” Problem w tym, że każdy doświadczony inżynier powie, że nie jest możliwe sprowadzenie każdej dużej konstrukcji inżynierskiej do komponentów, których wytworzenie zmieści się w trzytygodniowym odcinku czasu. Ta zasada (3 tyg. sprinty) nie tylko mnie wprawa w zakłopotanie bo np. zapewne można w trzy tygodnie stworzyć stronę która posłuży to wypełniania wniosków o polisę czy kredyt, ale stworzenie w 3 tyg. komponentu scoringowego, przydatnego do oceny zdolności kredytowej wnioskodawcy jest niemożliwe a oddanie do użytku, po 3 tyg.  “niekompletnego” takiego modułu raczej przyniesie szkody niż “korzyści dla klienta”  (ta uwaga dotyczy także następnej sekcji Możliwość podziału produktu na krótkie fazy, (3) str. 30).

Nie podważam tego, że użycie “agile” prowadziło gdzieś do sukcesów, jednak bez zdefiniowania  pojęcia “sukces” projektu, taka ocena jest bezwartościowa, bo sam fakt, że projekt w końcu został doprowadzony do końca nic tu nie znaczy, liczy się to jak się miał pierwotny plan do uzyskanego efektu a tego tu nie napisano.

Nie była tu moim celem ocena tego opracowania. Celem jest konfrontacja opisanego przeze mnie iteracyjno-przyrostowe procesu inżynierii z opiniami autorów Opinii. Autorzy w ramach podsumowania na str. 83, umieścili tabelę zawierające listę “czynników zwinności” i możliwości ich zastosowania w projektach dla administracji. Wygląda na to, że jest to możliwe, co prawda ja powyżej skupiłem się na opisie metody iteracyjno-przyrostowej, także uznawanej za “zwinną”, ale takich “uznań”  mamy wiele w literaturze łącznie z tak zwanym “programowaniem ekstremalnym”.

Sama opinia prawna zawarta w Opinii jest bardzo cenna i wartościowa. Moim zdaniem jednak nie ma potrzeby budowania skomplikowanych mechanizmów prawnych do przeprowadzenia “zwinnego” projektu na bazie PZP. Uważam, że kluczem jest opisane przeze mnie klasyczne inżynierskie podejście (etapy i podział na komponenty – przypadki użycia) i dyscyplina w projekcie. Tu należy zgodzić się, że – za SCRUM – kluczową jest rola Product Ownera, który – nie tylko moim zdaniem – powinien być bezwzględnie rolą po stronie Zamawiającego, oraz rola Kierownika Projektu po stronie Wykonawcy, który powinien utrzymywać bardzo dużą dyscyplinę, mając w umowie bardzo dobrą procedurę komunikacji, zarządzania zmianą i dokumentacją. Największym ryzykiem jest, w moim mniemaniu, założenie wymaganego “zgodnego działania stron” (wiem, ze takie sformułowanie jest w Kodeksie Cywilnym). Każdy kto spotkał się w sądzie ze sporem pomiędzy Zamawiającym oprogramowanie a jego Dostawcą wie, że największym problem jest brak rzetelnej dokumentacji projektowej, w szczególności precyzującej “to co miało powstać”.

(informacja o artykule została wysłana 16.02.2017 na adres Kancelarii biuro@maruta.pl, nie otrzymałem żadnych uwag z Kancelarii)

P.S.

jako ciąg dalszy polecam wpis Wzorcowe klauzule w umowach IT.