Sprint: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (Dodanie TL;DR)
m (cleanup bibliografii i rotten links)
 
(Nie pokazano 11 wersji utworzonych przez 2 użytkowników)
Linia 1: Linia 1:
{{infobox4
'''Sprint''' to pojedyncza iteracja w [[Adaptacyjne zarządzanie projektami|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]].
|list1=
<ul>
<li>[[Sprint review]]</li>
<li>[[Backlog produktu]]</li>
<li>[[Planowanie sprintu]]</li>
<li>[[Procesy realizacji wg PMBOK]]</li>
<li>[[Getting Things Done]]</li>
<li>[[Technika MoSCoW]]</li>
<li>[[Planowanie]]</li>
<li>[[Metodyka Extreme Programming]]</li>
<li>[[Inicjowanie Projektu]]</li>
</ul>
}}
 
 
'''Sprint''' to pojedyncza iteracja w [[Adaptacyjne zarządzanie projektami|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).
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).
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==
==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ń.
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 ==
==Założenia Sprintu==
'''W trakcie Sprintu:'''  
'''W trakcie Sprintu:'''
* nie są wprowadzane zmiany które stanowią [[zagrożenie]] dla spełnienia Celu Sprintu,  
* nie są wprowadzane zmiany które stanowią [[zagrożenie]] dla spełnienia Celu Sprintu,
* [[cele]] jakościowe nie są obniżane,  
* [[cele]] jakościowe nie są obniżane,
* [[zakres]] prac może być wyświetlony i renegocjowany pomiędzy [[Product owner|Właścicielem Produktu]] i Zespołem Deweloperskim zawsze, gdy odkrywane jest coś nowego.  
* [[zakres]] prac może być wyświetlony i renegocjowany pomiędzy [[Product owner|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.
Jak każdy [[projekt]], Sprint używany jest do osiągnięcia jakiegoś celu.
<google>t</google>


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.
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.  
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 [[Product owner|Właściciela Produktu]]. Ponieważ tylko on ma [[prawo]] przerwać Sprint, aczkolwiek może podjąć taką decyzję pod wpływem opinii [[Interesariusze|interesariuszy]], Zespołu Deweloperskiego albo [[Scrum]] Mastera.  
Sprint może zostać przerwany przed upływem ograniczenia czasowego przez [[Product owner|Właściciela Produktu]]. Ponieważ tylko on ma [[prawo]] przerwać Sprint, aczkolwiek może podjąć taką decyzję pod wpływem opinii [[Interesariusze|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.  
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.  
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 [[Backlog produktu|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.  
Kiedy Sprint jest przerywany, "Ukończone" elementy [[Backlog produktu|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).
Przerwania Sprintów zużywają [[zasoby]] i są traumatyczne dla Zespołu Scrumowego i zachodzą bardzo rzadko (K. Schwaber 2016, s. 8).


== Cel Sprintu ==
<google>n</google>
 
==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).
'''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 ==
==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.  
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''':
'''Planowanie Sprintu daje odpowiedź na takie pytania''':
* Co może zostać dostarczone w ramach Przyrostu będącego rezultatem nadchodzącego Sprintu?  
* 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)
* W jaki sposób, niezbędna do dostarczenia Przyrostu, praca będzie realizowana? (K. Schwaber 2016, s. 9)


== Codzienny Scrum ==
==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.  
'''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:'''  
'''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 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?  
* 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)
* 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.  
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.  
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).
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==
'''[[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''' 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:'''  
'''Przegląd Sprintu obejmuje następujące punkty:'''
* Obecni są Zespół Scrumowy oraz kluczowi [[interesariusze]] zaproszeni przez Właściciela Produktu.  
* Obecni są Zespół Scrumowy oraz kluczowi [[interesariusze]] zaproszeni przez Właściciela Produktu.
* [[Product owner|Właściciel Produktu]] wyjaśnia, które funkcjonalności zostały "Ukończone”, a które nie.  
* [[Product owner|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 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.  
* 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.  
* 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.  
* 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.  
* 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.
* 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).
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==
'''[[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 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 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 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:'''  
'''Retrospektywa Sprintu ma na celu:'''
* sprawdzenie, co działo się w ostatnim Sprincie, odnosząc się do ludzi, relacje, procesy oraz narzędzi,  
* 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,  
* 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.  
* 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.  
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.  
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).
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).
{{infobox5|list1={{i5link|a=[[Sprint review]]}} &mdash; {{i5link|a=[[Backlog produktu]]}} &mdash; {{i5link|a=[[Planowanie sprintu]]}} &mdash; {{i5link|a=[[Procesy realizacji wg PMBOK]]}} &mdash; {{i5link|a=[[Getting Things Done]]}} &mdash; {{i5link|a=[[Technika MoSCoW]]}} &mdash; {{i5link|a=[[Planowanie]]}} &mdash; {{i5link|a=[[Metodyka Extreme Programming]]}} &mdash; {{i5link|a=[[Inicjowanie Projektu]]}} }}


==Bibliografia==
==Bibliografia==
* J. Werewka, M. Turek, T. Włodarek, [http://studiainformatica.polsl.pl/index.php/SI/article/view/97/94 Systematyczny opis metodyki Scrum dla zespołów projektowcyh, "Studia Informatica"], 2012 nr 1
<noautolinks>
* K. Schwaber, J. Sutherland (2016), [https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf "The Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game"]
* Ćwiklicki M., Włodarek T. (2010), ''Metodyka Scrum w Polsce w świetle badań'', Nauka i Gospodarka, nr 3
* M. Ćwiklicki, T. Włodarek, [http://www.poddrzewem.pl/do-pobrania/doc_details/38-metodyka-scrum-w-swietle-badan Metodyka Scrum w Polsce w świetle badań, "Nauka i Gospodarka"], 2010, nr 3
* Strona internetowa: ''[https://www.scrumguides.org Scrum guides]'', podręczniki Scrum, Sutherland J., Schwaber K.
* M. Trocki, (2017). Metodyki i standatdy zarządzania projektami, Polskie Wydawnictwo Ekonomiczne S.A. Warszawa
* 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
</noautolinks>


{{a|Oleksii Donets}}
{{a|Oleksii Donets}}
[[Kategoria:Techniki zwinne]]


[[Kategoria:Zarządzanie projektami]]
{{#metamaster:description|Sprint to iteracja w metodykach zwinnych. Trwa około miesiąca i generuje gotowy przyrost projektu. Składa się z planowania, spotkań, pracy, przeglądu i retrospektywy. W Polsce trwają zazwyczaj 14 dni.}}

Aktualna wersja na dzień 22:22, 7 gru 2023

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).


Sprintartykuły polecane
Sprint reviewBacklog produktuPlanowanie sprintuProcesy realizacji wg PMBOKGetting Things DoneTechnika MoSCoWPlanowanieMetodyka Extreme ProgrammingInicjowanie 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