Na czym właściwie polega model 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?
Czy przedmiot umowy w modelu scrum jest potrzebny w umowie?
Przedmiot umowy powinien być opisany w sposób ogólny, odnoszący się do oczekiwanego efektu prac. Z uwagi jednak na fakt, że nigdy nie wiadomo do końca, ile będzie kolejnych sprintów i czy w trakcie ich realizacji nie zmienią się założenia zamawiającego, warto wystrzegać się szczegółowej specyfikacji technicznej. Jak w takim razie opisać rezultat prac?
Najlepiej, jeżeli umowa będzie określała najważniejsze funkcje, dostępne opcje czy kluczowe elementy interfejsu. Powinna jednak zostawiać swobodę w doborze środków do realizacji celu. Dzięki temu nie ma potrzeby sporządzania kolejnych aneksów, jeżeli zamawiający zażyczy sobie wykorzystania nowszej technologii lub zmiany architektury poszczególnych elementów systemu

Skład zespołu

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.
Jak zorganizowane są prace w modelu Scrum?
Scrum, podobnie jak inne techniki zwinne, opiera się na tzw. sprintach, czyli krótkich i zaplanowanych okresach, kiedy realizowane są kolejne etapy zadania. W umowie warto określić maksymalną liczbę sprintów, a także wskazać ich spodziewaną długość (zwykle od tygodnia do miesiąca), przy czym trudno określić dokładnie, jakie funkcjonalności będą wdrażane na konkretnym etapie prac.
Kontrakt może przewidywać limity czasowe na wdrożenie tzw. milestone’ów, czyli ukończenia najważniejszych etapów, ale całość prac zamknięta jest w jedne ramy czasowe, w których wykonawcy poruszają się swobodnie.
Kontrakt powinien uwzględniać kontakt wykonawców z zamawiającym po ukończeniu każdego (lub przynajmniej kluczowych) sprintów. Tylko w ten sposób uda się zachować „zwinność” tworzenia aplikacji, czyli możliwość reagowania na zmiany rynkowe, biznesowe lub konkurencyjne w czasie rzeczywistym.

Proces decyzyjny w procesie tworzenia aplikacji

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.
Jak uregulować nanoszenie poprawek w modelu scrum?
Technika Scrum pozwala analizować zamawiającemu projekt na jego poszczególnych etapach. Dlatego ewentualne błędy można zlokalizować wcześnie i usunąć relatywnie niskim kosztem. Umowy o zwinne tworzenie aplikacji zwykle przewidują usuwanie poprawek niejako „poza” grafikiem prac. W praktyce oznacza to, że wykonawca sam decyduje, kiedy i w jaki sposób usunie błędy, ważne jest jedynie, aby zmieścił się z wykonawstwem poszczególnych faz projektu. Z reguły poprawki nanoszone są bez dodatkowego wynagrodzenia, chyba że są wynikiem zmiany koncepcji po stronie zamawiającego.
Sposobem na to, aby przyspieszyć realizację prac jest wprowadzenie ograniczenia czasowego dla zamawiającego na zgłoszenie poprawek, po upływie którego dany etap uznaje się za zaakceptowany. Ważne, aby nie był to czas zbyt długi.

W jaki sposób określić wynagrodzenie zespołu?

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.
Co dzieje się w przypadku rozwiązania umowy na tworzenie aplikacji w modelu Scrum?
W przypadku programowania metodą iteracyjno-przyrostową problemem dla zamawiającego jest zwykle rozwiązanie umowy z wykonawcą w trakcie, np. z uwagi na nieosiągnięcie założonego rezultatu albo naruszenie tajemnicy przedsiębiorstwa. Zespół, który do tej pory pracował nad aplikacją nadal jest w posiadaniu kodu źródłowego, dokumentacji czy ogólnej koncepcji dotyczącej kolejnych sprintów. Dlatego warto zabezpieczyć swoje interesy poprzez zobowiązanie wykonawcy do:
- odpłatnego przeniesienia praw autorskich majątkowych do stworzonych elementów aplikacji;
- wydania całej dokumentacji projektu;
- oferowania wsparcia technicznego po rozwiązaniu umowy za wynagrodzeniem.
Utrzymując taką „ciągłość” współpracy zamawiający ma pewność, że w razie skorzystania z usług innego software house’u kolejny zespół otrzyma komplet danych umożliwiający dalszą pracę bez zbędnych opóźnień.

Kiedy warto wybrać model współpracy Scrum?

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.
Pytania i odpowiedzi
Z punktu widzenia wykonawcy najlepszym rozwiązaniem będzie transfer praw autorskich majątkowych po zakończeniu współpracy. Z kolei zamawiający powinien dążyć, aby otrzymać prawa autorskie po odebraniu każdego sprintu. W praktyce zwykle stosuje się rozwiązania kompromisowe, które uwzględniają interes obu stron umowy.
Jak najbardziej, testy software’u na różnych etapach jego tworzenia są bardzo istotne w metodykach zwinnych. Z reguły przeprowadza je zamawiający, mając jednocześnie określony czas na zgłoszenie poprawek.
Zaufali nam: