Jak pisać umowy dla projektów IT realizowanych w modelu Agile? Cz. IV.

Zdarzenia, to kolejny po rolach, element Scruma, o którym powinnyśmy pamiętać pisząc umowę na realizację projektu w modelu Agile. Zanim jednak powiemy sobie jak konkretnie mają brzmieć poszczególne postanowienia umowy odnoszące się do zdarzeń scrumowych, należy zadać sobie pytanie, czy opis tego obszaru w ogóle powinien znaleźć się w umowie?

Obserwując praktykę rynkową, można zauważyć co najmniej dwa modele będące odpowiedzią na tak postawione pytanie.

Pierwszy z nich polega na całkowitym pominięciu w umowie postanowień odnoszących się do zdarzeń scrumowych. Model ten najczęściej ogranicza się do zawartego w umowie postanowienia odsyłającego do ogólnych zasad modelu Scrum. W opinii stron decydujących się na ten model, uzasadnieniem dla jego zastosowania jest oszczędność czasu i skrócenie przebiegu negocjacji, pozwalające na szybsze podpisanie przez strony umowy.

Nie da się ukryć, że taki model istotnie przyspieszy proces negocjacyjny, pytanie tylko, czy warto to robić. Pół biedy jeżeli zawarte w umowie odesłanie kieruje nas do jakiegokolwiek opisanego zbioru zasad czy reguł odnoszących się do modelu Scrum (np. Scrum Guide). Dużo gorzej jeżeli odesłanie ma charakter bardzo ogólny, ograniczający się w istocie do zdawkowego postanowienia typu „przebieg zdarzeń w ramach umowy będzie realizowany zgodnie z modelem Scrum”. W takim przypadku możemy być niemal pewni, że czas jaki udało się nam zaoszczędzić podczas negocjacji, stracimy już na etapie realizacji umowy próbując ustalić co tak naprawdę rozumieliśmy pod pojęciem „zgodnie z modelem Scrum”.

Dodatkowo pamiętajmy, że nawet odesłanie do konkretnego zbioru zasad i reguł scrumowych (np. Scrum Guide), nie gwarantuje nam stuprocentowej pewności, że strony tak samo rozumieć będą zawarte w nim postanowienia. Wynikać to może z odmiennych praktyk, doświadczeń i przyzwyczajeń w realizacji projektów Scrumowych, które mogą się różnić w zależności od profilu branży lub podmiotu te zasady stosującego. Warto w tym miejscu pamiętać, że właśnie sam Scrum Guide, na swoich pierwszych stronach wskazuje, że poszczególne zasady stosowania Scruma mogą się różnić.

Jaki z tego wniosek?

Po pierwsze nie ograniczajmy się w umowie do zdawkowych odesłań w rodzaju „zgodnie z modelem Scrum”. W najlepszym wypadku czas zaoszczędzony podczas negocjacji stracimy już na etapie realizacji projektu, poświęcając go na konieczne doprecyzowanie nazbyt ogólnie opisanych zasad, w najgorszym zaś wypadku, eskalacja konfliktu stron co do właściwego rozumienia opisu zdarzeń scrumowych doprowadzi do wstrzymania projektu, straty czasu, pieniędzy oraz nerwów.

Po drugie, odsyłając w umowie do konkretnego zbioru zasad scrumowych, upewnijmy się, że zawarte w nim postanowienia nie pozostawiają zbyt dużej przestrzeni interpretacyjnej, ta bowiem może szybko spowodować konflikt stron co do właściwego rozumienia jego poszczególnych zapisów.

Po trzecie, dążąc do uniknięcia wyżej sygnalizowanych ryzyk, poświęćmy w ramach negocjacji czas na wypracowanie przez strony załącznika do umowy, który w sposób precyzyjny i nie pozostawiający przestrzenie na niepotrzebne wątpliwości, określi rodzaj oraz przebieg zdarzeń scrumowych, jakie będą realizowane w ramach objętego umową projektu.

Opiszmy te obszary zdarzeń, które z punktu widzenia projektu są szczególnie ważne. Określmy maksymalny czas ich trwania, cel, lokalizację, członków Zespołu Scrumowego, którzy mają w nich uczestniczyć.

Co ważne, tym razem bardziej z projektowego niż prawnego punktu widzenia, zasady te opiszmy właśnie w formie odrębnego załącznika do umowy. W ten sposób osoby realizujący projekt od strony operacyjnej, nie będą musiały za każdym razem przedzierać się przez postanowienia całej umowy aby odnaleźć najczęściej, z ich punktu widzenia, potrzebne zapisy, odnoszące się do przebiegu realizacji projektu. Każda z osób posiadająca doświadczenie w realizacji złożonych projektów informatycznych, wie, że ten prosty w swojej istocie zabieg, może w sposób zasadniczy przyczynić się do wzrostu efektywności realizacji projektu.

SPRINT

Sprint to z całą pewnością podstawowe zdarzenie w ramach Scruma. Z perspektywy postanowień umowy powinnyśmy przede wszystkim pamiętać o uregulowaniu następujących obszarów z nim związanych.

Czas

Koniecznym postanowieniem jest określenie w umowie maksymalnego okresu (czasu) trwania Sprintu. Strony każdorazowo przed rozpoczęciem danego Sprintu będą ustalać długość jego trwania, niemniej długość ta, nie będzie mogła przekraczać ustalonej przez strony granicy maksymalnego czasu trwania Sprintu. Zapis ten stanowi odzwierciedlenie jednej z naczelnych zasad Scruma, nakazującej aby wszystkie zdarzenia miały wyraźnie określony dopuszczalny, maksymalny czas ich trwania (time-boxed). Ma to na celu utrzymanie właściwej dyscypliny i dynamiki w ramach realizowanego projektu. Nie oznacza to oczywiście, że dane zdarzenie realizowane w ramach umowy nie może trwać krócej. Krócej trwać może zawsze. Ważne aby nie trwało dłużej niż maksymalny czas przewidziany w umowie dla danej kategorii zdarzenia.

