Backlog sprintu: Różnice pomiędzy wersjami
mNie podano opisu zmian |
m (Czyszczenie tekstu) |
||
| Linia 14: | Linia 14: | ||
}} | }} | ||
'''[[Backlog]] sprintu''' | '''[[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>. | 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>. | ||
| Linia 27: | Linia 27: | ||
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)., 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'''==== | |||
[[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. | ||
===='''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: | ||
| Linia 42: | Linia 40: | ||
* 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 "zamknięciem” historyjki, | * 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. 2015, s. 258</ref>: | Przykładowe typy zadań, na jakie może zostać podzielona historyjka<ref>Chrapko M. 2015, s. 258</ref>: | ||
| Linia 56: | Linia 54: | ||
* 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 65: | ||
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. | ||
| Linia 86: | Linia 85: | ||
{{a|Karolina Zasada}} | {{a|Karolina Zasada}} | ||
[[Kategoria:Zarządzanie projektami]] | [[Kategoria:Zarządzanie projektami]] | ||
{{#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.}} | ||
Wersja z 12:34, 2 lis 2023
| Backlog sprintu |
|---|
| Polecane artykuły |
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].
Przypisy
Bibliografia
- Chrapko M. Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice 2015
- Mastelarz M. (2015) Zwinne podejście w zarządzaniu przedsiębiorstwem "Zeszyty Naukowe Uniwersytetu Szczecińskiego", nr 863, s. 82
- 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ły gry
Autor: Karolina Zasada
