Sprint

Sprint to pojedyncza iteracja w metodykach zwinnych. Sprintem jest ograniczenie czasowe które trwa nie dłużej jednego miesiąca, podczas którego generowany jest gotowy do użycia i potencjalnego wydania przyrost.

Najlepiej jest, gdy długość Sprintów jest taka sama przez cały period trwania prac. Nowy Sprint zaczyna się bezpośrednio po zakończeniu poprzedniego. Sprinty składają się z Planowania Sprintu, Codziennych Scrumów, pracy wytwórczej, Przeglądu Sprintu oraz Retrospektywy Sprintu (K. Schwaber 2016, s. 8).

W Polsce Sprinty trwają najczęściej 14 dni. Brakuje jednak zgodności co do wyboru rodzaju dni (robocze czy kalendarzowe) (M. Ćwiklicki 2010, s. 8).

TL;DR

Sprint to pojedyncza iteracja w metodykach zwinnych, trwająca maksymalnie jeden miesiąc, podczas której generowany jest gotowy do użycia przyrost. Sprint składa się z Planowania Sprintu, Codziennych Scrumów, pracy wytwórczej, Przeglądu Sprintu i Retrospektywy Sprintu. Cel Sprintu określa kierunek prac w danym Sprintu. Planowanie Sprintu to ustalenie pracy do wykonania. Codzienny Scrum to krótkie spotkanie, podczas którego członkowie zespołu synchronizują działania. Przegląd Sprintu to inspekcja Przyrostu i dostosowanie Backlogu Produktu. Retrospektywa Sprintu to spotkanie w celu przeglądu działań i opracowania planu usprawnień.

Założenia Sprintu

W trakcie Sprintu:

• nie są wprowadzane zmiany które stanowią zagrożenie dla spełnienia Celu Sprintu,
• cele jakościowe nie są obniżane,
• zakres prac może być wyświetlony i renegocjowany pomiędzy Właścicielem Produktu i Zespołem Deweloperskim zawsze, gdy odkrywane jest coś nowego.

Jak każdy projekt, Sprint używany jest do osiągnięcia jakiegoś celu.

Z każdym Sprintem jest związany opis tego, co należy wybudować, projekt oraz elastyczny plan wykonania prac które będą wykonywane dla wytworzenia oczekiwanego produktu. Jeśli termin zakończenia Sprintu jest zbyt odległy, może zmienić się definicja tego, co ma zostać utworzone, może zwiększyć się złożoność oraz wzrosnąć ryzyko. Sprinty ograniczają ryzyko do kosztu jednego miesiąca.

Sprint może zostać przerwany przed upływem ograniczenia czasowego przez Właściciela Produktu. Ponieważ tylko on ma prawo przerwać Sprint, aczkolwiek może podjąć taką decyzję pod wpływem opinii interesariuszy, Zespołu Deweloperskiego albo Scrum Mastera.

Sprint może zostać przerwany, jeśli cel sprintu przestanie być aktualnym. Może się to zdarzyć, jeśli firma zmieni swój wektor rozwoju albo gdy zmienią się uwarunkowania rynkowe lub technologiczne.

Warto zaznaczyć, że ze względu na krótki czas trwania Sprintów ich przerywanie rzadko jest sensownym. Kiedy Sprint jest przerywany, "Ukończone" elementy Backlogu Produktu zostaną przeglądane. Jeśli część tej pracy odpowiada do potencjalnego wydania, Właściciel Produktu zazwyczaj ją akceptuje. Wszystkie nieukończone elementy Backlogu Produktu są ponownie szacowane i zwracane do Backlogu Produktu. Praca na nich wykonana szybko się dewaluuje i z tego względu musi być często szacowana powtórnie.

Przerwania Sprintów zużywają zasoby i są traumatyczne dla Zespołu Scrumowego i zachodzą bardzo rzadko (K. Schwaber 2016, s. 8).

Cel Sprintu

Cel Sprintu pokazuje opisowy cel pojedynczego Sprintu, który wyznacza kierunek prac które są przeznaczone do wykonania w Sprincie. Nadrzędny Cel Sprintu pomaga zespołowi utrzymać koncentrację podczas wykonywania prac w Sprincie. Zazwyczaj cel Sprintu jest przedstawiony lapidarnie jako odpowiednio dobrana nazwa sprintu lub zdanie które które podsumowuje zakres prac do wykonania w Sprincie (J. Werewka 2012, s. 28).

