Agile czy waterfall? Alternatywne modele pracy z softwere housem

Czym są zwinne umowy?

Zwinne umowy to kontrakty oparte o metodologię agile, która w świecie IT stanowi alternatywę do waterfalla. Ta ostatnia zakłada, że strony już na wstępnie określają wszystkie parametry przyszłej aplikacji, które softwere house ma obowiązek uwzględnić w trakcie swoich prac. Inaczej jest w przypadku umów zwinnych (agile’owych). Tu w momencie zawarcia umowy nie istnieje specyfikacja finalnego produktu – tworzy się ją wraz z postępem prac nad oprogramowaniem. Co istotne, w przypadku umów zwinnych produkty powstają na zasadzie przyrostowej, czyli softwere house nie przekazuje gotowego oprogramowania – efekty pracy są przekazywane w częściach, które posiadają samodzielne znaczenie i obejmują określoną część funkcjonalności. Przyjęcie modelu agile oznacza, że zamawiający i softwere house już na wstępie kooperacji dopuszczają wprowadzanie zmian w toku projektowania i modyfikowanie pierwotnych założeń tworzonego produktu.

Co to jest MVP?

MVP – z języka angielskiego minimum viable product, to produkt o ograniczonej liczbie funkcjonalności, który może zostać wprowadzony na rynek w celu jego weryfikacji i uzyskania feedbacku. Wypuszczenie takiego „niedokończonego” produktu jest głęboko osadzone w dynamice obecnego rynku. Pozwala bowiem, przy minimalnym zaangażowaniu czasu i środków, zweryfikować zapotrzebowanie na finalny produkt oraz ewentualnie zmodyfikować dalszy kierunek jego rozwoju.

Czy agile można łączyć z MVP?

W tym miejscu pojawia się pytanie: jaki jest związek między agile a MVP? Podstawowym założeniem zwinnych umów jest wytwarzanie oprogramowania etapowo, co pozwala na takie zorganizowanie prac nad produktem, aby jednym z etapów był właśnie MVP. Jest on najczęściej określany mianem kamienia milowego. Istotne jest również to, że po poddaniu produktu testowi rynku umowa zwinna pozwala na dokonanie zmian we wstępnych założeniach produktu, stosownie do otrzymanego feedbacku. Daje to możliwość dokonania modyfikacji pierwszej wersji umowy i wprowadzenia zmian w oprogramowaniu odpowiednio do wyniku testu rynkowego.

MVP a waterfall

Kolejna wątpliwość może dotyczyć tego, czy takie rozwiązanie wchodzi w grę w przypadku tradycyjnego modelu, tj. waterfall? Nic nie stoi na przeszkodzie, aby także wtedy wprowadzić etapowość prac i rozpocząć realizację projektu od stworzenia MVP. Problem zaczyna się dopiero wówczas, gdy po konfrontacji „prototypu” z reakcją rynku konieczne okaże się dokonanie zmian w pierwotnych założeniach. Tradycyjna metodologia pracy nad produktem zakłada bowiem, że z góry określamy, jaki ma być finalny produkt. Zmiana tych założeń będzie się więc wiązała z koniecznością zawarcia aneksu do umowy, co z kolei może wpłynąć na opóźnienie zakończenia projektu. Jeśli na dodatek od dnia zawarcia umowy do czasu wprowadzenia na rynek MVP zmienią się stawki softwere house’u, nie można wykluczyć, że niezbędne będzie przyjęcie nowych – najczęściej wyższych – stawek.

Exit plan

W kontekście wprowadzenia na rynek MVP trzeba wspomnieć o różnych skutkach wcześniejszego zakończenia współpracy, zarówno w przypadku umów agile, jak i waterfall. Taki scenariusz powinien być wzięty pod uwagę ze względu na niezwykle dynamiczne zmiany na dzisiejszym rynku. Tutaj również występują istotne różnice pomiędzy waterfall a agile – na korzyść tego ostatniego modelu. W przypadku metodologii zwinnych jedną z podstawowych kwestii, która powinna zostać uregulowana w umowie jest tzw. plan wyjścia, czyli postanowienia dotyczące sposobu i skutków rozwiązania umowy. Natomiast w modelu waterfall przewiduje się co prawda odstąpienie od umowy lub od jej dalszej realizacji, jednak na wstępie zakłada się wykonanie jej w całości, przez co możliwość wcześniejszego zakończenia musi być obwarowana określonymi warunkami. Warto też wiedzieć, że w świetle prawa zamawiający ma możliwość rezygnacji z wykonania dalszej części umowy łączącej go z softwere housem. Wybór tego wariantu będzie się jednak wiązać z koniecznością zapłaty na rzecz softwere house’u pozostałej części wynagrodzenia, pomniejszonej o oszczędności wynikające z niedokończenia projektu. To rozwiązanie nie będzie tak korzystne dla zamawiającego, jak realizacja procedury wyjścia będącej typowym modelem w umowach zwinnych.

