Odsłona trzecia – KEY LEGAL ISSUES, na przykładzie metodyki SCRUM
Najważniejsze zagadnienia prawne i strukturalne rozważane przy okazji umów towarzyszących projektom Agile są zbliżone do tych analizowanych w związku z umowami w modelach tradycyjnych. Zasadnicza różnica przejawia się w treści, którą się nadaje tradycyjnym konstrukcjom oraz myśleniu, które powinno towarzyszyć tworzeniu i wdrażaniu w życie takich konstrukcji. Myśleniu w duchu elastyczności, zwinności i współpracy.
Najłatwiej zrozumieć ideę Agile jeśli porówna się ją z tradycyjną, waterfallową metodą prowadzenia projektu. Poniżej rysunek obrazujący obydwa procesy, w obszarze „software development”.
Model kaskadowy zakłada wytwarzanie całego oprogramowania w ramach odrębnych faz projektowych, w porządku jedna po drugiej, każda faza to kolejny schodek. Brak pożądanych rezultatów na danym etapie oznacza konieczność cofnięcia się do poprzedniego/ch pełnego/ch etapu/ów, co jest niezwykle kosztowne i czasochłonne. W modelu Agile proces wytwarzania oprogramowania rozdzielony jest na stosunkowo krótkie (2-4 tygodni) interwały kończące się dostarczeniem określonych elementów projektu stanowiących zamkniętą całość, zaprojektowanych, przetestowanych i wdrożonych.
Poniżej najważniejsze elementy strukturalne umowy w projekcie na bazie koła.
Przedmiot umowy, czy raczej zakres umowy
W przeciwieństwie do umów waterfallowych umowy w projektach Agile nie opisują dokładnie zakresu projektu, choć oczywiście stosowane są różne wariacje w zakresie stopnia szczegółowości, od bardziej ogólnego do bardziej szczegółowego (target-cost contracts opisują zakres projektu oraz detale na początku projektu tak szczegółowo jak to tylko jest możliwe, z mechanizmem pozwalającym na zmianę, na drugim końcu znajdują się umowy progresywne, w których nie opisuje się zakresu całego projektu, a wyłączenie zakres pierwszej iteracji z tendencją do rozszerzeń). Stopień ten należy dostosować do rodzaju projektu i poziomu elastyczności partnerów biznesowych. Niezależnie od stopnia szczegółowości opis zakresu, wizji i motywacji biznesowych należy w kontrakcie umieścić, najlepiej nie metodą copy-paste, ale metodą kreatywną, ze zrozumieniem tak wizji projektu i jak i wszelkich aktywności z nim związanych.
Role w projekcie
W projekcie można wyróżnić trzy role o fundamentalnym znaczeniu dla realizacji projektu: Product Owner, Scrum Master i Development Team, których opisanie wymaga sporej zwinności. Product Owner reprezentuje klienta i jego wizję oraz wymagania wobec projektu w relacji z Development Team. Umowa powinna zaadresować jego rolę w projekcie poprzez jego odpowiednie umocowanie, kompetencje, zaangażowanie zarówno na poziomie czasowym jak i merytorycznym oraz stabilny udział w projekcie. Development Team odpowiada za operacyjne prowadzenie części deweloperskiej projektu. Skład i pochodzenie zespołu determinują strony zbliżając się bardziej (zespół o kombinowanym składzie osobowym zarówno ze strony klienta jak i dostawcy) lub mniej (zespół w składzie osobowym wyłącznie ze strony dostawcy) do modelu Agile w czystej postaci. Postać i opis Scrum Master stanowią prawdopodobnie największe wyzwanie operacyjne dla twórców kontraktu. Jego rola podobna jest to roli coach’a albo mentora wspierającego Poduct Ownera i Development Team w trakcie ich współpracy w projekcie scrumowym, może to być osoba z zespołu dostawcy, może być osoba z zewnątrz niezwiązana z żadną ze stron. Z uwagi na kluczowe znaczenie opis jego praw i obowiązków, kompetencji i umiejętności, a także zakres udziału w projekcie wymaga sporej kreatywności i otwartości.
Product Backlog
To trochę taki odpowiednik SOR (Statment of Requirments), skomponowana według priorytetów lista prac do wykonania w trakcie realizacji projektu, nazywanych „user stories”. Może stanowić załącznik do umowy, a może pojawić się później w toku współpracy. Podobnie jak pozostałe elementy projektu Agile powinna być ujęta w sposób zwinny, pozwalając na zmiany priorytetów w obrębie listy, usuwanie jednych i dodawanie innych w trakcie współpracy w ramach poszczególnych Sprintów. Tym samym lista na starcie projektu może się różnic od tej na koniec. Jeśli umowa nie określa samego Product Backlog powinna definiować metody i ścieżki jego opracowania w toku projektu, przewidywany poziom zaangażowania w poszczególne elementy i ustalania priorytetów.
Sprinty
Zasadą jest prowadzenie projektu w krótkich interwałach, zwykle mocno osadzonych w czasie. Strony posiadają jednak swobodę w zakresie ustalania długości Sprintów w ramach określonych przez metodykę, rodzaju spotkań, sposobu prowadzenia spotkań, oraz ustalenia priorytetów w ich ramach. Częstotliwość i forma powinna być dostosowana do specyfiki projektu, motywacji stron i stopnia wytrzymałości na nieustanną komunikację.
Definition of Done
Prawdziwa dusza procesu, najlepiej gdyby została uzgodniona i opisana już na etapie negocjacji umowy i włączona do załącznika, choć praktyki w tym zakresie są różne. Sprawdzanie teorii i praktyki powinno się odbywać na etapie każdego Sprintu, najchętniej w obrębie części Sprint review. Niebagatelne znaczenie może mieć również dołożenie odpowiedniej klauzuli rozstrzygającej spory w tym zakresie, bowiem pomimo woli współpracy stron w tym miejscu mogą pojawiać się największe rozbieżności.
Autorskie prawa majątkowe
Niewątpliwie rodzaj problemów w tym obszarze jest podobny w umowach realizowanych tak w modelu Agile jak i w modelu waterfallowym różnice wiążą się jedynie z dostawami realizowanymi w zamkniętych paczkach poszczególnych iteracji w regularnych odstępach czasu, co momentami może się zbliżać do realesów w modelu kaskadowym. W umowach należy zaadresować zagadnienie ewentualnego przeniesienia praw na klienta lub udzielenia licencji do przekazywanych elementów z pozostawieniem sobie możliwości w ich ingerowanie bez naruszania praw. Zagadnienia praw do kodu nadają sprawie rumieńców.
Wynagrodzenie
Trudny punkt do negocjacji i uzgodnień, bo musi pogodzić sprzeczne interesy klienta i dostawcy. Największy obszar niepewności dla klientów, którzy godząc się na prowadzenie projektu w krótkich interwałach obawiając się eskalacji kosztów i utraty cash-flow na projekcie przy dużej niepewności co do jego ostatecznego rezultatu. Rozważać można różne kombinacje, czystego T&M albo z capp, fixed-price per iteracja, per unit-work (albo jakiś pakiet UoW), fixed-price per scope (FPPS) albo ich hybrydy. Wiele zależy od entuzjazmu i elastyczności stron oraz ryzyk projektowych. Prawdziwe wyzwanie dla biznesu i prawników.
Odpowiedzialność
Zakres i rodzaj negocjacji w tym obszarze jest bardzo zbliżony do obszarów dyskutowanych przy okazji projektów waterfallowych. Najczęściej dyskutowanymi kwestiami są zakres tej odpowiedzialności oraz jej limity. Kwestią wymagającą zaadresowania będą niewątpliwie ewentualne opóźnienia w projekcie. Kombinowany model Development Team (przedstawiciele dostawcy i klienta) mogą uczynić negocjacje tego punktu jeszcze bardziej intrygującą.
Zakończenie projektu
Poza wynagrodzeniem i odpowiedzialnością jest to punkt wywołujący największe emocje. Klient najczęściej jest zainteresowany zapewnieniem sobie możliwości wyjścia z umowy po każdej interacji będąc jednocześnie znacznie mniej elastycznym co do analogicznych uprawnień po stronie dostawcy. Niewątpliwie umowa powinna też adresować konsekwencje wcześniejszego jej zakończenia, szczególnie w obszarze wzajemnych rozliczeń, praw autorskich i praw do kodu.
Osoby zainteresowane rozszerzeniem swojej wiedzy o zwinnych umowach zapraszam na kwietniowe szkolenie. 27 kwietnia 2017 r. Warszawa. Więcej informacji pod linkiem http://www.edufuturo.pl/zarzadzanie-projektami/291-agile-contract-s-design-zwinne-projektowanie-warunkow-prawnych-dla-wdrozen-w-modelu-agile.html