Backlog sprintu: Różnice pomiędzy wersjami
m (cleanup bibliografii i rotten links) |
mNie podano opisu zmian |
||
Linia 15: | Linia 15: | ||
'''[[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]]. | '''[[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) | 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). | Wszystkie zadania w backlogu bieżącego sprintu powinny zawierać następujące [[informacje]]<ref>Sachdeva S. (2016). s. 16798</ref>: | ||
* 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, | ||
Linia 28: | Linia 28: | ||
==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). | 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'''==== | ===='''1. Wybór historyjek użytkownika z backlogu produktu'''==== | ||
Linia 44: | Linia 44: | ||
* 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. | * 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 68: | Linia 68: | ||
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. | 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<ref>Chrapko M. | 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>. | ||
==Przypisy== | ==Przypisy== |
Wersja z 18:27, 27 paź 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