Kara umowna a premia technologiczna

Typowym wręcz rozwiązaniem dla umów opartych o waterfall jest wprowadzanie kar umownych za ich nieterminowe wykonanie. Zdarza się, szczególnie w przypadku wdrażania innowacyjnych rozwiązań, że termin wykonania produktu może mieć negatywny wpływ na poziom wdrożonych rozwiązań. Pojawia się wtedy pytanie, na czym bardziej nam zleży: na bezwzględnym dochowaniu terminu, czy raczej kładziemy nacisk na stworzeniu rozwiązań najwyższej jakości. Waterfall nie daje przestrzeni do pogodzenia tych dwóch wartości, a głównym środkiem mającym na celu „zdopingowanie” software house’u do pracy są kary umowne. W umowach agile nie wyklucza się co prawda wprowadzenia kar umownych, jednak możliwe jest wprowadzenie tak zwanych premii technologicznych, czyli postanowień umownych zwiększających wynagrodzenie softwere house’u w przypadku terminowego wykonania oprogramowania o określonym zakresie funkcjonalności. Nie jest to jeszcze niestety popularne rozwiązanie na polskim rynku, ponieważ w dalszym ciągu za najwyższą formę zaufania do partnera biznesowego uznaje się wprowadzenie w kontrakcie maksymalnej ilości kar umownych. Model premiowy jest jednak zdecydowanie bliższy umowom zwinnym, niż waterfallowym. Ponadto, fakt, że w trakcie realizacji umowy zwinnej strony na bieżąco ustalają, które prace będą kolejno wykonywane, daje możliwość pogodzenia terminowości z wysoką jakością produktu. W praktyce oznacza to, że zamawiający na każdym etapie prac będzie mógł podjąć decyzję, czy dodatkowa funkcjonalność ma być realizowana, czy zrezygnuje z niej na rzecz terminowego ukończenia prac nad oprogramowaniem.

W kontekście kar umownych warto mieć świadomość, że każdy softwere house licząc się z koniecznością zapłaty kar umownych – co jest bardzo realną ewentualnością wobec niemożliwych do przewidzenia przeszkód w toku realizacji projektu – odpowiednio (wysoko) skalkuluje wartość kontraktu. W skrajnym przypadku zamawiający, zamiast spożytkować środki na rozwój produktu, ulokuje je w stworzeniu sobie możliwości naliczenia kar umownych.

Zaangażowanie stron umowy w proces pracy nad produktem

Umowy zwinne wyróżnia jeszcze jeden element, który z pewnością stawia je wyżej od umów wykonywanych w waterfall. Chodzi o równomierne zaangażowanie obu stron umowy w proces tworzenia produktu w celu zapewnienia maksymalizacji powodzenia przedsięwzięcia. Najlepiej widać to w jednym z wariantów zwinnych kontraktów, którym jest scrum. Zastosowanie tej metodologii pracy nad produktem niejako wymusza wprowadzenie przez zamawiającego co najmniej jednej osoby na bieżąco zaangażowanej w proces tworzenia produktu. Mowa tu o właścicielu produktu, który nie dość, że jest odpowiedzialny za nadzór nad rozwojem oprogramowania, to jeszcze na podstawie umowy otrzymuje bardzo daleko idące kompetencje w zakresie dokonywania w niej zmian. Warto też nadmienić o osobie scrum mastera, którego rolą jest optymalizowanie pracy zespołu deweloperskiego i pomoc w układaniu maksymalnie wydajnych relacji pomiędzy tym zespołem a właścicielem produktu.

Podsumowanie

Jeśli celem Twojej firmy jest wypuszczenie na rynek aplikacji wysokiej jakości, w przewidzianym umową terminie, rozważ rezygnację z kar umownych na rzecz premii technologicznych oraz uelastycznienia pracy nad oprogramowaniem. Innymi słowy, koniecznie weź pod uwagę wykorzystanie umowy zwinnej.

Piotr Kantorowski
radca prawny, wspólnik w Kancelarii Prawnej Kantorowski, Głąb i Wspólnicy sp. k