Umowa na stworzenie oprogramowania w modelu Scrum

Termin Scrum po raz pierwszy pojawił się jeszcze w latach 80. ubiegłego wieku i dotyczył raczej rozwoju produktów i przedsiębiorstwa niż programowania. Musiało upłynąć niemal 10 lat, kiedy w 1995 roku zaproponowano wykorzystanie metodologii Scrum jako techniki programowania. Pomysł okazał się jednak strzałem w dziesiątkę i w 2009 roku powstała pierwsza oficjalna wersja The Scrum Guide, czyli powszechnie przyjętych wytycznych dotyczących programowania w tym standardzie.

Na wstępie warto zaznaczyć, że Scrum jest jedną z metod programowania Agile. Oznacza to, że ogólne zasady dotyczące programowania zwinnego znajdą zastosowanie również i tutaj. Należy w odpowiedni sposób zdefiniować takie zagadnienia, jak czas trwania poszczególnych wydarzeń scrumowych, ogólny cel zawartej umowy, czy skład zespołu scrumowego, jednak bez przesadnie kazuistycznej regulacji.

Zaleca się też, aby nie zamieszczać w umowie postanowień odsyłających do szeroko przyjętego Scrum Guide, ponieważ stopień ich ogólności pozwala rozumieć go każdego członkowi zespołu nieco inaczej.

Z definicji każda umowa wykorzystująca model Scrum będzie umową nienazwaną, a zatem strony mają w zasadzie pełną dowolność w zakresie kształtowania poszczególnych postanowień kontraktu tak długo, jak działają w granicach swobody umów. Jakie są szczególnie istotne elementy umowy o tworzenie oprogramowania w modelu Scrum?

Osią, dookoła której obraca się model Scrum jest odpowiednio dobrany zespół. W tej technice tworzenia oprogramowania wyróżnia się trzy podstawowe role, które są przypisywane poszczególnym członkom zespołu:

Product Owner

Każdy projekt Scrum musi posiadać jednego „właściciela produktu”. Jest on odpowiedzialny za utrzymywanie relacji między zamawiającym, użytkownikami a wykonawcami aplikacji. Pomaga zidentyfikować potrzeby odbiorców i dba o biznesowy aspekt projektu. Do zadań Product Ownera należy zarządzanie backlogiem, czyli listą priorytetowych funkcji, które powinny zostać wdrożone oraz komunikowanie inwestorom tzw. RIDAs (ang. Risk, Impediments, Dependancies and Assumptions) – wszelkich ryzyk, wątpliwości i zależności występujących między projektami.

Istotną cechą charakterystyczną Product Ownera jest to, że nie doradza on developerom w aspektach technicznych realizacji prac, choć może pomóc w osiągnięciu konsensu przez członków zespołu zestawiając ze sobą zmieniające się wymagania zamawiającego oraz możliwości techniczne wykonawcy.

Developer

Developerzy są odpowiedzialny za przygotowanie, testowanie i poprawę funkcjonalności aplikacji. Zazwyczaj przy projekcie pracuje ich kilku w zależności od skali i oczekiwanego terminu realizacji prac

Scrum master

Rola charakterystyczna dla techniki Scrum. Pełni on zadania związane z coachingiem, edukacją członków zespołu, a także nadzorowaniem końcowego efektu. Najłatwiej przyrównać Scrum mastera do Project managera. Zasadniczo Scrum master odpowiada za to, aby prace przebiegały możliwie szybko i sprawnie i dotarły do klienta na czas. Jednocześnie nie zarządza on pracą poszczególnych osób, dając im dużą swobodę działania.

Umowa powinna określać w sposób precyzyjny obowiązki związane z realizację danej funkcji, aby – pomimo elastycznego procesu realizacji umowy – można było jednoznacznie ustalić, kto jest odpowiedzialny za realizację określonych zadań.

W umowie warto wskazać jedynie, z jakich funkcji i w ilu osobach składa się zespół, np. 1 product owner, 1 scrum master i 3 developerów. Należy unikać imiennego określania współpracowników, dzięki czemu zamawiający może zapewnić płynną realizację poszczególnych sprintów, niezależnie od ewentualnych braków kadrowych lub przesunięć poszczególnych osób do realizacji innych projektów.

Sposobem na zabezpieczenie interesów zamawiającego jest konieczność uzyskania zgody na zmianę członka zespołu lub wprowadzenie konkretnych wymagań co do minimalnego poziomu jego umiejętności.

Aby zapewnić płynną realizację prac przy tworzeniu aplikacji, należy zadbać o odpowiednie uformowanie procesu decyzyjnego. Przede wszystkim warto przenieść komunikację na niższy poziom w firmie. Mniej istotne ustalenia, jakie w imieniu software house’u czyni z zamawiającym product owner powinny być zatwierdzane przez managerów odpowiedzialnych za dany dział lub produkt. Wprowadzenie do kontraktu konieczności każdorazowego uzyskiwania zgody kadry wysokiego szczebla może sparaliżować prace. Dlatego umowa może rozróżniać poszczególne kategorie czynności. Jako przykład można podać decydowanie przez dyrektora działu o:

• zmianie składu developerów;
• przesunięciu realizacji poszczególnych milestone’ów;
• zmianie ustaleń co do pobocznych funkcjonalności lub technologii wykonania aplikacji.

Z kolei kadra zarządzająca ostatecznie podejmuje decyzję o:

• podniesieniu lub obniżeniu budżetu;
• terminie ukończenia całego projektu lub jego najważniejszych etapów;
• zmianie Product Ownera.

Taki podział zapewnia wpływ zamawiającego na ramy umowy z jednoczesnym zachowaniem jej elastyczności. Dodatkowo pisemna forma zmiany umowy powinna być zachowana jedynie do największych jej modyfikacji. Co do zasady wymiana ustaleń powinna zachodzić drogą cyfrową, np. z wykorzystaniem adresów e-mail lub komunikatorów.

Wynagrodzenie za programowanie w metodykach zwinnych najczęściej określane jest godzinowo lub etapowo, po ukończeniu poszczególnych sprintów. Trudno będzie określić je w sposób zryczałtowany z uwagi na możliwość dalszej modyfikacji założeń umownych, choć zamawiający często wprowadzają tzw. cap, czyli górną granicę, jakiej nie może przekroczyć wynagrodzenie wykonawcy. Taki limit warto powiązać z obowiązkiem Product Ownera do informowania zamawiającego o wykorzystaniu określonej części budżetu, np. 30%, 40%, 60% i 80%. W ten sposób łatwiej będzie planować prace i zarządzać całym projektem.

Firmy, które decydują się na zamówienie stworzenia aplikacji w modelu Scrum lub z wykorzystaniem innej metodyki zwinnej powinny zdawać sobie sprawę, że jest to z reguły proces kosztowny, choć pozwala na dostarczenie odbiorcy końcowemu oprogramowania uwzględniającego wszystkie jego potrzeby.

Formułując umowę warto zdawać sobie sprawę z pułapek, jakie czyhają na klienta, który nie zadba o należyte zabezpieczenie swoich interesów. Niefortunnie zbudowana umowa o tworzenie oprogramowania Scrum doprowadzi do tego, że zamawiający będzie musiał płacić wykonawcy bez żadnej gwarancji rezultatu. Aby zagwarantować skuteczną współpracę z software house’m, warto zlecić negocjacje kontraktu oraz jego sporządzenie kancelarii prawnej z doświadczeniem w obsłudze prawnej branży IT.