Wybór między agile a waterfall to nie tylko decyzja o stylu pracy zespołu, ale o tym, jaką umowę podpisujesz. Metodyka i umowa to system naczyń połączonych, dobrze dobrana umowa chroni projekt, źle dobrana blokuje go tak samo jak brak umowy. Przy planowaniu współpracy warto sprawdzić, jak powinna zostać skonstruowana Umowa software house z klientem, aby odpowiadała rzeczywistemu modelowi realizacji projektu.
- Waterfall zwykle prowadzi do umowy o dzieło – płacisz za z góry określony rezultat, z jednym odbiorem końcowym i rękojmią za wady.
- Agile zwykle prowadzi do umowy o świadczenie usług – płacisz za pracę zespołu w kolejnych sprintach, a zakres kształtuje się w trakcie.
- Agile nie znaczy „bez umowy” – to mit; brak kontraktu przy zmiennym zakresie kończy się sporem o to, co było w cenie oraz o wysokość wynagrodzenia w relacji do wykonanych prac.
- W agile prawa autorskie i odbiory idą etap po etapie – nie jednym aktem na końcu, lecz po każdym sprincie i są powiązane z płatnością.
- Kluczowa klauzula w agile to procedura zmiany zakresu – bez niej każda zmiana w backlogu to potencjalny spór o dodatkowe wynagrodzenie.
- Model hybrydowy bywa najbezpieczniejszy – twardy zakres jako podstawa prac, metodyka zwinna w usługach rozwoju; jedna umowa, dwa reżimy rozliczeń.
Zaczynasz projekt IT i słyszysz od software house’u dwa słowa: agile albo waterfall. Traktujesz to jak wybór techniczny, sposób, w jaki zespół deweloperski organizuje pracę. W praktyce podejmujesz wtedy decyzję prawną: przesądzasz, jaki rodzaj umowy zostanie zawarty, kiedy będziesz mógł odebrać efekty i w którym momencie staniesz się właścicielem praw do kodu.
Agile vs waterfall – porównanie metodyk w projekcie IT
Metodyki zarządzania projektem w IT dzielą się z grubsza na dwa nurty: kaskadowy waterfall i zwinny agile. Obie to metodyki wytwarzania oprogramowania, ale różnią się przede wszystkim tym, kiedy ustala się zakres i jak często oddaje się efekt pracy. To najważniejsza różnica, bo z niej wynikają wszystkie konsekwencje prawne.
Waterfall (kaskadowy model wytwarzania) prowadzi projekt sekwencyjnie: najpierw pełna analiza i wymagania projektowe, potem projektowanie, wytwarzanie, testy i wdrożenie. Zakres jest ustalony z góry, a efekt oddaje się zwykle raz, na końcu. Metodyka agile odwraca tę logikę, to iteracyjne podejście do projektu, w którym praca biegnie w krótkich cyklach zwanych sprintami, a lista zadań (backlog produktu) jest priorytetyzowana i zmieniana na bieżąco.
Najpopularniejsze ramy pracy zwinnej to Scrum i Kanban. W Scrumie zespół pracuje w sprintach, a takie role jak Product Owner i Scrum Master pilnują odpowiednio priorytetów i procesu; DevOps dokłada do tego ciągłe dostarczanie kolejnych wersji. Dla porównania metodyk najważniejsze są cztery praktyczne różnice:
- Zakres – w waterfall zamknięty na starcie; w agile otwarty i doprecyzowywany w kolejnych iteracjach.
- Dostarczanie – w waterfall jeden produkt końcowy; w agile działające przyrosty po każdym sprincie.
- Zmiana – w waterfall kosztowna i formalna; w agile wpisana w metodę jako ciągłe doskonalenie procesu.
- Ryzyko – w waterfall ryzyko kumuluje się na końcu; w agile rozkłada się na iteracje.
Zalety i wady obu podejść sprowadzają się więc do jednego napięcia: przewidywalność kontra elastyczność. I dokładnie w tym punkcie zaczyna się prawo i ekspozycja na ryzyko.
Wybór metodyki a rodzaj umowy w projekcie IT
Metodyka przesądza o tym, jaki rodzaj umowy realnie zawierasz, a rodzaj umowy decyduje, za co odpowiada dostawca. To najważniejsza konsekwencja prawna całego wyboru.
Waterfall pasuje do umowy o dzieło. Liczy się z góry określony rezultat, dostawca odpowiada za jego osiągnięcie, a klientowi przysługuje rękojmia za wady. Agile bliższy jest umowie o świadczenie usług (art. 750 KC): dostawca zobowiązuje się starannie pracować w kolejnych sprintach, ale nie gwarantuje z góry konkretnego, zamkniętego produktu, bo ten dopiero się kształtuje w procesie wytwarzania.
Jakie są konsekwencje dokonanego wyboru:
- Odpowiedzialność za wady – w modelu umowy o dzieło obowiązuje rękojmia ustawowa; w modelu usług trzeba ją odtworzyć umowną gwarancją jakości, bo sama z siebie nie przysługuje.
- Wynagrodzenie – dzieło zwykle rozlicza się jako Fixed Price, usługi jako Time & Material. Różnice między tymi modelami rozliczeń opisano osobno: Fixed Price vs Time & Material.
- Kwalifikacja przez sąd – o rodzaju umowy nie decyduje jej tytuł, lecz rzeczywista treść i sposób wykonania. Nazwanie umowy „zwinną” niczego nie przesądza.
Przy projektach prowadzonych stale lub rozwijanych przez dłuższy czas znaczenie może mieć również kompleksowa Obsługa prawna firm IT, obejmująca nie tylko samą umowę wdrożeniową, ale także kolejne etapy współpracy z klientami i podwykonawcami.
Agile nie znaczy „bez umowy” – dlaczego brak kontraktu zwiększa ryzyko?
Agile bez umowy to nie elastyczność, tylko brak zabezpieczenia. Agile stawia „działające oprogramowanie ponad dokumentację” i „współpracę ponad negocjowanie kontraktów”, co bywa czytane jako zgoda na projekt bez umowy. To nieporozumienie, bo Agile odwołuje się do opisu sposobu pracy, a nie wyłącza potrzeby uregulowania praw i obowiązków.
Przy zmiennym zakresie brak umowy uderza mocniej niż w waterfall, bo nie ma nawet punktu odniesienia, względem którego można ocenić, co było „w cenie”. Gdy dochodzi do sporu, sąd i tak zakwalifikuje relację według jej rzeczywistej treści.
Jak wygląda spór przy projekcie bez umowy?
Startup i software house ruszają zwinnie w projekt, „na zaufanie”, bez umowy, tylko akceptacje kolejnych zadań mailem. Po pięciu sprintach klient uznaje, że część funkcji miała być „w ramach” dotychczasowej stawki; dostawca traktuje je jako nowy zakres do dodatkowej wyceny. Nie ma procedury zmiany, nie ma definicji ukończenia, nie ma protokołów odbioru. Spór nie dotyczy jakości kodu, tylko tego, co strony w ogóle uzgodniły i ile ma to kosztować, a tego z rozproszonych maili nie da się jednoznacznie odtworzyć.
Zmiana zakresu w agile – jak uregulować change request?
W agile zakres z założenia się zmienia, więc umowa musi regulować sposób jego zmiany, a nie zamrażać go w jednym załączniku. To odwrotność z waterfall, gdzie zakres opisuje się raz i pilnuje jego nienaruszalności.
Rozwiązaniem jest procedura zmiany zakresu (change request): opis, kto i jak zgłasza nowe wymagania projektowe, jak wpływają na wynagrodzenie i harmonogram projektu oraz kto je zatwierdza. Backlog produktu żyje, ale każda istotna zmiana przechodzi przez uzgodnioną ścieżkę, dzięki czemu „ciągłe doskonalenie procesu” nie zamienia się w ciągły spór o pieniądze.
Przykładowa klauzula zmiany zakresu
„Zmiana zakresu prac następuje na podstawie zgłoszenia zmiany (change request) zaakceptowanego przez obie Strony. Zgłoszenie określa wpływ zmiany na wynagrodzenie, harmonogram oraz kryteria odbioru. Prace objęte zaakceptowanym zgłoszeniem rozliczane są zgodnie z modelem … . Do czasu akceptacji zgłoszenia Dostawca realizuje zakres dotychczas uzgodniony.”
Odbiór prac w agile i waterfall – czym różnią się oba modele?
Metodyka zmienia moment i sposób odbioru, a odbiór to miejsce, w którym ryzyko i płatność zmieniają właściciela. W waterfall odbiór jest zwykle jeden, końcowy, całości prac lub dwóch-trzech etapów prac podejmowanych w ramach projektu. W agile odbiera się przyrosty prac po kolejnych sprintach, każdy według wcześniej ustalonych kryteriów.
W obu modelach potrzebujesz jednego: mierzalnej definicji ukończenia (Definition of Done). Bez niej „gotowe” znaczy co innego dla każdej ze stron. W agile ta definicja pracuje po każdym sprincie i najlepiej wiązać ją z płatnością za dany przyrost w projekcie.
Przykładowa klauzula odbioru sprintu
„Odbiór przyrostu następuje po zakończeniu sprintu, na podstawie potwierdzenia spełnienia kryteriów akceptacji (Definition of Done) uzgodnionych dla danego sprintu. Zamawiający zgłasza uwagi w terminie … dni roboczych; brak uwag w tym terminie oznacza odbiór przyrostu. Wynagrodzenie za sprint staje się wymagalne po odbiorze przyrostu.”
Prawa autorskie w agile – kiedy powinny przechodzić na klienta?
W modelu agile prawa autorskie do kodu trzeba przenosić iteracyjnie, bo projekt jest wykonywany przyrostowo. To istotna różnica wobec waterfall, gdzie przeniesienie można spiąć z jednym odbiorem końcowym.
Zasada pozostaje ta sama niezależnie od metodyki: umowa przenosi majątkowe prawa autorskie tylko na wyraźnie wymienionych polach eksploatacji; dla programów komputerowych katalog pól określa art. 74 ust. 4 pr.aut., a dla innych utworów np. dokumentacji art. 50 pr.aut. W modelu zwinnym najkorzystniej jest wiązać przeniesienie praw do każdego przyrostu z zapłatą za dany sprint.
Przykładowa klauzula dotycząca praw autorskich
„Z chwilą zapłaty wynagrodzenia za dany sprint Dostawca przenosi na Zamawiającego majątkowe prawa autorskie do utworów powstałych w tym sprincie, na polach eksploatacji określonych w § … . Przeniesienie obejmuje kod źródłowy, kod wynikowy i dokumentację jako formy wyrażenia programu. Do czasu zapłaty Zamawiający korzysta z przyrostu na podstawie licencji niewyłącznej w zakresie niezbędnym do testów i odbioru.”
Model hybrydowy – kiedy łączenie agile i waterfall ma sens?
Łączenie agile i waterfall w jednym projekcie ma sens wtedy, gdy część zakresu jest stabilna, a część dopiero się kształtuje. To częsty i rozsądny wybór, a umowa potrafi go obsłużyć bez sprzeczności.
W hybrydowym podejściu twardy, przewidywalny fundament (np. integracje, wymagania regulacyjne, architektura) rozlicza się kaskadowo jak dzieło za stałą cenę. Warstwę rozwijaną iteracyjnie prowadzi się zwinnie, jak usługę rozliczaną za sprinty. W jednej umowie współistnieją wtedy dwa reżimy: część z odbiorem końcowym i rękojmią, część z odbiorami po sprintach i gwarancją umowną. Warunkiem jest wyraźne rozgraniczenie, który zakres należy do którego reżimu.
W projektach technologicznych działających w sektorze regulowanym dodatkowego znaczenia nabiera obsługa prawna FinTech, ponieważ wymagania regulacyjne mogą bezpośrednio wpływać na zakres projektu, architekturę rozwiązania i obowiązki kontraktowe stron.
Jak wybrać metodykę projektu software’owego i dopasować do niej umowę?
Wybór metodyki zależy przede wszystkim od tego, jak stabilny jest zakres i na jakim etapie jest produkt. To kryterium ważniejsze niż popularność danego podejścia w branży.
Kiedy stosować metodykę waterfall w IT: gdy zakres jest znany i stabilny, wymagania nie będą się zmieniać, a projekt ma twarde ramy (np. wdrożenie pod konkretny wymóg prawny lub integrację o ustalonej specyfikacji). Kiedy warto wybrać agile: gdy produkt dopiero powstaje, zakres będzie ewoluował, a liczy się szybkie dostarczanie kolejnych wersji.
Dla mniejszych projektów i startupów, gdzie kierunek produktu jeszcze się klaruje, zwinne podejście jest zwykle lepsze, ale pod warunkiem, że stoi za nim umowa z procedurą zmiany i odbiorami po sprintach. Niezależnie od tego, którą metodykę zarządzania projektem IT wybierzesz, to nie nazwa decyduje, a treść umowy.
W przypadku bardziej złożonych projektów warto sprawdzić także wsparcie Prawnik IT Kraków nowe technologie, szczególnie gdy umowa łączy kwestie wdrożeniowe, prawa autorskie, odpowiedzialność dostawcy oraz rozwój produktu.
Najczęściej zadawane pytania (FAQ)
Czym różni się Agile od Waterfall?
Agile prowadzi projekt iteracyjnie, w sprintach, ze zmiennym zakresem; waterfall prowadzi go kaskadowo, z zakresem ustalonym z góry i jednym odbiorem końcowym lub dwoma-trzema odbiorami dużych etapów prac. Z perspektywy prawnej waterfall bliższy jest umowie o dzieło, a agile umowie o świadczenie usług.
Kiedy stosować metodykę Waterfall w projekcie IT?
Waterfall warto stosować, gdy zakres jest znany i stabilny, a wymagania nie będą się zmieniać. Tytułem przykładu: gdy przedmiotem projektu jest wdrożenie pod konkretny wymóg regulacyjny lub integracja o ustalonej specyfikacji. Taki projekt dobrze układa się w umowę o dzieło ze stałą ceną.
Kiedy warto wybrać Agile zamiast Waterfall?
Agile warto wybrać, gdy produkt dopiero powstaje, a zakres będzie się zmieniał w trakcie. Wtedy elastyczność jest wartością – pod warunkiem, że umowa zawiera procedurę zmiany zakresu, odbiory po sprintach i przeniesienie praw powiązane z płatnością za sprint.
Jakie są zalety i wady metodyki Agile?
Zaletą agile jest elastyczność, szybkie dostarczanie i możliwość korekty kierunku, do wad zaliczymy: trudniejszą wycenę i ryzyko rozjazdu oczekiwań co do zakresu między dostawcą a klientem. Prawnie tę wadę neutralizuje się procedurą zmiany zakresu i definicją ukończenia sprintu.
Jakie są zalety i wady metodyki Waterfall?
Zaletą waterfall jest przewidywalność zakresu, kosztu i terminu. Do wad zaliczymy: wysoki koszt zmiany i ryzyko skumulowane na końcu projektu, związane z prawidłowością wykonania projektu. Prawnie sprzyja to umowie o dzieło, ale wymaga bardzo dokładnego opisu przedmiotu, bo wszystko, czego nie ujęto w zakresie, staje się później sporne.
Czy można łączyć Agile i Waterfall w jednym projekcie?
Tak, model hybrydowy często występuje w relacjach biznesowych. Łączy podstawowy zakres rozliczany jak dzieło z warstwą rozwojową oprogramowania, która jest usługą. Warunkiem powodzenia jest wyraźne rozgraniczenie w umowie, który zakres podlega któremu reżimowi odbioru i odpowiedzialności.
Jak dopasować umowę do wybranej metodyki?
Agile czy waterfall to nie tylko pytanie o zarządzanie projektem, ale też o to, jaki rodzaj umowy zostanie zastosowany w projekcie. Waterfall ciąży ku umowie o dzieło z jednym odbiorem lub kilkoma dużymi i rękojmią za wady; agile to raczej umowa o świadczenie usług z odbiorami po sprintach, procedurą zmiany zakresu i przeniesieniem praw etap po etapie. Największe ryzyko nie leży w wyborze metodyki, lecz w tym, że wybrana metodyka nie zostaje właściwie przełożona na treść umowy. Dobre zarządzanie projektem IT zaczyna się więc nie od wyboru narzędzia, lecz od dopasowania umowy do projektu.
Sprawdź naszą usługę w Łochowski Legal – dopasujemy umowę do Twojej metodyki: zakres, odbiory, wynagrodzenie i prawa do kodu.
