Backlog produktu
| Backlog produktu |
|---|
| Polecane artykuły |
TL;DR
Backlog produktu to lista zadań potrzebnych do wykonania, aby otrzymać produkt. Jest on stale aktualizowany i priorytetowany. Cykl życia backlogu obejmuje przedstawienie wymagań, wyznaczenie priorytetów, realizację zadań i usuwanie ich z listy. Backlog jest dynamiczny i może ulegać zmianom. Klient jest zaangażowany w proces tworzenia produktu i nie wymaga tworzenia dodatkowej dokumentacji. Backlog powinien zawierać zadania na najbliższe 2-4 sprinty, a priorytetyzacja może odbywać się za pomocą formy wektorowej lub dzielenia zadań na zbiory. Refinement to etap pielęgnacji backlogu, który odbywa się podczas regularnych spotkań zespołu.
Backlog produktu
Backlog produktu – pojęcie związane z metodą scrum. Jest to spriorytetyzowana lista wszystkich zadań jakie powinny być wykonane, aby otrzymać produkt. W dosłownym tłumaczeniu jest to rejestr produkt. Rejestr ten rozpoczyna cały cykl scrum. Jest to jedyne źródło wymagań dla wszelkich zmian, które należy wprowadzić do produktu. Stanowi podstawę wymagań klienta wobec ostatecznego kształtu oczekiwanego produktu.
Główną osobą odpowiedzialną za backlog produktu jest Product owner. Zakres ten obejmuje zawartość backlogu, jego dostępność oraz zamawianie. Składa się on przede wszystkim z funkcji, wymagań, proponowanych ulepszeń, które należy wprowadzić w przyszłych wydaniach produktu. Oprócz tego, backlog zawiera tak zwane atrybuty opisu, porządku, szacunku i wartości. Elementy backlogu często zawierają opisy testów, które potwierdzają jego kompletność po wykonaniu zadania. Backlog produktu przybiera coraz większe rozmiary, kiedy produkt jest używany i zaczyna nabierać wartości, a użytkownicy produktu dostarczają informacji zwrotnej.
Cykl życia backlogu produktu
{{#ev:youtube|ODsSlyYeQUI|480|right|Jak utworzyć backlog? (Sławomir Wawak)|frame}} Cykl życia backlogu produktu:
1. Własciciel produktu przedstawia wymagania dotyczące ostatecznego kształtu produktu.
2. Wyznaczenie priorytetów zadań w backlogu.
3. Backlog jest przedstawiany na spotkaniu planistycznym sprintu.
4. Zadania backlogu przyjmowane są do wykonania.
5. Zadania wykonane usuwane są z backlogu produktu.
6. Rozpoczęcie cyklu od nowa, tj. powrót do kroku 1.
Charakterystyka backlogu
Backlog produktu najczęściej jest dostępny w formie papierowej na tablicy, która znajduje się blisko pracy zespołu scrumowego. Ważne, aby każdy członek zespołu miał łatwy dostęp do backlogu. Stałe monitorowanie backlogu ułatwia zarządzanie poszczególnymi elementami w czasie. Backlog produktu nigdy nie jest w pełni kompletny. Ma on charakter dynamiczny, może ulegać modyfikacjom w miarę jak zmienia się ostateczna funkcjonalność, przydatność, przeznaczenie oraz konkurencyjność produktu.
W związku z tym, że ciągle mogą pojawić się nowe wymagania, backlog produktu jest żywym artefaktem. Zmiany w wymaganiach biznesowych, warunki biznesowe czy też technologia mogą powodować zmiany w backlogu. Zadania znajdujące się w górnej części backlogu najczęściej są bardziej uszczegółowione, ale też prostsze. Dolna część backlogu zawiera zdecydowanie mniej szczegółów.
Klient, który jest głównym dostarczycielem wymagań co do produktu uczestniczy w spotkaniach zespołu na koniec każdego sprintu. Co ważne, klient w rzeczywistości staje się członkiem zespołu. Sytuacja ta wymaga od zespołu dużej otwartości. Jest to o tyle trudne, gdyż w tradycyjnym zazarządzaniu projektami, klient najczęściej otrzymuje wyniki prac, jednak nie uczestniczy czynnie wraz zespołem w planowaniu najbliższych zadań. Jednak taka forma współpracy sprawia, iż nie jest wymagane tworzenie dokumentacji dla klienta, gdyż on sam jest uczestnikiem zespołu i wszystkiego dowiaduje się z rozmów. Należy zauważyć, że tworzenie dokumentacji wynika z braku dostatecznej komunikacji.
Celem sprawnej komunikacji wprowadzono w Agile są tzw. historyjki użytkownika. Mają one swoje zastosowanie podczas spotkań zespołu. Historyjka się jest jednostką funkcjonalności w projektach XP (Extreme Progamming). Pokazujemy postać prac, dostarczając przetestowany i zintegrowany kod, który składa się na implementacje danej historyjki. Historyjka powinna być zrozumiała i wartościowa dla klientów, testowalna przez programistów i na tyle mała, żeby programiści mogli zaimplementować sześć historyjek w trakcje jednej iteracji.(K.Beck, M. Fowler, 2000, s. 42) Historyjki te przybierają postać fiszek, które zawierają opis funkcjonalności, jakie oczekuje klient lub użytkownik systemu. Składają się one z krótkich zdań, które wyznaczają cele na najbliższy czas.
Czas
Backlog powinien zawierać zadania na najbliższe 2 – 4 sprinty. Warto wspomnieć, iż według założeć sprint nie powinien trwać dłużej niż 30 dni kalendarzowych. Należy zadbać, aby przynajmniej połowa zadań była określona dokładnie przez cały zespół. Natomiast reszta zadań może być ustalona w małych podzespołach. Pozwala to członkom zespołu wyraźnie spojrzeć na najbliższą przyszłość, która w dużej mierze została zaplanowana. Przedstawiony schemat działania pozwala uniknąć nadmiernej presji na zmiany strategii rozwoju oprogramowania podczas kolejnych sprintów.
Zespół deweloperski jest odpowiedzialny za wszelkie estymacje czasowe. Product owner może wpłynąć na zespół deweloperski poprzez pomoc w lepszym zrozumieniu procesu i osiągnięciu kompromisu, jednak członkowie zespołu, którzy będą wykonywać zadania podejmują decyzje o ostatecznych oszacowaniach.
Priorytetyzacja backlogu
Z backlogu wybiera się zadania do wykonania w konkretnych sprintach – zaczynając od tych o najwyższym priorytecie. Istnieją dwie formy priorytetyzowania backlogu:
1. Forma wektorowa - priorytetyzowanie każdej pozycji innym priorytetem. Zaletą sposobu wektorowego jest uniknięcie sytuacji gdzie mamy nadany najwyższy priorytet wielu zadaniom. W metodzie tej istnieje tylko jedno zadanie o najwyższym priorytecie.
- Sytuacja ta może jednak stworzyć problem w oczach Product ownera. Właściciel produktu, widząc wiele zadań o niskim priorytecie nabiera poczucia, iż członkowie zespołu uznają je za nieważne. Może to wynikać z braku zaufania. Proponowanym rozwiązaniem tego problemu jest przedstawienie backlogu właścicielowi w kategoriach "które zadania powinny wg niego być wykonane wcześniej” zamiast "które zadanie są najważniejsze”.
2. Dzielenie zadań na zbiory według ważności - Dokonuje się podziału na kilka zbiorów zadań o różnej ważności, a następnie dane zadanie przypisuje do danego zbioru.
- Metoda "zbiorów” jest zdecydowanie szybsza niż wektorowa. Product owner, który dokonuje podziału zadań, najczęściej stosuje te właśnie forme. Praktyka pokazuje, iż stosowanie tej metody, stwarza trudności kiedy zachodzi potrzeba zmiany sposobu priorytetyzacji.
Refinement
Refinement, czyli pielęgnacja. Kiedyś stosowano nazwę grooming, jednak dzisiaj używana jest coraz rzadziej. Refinement jest to stały etap cyklu pracy, który polega na uporządkowywaniu backlogu. Jeden z autorów porównuje ten etap do pielęgnacji ogrodu, który kiedy zostanie zaniedbany, szybko zacznie zarastać chwastami. Podobnie jest z backolgiem, który wymaga ciągłej dbałości, aby utrzymać go we właściwej formie. Refinement odbywa się podczas regularnych spotkań zespołu z właścicielem produktu. Podczas spotkania porusza się następujące tematy:
- przygotowanie historyjki przy uwzględnieniu najbliższego planowania sprintu
- Ustalenie priorytetów poszczególnych historyjek
- estymacja poziomu wielkości historyjek (wyrażona w punktach)
- Stworzenie nowych historyjek lub poprawa starych.
Etap udoskonalania zwykle zajmuje około 10% całkowitego czasu pracy zespołu. W miarę potrzeb i bieżącej sytuacji można zwoływać spotkania. Uprawnieni są do tego Product owner oraz osoby, którego zostaną do tego zadania oddelegowane. Najczęściej spotkania takie odbywają się 2 – 3 razy w tygodniu w krótkich sesjach lub też raz w tygodniu z większym nakładałem czasu.
Bibliografia
- Beck K., Fowler M., (2000) Planning Extreme Programming, Addison-Wesley, Boston, s. 123
- Chrapko M. Scrum. O zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice 2013
- Mastelarz M. (2015) Zwinne podejście w zarządzaniu przedsiębiorstwem "Zeszyty Naukowe Uniwersytetu Szczecińskiego", nr 863, s. 82
- Schwaber K. Sutherland J. (2013) The scrum guide. The Definitive Guide to Scrum: The Rules of the Game, s. 12
- Segers J. (2012) Analysis of a paper and software based Scrum task board Business Information Technology MSc Thesis, Enschede, s. 22
Autor: Robert Staniszewski
