Czy prawo „nadąża” za IT?

Często spotykaną przeze mnie tezą jest ta, że prawo zupełnie nie nadąża za IT. Cóż, myślę, że w pewnym sensie całe szczęście, bo gdyby było inaczej to IT naprawdę wolno by się rozwijało. Najrzadziej jest bowiem tak, że to prawo tworzy nową rzeczywistość. Najczęściej prawo co najwyżej oddziałuje na rzeczywistość istniejącą, albo też w mniejszym lub większym stopniu stara się ją uchwycić, opisać i ustanowić pewne kanony, które uznaje się za dozwolone albo niedozwolone.

Nie wiem czy zastanawiałeś się kiedyś, czy prawo przewiduje jakiekolwiek rozwiązania dla zwinnego zarządzania projektami, takich choćby jak scrum. Jeśli tak to ciekaw jestem jakie były Twoje wnioski. Jeśli tego nie robiłeś – spieszę donieść, że w zasadzie zupełnie trafnie można postawić tezę, że te systemy prawa, które wprowadzały swobodę umów, zwinną metodykę pracy nad projektami przewidywały nawet wcześniej niż ona faktycznie powstała.

Scrum i agile, a swoboda umów

Brzmi to może dość enigmatycznie, ale już wyjaśniam, że chodzi po prostu o to, że jeśli prawo danego państwa przewidywało, że strony mogą umówić się w zasadzie dowolnie dopóki nie przekracza to określonych prawem granic to taki system prawa po prostu dopuszczał ułożenie umów w sposób, który jest adekwatny do dzisiejszego agile, czy scrum. W Polsce przepisem, który na to pozwala jest art. 3531 Kodeksu cywilnego, który obowiązuje od 1 października 1990 r. i stanowi, że strony zawierające umowę mogą ułożyć stosunek prawny według swego uznania, byleby jego treść lub cel nie sprzeciwiały się właściwości (naturze) stosunku, ustawie ani zasadom współżycia społecznego.

Wiemy już w takim razie, że kwestia stosowania zwinnych umów to w gruncie rzeczy decyzja stron i przejaw ich woli. Wiemy też, że nie ma w polskich ustawodawstwie skodyfikowanych umów scrum’owych, czy agile’owych. Nie oznacza to jednak, że takie umowy nie mają żadnych ugruntowanych cech.

Jak orzecznictwo widzi scrum?

Warto jednak zaznaczyć, że szczególnie scrum doczekał się już pewnych orzeczeń, które zapadły na jego kanwie. Choć wypowiedzi dotyczące tego na czym polega praca w scrume, które zostały zawarte w tych orzeczeniach nie pochodzą od organów, czy sądów, a od stron postępowań to warto zaznaczyć, że nie były one w żadnej mierze kwestionowane. Przykładem orzeczenia, które dość szczegółowo przedstawia na czym, w ujęciu prawnym, polega praca w scrum jest choćby pismo z dnia 13 grudnia 2018 r. Dyrektor Krajowej Informacji Skarbowej, 0111-KDIB1-3.4010.471.2018.2.BM, czy też wyrok Krajowej Izby Odwoławczej z dnia 8 sierpnia 2017 r., KIO 1471/17, w których zostało wyjaśnione to w sposób następujący:

Wytwarzanie oprogramowania metodyką zwinną oznacza, iż prace nad nowym rozwiązaniem lub ulepszeniem rozwiązania istniejącego oparte są o podejście iteracyjne, tj. przyrostowe mające na celu zwiększenia przewidywalności i lepszej kontroli ryzyka.

W praktyce metodyka pracy polega na podzieleniu prac nad nowym rozwiązaniem na etapy (tzw. sprinty). Efektem każdego etapu prac jest stworzenie tzw. przyrostu w postaci funkcjonującego elementu produktu (modułu/funkcji oprogramowania).