Planowanie Sprintu

Podczas Planowania Sprintu zaplanowana jest praca, która będzie wykonana w Sprincie. Plan jest skutkiem wspólnej pracy Zespołu Scrumowego. Planowanie miesięcznego sprintu trwa zwykle około ośmiu godzin. Scrum Master jest odpowiedzialny za planowanie Sprintu i za zrozumienie przez wszystkich członków zespołu celu tego zdarzenia.

Planowanie Sprintu daje odpowiedź na takie pytania:

• Co może zostać dostarczone w ramach Przyrostu będącego rezultatem nadchodzącego Sprintu?
• W jaki sposób, niezbędna do dostarczenia Przyrostu, praca będzie realizowana? (K. Schwaber 2016, s. 9)

Codzienny Scrum

Codzienny Scrum to zdarzenie dla Zespołu Deweloperskiego, jest ono ograniczone czasowo i trwa do piętnastu minut. Podczas takiego spotkania bieżące działania są synchronizowane i powstaje plan na następne dwadzieścia cztery godziny. Jest to osiągane poprzez inspekcję prac, które zostały wykonane od ostatniego Codziennego Scruma i prognozowanie prac, które mogą zostać wykonane przed następnym spotkaniem. Dla redukcji złożoności, takie spotkanie ma stałe wyznaczone miejsce i czas.

Podczas Codziennego Scruma każdy członek Zespołu Deweloperskiego udziela informacji:

• Co zostało zrobione wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
• Co zostanie zrobione dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
• Czy identyfikowane są jakieś przeszkody mogące uniemożliwić Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu? (M.Trocki 2017 s. 252)

Codzienne Scrumy są używane do oceny postępów prac w kierunku Celu Sprintu i trendu względem ukończenia całej pracy z Backlogu Sprintu. Codzienny Scrum zwiększa szanse osiągnięcia Celu Sprintu. Każdego dnia Sprintu Zespół Deweloperski powinien rozumieć w jaki sposób będzie przebiegała dalsza współpraca w zespole żeby przy wykorzystaniu reguł samoorganizacji, osiągnąć Cel Sprintu i zbudować oczekiwany Przyrost.

Zespół Deweloperski lub poszczególni jego członkowie często spotykają się bezpośrednio po Codziennym Scrumie dla szczegółowego przedyskutowania wybranych zagadnień lub dostosować plan prac na dalszą część Sprintu.

Scrum Master jest odpowiedzialny za to, że Zespół Deweloperski spotyka się w ramach Codziennego Scruma, jednak za przebieg tego spotkania jest odpowiedzialny Zespół Deweloperski. Codzienne Scrumy sprzyjają szybkiemu podejmowaniu decyzji, polepszają komunikację, redukują inne spotkania, identyfikują i usuwają przeszkody i podnoszą poziom wiedzy Zespołu Deweloperskiego (K. Schwaber 2016, s. 11).

Przegląd Sprintu

Przegląd Sprintu jest spotkaniem organizowanym na zakończenie Sprintu w celu przeprowadzenia inspekcji Przyrostu i dostosowania Backlogu produktu (opcjonalnie). Przegląd Sprintu trwa nie dłużej niż 4 godziny (M. Trocki 2017, s. 250).

Przegląd Sprintu obejmuje następujące punkty:

• Obecni są Zespół Scrumowy oraz kluczowi interesariusze zaproszeni przez Właściciela Produktu.
• Właściciel Produktu wyjaśnia, które funkcjonalności zostały "Ukończone", a które nie.
• Zespół Deweloperski omawia, co poszło dobrze w trakcie Sprintu, jakie były problemy oraz jak je rozwiązano.
• Zespół Deweloperski prezentuje "Ukończoną" pracę i odpowiada na pytania dotyczące Przyrostu.
• Właściciel Produktu omawia Backlog Produktu w jego aktualnej postaci. Jeśli zachodzi taka potrzeba, przewiduje termin zakończenia prac, biorąc pod uwagę dotychczasowe postępy i tempo.
• Cała grupa wspólnie omawia kolejne kroki. W ten sposób Przegląd Sprintu dostarcza wartościowego wkładu w następujące po nim Planowanie Sprintu.
• Dokonuje się przeglądu tego, jak rynek lub potencjalne zastosowanie produktu mogły się zmienić i co w tej sytuacji jest najbardziej wartościową rzeczą do zrobienia.
• Rewiduje się czas, budżet, potencjalne możliwości i uwarunkowania rynkowe dla kolejnego przewidywanego wydania produktu.