Zakres

Kolejnym elementem dotyczącym Sprintu istotnym z punktu widzenia postanowień umowy jest zapis, na podstawie którego, strony zgodnie ustalają, że z momentem dokonania przez strony ustaleń co do zakresu danego Sprintu (Sprint Backlog), zakres ten ulega zamrożeniu. Tym samym do czasu zakończenia danego Sprintu, żadna ze stron umowy nie może zmieniać zakresu prac przewidzianych do realizacji w danym Sprincie. Innymi słowy elastyczność co do wybranego obszaru projektu kończy się z chwilą jego ustalenia i przyjęcia do realizacji w ramach danego Sprintu.

Przerwanie Sprintu

Kolejny obszar, który warto przewidzieć i uregulować w umowie to przerwanie Sprintu. Modelowo takie uprawnienie powinno leżeć w gestii Product Ownera (Zamawiającego), który w każdym czasie albo w wyraźnie przewidzianych w umowie okolicznościach może podjąć decyzję co do przerwania prac realizowanych w ramach konkretnego Sprintu. Co istotne, jeżeli decydujemy się na przyznanie Product Ownerowi prawa do przerwania Sprintu, pamiętajmy aby jednocześnie jednoznacznie uregulować związane z taką sytuacją okoliczności. Mamy tu w szczególności na myśli zasady rozliczeń co do przerwanych prac oraz transferu praw autorskich do tych elementów, które zostały wyprodukowane przez wykonawcę w ramach przerwanego Sprintu.

Przestój

Z punktu widzenia zamawiającego warto przewidzieć w umowie prawo Product Ownera do zarządzenia przestoju pomiędzy zakończeniem jednego Sprintu a rozpoczęciem kolejnego. Przy czym zapis ten nie powinien oczywiście ograniczać się do samego uprawnienia przyznanego w tym zakresie Product Ownerowi. Dodatkowo określić należy maksymalny czas takiego przestoju oraz warunki rozliczeń stron związanych z zatrzymaniem prac pomiędzy Sprintami (oplata postojowa).

Inne Zdarzenia

Poza opisem zasad dotyczących przebiegu samego Sprintu warto również określić w umowie przynajmniej podstawowe reguły odnoszące się do pozostałych kategorii zdarzeń scrumowych. Tym samym opisując Dzienny Scrum ustalić należy jakie osoby z Zespołu Scrumowego mają w nim uczestniczyć, gdzie taki Dzienny Scrum będzie realizowany i oczywiście jaki jest maksymalny, dopuszczalny czas jego trwania. W istocie skład, lokalizacja oraz maksymalny czas trwania to te parametry, które powinny zostać określone w umowie dla każdej kategorii Zdarzeń (Dzienny Scrum, Przegląd Sprintu, Retrospektywa).

Dodatkowo, każdego z tych Zdarzeń, ze względu na swój cel oraz specyfikę mogą dotyczyć dodatkowe, szczególne regulacje przewidziane w umowie. I tak opisując przebieg Retrospektywy Sprintu warto wprowadzić zapis nakładający na strony umowy obowiązek implementacji do projektu wszelkich usprawnień będących rezultatem przeprowadzanych Retrospektyw. Tym samym jedna z naczelnych idei zwinnego zarządzania, kładąca nacisk na stały rozwój i doskonalenie działań w ramach projektu, znajdzie formalne umocowanie w ramach umowy.

Błąd przeregulowania

Na zakończenie jeszcze jedna uwaga natury ogólnej.

Opisując w umowie zasady przebiegu poszczególnych Zdarzeń warto zachować zdrowy umiar aby nie popełnić błędu nadmiernego przeregulowania kontraktu. Zdarza się bowiem, że nadmierna inwencja autora umowy, zmierzająca do uregulowania możliwie największej liczby potencjalnie możliwych okoliczności doprowadzi do powstania skostniałych procedur, które nie będą miały za wiele wspólnego z elastycznym (zwinnym) podejściem do realizacji projektu.

Co więcej, efektem takiego podejścia może być bardzo niebezpieczna sytuacja polegająca na istnieniu dwóch niezależnych światów – świata umowy i świata projektu. To bowiem jedna z najczęstszych konsekwencji przeregulowania zapisów umowy, i ujęcia ich w taki sposób, który istotnie odbiega od realiów realizacji projektu informatycznego. Jednym słowem zdrowy rozsądek i doświadczenie projektowe powinny podpowiadać nam, które z obszarów dotyczące Zdarzeń scrumowych w danym projekcie powinny zostać uregulowane szczegółowo, a które z nich mogą zostać pozostawione do roboczych ustaleń wypracowanych wspólnie przez strony już na etapie realizacji projektu.


Agile – transformacja organizacji i wdrożeń IT

Metodyki zwinne (agile) pozwalają podnieść efektywność wdrażania rozwiązań IT oraz obniżyć koszty tych wdrożeń. Jest to związane z przynoszonym przez metodyki agile uelastycznieniem i usprawnieniem procesów zakupowych i deweloperskich.

Zobacz rozwiązanie >

Zobacz pozostałe artykuły z tej serii