Każdy etap obejmuje planowanie Sprintu (określenie celu – definicji wykonanej pracy – oraz zaplanowanie drogi jego realizacji), wykonanie założonego celu oraz przegląd efektów oraz przebiegu prac na danym etapie.

Kluczowe elementy scrum

Kluczowym elementem w tej metodyce pracy są zasady:

1) przejrzystości (jednoznaczny opis planowanych efektów i elementów procesu, zrozumiały zarówno dla klienta definiującego potrzeby, jak i dla zespołu projektowego wykonawcy),

2) inspekcji (stała kontrola procesu w celu jak najszybszego zidentyfikowania nieprawidłowości),

3) adaptacji (jak najszybsza korekta wykrytych nieprawidłowości w celu ograniczenia dalszych odstępstw od założonych efektów).

Iteracyjność scrum w świetle prawa

Zwinna metodyka wytwarzania oprogramowania Scrum różni się od tradycyjnych metod wytwarzania oprogramowania, w których prace nie są podzielone na przyrostowe etapy, lecz obejmują zdefiniowanie całości wymagań co do produktu końcowego na wstępie prac, następnie przygotowanie całości produktu według tych odgórnie zdefiniowanych wymagań oraz jego testowanie i walidację przez klienta. Wskutek tego, w przypadku projektów tradycyjnych, rozbieżności w stosunku do rzeczywistych potrzeb klienta (zarówno uświadomionych i zakomunikowanych wykonawcy, jak i nie uświadomionych przez niego) mogą narastać w toku procesu i powodować konieczność dużo większych prac adaptacyjnych na skończonym produkcie na koniec całego procesu, co nie ma miejsca w sytuacji, gdy proces adaptacyjny realizowany jest przez cały czas prac nad produktem w kolejnych etapach.

W metodyce Scrum wykonawca dostarcza produkt iteracyjnie i przyrostowo, zwiększając szanse na wczesne uzyskanie informacji zwrotnej od klienta. Przyrostowe dostarczanie “ukończonego” produktu zapewnia nieprzerwaną dostępność jego działającej, potencjalnie użytecznej wersji. Realizacja ww. zasad metodyki Scrum wymaga jednak innej organizacji pracy, wyrażającej się przede wszystkim innym podziałem ról w zespole projektowym (“Zespół Projektowy/Scurmowy”) w porównaniu do tradycyjnych metod wytwarzania oprogramowania.

Znaczenie zespołu w scrum’ie, a prawidłowe skonstruowanie umowy

W skład Zespołu Projektowego (Scrumowego) wchodzą:

1) Właściciel Produktu (z ang. Product Owner),

2) Zespół Deweloperski (z ang. Development Team), oraz

3) Scrum Master.

Model zespołu proponowany w Scrumie został zaprojektowany tak, aby zoptymalizować elastyczność, kreatywność i produktywność. Zespół Scrumowy realizuje prace całkowicie we własnym zakresie, opierając się wyłącznie na narzędziach programistycznych (środowiska programowania, biblioteki, środowiska baz danych), bez wykorzystania gotowych rozwiązań. Innymi słowy, proces ten obejmuje zdefiniowanie wymogów biznesowych, zaprojektowanie modułów (funkcjonalności) rozwiązania, programowanie, testowanie rozwiązania i wprowadzanie poprawek.

Czy prawo pozwala być zgodnym z założeniami scrum?

Trzeba powiedzieć, że umowy oparte o scrum mogą być w pełni zgodne z wszystkimi cechami, które scrum powinien posiadać zgodnie z jego założeniami. Zawdzięczać to możemy przede wszystkim temu, że w naszym systemie prawa istnieje zasada swobody umów. Niemniej jednak, niezależnie od tytułu, który zostanie takiej umowie nadany nie można zapominać o tym, że w świetle prawa będzie to jednak tak zwana umowa nienazwana, a to jakie przepisy będą do niej stosowane zależy w gruncie rzeczy od tego jak bardzo precyzyjnie strony oddadzą w niej swój zamysł i zasady sctrum’a.