Rezultatem Przeglądu Sprintu jest zaktualizowany Backlog produktu który pokazuje które elementy prawdopodobnie zostaną zaplanowane na następny Sprint. Ponadto Backlog Produktu może zostać zmieniony w taki sposób, aby wykorzystać nadarzające się okazje (K. Schwaber 2016, s. 11).

Retrospektywa Sprintu

Retrospektywa Sprintu to spotkanie służące przeglądowi działań które zostały zrealizowane w Sprincie i opracowaniu planu usprawnień, który zostanie wcielony w życie w następnym Sprincie. Retrospektywa powinna trwać do trzech godzin. Dla krótszych Sprintów zwykle zajmuje mniej czasu (M. Trocki 2017, s. 253).

Retrospektywa Sprintu to okazja dla Zespołu Scrumowego do przeprowadzenia inspekcji swoich działań oraz opracowania planu usprawnień, który będzie wcielony w życie w kolejnym Sprincie.

Retrospektywa Sprintu przeprowadzana jest po Przeglądzie i przed kolejnym Planowaniem Sprintu. Scrum Master zapewnia, że wydarzenie się odbędzie, wszyscy uczestnicy zrozumieją jego cel i uczy ich, jak utrzymać je w ramach czasowych. Scrum Master uczestniczy w Retrospektywie jako zwykły członek zespołu odpowiedzialny za Scruma.

Retrospektywa Sprintu ma na celu:

• sprawdzenie, co działo się w ostatnim Sprincie, odnosząc się do ludzi, relacje, procesy oraz narzędzi,
• zidentyfikowanie i uporządkowanie istotnych elementów, które sprawdziły się w działaniu oraz tych, które kwalifikują się do usprawnienia,
• stworzenie planu wprowadzania w życie usprawnień sposobu wykonywania pracy przez Zespół Scrumowy.

Scrum Master zachęca członków Zespołu Scrumowego do usprawniania w ramach Scruma procesu i praktyk wytwórczych tak, aby w kolejnym Sprincie uczynić wykonywaną pracę bardziej efektywną i dającą więcej radości.

Podczas każdej Retrospektywy Sprintu Zespół Scrumowy planuje, w jaki sposób podniesie jakość produktu dostosowując Definicję Ukończenia do aktualnych potrzeb. Po Retrospektywie Sprintu, Zespół Scrumowy musi zidentyfikować usprawnienia, które zostaną wprowadzone w najbliższym Sprincie.

Zastosowanie tych usprawnień w kolejnych Sprintach jest przejawem adaptacji, która nastąpiła w efekcie autoinspekcji Zespołu Scrumowego. Pomimo tego, że usprawnienia mogą być wprowadzane w dowolnym momencie, Retrospektywa jest formalnym elementem Scruma, który jest całkowicie skoncentrowany na procesie inspekcji i adaptacji (K. Schwaber 2016, s. 12).

Sprint — artykuły polecane

Sprint review — Backlog produktu — Planowanie sprintu — Procesy realizacji wg PMBOK — Getting Things Done — Technika MoSCoW — Planowanie — Metodyka Extreme Programming — Inicjowanie Projektu

Bibliografia

• Ćwiklicki M., Włodarek T. (2010), Metodyka Scrum w Polsce w świetle badań, Nauka i Gospodarka, nr 3
• Strona internetowa: Scrum guides, podręczniki Scrum, Sutherland J., Schwaber K.
• Trocki M. (red.) (2017), Metodyki i standardy zarządzania projektami, Polskie Wydawnictwo Ekonomiczne, Warszawa
• Werewka J., Turek M., Włodarek T. (2012), Systematyczny opis metodyki Scrum dla zespołów projektowcyh, Studia Informatica, nr 1

Autor: Oleksii Donets