Planowanie sprintu
| Planowanie sprintu |
|---|
| Polecane artykuły |
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
{{#ev:youtube|rpmg9y4-W9w|480|right|Scrum (Sławomir Wawak)|frame}} 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]
Bibliografia
- Pfahl D. (2014). Lecture 11: Agile/Lean Methods, s. 7
- Sachdeva S. (2016). Scrum Methodology, "International Journal Of Engineering And Computer Science", nr 5, s. 16798
- Schwaber K. (2013). Scrum Guide, Przewodnik do Scrumie: Regułu gry, s. 9
Przypisy
- ↑ * Sachdeva S. (2016). Scrum Methodology, "International Journal Of Engineering And Computer Science", nr 5, s. 16798
- ↑ Pfahl D. (2014). Lecture 11: Agile/Lean Methods, s. 7
- ↑ Schwaber K. (2013). Scrum Guide, Przewodnik do Scrumie: Regułu gry, s. 9
Autor: Paweł Ciupek
