Projekty realizowane w modelu Agile są odpowiedzią na zmienność wymagań i otoczenia biznesowego w toku realizacji projektu oraz ryzyko związane z dużymi projektami IT. W przeciwieństwie do tradycyjnych kontraktów kaskadowych, opartych na sztywnym zakresie i harmonogramie, umowy Agile koncentrują się na współpracy, adaptacji i iteracyjnym dostarczaniu wartości biznesowej. Oferują podejście zwinne, rozbijające projekt na drobne części realizowane w krótkich sprintach. Stawiają na elastyczność i częste dostarczanie mniejszych, ale kompletnych elementów, które – w zależności od potrzeb – można rozwijać w wybranym kierunku.
W modelu Agile punkt ciężkości zostaje przesunięty z precyzyjnego określenia rezultatu końcowego na zdefiniowanie zasad współpracy, mechanizmów decyzyjnych oraz sposobu zarządzania zakresem i zmianą. Jest to obecnie najczęściej stosowana alternatywa, zwłaszcza w projektach, gdzie nie da się zaplanować wszystkiego z góry, a wymagania lub okoliczności zewnętrzne mogą zmieniać się w trakcie prac wdrożeniowych.
Jak to działa?
Podstawowe założenie jest takie, że nie wszystkie wymagania są precyzyjnie definiowane na początku projektu. Charakterystyczną cechą umów Agile jest brak sztywno określonego zakresu funkcjonalnego na moment kontraktowania. Zakres prac nie jest zamrożony, a rozwija się w trakcie realizacji projektu, w krótkich iteracjach zwanych sprintami, odpowiadających na kształtujące się potrzeby biznesowe. W każdym sprincie powstaje działający fragment produktu, który można od razu sprawdzić, ocenić i udoskonalić. Właśnie częste dostarczanie mniejszych, ale kompletnych wartości, które można rozwijać w wybranym kierunku, jest istotą metodyki.
W projektach Agile ważną rolę odgrywa transparentność i ciągłe zaangażowanie obu stron, a zwłaszcza wczesny i regularny kontakt Zamawiającego z tworzonym oprogramowaniem. Zamawiający musi aktywnie uczestniczyć w projekcie, regularnie odbierając efekty prac i współdecydując o kolejnych krokach. Musi na bieżąco testować i oceniać budowane funkcje, dzięki czemu może od razu weryfikować jakość produktu i określać kierunek jego rozwoju. Drugim istotnym elementem jest sposób zarządzania zmianą. Podejście zwinne nie traktuje zmian jako ryzyka lub zmiany umowy, a zakłada, że zmiana jest naturalną cecha projektu i umożliwia jej płynne uwzględnianie w procesie wdrożeniowym. Kluczowa jest również dokumentacja, tzw. backlog, odzwierciedlająca przebieg dotychczasowych prac i aktualny stan projektu.
Taki model działania doskonale wpisuje się zarówno w sytuacje, w których Zamawiający nie ma jeszcze dokładnie sprecyzowanych celów biznesowe lub nie jest w stanie określić szczegółowych wymagań projektu, jak i w sytuacje, w których mamy do czynienia ze zmiennością w czasie okoliczności zewnętrznych wpływających na sposób realizacji projektu (wymagania rynku, technologia, przepisy, normy). Z perspektywy osoby zarządzającej wdrożeniem podstawową zaletą jest większa elastyczność, szybsze dostarczanie rezultatów oraz lepsze dopasowanie końcowego rozwiązania do realnych potrzeb biznesowych. Konsekwencją pracy w modelu Agile jest jednak to, że wymaga on dojrzałości organizacyjnej po stronie Zamawiającego, zaufania do Wykonawcy oraz – co najważniejsze – dużej dyscypliny i gotowości Zamawiającego do aktywnej bieżącej współpracy z Wykonawcą, co w niektórych organizacjach może być trudne do realizacji.
Charakter prawny umowy Agile i jego konsekwencje
Zgodnie z charakterem modelu Agile, umowa nie opisuje szczegółowo końcowego produktu, lecz określa ramy współpracy i proces dochodzenie do efektu końcowego. Stąd też nie może być kwalifikowana jako umowa o dzieło w rozumieniu Kodeksu cywilnego. W praktyce umowy typu Agile kwalifikuje się jako umowy o świadczenie usług, albo umowy ramowe, na podstawie których udzielane są zamówienia na wykonanie poszczególnych usług, co jest realizowane w postaci kolejnych sprintów. Ma to swoje konsekwencje prawne. W szczególności:
Umowa Agile nie jest umową rezultatu. Zamawiający nie może wymagać się od Wykonawcy dostarczenia umówionego, z góry określonego wyniku swojej pracy (dzieła).
Wykonawca – co do zasady – nie ponosi odpowiedzialności za końcowy efekt swojej pracy, a jedynie za zachowanie przy swoich działaniach należytej staranności.
Z umową typu Agile nie są powiązane przepisy Kodeksu cywilnego o rękojmi lub gwarancji jakości za wady.
Nie ma podstaw do stosowanie przepisów umowy o dzieło o odstąpieniu od umowy.
Kwestie te mają istotny wpływ na sposób realizacji umowy wdrożeniowej i skutki jej nieprawidłowego wykonania. W tym zwłaszcza na zasady odpowiedzialności stron i uprawnienia przysługujące Zamawiającemu wobec Wykonawcy.
Dlatego: negocjując i zawierając umowę wdrożeniową w modelu Agile należy przede wszystkim precyzyjnie określić proces realizacji umowy, podział ról, sposób podejmowania decyzji, mechanizmy kontroli postępu prac oraz warunki zakończenia projektu. Dobrze przygotowana umowa Agile nie ogranicza zwinności realizacji projektu, a zapewnia jego bezpieczne prowadzenie na umówionych warunkach.
Kiedy Agile, a kiedy nie?
Zwinny model pracy sprawdza się m.in. tam, gdzie nie da się zaplanować wszystkiego z góry, a wymagania mogą zmieniać się w trakcie prac wdrożeniowych. Pozwala na ciągłą adaptację, eksperymentowanie i doskonalenie efektów prac.
Umowy Agile dobrze funkcjonują w projektach innowacyjnych, transformacyjnych i tam, gdzie zakres i rozwiązania muszą ewoluować wraz z wiedzą zdobytą w trakcie realizacji. Model zwinny powinien być stosowanych również w projektach, których kształt wynika od okoliczności zewnętrznych, zmiennych w czasie, do których projekt musi być płynnie dopasowywany (np. zmiany regulacyjne). W odpowiednich warunkach model ten pozwala skutecznie łączyć cele biznesowe z elastycznością współpracy.
Należy jednak pamiętać, że nie zawsze można przewidzieć, jaki będzie ostateczny rezultat projektu i jaki będzie jego koszt. Jeżeli zaczynamy projekt od ogólnie sformułowanych wymagań i je stopniowo doprecyzowujemy, to musimy się liczyć z nie do końca znanym kosztem prac projektowych, co dotyczy zarówno kosztu prac Wykonawcy, jak i kosztu prac własnych (czas pracy zaangażowanych pracowników). Często zatem to budżet wyznacza, jaki będzie efekt końcowy (kiedy projekt zostanie zatrzymany).
Podstawowe zalety modelu Agile:
Elastyczność – możliwość dostosowywania funkcjonalności w trakcie realizacji projektu bez konieczności zmiany umowy (cecha metodyki projektu).
Lepsze dopasowanie do potrzeb biznesowych. Iteracyjne dostarczanie rozwiązań cząstkowych pozwala na bieżąco weryfikować kierunek postępu prac i korygować produkt zgodnie z aktualnymi priorytetami.
Szybsze dostarczanie widocznych rezultatów. Efekty prac są widoczne wcześniej, co umożliwia wcześniejsze wykorzystanie części rozwiązania lub przeciwnie – w skrajnym przypadku pozwala podjąć decyzję o zakończeniu projektu.
Transparentność realizacji. Regularny udział Zamawiającego w pracach nad projektem zwiększa kontrolę nad realizacją prac i niweluje ryzyko „zaskoczenia” kształtem ostatecznego produktu.
Lepsze zarządzanie niepewnością.
Podstawowe ryzyko:
Choć umowy realizowane w modelu Agile oferują dużą elastyczność, niosą ze sobą specyficzne ryzyka prawne i kontraktowe, które wymagają świadomego zarządzania.
Wysokie wymagania organizacyjne. Metodyki zwinne wymagają dużej dojrzałości ze strony Zamawiającego, dostępności osób decyzyjnych i stałego zaangażowania.
Nieostry przedmiot umowy. Brak jednoznacznie zdefiniowanego rezultatu końcowego może utrudniać ocenę należytego wykonania umowy.
Ryzyko budżetowe po stronie Zamawiającego. Brak odpowiednich mechanizmów kontrolnych (limity kosztowe, kamienie milowe, mierzalne cele) może prowadzić do utraty kontroli nad budżetem projektu i przekroczenia planowanych kosztów.
Rozmycie odpowiedzialności. Aktywny udział Zamawiającego w procesach decyzyjnych może utrudniać przypisanie odpowiedzialności za opóźnienia lub nieosiągnięcie celów.
Złożoność regulacji praw autorskich. Iteracyjne budowanie rozwiązania wymaga starannie opisanych zasad przejścia praw i korzystania z efektów częściowych.
Kiedy się nie sprawdzi:
Umowa wdrożeniowa typu Agile nie sprawdzi się przede wszystkim w projektach, w których Zamawiający mają ograniczone zasoby organizacyjne i nie mogą brać stałego bieżącego udziału w procesie wdrożenia. W praktyce brak zaangażowania ze strony Zamawiającego oznacza duże prawdopodobieństwo braku sukcesu projektu wdrożeniowego.
Zobacz także
