Planowanie sprintu: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
Nie podano opisu zmian
m (cleanup bibliografii i rotten links)
Linia 69: Linia 69:
==Bibliografia==
==Bibliografia==
<noautolinks>
<noautolinks>
* Pfahl D. (2014). ''[https://courses.cs.ut.ee/MTAT.03.094/2015_fall/uploads/Main/SE2014-handout11.pdf Lecture 11: Agile/Lean Methods]'', s. 7
* Sachdeva S. (2016), ''Scrum Methodology'', International Journal Of Engineering And Computer Science, nr 5
* Sachdeva S. (2016), ''Scrum Methodology'', International Journal Of Engineering And Computer Science, nr 5
* Schwaber K. (2013), ''Scrum Guide, Przewodnik do Scrumie: Reguły gry''
* Schwaber K. (2013), ''Scrum Guide, Przewodnik do Scrumie: Reguły gry''
* ŻŻXXXX Pfahl D. (2014), ''[https://courses.cs.ut.ee/MTAT.03.094/2015_fall/uploads/Main/SE2014-handout11.pdf Lecture 11: Agile/Lean Methods]'', s. 7
</noautolinks>
</noautolinks>



Wersja z 21:09, 7 gru 2023

Planowanie sprintu jest pierwszym spotkaniem, które przeprowadza zespół Scrumowy na początku każdego sprintu. Podczas spotkania planowane jest to jak powinien wyglądać kolejny inkrement rozwijanego produktu. W planowaniu sprintu udział biorą Product owner, Zespół deweloperski oraz Scrum master.[1] Jeżeli zespół deweloperów uważa, że brak im wystarczającej wiedzy technicznej, aby poprawnie zaplanować pracę, może zaprosić na spotkanie ekspertów spoza zespołu. Aby planowanie sprintu było efektywne, przed spotkaniem niezbędne jest przygotowanie poniższych informacji:

  • pojemność zespołu deweloperskiego: jest to informacja o tym, jakimi zasobami będzie dysponował zespół deweloperski podczas bieżącego sprintu. Zazwyczaj podaje się ją w godzinach na sprint,
  • Backlog produktu: aktualny Backlog jest niezbędny, aby wybrać wymagania, które zostaną zaimplementowane podczas sprintu,
  • aktualna sytuacja biznesowa: to jak wygląda aktualna sytuacja między firmą a klientem (np. nagła zmiana wymagań) może wpływać na zmianę priorytetów działań dla zespołu,
  • aktualne informacje o rozwijanym produkcie: informacja o tym, na jakim stopniu rozwoju jest w danym momencie produkt może okazać się kluczowa. Podjęcie decyzji jakie wymagania należy zaimplementować w danym momencie, aby dalej rozwijać produkt, jest całkowicie uzależnione od aktualnego statusu rozwoju produktu (np. inny zespół nie zdążył wykonać przydzielonych mu zadań, co sprawia, że produkt nie ma jeszcze pewnych funkcjonalności, które miały być rozwijane w ramach kolejnych działań zespołu, więc nie można się ich jeszcze podejmować),
  • technologia: czasami technologie, którymi na ten moment dysponuję zespół deweloperski nie są wystarczające, aby móc wykonać pewne zadania[2]

Etapy planowania sprintu

Posiadając powyższe informacje można przystąpić do planowania sprintu. Składa się ono z poniższych czynności:

  • analiza Backlogu produktu: podczas analizy zostaną wybrane te wymagania, których implementacja jest w danym momencie najkorzystniejsza dla produktu, a wymagania te połączone w całość pozwolą na stworzenie nowej, pełnej funkcjonalności dla produktu,
  • wybór celu sprintu: łącząc wymagania wybrane z Backlogu w całość można określić jaki jest pełny cel prac zespołu deweloperskiego w danym sprincie, z wykonania którego będą rozliczani deweloperzy. Jawne określenie celu pomaga lepiej zrozumieć połączenie pomiędzy poszczególnymi pracami, które muszą zostać wykonane w danym sprincie.
  • tworzenie projektu prac: po wybraniu celu sprintu należy zaplanować jak powinien wyglądać kolejny działający inkrement produktu, który będzie posiadał funkcjonalność zawartą w celu sprintu,
  • tworzenie Backlogu sprintu: pełny projekt prac, które będzie wykonywać zespół należy podzielić na mniejsze zadania, do których będą przydzielani poszczególni członkowie zespołu,
  • estymacja zadań: po stworzeniu Backlogu sprintu ostatnim krokiem do wykonania jest estymacja nakładów czasowych potrzebnych do wykonania każdego z zadań. Pozwoli to stwierdzić czy planowane prace uda się zakończyć w sprincie oraz umożliwi śledzenie stopnia wykonania późniejszych prac (np. używając Burndown charta). Jedną z metod estymacji czasu wykonania zadań jest tak zwany Planning poker. Jeżeli zespół deweloperski stwierdzi, że wybrany zakres prac jest za mały bądź za duży, w stosunku do możliwości przerobowych zespołu, to ma on prawo renegocjować wybór realizowanych wymagań z Backlogu produktu.

Na koniec warto również zaznaczyć, iż jeśli charakter prac zaplanowanych podczas planowania sprintu okaże się inny niż pierwotnie zakładano, zespół deweloperski ma prawo renegocjować z właścicielem produktu zakres Backlogu sprintu w trakcie trwania tego sprintu[3]

Planowanie sprintu - etapy i techniki

Analiza backlogu produktu

Backlog produktu to lista wszystkich zadań, które muszą zostać wykonane, aby osiągnąć zamierzony cel projektu. Jest on ważny dla planowania sprintu, ponieważ zawiera wszystkie wymagania klienta, a także priorytetyzuje je w celu efektywnego zarządzania procesem tworzenia produktu. Analiza backlogu produktu pozwala zrozumieć, jakie zadania są niezbędne do zrealizowania w danym sprincie.

Proces analizy backlogu produktu polega na dokładnym przejrzeniu wszystkich zadań znajdujących się na liście. W tym etapie należy zidentyfikować zadania o najwyższym priorytecie oraz te, które są niezbędne do zrealizowania w danym sprincie. Analiza backlogu produktu wymaga współpracy zespołu projektowego oraz klienta, aby upewnić się, że wszystkie wymagania są zrozumiane i uwzględnione.

Wybór celu sprintu

Określenie celu sprintu jest ważne, ponieważ pozwala zespołowi projektowemu skoncentrować się na konkretnym zadaniu lub funkcjonalności do zrealizowania w danym sprincie. Cel sprintu jest kluczowym elementem planowania, ponieważ definiuje, co ma zostać osiągnięte w określonym czasie.

Proces wyboru celu sprintu polega na omówieniu zespołu projektowego i klientem, jakie zadania lub funkcjonalności mają zostać zrealizowane w danym sprincie. W tym etapie należy uwzględnić priorytetyzację zadań oraz możliwości zespołu projektowego. Wybór celu sprintu wymaga również określenia oczekiwanych rezultatów i terminu zakończenia sprincie.

Tworzenie projektu prac

Projekt prac to plan, który zawiera wszystkie zadania, które muszą zostać wykonane w danym sprincie wraz z przypisanymi zasobami, terminami i priorytetami. Jest on potrzebny w planowaniu sprintu, ponieważ pozwala na efektywne zarządzanie zadaniami oraz kontrolę postępów w realizacji projektu.

Proces tworzenia projektu prac rozpoczyna się od analizy backlogu produktu i wyboru celu sprintu. Następnie zadania są przypisywane do odpowiednich członków zespołu projektowego, określane są terminy realizacji oraz priorytety. Projekt prac powinien być klarowny i zrozumiały dla każdego członka zespołu, aby wszyscy mieli jasność co do swoich zadań i ich terminów.

Tworzenie backlogu sprintu

Backlog sprintu to lista zadań, które zostaną zrealizowane w danym sprincie. Jest on ważny dla planowania, ponieważ zawiera szczegółowe informacje na temat każdego zadania, takie jak opis, priorytet, estymacja czasu wykonania, odpowiedzialny członek zespołu itp. Backlog sprintu pozwala na śledzenie postępów w realizacji zadań oraz efektywne zarządzanie nimi.

Proces tworzenia backlogu sprintu rozpoczyna się od analizy backlogu produktu i wyboru celu sprintu. Następnie dla każdego zadania określane są szczegóły, takie jak opis, priorytet, estymacja czasu wykonania itp. Tworzenie backlogu sprintu wymaga współpracy zespołu projektowego oraz uwzględnienia priorytetów i możliwości zespołu.

Estymacja zadań

Estymacja czasu wykonania zadań jest istotna w planowaniu sprintu, ponieważ pozwala na określenie, ile czasu będzie potrzebne do realizacji każdego zadania. Jest to ważne dla zaplanowania sprincie i ustalenia, czy wszystkie zadania zmieszczą się w dostępny czas. Estymacja czasu wykonania zadań pozwala również na efektywne zarządzanie zasobami i kontrolę postępów.

Metoda estymacji zadań - Planning poker - polega na tym, że każdy członek zespołu projektowego otrzymuje zestaw kart, na których są przedstawione różne jednostki czasu (np. godziny, dni). Następnie dla każdego zadania członkowie zespołu wybierają kartę, która ich zdaniem najlepiej odzwierciedla czas wykonania zadania. Po wybraniu karty, wszyscy jednocześnie odkrywają swoje wybory i jeśli istnieje znaczna różnica, członkowie zespołu mają okazję uzasadnić swoje wybory. Proces ten jest powtarzany, aż do uzyskania porozumienia w estymacji czasu wykonania zadania.

Rola Scrum Mastera

Scrum Master pełni kluczową rolę w planowaniu sprintu. Jego zadaniem jest zapewnienie, że proces planowania przebiega sprawnie i efektywnie. Scrum Master jest odpowiedzialny za stworzenie odpowiedniego środowiska i atmosfery pracy, w której cały zespół może skupić się na planowaniu i ustaleniu celów sprintu. Ponadto, Scrum Master pełni rolę lidera, który pomaga zespołowi w identyfikacji i rozwiązaniu problemów oraz eliminuje wszelkie przeszkody, które mogą utrudniać planowanie i realizację sprintu.

W kontekście planowania sprintu Scrum Master ma kilka kluczowych zadań. Przede wszystkim, jest odpowiedzialny za koordynację procesu planowania, zapewnienie odpowiednich narzędzi i dokumentacji oraz umożliwienie efektywnej komunikacji między członkami zespołu. Scrum Master również wspiera zespół w estymacji zadań, zapewniając, że proces jest uczciwy i oparty na wspólnej wiedzy i doświadczeniu. Ponadto, Scrum Master dba o to, aby uwzględnione zostały ryzyka i przeszkody, oraz pomaga w opracowaniu strategii ich rozwiązania. Jego rolą jest również zapewnienie przejrzystości procesu planowania i dostarczenie informacji na temat postępu prac oraz identyfikowanej wartości dla klientów i użytkowników.

Refleksja i ocena po zakończeniu sprintu

Czas po zakończeniu sprintu jest ważnym momentem, który należy przeznaczyć na refleksję i ocenę. Daje to zespołowi możliwość spojrzenia wstecz, identyfikacji mocnych stron, słabości i obszarów, w których można się poprawić. Refleksja pozwala na lepsze zrozumienie przyczyn sukcesów i niepowodzeń, co z kolei prowadzi do lepszych decyzji i działań w przyszłości.

Ocena po zakończeniu sprintu ma kluczowe znaczenie dla ciągłego doskonalenia pracy zespołu deweloperskiego. Pozwala na identyfikację aspektów, które należy poprawić, oraz na wyciągnięcie wniosków, które mogą wpłynąć na przyszłe planowanie sprintu. Jest to również okazja do wspólnego podsumowania osiągnięć i docenienia wysiłku całego zespołu.

Proces refleksji i oceny po zakończeniu sprintu powinien być przeprowadzany w sposób systematyczny i zorganizowany. Istnieje kilka kluczowych kroków, które można podjąć, aby zapewnić skuteczność tego procesu.

Pierwszym krokiem jest zebranie informacji zwrotnych od członków zespołu dotyczących przebiegu sprintu. Może to obejmować obserwacje, wnioski i sugestie dotyczące działań, które były skuteczne, oraz tych, które mogłyby zostać poprawione. Ważne jest, aby zapewnić otwarte i konstruktywne dyskusje, w których każdy członek zespołu może się wypowiedzieć.

Następnie, na podstawie zebranych informacji, można przeprowadzić analizę, aby zidentyfikować główne wnioski i obszary, które wymagają poprawy. W oparciu o te wnioski można opracować plan działań, które zostaną podjęte w celu poprawy jakości pracy zespołu w przyszłych sprintach.

Warto również zwrócić uwagę na cele i wyniki osiągnięte podczas sprintu. Porównanie rzeczywistych wyników z oczekiwaniami pozwoli na ocenę skuteczności działań podjętych przez zespół i dostarczy wskazówek do dalszego doskonalenia pracy.


Planowanie sprintuartykuły polecane
Backlog sprintuSprintSprint reviewPlanowanie ścieżki krytycznejGetting Things DonePlanowanieZarządzanie zmianą w projekcieVelocityOszczędność w projekcie

Przypisy

  1. Sachdeva S. (2016). s. 16798
  2. Pfahl D. (2014)., s. 7
  3. Schwaber K. (2013). , s. 9

Bibliografia

  • Sachdeva S. (2016), Scrum Methodology, International Journal Of Engineering And Computer Science, nr 5
  • Schwaber K. (2013), Scrum Guide, Przewodnik do Scrumie: Reguły gry
  • ŻŻXXXX Pfahl D. (2014), Lecture 11: Agile/Lean Methods, s. 7


Autor: Paweł Ciupek