Backlog Produktu

Backlog Produktu to — obok Backlogu Sprintu oraz Przyrostu — jeden z trzech podstawowych artefaktów w Scrumie. Jest to uporządkowana lista wszystkich rzeczy, które w danym momencie uznajemy za warte zrealizowania w obrębie konkretnego produktu. Oznacza to, że nowe funkcjonalności, zmiany, błędy czy zadania związane ze spłacaniem długu technologicznego, powinny być zawarte w Backlogu Produktu, aby Właściciel Produktu oraz interesariusze mieli jasny obraz prac związanych z produktem.

Za uporządkowanie, zawartość oraz zarządzanie Backlogiem Produktu odpowiedzialny jest Właściciel Produktu. Może on samodzielnie zarządzać Backlogiem Produktu lub zlecać to zadanie Zespołowi Deweloperskiemu. W praktyce można spotkać Właścicieli Produktów, którzy samodzielnie umieszczają elementy w Backlogu Produktu, jak i takich, którzy zlecają to zadanie Zespołowi Deweloperskiemu lub umożliwiają zrobienie tego szeroko rozumianym interesariuszom. W tym ostatnim przypadku, taki element jest oczywiście wyłącznie zaproszeniem do rozmowy i zwykle wymaga uszczegółowienia.

Backlog Produktu to żyjący artefakt

W odróżnieniu od klasycznej dokumentacji projektowej, Backlog Produktu nie jest ostateczną, zatwierdzoną wersją wymagań, tylko zmienia się wraz ze zwiększaniem się wiedzy Zespołu Scrumowego na temat potrzeb oraz oczekiwań końcowych użytkowników.

Przykładową, chociaż nie jedyną okazją do zdobywania takich informacji, jest Przegląd Sprintu, podczas którego interesariusze dokonują inspekcji Przyrostu produktu i dzielą się informacją zwrotną na bazie tego, co zaprezentował im Zespół Scrumowy. Na bazie zdobytych Informacji zachodzi proces adaptacji, polegający na zaktualizowaniu Backlogu Produktu o nowo zdobyte informacje. Powoduje to, że nauka zdobywana przez Zespół Scrumowy co Sprint jest do wykorzystywania od zaraz w kolejnym Sprincie.

Backlog Produktu jest dostępny i przejrzysty

Odpowiedzialnością Właściciela Produktu jest zapewnienie, że Backlog Produktu jest dostępny, przejrzysty i jasny dla wszystkich. Dostępności Backlogu Produktu oznacza, że istnieje jednoznacznie określone miejsce w którym się znajduje, oraz że jest ono znane oraz osiągalne dla interesariuszów. Przykładowo, Backlog Produktu zapisany w na dysku twardym Właściciela Produktu nie spełnia warunku dostępności.

Z kolei przejrzystość i jasność Backlogu Produktu oznacza, że jest on prowadzony w takiej formie, która zapewnia jednoznaczny sposób interpretacji informacji tam zapisanych. Jeżeli ktokolwiek z Zespołu Deweloperskiego lub interesariuszy nie jest w stanie poprawnie czytać z niego informacji, może to oznaczać, że brakuje ustalonych wspólnych standardów dotyczących tego, jak elementy Backlogu Produktu będę utrzymywane.

Proces doskonalenia Backlogu Produktu

Elementy na górze Backlogu Produktu powinny być klarowne i gotowe do implementacji

Elementy na górze Backlogu Produktu powinny być klarowne i gotowe do implementacji

Właściwie zarządzany Backlog Produktu podlega ciągłemu procesowi doskonalenia (ang. refinement), polegającemu na dodawaniu i usuwaniu elementów oraz uzupełnianiu ich o niezbędne szczegóły. Dodawane są również oszacowania elementów (popularnie zwane estymatami), ich wartość biznesowa oraz nadawana jest odpowiednia kolejność w Backlogu Produktu. Czynności te wg autorów Scruma nie zajmują zwykle więcej niż 10% czasu Zespołu Deweloperskiego w Sprincie. Praktyka pokazuje, że w zależności od wielu czynników, m.in. od aktualnego stanu Backlogu Produktu, złożoności produktu czy też aktualnego stanu wiedzy Zespołu Scrumowego, czas ten może się zarówno skracać jak i znacząco wydłużać.

