Na stronach portalu LindekIn ukazał sie bardzo dobry artykuł autorstwa Marcina Maruty z kancelarii Maruta Wachta sp.j., na temat oprogramowania open source:
Powyższe to tylko fragment na zachętę, gorąco polecam lekturę całego tego tekstu zanim zaczniecie Państwo czytać mój. Poniżej mój komentarz, jaki umieściłem pod powyższym tekstem.
Świetny tekst, cieszę się także że padło słowa “Oprogramowanie komputerowe jest przede wszystkim chronione prawem autorskim (niestety). “.
Po lekturze tego tekstu, z którym zgadzam sie w całości, ciśnie mi sie na ustal kilka koniecznych, chyba “inżynierskich”, uzupełnień. Od końca.
Prawo autorskie to prawa osobiste i majątkowe. Tezę o pracy za satysfakcję traktuję jako tezę tępiącą bierne przychody z licencji i monopol, które moim zdaniem niszczą rynek i budują barierę korzystania z nowych technologii. W moim odczuciu prawo autorskie osobiste to silna ochrona przez plagiatami (i lubię te ochronę nie tylko w nauce), prawa majątkowe mają moim zdaniem sens, gdy utwór (informacja jaką niesie) stanowi zarazem czyjeś chronione know-how, i moim zdaniem tylko wtedy. Ideałem dla mnie jest pobranie programu za darmo, i gdy uznam, że jest przydatny płacę “ludziom” wyłącznie za wykonaną pracę, np. prace nad dalszym rozwojem tego produktu, pracę typu help desk itp.. Ale tu ostrożnie, bo pracę nad dostosowaniem do moich potrzeb można nie raz uznać za rozbudowę mechanizmu realizowanej logiki, i tu może sie pojawić kwestia mojego know-how (należy wydzielić w umowie tez część projektu).
Prawo autorskie zostało w moich oczach w IT wynaturzone, ale nie dlatego że jest stosowane, a dlatego nie są tworzone pośrednie projekty mechanizmów (abstrakcja kodu). W efekcie chronione są miliony linii kodu jako “tekst”, co praktycznie blokuje rozwój tego kodu poza osobą jego autora. Gdyby przed kodem powstawał projekt (np. takie jakie znamy z dokumentacji patentów), kod programu byłby utworem zależnym z wszystkimi wadami i zaletami, tu: open source’owy projekt mechanizmu (logika i architektura systemu) pozwala na powstawanie dowolnej liczby implementacji, czyli mamy zarazem i konkurencję i ochronę dorobku ludzi. I projekty takie powstają, ale twórcy oprogramowania open source w zasadzie nigdy tego nie robią!
(źr. SYSTEM ANALYSIS AND DESIGN
John Wiley & Sons, Inc. http://www.wiley.com/college/dennis
Fifth Edition ALAN DENNIS Indiana University BARBARA HALEY WIXOM University of Virginia ROBERTA M. ROTH University of Northern Iowa)
Drugi poważny problem to teza, że “mając kod wiem co mam”. Niestety w latach 70-tych być może. Ale dzisiejsze aplikacje to miliony linii kodu i ich audyt w akceptowalnym czasie jest realnie niemożliwy. Odkrycia bugów “post factum” w systemach open source przeczą tezie, że “otwarty kod znaczy bezpieczny, bo każdy go może audytować i znajdować błędy”. To (te audyty) się nie dzieje, dzieją za to się skutki błędów tego kodu. Co możemy zrobić? Zacząć traktować oprogramowanie (określone moduły czy komponenty) jak czarne skrzynki dokumentowane tylko na poziomie mechanizmu jaki realizują (patrz dokumentacja patentów: opisują mechanizm a nie implementację). Wtedy: 1. pracujemy nie z milionami linii kodu a z kilkunastoma, góra kilkudziesięcioma, stronami technicznego opisu mechanizmu działania i architektury pomysłu (abstrakcja systemu). 2. zostawiamy inżynierom pełną swobodę implementacji, czyli pozwalamy konkurować jakością, doborem technologii, mówiąc inaczej otwieramy drogę do postępu technologii, prawnoautorska “ochrona kodu” betonuje zawarty w nim dług technologiczny: nie raz dużo lepszym rozwiązaniem jest wykonanie nowej implementacji danego mechanizmu, niż rozbudowa czy naprawa starej implementacji.
Krótkie i otwarte opracowanie obalające tezy, że kodu nie da się dokumentować na wyższym, abstrakcyjnym poziomie (fragment):
Programowanie nie polega wyłącznie na tworzeniu oprogramowania – programowanie polega na projektowaniu oprogramowania. Myślenie o kodzie źródłowym jako o projekcie nie oznacza, że nie należy projektować, tylko kodować. Dobra architektura i abstrakcje są niezbędne. Podobnie, architektura nie jest wyłącznie o projektowaniu oprogramowania, architektura jest o konstruowaniu oprogramowania. Inżynierowie oprogramowania coraz częściej potrzebują języków programowania wysokiego poziomu, które są bliższe temu, jak inżynierowie oprogramowania myślą i projektują oprogramowanie, a także języków modelowania, które są bliższe temu, jak szczegółowe projekty mogą być realizowane w kodzie. (Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3?5. https://doi.org/10.1109/MS.2019.2959049)
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:
znajdują zastosowanie w małych zespołach programistycznych.
członkowie zespołu sami decydują o sposobie realizacji projektu.
są etapy zbierania wymagań, analizy, planowania jednak nie sprecyzowano co i w jakiej postaci zawierają te “dokumenty”.
oprogramowanie powstaje metodą iteracyjno-przyrostową.
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.
Projekt mający jeden etap analizy i projektowania.
Projekt w którym na początku projektuje się architekturę a szczegóły doprecyzowuje się w toku kolejnych etapów (iteracji).
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:
biznesowy kontekst projektu zawierający modele procesów biznesowych,
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.
(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)
Tym razem króciutki wpis. Pragnę polecić numer 7/2014 COMPUTERWORLD a w nim (głównie, cały numer warto poznać ;)). Numer ten zawiera bardzo wartościowy artykuł “Pięć typowych błędów w umowach wdrożeniowych” Pana Marcina Maruty (Kancelaria Radców Prawnych Maruta i Wspólnicy).
Pan Maruta wskazuje, jako kluczową przyczynę wielu problemów z wdrożeniami (a konkretnie z kontraktami na ich realizację) jest źle sformułowany, a nie raz po prostu brak, przedmiot umowy. Przyznam, że banan przy moim uśmiechu na twarzy to pikuś, jak pomyślałem, co myślą zwolennicy “zwinnych metod” czytając to (cytat w ramce). Jeżeli przedmiot umowy (jego opis) to tak na prawdę efekt pierwszego etapu realizacji tej umowy (czyli po jej podpisaniu) wykonany przez dostawcę, to kłopoty niemalże gwarantowane.
Kolejna plaga, to forma realizacji umowy, czyli metodyka. Wniosek jest jeden: szukasz kłopotów to nie zapisuj tego co uzgadniasz i co robisz, jak zmieniasz zakres umowy lub harmonogram (są często załącznikami do umów) rób to niedbale.
Ale nie jest tu moim celem streszczanie tego napisał Pan Maruta, raczej staram się zachęcić do lektury tego numeru pisma. Wniosek jest jeden: realizacja umowy powinna byś dobrze zarządzanym i dokumentowanym procesem. Nikt nikomu nie życzy problemów, ale brak “śladów” po realizowanych zadaniach, źle opisany zakres umowy mści się po wielokroć, tak w sądzie jak i przy próbie zawarcia ugody, w przypadku jakichkolwiek problemów z jej realizacją.
