Planowanie sprintu: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Infobox update) |
(LinkTitles.) |
||
| Linia 16: | Linia 16: | ||
'''Planowanie sprintu''' jest pierwszym spotkaniem, które przeprowadza zespół [[Metodyka SCRUM|Scrumowy]] na początku każdego [[Sprint|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]].<ref>* Sachdeva S. (2016). ''[https://www.academia.edu/26010951/Scrum_Methodology Scrum Methodology]'', "International Journal Of Engineering And Computer Science", nr 5, s. 16798</ref> 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: | '''Planowanie sprintu''' jest pierwszym spotkaniem, które przeprowadza [[zespół]] [[Metodyka SCRUM|Scrumowy]] na początku każdego [[Sprint|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]].<ref>* Sachdeva S. (2016). ''[https://www.academia.edu/26010951/Scrum_Methodology Scrum Methodology]'', "International Journal Of Engineering And Computer Science", nr 5, s. 16798</ref> 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, | * '''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, | * '''[[Backlog produktu]]''': aktualny [[Backlog]] jest niezbędny, aby wybrać wymagania, które zostaną zaimplementowane podczas sprintu, | ||
<google>t</google> | <google>t</google> | ||
* '''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, | * '''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ć), | * '''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. <ref>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</ref> | * '''[[technologia]]''': czasami technologie, którymi na ten moment dysponuję zespół deweloperski nie są wystarczające, aby móc wykonać pewne zadania. <ref>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</ref> | ||
==Etapy planowania sprintu== | ==Etapy planowania sprintu== | ||
{{#ev:youtube|rpmg9y4-W9w|480|right|Scrum (Sławomir Wawak)|frame}} | {{#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: | 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, | *'''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. | *'''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 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 [[Backlog sprintu|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, | *'''tworzenie [[Backlog sprintu|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 chart|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. | *'''[[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 chart|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. <ref>Schwaber K. (2013). ''[http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-pl.pdf Scrum Guide, Przewodnik do Scrumie: Regułu gry]'', s. 9</ref> | 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. <ref>Schwaber K. (2013). ''[http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-pl.pdf Scrum Guide, Przewodnik do Scrumie: Regułu gry]'', s. 9</ref> | ||
Wersja z 01:42, 21 maj 2020
| 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
