Umowa Agile – jak skonstruować dobrą umowę Agile?

W branży IT występuje wiele różnych metodyk projektowych. Każda z nich ma swoje zalety, ale także słabe strony i wymaga odpowiedniego podejścia przy tworzeniu umowy. Jednym z bardziej popularnych podejść są tzw. metodyki zwinne, czyli agile. O czym pamiętać przy konstruowaniu kontraktu na projekt IT z jej wykorzystaniem?

Czym charakteryzują się metodyki agile?

Programowanie zwinne to metody zarządzania procesem tworzenia software’u w modelu iteracyjno-przyrostowym. Wyróżniają się dużą dynamiką realizacji poszczególnych etapów prac, tzw. sprintów, a także większą możliwością adaptacji do zmieniających się oczekiwań zarówno samego inwestora, jak i rynku niż klasyczne, sformalizowane metody tworzenia oprogramowania w modelu kaskadowym (ang. waterfall).

Dokumentacja schodzi w tym przypadku na dalszy plan, większe znaczenie ma bieżąca komunikacja między członkami zespołu. Choć prace są realizowane w oparciu o ogólny product backlog, jest on dzielony na wiele małych etapów. Uważa się, że prawidłowo stosowane metodyki agile mogą zwiększyć efektywność działań, a ostatecznie podnieść wartość rezultatu projektu.
Czy tak dużą dynamikę zmian można odzwierciedlić w umowie? Jak najbardziej! Co więcej trzeba to zrobić, ponieważ przyjęcie metody agile nie oznacza, że wykonawca działa w nieograniczonych terminach czy w nielimitowanym budżecie albo też, że zamawiającemu jest wszystko jedno, jaki produkt otrzyma.

Więcej na temat tych metodyk projektowych przeczytasz w artykule: Metodyki projektowe – Agile vs. Waterfall

Zamów pakiet umów IT!

Co ze specyfikacją projektu w metodyce agile?

Aby uniknąć niepotrzebnych przestojów w realizacji prac, należy zadbać o właściwe oznaczenie przedmiotu zamówienia. Taka specyfikacja pojawia się również w metodyce agile, choć będzie ona wyglądała inaczej niż w tradycyjnym modelu kaskadowym. Zamiast obszernego załącznika, który wylicza wszystkie technologie, biblioteki czy opisuje architekturę oprogramowania, specyfikacja zwinna uwzględnia przede wszystkim główne zręby projektu.

Najłatwiej porównać to do przykładu, w którym zamawiający określa, jaki rezultat chce zobaczyć i które funkcjonalności są dla niego najważniejsze, ale to wykonawca poszukuje właściwych dróg do osiągnięcia tego celu.

Jak określić skład zespołu w umowie na bazie agile?

Pracownicy po stronie software developera mogą się zmieniać, to oczywiste. Jak w takim razie zapewnić płynność realizacji umowy? Dobrym rozwiązaniem jest wskazanie reprezentantów zlecającego (tzw. Product Owner) oraz wykonawcy. Po stronie software house’u wystarczy wskazać konkretne „role”, które przedsiębiorca powinien obsadzić, np. jeden grafik, trzech programistów i dwóch testerów. Dzięki temu zmiany personalne nie hamują dynamiki prac.

Oznaczenie sprintów i terminowość realizacji prac

Sprint w programowaniu można porównać do niewielkiego, zamkniętego etapu prac. Cały cykl projektowy dzieli się na wiele sprintów trwających zwykle nie dłużej niż dwa tygodnie. Po tym czasie następuje odbiór prac, które albo są przyjmowane albo zgłaszane są do nich poprawki. Sprinty są wykorzystywane do testowania kolejnych etapów i usuwania przeszkód, które pojawiają się po drodze.

Rozłożenie czasowe sprintów warto określić już na samym początku współpracy, przy czym strony mogą porozumieć się, które etapy można przesunąć lub zamienić ze sobą miejscami. Aby zapanować nad terminowością prac, cały cykl zadań można podzielić na te o kluczowym znaczeniu (ang. milestones) oraz pozostałe, których termin realizacji nie wpływa w aż tak dużym stopniu na rezultat działań programistycznych.

Kiedy sprint jest wykonany poprawnie, czyli Definition of Done

Czy istnieje uniwersalna definicja poprawnego wykonania danego etapu prac? Niestety nie i w każdej umowie oczekiwania zamawiającego będą kształtowały się inaczej. Aby uniknąć zbędnej eskalacji roszczeń, umowa wdrożeniowa IT powinna przewidywać definicję prawidłowego wykonania dla konkretnego zadania (ang. Definition of Done). Wbrew pozorom DoD jest istotny nie tylko dla wykonawcy, ale również zamawiającego.

Z jednej strony software developer wie, co na danym etapie powinno być zrealizowane, z drugiej zamawiający jasno precyzuje swoje oczekiwania, więc łatwo ocenić, kiedy żądanie wykonania poprawek czy zapłaty kary umownej jest uzasadnione.

Przeniesienie praw autorskich i licencji w umowie IT. Kiedy o to zadbać?

