Projekt Scrum rozpoczyna się od wizji systemu, który ma powstać. Wizja ta może być na początku niejasna, jednak będzie się roz jaśniać w miarę posuwania się projektu do przodu. Właściciel produktu jest odpowiedzialny przed osobami pokrywającymi koszty
131 SCRUM – zarządzanie projektami w przedsiębiorstwie informatycznym opartym o zdalny model pracy
projektu za dostarczenie wizji w sposób, który maksymalizuje ich ZI. Właściciel produk-tu ustala plan działania tak, by zawierał zaległości produktowe. Te ostatnie stanowią listę funkcjonalnych i niefunkcjonalnych wymagań, które, kiedy zamieni się je w funkcjonal-ność, będą reprezentować tę wizję. W zaległościach produktowych ustala się priorytety tak, by elementy tej listy, które wygenerują pewną wartość, zawsze znajdowały się na począt-ku listy priorytetów. Dokonuje się także propozycji podziału tych elementów na poszcze-gólne wydania. Nadanie priorytetów elementom zaległości produktowych stanowi punkt począt kowy, a zawartość, priorytety oraz przydzielanie zaległości produktowych do po-szczególnych wydań zazwyczaj zmieniają moment rozpoczęcia projektu. Zmiany w zale-głościach produktowych odzwierciedlają zmiany wymagań biznesowych oraz zmiany tem-pa, w jakim zespół zamienia zaległości produktowe w funkcjonalność [Kaczor 2014, s. 7].
Cała praca jest wykonywana w sprintach. Każdy sprint jest iteracją 30 kolejnych dni kalenda rzowych. Rozpoczyna się od spotkania, na którym właściciel produktu oraz zespół zbierają się w celu omówienia przebiegu wspólnej pracy w czasie kolejnego sprintu. Do-konując wyboru zaległości produktowych o najwyższym priorytecie, właściciel produk-tu przekazuje zespołowi, co należy zrobić, a zespół informuje właściciela produkproduk-tu, jaka część z pożądanej części funkcjonalności może zostać zrealizowana w kolejnym sprincie. Spotkania planujące sprinty nie mogą trwać dłużej niż osiem godzin, czyli są ograniczone czasowo; chodzi o uniknięcie zbyt obszernych notatek na temat tego, co jest możliwe do wykonania. Celem jest zabranie się do pracy, a nie myślenie o pracy [Wolf 2014, s. 75].
Spotkania planujące sprint składają się z dwóch części. W ciągu pierwszych czterech godzin właściciel produktu prezentuje zespołowi najwyższe priorytety zaległości produk-towych. Następnie zespół zadaje pytania dotyczące zawartości, celu, znaczenia i intencji za-ległości produktowych. Kiedy zespół dowie się już wystarczająco dużo, jednak przed upły-wem pierwszych czterech godzin, wybiera taką część zaległości produktowych, jaka według członków zespołu może zostać zamieniona w możliwy do wydania kompletny przyrost funkcjonalności produktu do końca bieżącego sprintu. Zespół zobowiązuje się wobec właś-ciciela produktu, że zrobi wszystko, co jest w jego mocy. Podczas kolejnych czterech godzin spotkania planującego sprint zespół rozplanowuje szczegóły działania. Ponieważ zespół jest odpowiedzialny za zarządzanie swoją własną pracą, potrzebuje wstępnego planu w celu rozpoczęcia sprintu. Zadania, które składają się na ten plan, są umieszczane w zale głościach sprintu; zadania znajdujące się w zaległościach sprintu ujawniają się w trakcie przebiegu sprintu. Na początku drugiego czterogodzinnego odcinka spotkania planującego sprint ze-gar rozpoczyna odliczanie kolejnego 30-dniowego odcinka sprintu [Wolf 2014, s. 76].
Każdego dnia zespół zbiera się na 15-minutowe spotkanie nazywane codziennym Scrum, podczas którego każdy członek zespołu odpowiada na trzy pytania: Co zrobiłeś w projek cie od ostatniego spotkania? Co planujesz zrobić w projekcie między obecną
Michał Trziszka
chwilą a kolejnym spotkaniem? Jakie przeszkody stoją na drodze realizacji założeń dane-go sprintu oraz tedane-go pro jektu? Celem tedane-go spotkania jest codzienne zsynchronizowanie pracy członków całego zespołu i wyznaczenie harmonogramu spotkań, które są po-trzebne zespołowi do kontynuacji prac nad projektem. Pod koniec sprintu przeprowa-dzane jest spotkanie mające na celu dokonanie przeglądu sprintu. Na spotkaniu, trwaja-cym do 4 godzin, zespół prezentuje swoje osiągnięcia ze sprintu właścicielowi produktu oraz innym udziałowcom, którzy chcą uczestniczyć w spotkaniu. Ma ono charakter nie-formalny, jego celem jest zebranie ludzi, by pomóc im we wspólnym określaniu tego, co zespół powinien robić w dalszej kolejności. Po przeglądzie sprintu i przed rozpoczę-ciem kolejnego spotkania planującego sprint Scrum Master przeprowadza z zespołem retrospektywne spotkania dotyczące sprintów. Na tym ograniczonym do trzech godzin spotkaniu Scrum Master zachęca zespół do skorygowania (w ramach struktury procesu Serum oraz zasad w nim stosowanych) procesu tworzenia, tak by jego kolejny sprint był bardziej efek tywny i przyjemny. Łącznie spotkanie planujące sprint, codzienny Scrum, przegląd sprintu oraz retrospekcja sprintu stanowią empiryczną inspekcję oraz praktykę adaptacyjną Scrum [Wolf 2014, s. 76].
Scrum wprowadza kilka nowych artefaktów. Są one wykorzystywane w całym procesie Scrum i zostały opisane w kolejnych sekcjach. Wymagania związane z systemem lub produk-tem tworzonym poprzez projekt(y) znajdują się na liście zaległości projektowych. Właściciel produktu jest odpowiedzialny za zawartość, ustawianie priorytetów i dostępność zaległości produktowych. Zaległości produktowe nie są nigdy kompletne, a te używane w planie pro-jektu stanowią jedynie początkowe oszacowanie wymagań. Zaległości produktowe rozwi-jają się w miarę rozwoju produktu i środowiska, w którym będzie on następnie używany. Zaległości produktowe są dynamiczne, ciągłym zmianom podlega zarządzanie pod kątem identyfikacji odpowiednich potrzeb produktu, jego konkurencyjności i użyteczności.
Zaległości sprintu definiują pracę lub zadania składające się z elementów zaległości produktowych wybranych do danego sprintu i przeznaczonych przez zespół do zamia-ny w przyrost potencjal nej funkcjonalności nadającej się do wydania. Zespół opracowu-je początkową listę tych zadań w drugiej części spotkania planującego sprint. Zadania powinny zostać podzielone tak, by na ukoń czenie każdego z nich było przeznaczonych od 4 do 16 godzin. Zadania o długości wykraczającej poza ten przedział są traktowane jedynie jako elementy zastępujące zadania, które nie zostały jeszcze odpowiednio zde-finiowane. Jedynie zespół może zmienić zaległości sprintu. Zaległości sprintu dobitnie pokazują rzeczywisty obraz pracy, którą zespół zamierza wykonać podczas sprintu. Po zdefiniowaniu zadania szacun kowa liczba godzin pozostała do ukończenia zadania jest umieszczana na przecięciu zadania i danego dnia sprintu przez osobę pracującą nad tym zadaniem [Chrapko 2015, s. 129].
133 SCRUM – zarządzanie projektami w przedsiębiorstwie informatycznym opartym o zdalny model pracy
Scrum wymaga, aby zespoły tworzyły przyrosty funkcjonalności produktu przy każ-dym sprincie. Przyrost ten musi być możliwy do wydania, ponieważ właściciel produktu może natychmiast zde cydować o implementacji tej funkcjonalności. Konieczne jest więc, aby przyrost składał się ze szcze gółowo przetestowanego, dobrze skonstruowanego i dobrze napisanego kodu, który został zbu dowany w wykonywalny program. Potrzeb-na jest także dokumentacja przezPotrzeb-naczoPotrzeb-na dla użytkownika, albo w plikach pomocy, albo w postaci podręcznika. Tak właśnie można zdefiniować ukończony przyrost. Jeśli przyrost produktu, który jest tworzony podczas sprintu, ma służyć bardziej szczegółowym celom, organizacja tworząca ten produkt zazwyczaj definiuje dodatkowe wymagania jako stan-dardy lub konwencje. Część procesu akceptacji stanowi sprawdzenie, czy wymagania pro-duktowe są odpowiednie i kompletne, a także czy wymagania te mogą być bezpośrednio wprowadzone do produktu. Aby każdy przyrost krytycznych dla życia produktów był po-tencjalnie możliwy do wydania, te dodatkowe aspekty produktu również muszą być opra-cowane w taki sposób, by każdy przyrost produktu był potencjalnie gotowy do akceptacji przez dane przedsiębiorstwo [Ćwiklicki, Jabłoński, Włodarek 2010, s. 88].