Wydarzenia Scrumowe #1 Sprint

25 maja 2020 • 4 min to read

To pierwszy artykuł w serii o Spotkaniach Scrumowych, który pomoże Ci zrozumieć czym jest Sprint i jaką pełni rolę w Scrumie.

Spis treści

*Ten artykuł był zaktualizowany zgodnie z Przewodnikiem po Scrumie 2020.

Wstęp

Scrum zawiera 5 spotkań (wymienionych poniżej), które są określone czasowo i mają na celu zminimalizować potrzebę dodatkowych spotkań. Tworzą one pewną stałość, nawyk, który zwiększa efektywność pracy.

• Sprint
• Planowanie Sprintu- Sprint Planning
• Daily Scrum
• Sprint Review
• Retrospektywa Sprintu

Kolejne 5 artykułów będzie opisywać każde z tych 5 spotkań. Spotkania Scrumowe nadają strukturę każdej iteracji. W ten sposób tworzymy bezpieczne środowisko pracy i stymulujemy kreatywność w zespole.

Sprint - Definicja i Długość

Powołując się na Przewodnik po Scrumie 2020:

Sprinty są pulsem Scruma. W Sprintach pomysły są przekształcane w wartość. Są to wydarzenia o ustalonej długości, trwają maksymalnie miesiąc dla uzyskania regularności. Nowy Sprint rozpoczyna się natychmiast po zakończeniu poprzedniego.

Najlepszym sposobem na zrozumienie czym jest Sprint w Scrumie jest porównanie go do sprintu w sporcie. Jak wszyscy dobrze wiemy, sprint to krótkodystansowy bieg, skupiony na szybkim osiągnięciu celu.

Sprint w Scrumie działa dokładnie w ten sam sposób. Jest to krótki okres czasu (maksymalnie jeden miesiąc) skupiony na osiągnięciu Celu Sprintu, który wyznaczyliśmy sobie na początku planowania Sprintu.

Ważne, aby Sprinty były wystarczająco krótkie, aby móc dostosować się do zmieniającego się świata i uniknąć ryzyka związanego ze zbyt dużą złożonością.

Wyobraź sobie, że biegniesz krótkodystansowo - widzisz metę i to motywuje Cię do tego, aby biec szybciej. Tymczasem bieg długodystansowy wymaga dużo więcej planowania. Nie chcemy zużywać całej energii na początku, aby móc mieć jej wystarczająco do końca. Łatwo popełnić ten błąd - biec za szybko kiedy zaczynamy i być za bardzo zmęczonym na końcu. Czasami podczas tego planowania możemy nie wziąć pod uwagę ważnego czynnika, który zmieni całkowicie nasz wynik końcowy.

Podczas tworzenia produktów, lepiej jest działać w krótszym okresie czasu. W ten sposób unikamy ryzyka związanego z nagłymi zmianami, których nie wzięliśmy pod uwagę. Dlatego Sprint w Scrumie jest wystarczająco krótki, aby widzieć horyzont/ Cel Sprintu, ale wystarczająco długi, aby stworzyć użyteczny increment.

Iteracja

W Scrumie promuje się iteracyjny sposób pracy, co oznacza, że wszystkie aktywności są w cyklach. Podczas Sprintu odkrywamy co działa, co powinno się zmienić i zmieniamy to. Kolejny Sprint zaczyna się od razu po poprzednim i daje to możliwość używania wiedzy, którą zdobyliśmy w poprzednim Sprincie.

Główną wartością krótkich cyklów jest możliwość wczesnej informacji zwrotnej od interesariuszy oraz możliwość dostosowania do rynku.

Rama

Scrum to uproszczone ramy postępowania. W związku z czym wyobrażam sobie Sprint jako ramę, która mieści wszystkie pozostałe elementy. Podczas Sprintu, Zespół Scrumowy jest skupiony na obecnej iteracji i wszystkie akcje są związane z obecnym Sprintem:

• Sprint Planning - czas do zaplanowania Sprintu
• Sprint Goal - co chcemy osiągnąć podczas Sprintu
• Sprint Backlog - elementy backlogu zaplanowane na Sprint
• Daily Scrum - planowanie codzienne w Sprincie
• Sprint Review - podsumowanie tego co było zrobione w Sprincie
• Sprint Retrospective - sprawdzenie co działało i co powinno być usprawnione bazując na ostatnim Sprincie.

Jak widzicie, wszystkie akcje są skupione na obecnej iteracji czyli - Sprincie.

Oczywiście Produkt Owner potrzebuje mieć długodystansową wizję związaną z tworzeniem produktu oraz kolejnymi Sprintami. Dlatego też tworzy Product Backlog, który zawiera wszystkie elementy - także te, które są związane z przyszłymi zmianami w produkcie. Jego bądź jej rolą jest także utworzenie Celu Produktu, aby wskazać każdemu kierunek produktu.

Ważne, aby pamiętać, że Product Backlog jest elastyczny i może być zmieniany, poprawiany, a Sprint Backlog jest bardziej stały. Oczywiście może być wyklarowany, zmieniony, ale wymaga to zgody pomiędzy Product Ownerem i Deweloperami.

Zmiany, które mogłyby wpłynąć negatywnie na Cel Sprintu, bądź na jakość produktu, nie są akceptowalne w trakcie Sprintu.

Przerwanie Sprintu

W Scrumie istnieje możliwość przerwania Sprintu, jeżeli Cel Sprintu jest nieaktualny np. z powodu zmiany technologii, albo innej sytuacji na rynku. Szczerze mówiąc jest to raczej rzadka sytuacja, ale może się wydarzyć i może być zainicjowana tylko ze strony Product Ownera- jedynej osoby, która ma prawo do przerwania Sprintu.

Z technicznego punktu widzenia, kiedy Sprint jest przerwany, wszystko co jest “Zrobione” musi zostać sprawdzone. Jeżeli są jakieś potencjalnie gotowe do wprowadzenia elementy, to muszą być zatwierdzone przez Product Ownera. Sposób działania wobec nieskończonej pracy, jest taki sam jak w przypadku normalnego Sprintu tzn. Wracają do Product Backlogu i Deweloperzy je ponownie szacują.

Podsumowanie

Reasumując:

• Sprint to spotkanie w Scrumie, które może trwać maksymalnie 1 miesiąc.
• Sprint pomaga Deweloperom skupić się na pracy, która ma być zrobiona i na osiągnięciu wyznaczonego Celu Sprintu. Jest to także rama dla wszystkich innych spotkań, wydarzeń i definicji w Scrumie.
• Przerwanie Sprintu jest możliwe, ale nie jest częste i może się wydarzyć tylko z inicjatywy Właściciela Produktu.

Mam nadzieję, że ten artykuł pomógł Ci zrozumieć podstawy związane ze Sprintem. W kolejnych postach będę kontynuowała opisywanie pozostałych spotkań Scrumowych.