Jak napisać umowę wdrożeniową AGILE

Umowa wdrożeniowa to konstrukcja prawna, która może zawierać w sobie elementy innych typów umów lub nawet łączyć ich kilka na raz, stąd też mając na uwadze różnorodność projektów wdrożeniowych realizowanych w IT, nie daje się ich łatwo ująć w jeden ogólny schemat. Dzisiaj opowiemy Wam o umowie wdrożeniowej AGILE.

Artykuł ten stanowi fragment naszego e-booka. Możesz go pobrać bezpłatnie klikając baner poniżej. 

Sposób świadczenia usług w ramach metodyki Agile jest trudny do opisania w kilku zdaniach, szczególnie mając na uwadze zróżnicowanie metod zwinnych (Scrum, Kanban, SAFe, XP Programming, Lean).

Przeczytaj także:

  1. Postanowienia występujące w każdej umowie IT
  2. Jak napisać umowę wdrożeniową WATERFALL
  3. Jak napisać umowę wdrożeniową AGILE

Praca w tych modelach zakłada pracę w krótkich cyklach twórczych (iteracjach). Efektem każdej zakończonej iteracji jest działający element oprogramowania, stąd też powstaje ono w drodze drobnych przyrostów uwzględniających wszel-kie wnioski wynikające z przebiegu prac oraz bezpośredniego kontaktu z klientem.

W umowie agile znany jest (niekiedy przybliżony) budżet całkowity oraz termin ukoń-czenia prac, nie jest zaś z góry określony finalny produkt. Działa to na zasadzie umowy ramowej, gdzie zamawiający składa zamówienia na konkretne rozwiązanie/projekt nie musząc każdorazowo zawierać odrębnej umowy.

Opis procesu wytwarzania oprogramowania w iteracjach

Istotne dla pracy w systemach Agile jest określenie:

  • katalogu czynności, które powinny być wykonane w każdej iteracji,

  • wskazanie czasu trwania każdej iteracji,

  • harmonogram projektu, a więc termin końcowy oraz

  • ewentualnie punkty kontrolne/kamienie milowe projektu.

Warunki zatwierdzenia iteracji

– co do zasady, w Agile nie określa się wymogów stawianych poszczególnym iteracjom, gdyż każdora- zowo robi to właściwy zespół dla każdego produktu w każdym cyklu (jest to jedna z ważniejszych cech wpływających na elastyczność tej metody). Sugerowanym dla stron rozwiązaniem jest jednak określenie ogólnych, ramowych warunków uznania iteracji za zamkniętą.

Elastyczny mechanizm rozliczeń

– w żadnym wypadku elastyczność prac nie oznacza, iż końcowa wycena projektu jest nieokreślona. Stąd też należy wyraźnie określić kryteria wyceny, uwzględniając przy tym zarówno charakterystykę Agile, jak i założenia konkretnego projektu. Trzy najczęściej stosowane warianty to:

  • stawka za roboczogodzinę z uwzględnieniem zarówno różnic pomiędzy poszczególnymi funkcjami w zespole (analityk, developer, tester), a w obrębie funkcji – z uwzględnieniem posiadanego doświadczenia,

  • z góry określona stawka za całość projektu,

  • ustalenie stawki za gotowy do wdrożenia rezultat kilku iteracji.

Mechanizmy służące do zmiany umowy w toku pracy nad projektem

– istotną cechą elastyczności umów Agile jest wprowadzenie do nich całej gamy mechanizmów służących stronom w dokonywaniu zmian w ramach jasno określonej procedury. W toku prac i bieżącej anali- zy efektów, okazać się może iż podstawowe założenia okazały się wyolbrzymione, niedoszacowane lub całkowicie błędne (np. termin, kosztorys, ogólne założenia dotyczące produktu końcowego). Brak tego typu rozwiązań znacząco utrudniałby skuteczne działanie w ramach omawianej umowy.

Określenie ról kluczowych wykonawców projektu i ich kompetencji

– jednym z istotnych czynników pracy w Agile jest dostosowanie zespo- łu pod kątem konkretnego projektu tak, aby był on samowystarczalny w jego realizacji. Oznacza to, że na etapie tworzenia umowy wskaza- ne zostaną wymogi względem posiadania odpowiednich kompetencji członków zespołu deweloperskiego. Ponadto, aby spełnić zespo- łowi (bądź też poszczególnym jego członkom) cechę samowystar- czalności, niekiedy może być wymagane udzielenie odpowiednich pełnomocnictw.

Zasady współdziałania

– fundamentem prawidłowego przebiegu prac w Agile jest, oprócz samego wskazania obowiązku współdziała- nia stron, określenie ich organizacji. Warto uzgodnić w pierwszej kolejności częstotliwość i czas spotkań zespołu deweloperskiego z przedstawicielami klienta, osoby zobowiązane do uczestnictwa w spotkaniach oraz decyzje jakie mogą (bądź też muszą) na nich zapaść. Dobrą praktyką jest również określenie preferowanych kana- łów komunikacji oraz uzgodnienie dostępności i responsywności poszczególnych członków zespołów.

Mechanizmy wyjścia z umowy w trakcie jej trwania

– w toku prac nad projektem może okazać się, że zaistnieją przeszkody (nieko- niecznie zawinione przez którąkolwiek ze stron) uniemożliwia- jące przeprowadzenia kolejnych iteracji. W mniej skompliko- wanym wariancie, jedna ze stron może przecież wypowiedzieć umowę. Jest to normalna i często spotykana sytuacja w branży IT. Umowa Agile ma rozwiązywać ten problem. Gdy któraś z powyż- szych sytuacji nastąpi, nieodpowiednie uregulowanie kwestii wyjściowych doprowadzić może do powstania zawiłego sporu.

Katalog kwestii, które należy uregulować w planie wyjściowym nigdy nie będzie jednolity (jest to niemożliwe ze względu na różnorodność projektów realizowanych w Agile), jednak przykładowe zagadnienia obejmują:

  • szczegółową procedurę czynności, które każda ze stron musi wykonać w razie wcześniejszego zakończenia umowy z jakiegokolwiek powodu (wraz z terminami),
  • określenie kto i w jakim stopniu, odpowiedzialny jest za powstałą w toku prac dokumentację, kod źródłowy, dane poufne, wykorzystane materiały itp,
  • wskazanie po obydwu stronach osób odpowiedzialnych za zarządzanie procesem wyjścia.

Artykuł ten stanowi fragment naszego e-booka. Możesz go pobrać bezpłatnie klikając baner powyżej.