Tworzenie oprogramowania bardzo często wiąże się z powstaniem utworu w rozumieniu przepisów ustawy o prawie autorskim i prawach pokrewnych. Taki utwór z chwilą powstania będzie należał do wykonawcy, dlatego trzeba zadbać o jego właściwe przeniesienie na zamawiającego. W przeciwnym razie zamawiający nie będzie mógł korzystać z niego zgodnie z prawem.

Udostępnienie możliwości korzystania z utworu może polegać albo na udzieleniu licencji albo przeniesieniu praw autorskich majątkowych, przy czym dla umów wykorzystujących metodykę agile z reguły właściwe będzie przeniesienie praw do utworu, który przecież został dopasowany do indywidualnych oczekiwań zamawiającego. Taką umowę należy zawrzeć w formie pisemnej (alternatywnie w równoważnej z nią formie elektronicznej) pod rygorem nieważności. Do jej kluczowych elementów zalicza się przede wszystkim:

• dokładne określenie utworu, który jest przenoszony;
• enumeratywne wyliczenie pól eksploatacji, czyli określenie w jaki sposób dany utwór może zostać wykorzystany;
• wynagrodzenie za przeniesienie utworu lub wskazanie, że zostało ono uwzględnione w całkowitym wynagrodzeniu wykonawcy z tytułu developmentu;
• zezwolenie na dokonywanie zmian w utworze.

A co z momentem przeniesienia praw autorskich? Dobrze jest powiązać go z wypłatą wynagrodzenia i wskazać, że do przejścia praw autorskich dochodzi z chwilą uregulowania należności.

Jak określić wynagrodzenie w umowie IT z metodyką agile?

Wynagrodzenie za prace programistyczne realizowane w modelu agile można uregulować na kilka sposobów. Jeśli chodzi o częstotliwość płatności, modelem korzystnym dla zamawiającego jest rozliczanie się po wykonaniu wszystkich prac, dla wykonawcy zaś, po oddaniu każdego sprintu.

W umowach typu agile raczej rzadko stosuje się rozliczenie typu fixed price. Polega ono na przyjęciu z góry, jaką kwotę wynagrodzenia otrzyma wykonawca. Lepszym rozwiązaniem, w większym stopniu oddającym dynamikę jest time&material, jest naliczanie wynagrodzenia w zależności od liczby roboczogodzin poświęconych na realizację projektu. Aby zabezpieczyć się przed niekontrolowanym wzrostem wydatków i przekroczeniem budżetu, zamawiający powinien zadba o wprowadzenie do umowy limitu (ang. cap), powyżej którego wynagrodzenie nie będzie już naliczane.

Jak zabezpieczyć prawidłowe wykonanie umowy IT?

W praktyce stosuje się wiele różnych mechanizmów pozwalających na zabezpieczenie prawidłowego wykonania umowy IT. Może to być wykonanie zastępcze, zadatek, zatrzymanie wypłaty części wynagrodzenia, możliwość odstąpienia od umowy, potrącenie czy kara umowna.

Sztandarowym przykładem zabezpieczenia jest najczęściej kara umowna, czyli zobowiązanie drugiej strony umowy do zapłaty świadczenia pieniężnego w razie niewykonania lub nienależytego wykonania zobowiązania o charakterze niepieniężnym. Strony powinny zadbać, aby zastrzec jednocześnie możliwość dochodzenia odszkodowania przenoszącego wysokość zastrzeżonej kary umownej. Kiedy takiej kary można żądać? Z punktu widzenia wykonawcy może to być sytuacja, kiedy zamawiający odmawia przekazania informacji o kluczowym znaczeniu dla projektu. Dla zamawiającego zaś opóźnienie z realizacją sprintu.

Dlaczego poufność i zakaz konkurencji są ważne?

W umowach IT bazujących na modelu agile często ujawnianych jest więcej informacji o istotnym znaczeniu przedsiębiorstwa niż w kaskadowym tworzeniu oprogramowania. Wynika to z dynamiki procesu tworzenia software’u i tego, że na początku może być trudno określić, które informacje będą miały znaczenie dla programistów.

Z tego względu kontrakt powinien przewidywać zobowiązanie pracowników wykonawcy do zachowania w tajemnicy wszystkich informacji, które zdobyli oni podczas wykonywania obowiązków. Na podobnej zasadzie działa zakaz konkurencji, który zapobiega „sprzedaży” nowo nabytej wiedzy dla innego podmiotu. Zarówno w jednym, jak i w drugim przypadku trzeba zadbać o maksymalną precyzję zapisów, ponieważ nie zawsze wystarczające będzie powołanie się na zasadę swobody umów charakterystyczną dla relacji B2B.

Jesteś przedsiębiorcą, który planuje zamówić stworzenie oprogramowania, ale masz wątpliwości, jak zabezpieczyć swoje interesy? A może działasz jako software house, który oferuje firmom profesjonalne usługi tworzenia aplikacji? Pomożemy Ci zbudować umowę, która należycie ochroni Twoją pozycję w biznesowej relacji.

Potrzebujesz wsparcia prawnika IT? Napisz do mnie!