W konsekwencji doskonalenia Backlogu Produktu elementy znajdujące się wyżej są zwykle bardziej szczegółowo opisane, co wpływa na większą precyzję ich oszacowań. Elementy znajdujące się na samej górze Backlogu Produktu spełniają zwykle definicję przygotowania (ang. definition of ready) określoną przez Zespół Scrumowy. Oznacza to, że są na tyle jasne i kompletne, że zespół może je wziąć pod uwagę podczas prognozowania zakresu prac w trakcie Planowania Sprintu.

Z kolei elementy znajdujące się nisko w Backlogu Produktu — jako, że ich implementacja jest oddalona w czasie — zwykle są bardziej ogólne, a oszacowania mogą znacząco ulec zmianie w przyszłości. W konsekwencji elementy te nie są zwykle przygotowane na tyle, aby Zespół Deweloperski był w stanie zrealizować je podczas pojedynczego Sprintu.

Forma zapisu elementów Backlogu Produktu

Oficjalny Przewodnik po Scrumie nie wskazuje, w jakiej formie powinny być wyrażane elementy Backlogu Produktu. Pozostaje to w gestii zespołu, aby wybrać dogodny dla nich format zapisu.

W praktyce, najczęściej spotykany format zapisu elementów Backlogu Produktu to forma historii użytkownika (ang. user story), wywodzący się z Extreme Programming. Historie użytkownika wyrażają jego potrzeby i oczekiwania w formacie: JAKO <użytkownik> CHCĘ <potrzeba> TAK, ABY <korzyść>.

Ta zwięzła forma ma na celu wzbudzenie dyskusji w Zespole Scrumowym, której celem jest dogłębne zrozumienie, co kryje się za tym krótkim zdaniem. Szczegóły historii użytkownika — często wyrażane w postaci kryteriów akceptacji (ang. acceptance criteria) — wyłaniają się w trakcie dyskusji w obrębie Zespołu Scrumowego.

Narzędzia do utrzymywania Backlogu Produktu

Istnieją dwie główne możliwości utrzymywania Backlogu Produktu: w wersji fizycznej lub elektronicznej.

W pierwszej opcji elementy Backlogu Produktu są zapisywane przykładowo na kartkach typu post-it, a następnie przyklejane na ścianę, tablicę suchościeralną lub przygotowany wcześniej odpowiedni duży arkusz folii elektrostatycznej lub zwykłego papieru. Plusem takiego podejścia jest możliwość spojrzenia na Backlog Produktu jako całość, robiąc kilka kroków w tył od miejsca, w którym się znajduje. Dodatkowo, łatwość przesuwania kartek i dowolnego ich aranżowania zwykle pobudza dyskusję oraz pozwala na analizowanie różnorodnych scenariuszy dalszego rozwoju produktu. Minusem jest problematyczna synchronizacja Backlogu Produktu pomiędzy różnymi lokalizacjami, gdy mamy do czynienia z zespołem rozproszonym geograficznie.

Z kolei w wersji elektronicznej mamy do dyspozycji dużą ilość darmowych oraz komercyjnych narzędzi, takich jak JIRA, Trello czy też popularny Microsoft Excel. Plusem w tym przypadku jest dostępność tak utrzymywanego Backlogu Produktu, który jest osiągalny w sposób ciągły dla zainteresowanych z niemal dowolnej lokalizacji oraz z dowolnego urządzenia. Minusem jest słabsza całościowa widoczność produktu, ponieważ zwykle aplikacje pozwalają wyświetlić wyłącznie wybrany fragment Backlogu Produktu, którego rozmiar ograniczony jest przekątną ekranu, którą dysponujemy. Dodatkowo, dyskusje toczone wokół telewizora lub dużego monitora są zwykle mniej interaktywne niż te przeprowadzane przy użyciu fizycznego Backlogu Produktu.

Komentarze do wpisu: “Backlog Produktu


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x