Backlog sprintu: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (cleanup bibliografii i rotten links) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 10 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''[[Backlog]] sprintu''' - w [[Metodyka SCRUM|metodyce SCRUM]], jest to zbiór zadań wybranych z [[backlog produktu|backlogu produktu]], który jest realizowany w danym [[sprint|sprincie]]. Ustalany jest on przed rozpoczęciem sprintu, podczas jego [[planowanie sprintu|planowania]]. | |||
W przeciwieństwie do [[backlog produktu]], który składa się zazwyczaj z historyjek użytkownika, backlog sprintu zawiera listę konkretnych zadań do wykonania przez [[zespół deweloperski]] w trakcie sprintu<ref>Mastelarz M. (2015), s. 82 </ref>. | |||
</ | |||
Wszystkie zadania w backlogu bieżącego sprintu powinny zawierać następujące [[informacje]]<ref>Sachdeva S. (2016). s. 16798</ref>: | |||
Wszystkie zadania w backlogu bieżącego sprintu powinny zawierać następujące [[informacje]]<ref>Sachdeva S. (2016). | |||
* opis danego zadania, w tym również [[informacja]] o historyjce użytkownika, z której się wywodzi, | * opis danego zadania, w tym również [[informacja]] o historyjce użytkownika, z której się wywodzi, | ||
* szacowany czas wykonania zadania, | * szacowany czas wykonania zadania, | ||
* członka zespołu odpowiedzialnego za wykonanie zadania (jeżeli jest ono już realizowane), | * członka zespołu odpowiedzialnego za wykonanie zadania (jeżeli jest ono już realizowane), | ||
* status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane). | * status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane). | ||
==TL;DR== | ==TL;DR== | ||
Backlog sprintu to lista zadań wybranych z backlogu produktu, które są realizowane w trakcie sprintu w metodyce SCRUM. Etapy tworzenia backlogu sprintu obejmują wybór historyjek użytkownika, podział na zadania i szacowanie czasu ich wykonania. Zmiany w backlogu mogą być wprowadzane w trakcie sprintu przez zespół deweloperski. | Backlog sprintu to lista zadań wybranych z backlogu produktu, które są realizowane w trakcie sprintu w metodyce SCRUM. Etapy tworzenia backlogu sprintu obejmują wybór historyjek użytkownika, podział na zadania i szacowanie czasu ich wykonania. Zmiany w backlogu mogą być wprowadzane w trakcie sprintu przez zespół deweloperski. | ||
==Etapy tworzenia Backlogu sprintu== | ==Etapy tworzenia Backlogu sprintu==Backlog Sprintu jest wynikiem planowania sprintu, w którym [[udział]] biorą [[Zespół deweloperski]], [[Product owner]] i [[Scrum master]]<ref>Sachdeva S. (2016)., s. 16798</ref>. Tworzony jest w następujących krokach<ref>Chrapko M. 2015, s. 252</ref>===='''1. Wybór historyjek użytkownika z backlogu produktu'''==== | ||
Backlog Sprintu jest wynikiem planowania sprintu, w którym [[udział]] biorą [[Zespół deweloperski]], [[Product owner]] i [[Scrum master]]<ref>Sachdeva S. (2016). | |||
===='''1. Wybór historyjek użytkownika z backlogu produktu'''==== | |||
[[Zespół]] ustala, które historyjki zawarte w backlogu produktu zostaną zrealizowane w trakcie najbliższego sprintu. Przy wyborze brane są pod uwagę następujące zagadnienia: | [[Zespół]] ustala, które historyjki zawarte w backlogu produktu zostaną zrealizowane w trakcie najbliższego sprintu. Przy wyborze brane są pod uwagę następujące zagadnienia: | ||
* cel sprintu, który został ustalony przez zespół na początku planowania, | * cel sprintu, który został ustalony przez zespół na początku planowania, | ||
* priorytety historyjek (ustalone w trakcie tworzenia backlogu produktu) | * priorytety historyjek (ustalone w trakcie tworzenia backlogu produktu) - zazwyczaj zespół stara się zrealizować w pierwszej kolejności historyjki z najwyższym priorytetem, | ||
* szybkość działania zespołu | * szybkość działania zespołu - w jakim tempie pracują członkowie zespołu, a więc ile pracy będą w stanie wykonać w czasie trwania sprintu. Tutaj możliwe są dwie metody szacowania: | ||
: - na podstawie prędkości realizowania zadań w poprzednim sprincie, | : - na podstawie prędkości realizowania zadań w poprzednim sprincie, | ||
: - na podstawie dostępności zespołu, a więc informacji o tym, ile czasu każdy członek zespołu będzie pracował w danym projekcie. | : - na podstawie dostępności zespołu, a więc informacji o tym, ile czasu każdy członek zespołu będzie pracował w danym projekcie. | ||
<google>n</google> | |||
===='''2. Podział na zadania'''==== | ===='''2. Podział na zadania'''==== | ||
Każdą historyjkę, która została wybrana do sprintu, zespół dzieli na pojedyncze zadania do wykonania. Zadania powinny mieć następujące cechy: | Każdą historyjkę, która została wybrana do sprintu, zespół dzieli na pojedyncze zadania do wykonania. Zadania powinny mieć następujące cechy: | ||
* być możliwe do wykonania przez jedną osobę, | * być możliwe do wykonania przez jedną osobę, | ||
* czas wykonania jednego zadania nie powinien przekraczać 8 godzin, | * czas wykonania jednego zadania nie powinien przekraczać 8 godzin, | ||
* wykonanie wszystkich zadań dla danej historyjki skutkuje automatycznym " | * wykonanie wszystkich zadań dla danej historyjki skutkuje automatycznym "zamknięciem" historyjki, | ||
* mieć rzeczywistą [[wartość]] dla realizacji projektu | * mieć rzeczywistą [[wartość]] dla realizacji projektu - do backlog sprintu powinny trafiać tylko zadania mające realny wpływ na [[projekt]]; nie dodajemy więc do backlogu zadań związanych np. z rekrutacją, czy spotkaniami organizacyjnymi. | ||
Przykładowe typy zadań, na jakie może zostać podzielona historyjka<ref>Chrapko M. | Przykładowe typy zadań, na jakie może zostać podzielona historyjka<ref>Chrapko M. 2015, s. 258</ref>: | ||
* przygotowanie dokumentacji, | * przygotowanie dokumentacji, | ||
* projekt UI, | * projekt UI, | ||
| Linia 56: | Linia 40: | ||
* testy, | * testy, | ||
* poprawa błędów. | * poprawa błędów. | ||
===='''3. Szacowanie zadań'''==== | ===='''3. Szacowanie zadań'''==== | ||
Dla każdego zadania, które zostało zdefiniowane w poprzednim kroku, zespół ustala przewidywalny czas jego wykonania w godzinach idealnych, a więc ile godzin zajmie wykonanie tego zadania jednej osobie, w warunkach idealnych. Jeżeli [[dane]] [[zadanie]] zostanie oszacowane na ponad 8 godzin (jeden dzień roboczy), należy się wówczas zastanowić, czy nie byłoby zasadne rozbicie go na kilka mniejszych | Dla każdego zadania, które zostało zdefiniowane w poprzednim kroku, zespół ustala przewidywalny czas jego wykonania w godzinach idealnych, a więc ile godzin zajmie wykonanie tego zadania jednej osobie, w warunkach idealnych. Jeżeli [[dane]] [[zadanie]] zostanie oszacowane na ponad 8 godzin (jeden dzień roboczy), należy się wówczas zastanowić, czy nie byłoby zasadne rozbicie go na kilka mniejszych - zwłaszcza, jeżeli szacowana długość realizacji jest kilkukrotnie większa niż 8 godzin. | ||
Zadania powinny być szacowane wspólnie przez cały zespół, a nie przez jego pojedynczych członków, bez porozumienia z pozostałymi. | Zadania powinny być szacowane wspólnie przez cały zespół, a nie przez jego pojedynczych członków, bez porozumienia z pozostałymi. | ||
| Linia 66: | Linia 51: | ||
Właścicielem Backlogu sprintu jest zespół deweloperski, i tylko on może wprowadzać w nim zmiany w trakcie trwania sprintu (przypis Scrum Guide, Przewodnik do Scrumie, s14). | Właścicielem Backlogu sprintu jest zespół deweloperski, i tylko on może wprowadzać w nim zmiany w trakcie trwania sprintu (przypis Scrum Guide, Przewodnik do Scrumie, s14). | ||
Backlog prezentuje informacje o stanie danego sprintu, dlatego jest on na bieżąco aktualizowany w trakcie sprintu | Backlog prezentuje informacje o stanie danego sprintu, dlatego jest on na bieżąco aktualizowany w trakcie sprintu - dodawane są np. informacje o tym, do kogo dane zadanie zostało przydzielone, i jaki jest jego status realizacji. | ||
Dopuszczalne są zmiany w samych zadaniach, więc jeżeli zespół uzna, że w trakcie planowania sprintu nie zostały uwzględnione wszystkie niezbędne zadania, albo że zadania zostały błędnie sformułowane | Dopuszczalne są zmiany w samych zadaniach, więc jeżeli zespół uzna, że w trakcie planowania sprintu nie zostały uwzględnione wszystkie niezbędne zadania, albo że zadania zostały błędnie sformułowane - wówczas może on wprowadzić odpowiednie zmiany do backloga sprintu, po czym kontynuować pracę zgodnie z nowymi ustaleniami<ref>Chrapko M. 2015, s. 257</ref>. | ||
Możliwe jest również edycja backloga polegające na usuwaniu zadań niepotrzebnych, czy też zmiany dotyczące oszacowanej pracochłonności. | Możliwe jest również edycja backloga polegające na usuwaniu zadań niepotrzebnych, czy też zmiany dotyczące oszacowanej pracochłonności. | ||
Szczególnym przykładem zmiany wprowadzanej w backlogu sprintu to zmiany w samym zakresie sprintu, a więc np. usuwanie z niego zadań, czy historyjek, jeśli zespół uzna, że nie będzie w stanie ich wykonać w ramach danego sprintu. Tego typu zmiany powinny jednak być ustalane drogą negocjacji z Product Ownerem<ref>Schwaber K. (2013) | Szczególnym przykładem zmiany wprowadzanej w backlogu sprintu to zmiany w samym zakresie sprintu, a więc np. usuwanie z niego zadań, czy historyjek, jeśli zespół uzna, że nie będzie w stanie ich wykonać w ramach danego sprintu. Tego typu zmiany powinny jednak być ustalane drogą negocjacji z Product Ownerem<ref>Schwaber K. (2013), s. 10</ref>. | ||
{{infobox5|list1={{i5link|a=[[Planowanie sprintu]]}} — {{i5link|a=[[Estymacja czasu trwania zadań]]}} — {{i5link|a=[[Sprint review]]}} — {{i5link|a=[[Sprint]]}} — {{i5link|a=[[Zarządzanie zakresem Etapu]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[User stories]]}} — {{i5link|a=[[Kamień milowy]]}} — {{i5link|a=[[Zarządzanie integralnością wg PMBOK]]}} }} | |||
==Przypisy== | ==Przypisy== | ||
| Linia 79: | Linia 66: | ||
==Bibliografia== | ==Bibliografia== | ||
<noautolinks> | <noautolinks> | ||
* Chrapko M. ''Scrum | * Chrapko M. (2015), ''Scrum: o zwinnym zarządzaniu projektami'', Wydawnictwo Helion, Gliwice | ||
* Mastelarz M. (2015) [ | * Mastelarz M. (2015), ''[http://wneiz.pl/nauka_wneiz/studia_inf/36-2015/si-36-75.pdf Zwinne podejście w zarządzaniu przedsiębiorstwem]'', Zeszyty Naukowe Uniwersytetu Szczecińskiego, nr 863 | ||
* Sachdeva S. (2016) '' | * 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'' | ||
</noautolinks> | </noautolinks> | ||
{{a|Karolina Zasada}} | {{a|Karolina Zasada}} | ||
[[Kategoria:Techniki zwinne]] | |||
[[Kategoria: | |||
{{#metamaster:description|Backlog sprintu w metodyce SCRUM - zbiór zadań do wykonania przez zespół deweloperski w trakcie sprintu. Dowiedz się więcej o planowaniu sprintu.}} | {{#metamaster:description|Backlog sprintu w metodyce SCRUM - zbiór zadań do wykonania przez zespół deweloperski w trakcie sprintu. Dowiedz się więcej o planowaniu sprintu.}} | ||
Aktualna wersja na dzień 20:53, 17 gru 2023
Backlog sprintu - w metodyce SCRUM, jest to zbiór zadań wybranych z backlogu produktu, który jest realizowany w danym sprincie. Ustalany jest on przed rozpoczęciem sprintu, podczas jego planowania. W przeciwieństwie do backlog produktu, który składa się zazwyczaj z historyjek użytkownika, backlog sprintu zawiera listę konkretnych zadań do wykonania przez zespół deweloperski w trakcie sprintu[1].
Wszystkie zadania w backlogu bieżącego sprintu powinny zawierać następujące informacje[2]:
- opis danego zadania, w tym również informacja o historyjce użytkownika, z której się wywodzi,
- szacowany czas wykonania zadania,
- członka zespołu odpowiedzialnego za wykonanie zadania (jeżeli jest ono już realizowane),
- status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane).
TL;DR
Backlog sprintu to lista zadań wybranych z backlogu produktu, które są realizowane w trakcie sprintu w metodyce SCRUM. Etapy tworzenia backlogu sprintu obejmują wybór historyjek użytkownika, podział na zadania i szacowanie czasu ich wykonania. Zmiany w backlogu mogą być wprowadzane w trakcie sprintu przez zespół deweloperski.
Etapy tworzenia Backlogu sprintu==Backlog Sprintu jest wynikiem planowania sprintu, w którym udział biorą Zespół deweloperski, Product owner i Scrum master[3]. Tworzony jest w następujących krokach[4]====1. Wybór historyjek użytkownika z backlogu produktu==
Zespół ustala, które historyjki zawarte w backlogu produktu zostaną zrealizowane w trakcie najbliższego sprintu. Przy wyborze brane są pod uwagę następujące zagadnienia:
- cel sprintu, który został ustalony przez zespół na początku planowania,
- priorytety historyjek (ustalone w trakcie tworzenia backlogu produktu) - zazwyczaj zespół stara się zrealizować w pierwszej kolejności historyjki z najwyższym priorytetem,
- szybkość działania zespołu - w jakim tempie pracują członkowie zespołu, a więc ile pracy będą w stanie wykonać w czasie trwania sprintu. Tutaj możliwe są dwie metody szacowania:
- - na podstawie prędkości realizowania zadań w poprzednim sprincie,
- - na podstawie dostępności zespołu, a więc informacji o tym, ile czasu każdy członek zespołu będzie pracował w danym projekcie.
2. Podział na zadania
Każdą historyjkę, która została wybrana do sprintu, zespół dzieli na pojedyncze zadania do wykonania. Zadania powinny mieć następujące cechy:
- być możliwe do wykonania przez jedną osobę,
- czas wykonania jednego zadania nie powinien przekraczać 8 godzin,
- wykonanie wszystkich zadań dla danej historyjki skutkuje automatycznym "zamknięciem" historyjki,
- mieć rzeczywistą wartość dla realizacji projektu - do backlog sprintu powinny trafiać tylko zadania mające realny wpływ na projekt; nie dodajemy więc do backlogu zadań związanych np. z rekrutacją, czy spotkaniami organizacyjnymi.
Przykładowe typy zadań, na jakie może zostać podzielona historyjka[5]:
- przygotowanie dokumentacji,
- projekt UI,
- planowanie testów,
- automatyzacja testów,
- implementacja,
- spotkania z właścicielem produktu,
- bufor,
- przygotowanie przypadków testowych,
- przegląd kodu,
- testy,
- poprawa błędów.
3. Szacowanie zadań
Dla każdego zadania, które zostało zdefiniowane w poprzednim kroku, zespół ustala przewidywalny czas jego wykonania w godzinach idealnych, a więc ile godzin zajmie wykonanie tego zadania jednej osobie, w warunkach idealnych. Jeżeli dane zadanie zostanie oszacowane na ponad 8 godzin (jeden dzień roboczy), należy się wówczas zastanowić, czy nie byłoby zasadne rozbicie go na kilka mniejszych - zwłaszcza, jeżeli szacowana długość realizacji jest kilkukrotnie większa niż 8 godzin.
Zadania powinny być szacowane wspólnie przez cały zespół, a nie przez jego pojedynczych członków, bez porozumienia z pozostałymi.
Przykładowym narzędziem, które można wykorzystać do szacowania zadań jest planning poker.
Zmiany w Backlogu w trakcie trwania sprintu
Właścicielem Backlogu sprintu jest zespół deweloperski, i tylko on może wprowadzać w nim zmiany w trakcie trwania sprintu (przypis Scrum Guide, Przewodnik do Scrumie, s14).
Backlog prezentuje informacje o stanie danego sprintu, dlatego jest on na bieżąco aktualizowany w trakcie sprintu - dodawane są np. informacje o tym, do kogo dane zadanie zostało przydzielone, i jaki jest jego status realizacji.
Dopuszczalne są zmiany w samych zadaniach, więc jeżeli zespół uzna, że w trakcie planowania sprintu nie zostały uwzględnione wszystkie niezbędne zadania, albo że zadania zostały błędnie sformułowane - wówczas może on wprowadzić odpowiednie zmiany do backloga sprintu, po czym kontynuować pracę zgodnie z nowymi ustaleniami[6].
Możliwe jest również edycja backloga polegające na usuwaniu zadań niepotrzebnych, czy też zmiany dotyczące oszacowanej pracochłonności.
Szczególnym przykładem zmiany wprowadzanej w backlogu sprintu to zmiany w samym zakresie sprintu, a więc np. usuwanie z niego zadań, czy historyjek, jeśli zespół uzna, że nie będzie w stanie ich wykonać w ramach danego sprintu. Tego typu zmiany powinny jednak być ustalane drogą negocjacji z Product Ownerem[7].
| Backlog sprintu — artykuły polecane |
| Planowanie sprintu — Estymacja czasu trwania zadań — Sprint review — Sprint — Zarządzanie zakresem Etapu — Feature-Driven Development — User stories — Kamień milowy — Zarządzanie integralnością wg PMBOK |
Przypisy
Bibliografia
- Chrapko M. (2015), Scrum: o zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice
- Mastelarz M. (2015), Zwinne podejście w zarządzaniu przedsiębiorstwem, Zeszyty Naukowe Uniwersytetu Szczecińskiego, nr 863
- 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
Autor: Karolina Zasada
