ZWINNA UMOWA W IT.

JAK PISAĆ I TWORZYĆ TAKIE UMOWY?

Przełożenie pryncypiów Agile na język umów wymaga nie tylko innowacyjnego myślenia, ale i warsztatu dostosowanego do specyfiki tych projektów. Zwinna umowa wymaga dużej elastyczności.

Najważniejsze zagadnienia prawne i strukturalne 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.

——————————————————————————————————————————————————-

Z cyklu NOWOCZESNE KONTRAKTY posted by Renata W.Lewicka

 

NAJWAŻNIEJSZE ZAGADNIENIA PRAWNE NA PRZYKŁADZIE METODYKI SCRUM

Najłatwiej zrozumieć ideę Agile jeśli porówna się ją z tradycyjną, waterfallową metodą prowadzenia projektu

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.

ZWINNA UMOWA – PRZEDMIOT, A RACZEJ ZAKRES

W przeciwieństwie do umowy waterfallowej zwinna umowa w projektach Agile nie opisuje dokładnie zakresu projektu.

Oczywiście stosowane są różne wariacje w zakresie stopnia szczegółowości, od bardziej ogólnego do bardziej szczegółowego np.:

• 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 jednak od stopnia szczegółowości zanim opis zakresu, wizji i motywacji biznesowych powstanie trzeba go najpierw zrozumieć.

Następnie zaś, najlepiej metodą kreatywną, a nie copy&paste umieścić w kontrakcie.

ZWINNA UMOWA – ROLE W PROJEKCIE

W projekcie można wyróżnić trzy role o fundamentalnym znaczeniu:

• 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 zwinna 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 iteracji 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.