Zwinne metodyki realizacji projektów IT są co raz popularniejsze. Sposób w jaki realizowane są projekty agile znacząco odbiega od realiów klasycznej umowy wdrożeniowej. O ile klasyczna umowa wdrożeniowa zakłada, że z góry znamy szczegółowy opis produktu i wiemy co powstanie, a załącznikiem do niej najczęściej jest rozbudowana specyfikacja techniczna i wszystkie odstępstwa od niej są „utrudnione”. O tyle przy wdrożeniach Agile, w tym Scrum, na dzień podpisywania umowy znamy tylko wizję produktu, wiemy co mniej więcej chcemy wyprodukować, ale zakładamy, że ta wizja może się jeszcze zmienić i z pewnością będzie dostosowywana do potrzeb użytkowników produktu.
Wdrożenia oparte o Agile wydają się być idealne dla projektów „startupowych”, produktów, które od MVP do wersji „produkcyjnej” zmienią się niezliczoną ilość razy – pod wpływem działań ich użytkowników. Ta zmienność sprawia, że umowa agile musi być odpowiednio zaprojektowana i przygotowana.
Czy korzystać z prawnika przy opracowaniu umowy Agile?
Prawnicy mają problem z Agile – nie zawsze je rozumieją. Jesteśmy uczeni aby w umowie zabezpieczyć klienta na wszystkie możliwe scenariusze i jak najdokładniej opisać przedmiot umowy. Umowy Agile są czymś co wywraca prawnicze myślenie do góry nogami. Przygotowując umowę Agile potrzeba nie tylko „świadomego” prawnika, ale daleko idącej współpracy pomiędzy prawnikiem a klientem. Metodyki Agile są zwinnie dostosowywane do potrzeb poszczególnych softwarehousów czy klientów – np. dosyć powszechne są umowy typu wagile (z elementami waterfall, gdzie rezultat jest znany, natomiast realizacja przebiega zgodnie z agile) lub umowy ramowe agile – nie dotyczące konkretnego projektu, a długo terminowej współpracy pomiędzy softwerhousem czy agencją interaktywną a klientem. Umowa wdrożeniowa Agile powinna mieć jeden główny cel – nie doprowadzić do sporu między stronami i rozwiewać wszelkie wątpliwości gdy tylko pojawi się sytuacja konfliktowa. Dlatego też powinna stanowić odzwierciedlenie negocjacji i intencji stron. Współpraca z odpowiednim prawnikiem będzie przy przygotowaniu takiej umowy bezcenna.
Zalety umów wdrożeniowych Agile
Odpowiednia umowa wdrożeniowa agile (w tym wagile) nie tylko pozwala uchronić strony przed długotrwałym i bardzo kosztownym dla wszystkich sporem sądowym. Taka umowa pozwala na sprawne wycofanie się z projektu, bez szkody dla którejkolwiek ze stron. Wyobraźmy sobie sytuację, w której softwarehouse stwierdza, że nie dogaduje się z klientem. Współpraca się po prostu nie układa, projekt stoi w miejscu. Przy standardowej umowie wdrożeniowej wyjście z projektu najpewniej wiązałoby się z brakiem wynagrodzenia dla wykonawcy i brakiem efektu dla zlecającego. Obie strony przegrywają. Natomiast przy umowach agile, możliwe jest takie zaprojektowanie exitu aby softwarehous otrzymał należną część wynagrodzenia, a klient mógł szybko przenieść projekt gdzie indziej.
Co powinna zawierać umowa na wdrożenie w metodyce Agile (na przykładzie Scrum):
Wizję produktu
W umowie powinien znaleźć się opis tego co chcemy zrobić, dlaczego to chcemy zrobić i po krótce wskazanie jak to chcemy zrobić. Niech umowa określa główne cele i założenia produktu.
Definicje
Aby uniknąć wątpliwości z błędnym zrozumieniem pojęć metodyk Agile – powinny zostać one określone w umowie. Przygotowanie definicji pozwala wszystkim stronom zorientować się, że chodzi o to samo.
Role w projekcie
Kto będzie Product Ownerem, do czego jest uprawniony? Czy i jak można go zmienić? A jak ze Scrum Masterem? To wszystko powinno się znaleźć w umowie. Jeśli jest się zamawiającym – warto zapewnić sobie prawo do oceny kompetencji zespołu deweloperskiego.
Product Backlog i user stories
Czy główne funkcje produktu (np. w postaci user stories) znane są na dzień zawarcia umowy? Jeśli tak warto zrobić z nich załącznik. Na jakich zasadach może być modyfikowany backlog? Kiedy Product Owner może zmieniać priorytety poszczególnych user stories? A może umowa zawierana jest na konkretny pakiet user stories?
Sprint
Długość sprintów, sposób przeprowadzania spotkań, sposób włączania user stories i zadań do sprintów, a także ich rolowanie czy zmiana priorytetów poszczególnych zadań – to takie umowne „must have”.
Definition of Done
No właśnie – kiedy dany element projektu jest skończony? Co jeśli strony umowy nie są zgodne, czy np. dana user story jest realizowana prawidłowo? Warto wprowadzić checklistę i mechanizmy weryfikacyjne.
Prawa autorskie
W przypadku wdrożeń Agile ze względu na duże zaangażowanie zamawiającego kwestia praw autorskich może się trochę skomplikować. Dlatego też szczególnie ważne jest określenie w umowie jak będzie wyglądać kwestia własności intelektualnej. Kto ma prawa autorskie? Kiedy udzielane są licencje, a kiedy następuje przeniesienie praw?
Rozliczenia
Jak dany projekt będzie rozliczany? Czy nastawiacie się na rozliczenie godzinowe? A może fixed price? Jeśli fixed price to ustalcie czy ma być to za cały projekt, ilość sprintów, a może ilość user stories? Odpowiednio skonstruowany mechanizm rozliczeń jest kluczowym elementem umowy – to właśnie rozliczenia budzą zawsze najwięcej wątpliwości.
Odpowiedzialność stron
Kto i na jakich zasadach odpowiada za prawidłową realizację umowy? Kto odpowiada za opóźnienia w realizacji poszczególnych sprintów? Czy przewidywane są jakieś gwarancje po zakończeniu projektu?
Zakończenie projektu
Umowa powinna określać kiedy projekt zostanie zrealizowany. Jest to szczególnie istotne jeśli przyjmujecie, że Product Backlog i lista user stories zmieniają się dynamicznie w czasie realizacji projektu.
Wyjście z projektu
W umowie powinna istnieć odpowiednia procedura wyjścia (i rozliczeń) na wypadek gdyby z jakiegoś powodu dalsze prace nad produktem zostały przerwane. Oczywiście – należy tu rozróżnić różne przypadki. To jedna z najistotniejszych klauzul. W połączeniu z odpowiednio zaprojektowanym mechanizmem rozliczeń pozwala stronom uniknąć niepotrzebnych sporów. Dodatkowo „zwinny exit” pozwala zleceniodawcy na szybkie przeniesienie projektu do innego wykonawcy.
SLA
Ponieważ wdrożenie Agile, w tym testowanie i wykrywanie błędów przebiegają inaczej niż przy klasycznej umowie wdrożeniowej – konieczne będzie odpowiednio zmodyfikowane SLA, dostosowane do realiów pracy w sprintach.
Standardy programowania i dokumentowania
Co prawda Agile stawia działanie przed dokumentowanie, to czasem strony (zwłaszcza zamawiający) mogą chcieć określić jakieś standardy przygotowania i dokumentowania kodu. Od wyboru języka programowania i platformy (np. PHP 7.0, Laravel) po sposób komentowania kodu czy przygotowania dokumentacji.
