Dobre cechy rejestru produktu

W zeszłym tygodniu opisałem rejestr produktu. Dziś chciałbym przybliżyć temat jakości rejestru produktu.
Dobry rejestr produktu jest DEEP. Akronim DEEP został stworzony przez Romana Pichlera i Mike’a Cohena ułatwiający zapamiętanie kryteriów służących do oceny jakości
rejestru produktu. DEEP oznacza:
Detailed appropriately – wystarczająco szczegółowy,
Estimated – szacunkowy
Emergent – nowo powstający (podaję za Pichlerem [2])
Prioritized – zawiera priorytety
Roman Pichler w swojej książce [2] tak wyjaśnia wymieniony powyżej zestaw cech:
Wystarczająco szczegółowy
Elementy mające wyższy priorytet opisane są bardziej szczegółowo niż te o niższym priorytecie. (..). Kierowanie się tymi wytycznymi pozwala na utrzymanie zwięzłości rejestru i upewnienie się, że elementy, nad którymi zespoły będą prawdopodobnie pracować w następnym sprincie, są na to przygotowane. W konsekwencji wymagania są odkrywane, rozkładane na czynniki i dopracowywane w trakcie całego projektu.
 
Szacunkowy
Elementy rejestru produktów są szacunkowe. Są one ogólnikowe i często wyrażane za pomocą punktów lub dni idealnych. Poznanie rozmiarów elementu pomaga w nadaniu mu odpowiedniego priorytetu oraz zaplanowaniu wydania. Szczegółowe szacunki na poziomie zadań tworzone są w trakcie planowania sprintu; zadania i dotyczące ich szacunki zapisywane są w rejestrze sprintu.
 
Nowo powstający
Rejestr produktu ma naturalną jakość. Ewoluuje, a jego zawartość często się zmienia. Odkrywane są nowe elementy, które dodaje się do rejestru na podstawie opinii zwrotnych klientów i użytkowników. Istniejące elementy są regularnie modyfikowane, dopracowywane, usuwane lub zmienia się im priorytet.
 
Zawierający priorytety
Wszystkie elementy rejestru produktów mają priorytety. Te najważniejsze, o najwyższym priorytecie, implementowane są jako pierwsze.
Można je znaleźć na szczycie rejestru produktu (…). Każdy element, który zostanie wykonany, jest usuwany z rejestru.
Składnikiem rejestru produktu zazwyczaj są historyjki użytkownika, epiki i tematy – pisałem o tym tydzień temu. Lecz nie tylko.
Jeśli jednak korzystasz z user stories, nie powinieneś czuć się zobligowany do opisania każdego elementu rejestru jako historii. Przykładowo: wymagania dotyczące użyteczności najlepiej obrazują prototypy lub szkice. Praca z rejestrem produktu nie oznacza, że zespół scrumowy nie może tworzyć innych pomocnych artefaktów, w tym streszczeń user stories, historii modelujących przepływ pracy, diagramów ilustrujących zasady biznesowe, arkuszy kalkulacyjnych przedstawiających złożone obliczenia, szkiców interfejsu użytkownika, scenopisów, diagramów nawigacyjnych oraz prototypów interfejsu użytkownika”[2].
To co moim zdaniem jest istotne to przypisanie priorytetów elementom w krótkim horyzoncie czasowym — przeznaczonym do realizacji w ciągu kilku nadchodzących sprintów.
Zbliżając się do pracy nad większymi elementami, takimi jak eposy, będziemy dzielić je na zbiory mniejszych historyjek nadających się do sprintu. Takie działanie powinno odbywać się w samą porę. Jeżeli zbyt wcześnie dokonamy uszczegółowienia, być może poświęcimy sporą ilość czasu na wypracowanie szczegółów, a mimo to nigdy nie zaimplementujemy całej historii. Jeżeli będziemy czekać zbyt długo, wyhamujemy strumień elementów wchodzących do sprintów i tym samym spowolnimy pracę zespołu. Musimy znaleźć równowagę pomiędzy pracą w samą porę i pracą w stopniu wystarczającym” [1].
Reasumując. Dobry rejestr produktu składa się z historyjek użytkownika i innych wymagań oraz artefaktów (modele procesów biznesowych itp), które Zespołowi Scrum mogą opisać produkt. Rejestr produktu może także zawierać epiki i tematy tak by za pomocą epik opisać zagadnienia do uszczegółowienia w kolejnych iteracjach a tematy pozwolą powiązać historyjki w większe zagadnienia.

 

Cały cykl artykułów na temat metodyki Scrum jest pod adresem: https://www.michalwolski.pl/tag/scrum-framework/ . Zapraszam do lektury.

Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.

Podobne wpisy

  • Sprint Planning Meeting – Planowanie Sprintu Na spotkaniu dot. Planowania Sprintu (ang. Sprint Planning Meeting) Zespół Scrum oraz Właściciel Produktu określają, które cechy i zadania będą poddane próbie wykonania w nadchodzącym […]
  • Task Board – Tablica Zadań Tablica Zadań (ang. Task Board) pokazuje całość pracy wykonywanej przez zespół podczas sprintu. Jest ona stale aktualizowana w trakcie sprintu- jeżeli ktoś myśli o nowym zadaniu, pisze […]
  • Prioritizing the Backlog – Priorytezacja Rejestru Produktu W trakcie czynności Priorytezacja Rejestru Produktu  (ang. Prioritizing the Backlog) pozycje w Product Backlogu są hierarchizowane przez Właściciela Produktu przed planowaniem wydania i […]
  • Historyjki użytkownika a wymagania Pisząc jakąkolwiek specyfikację wymagań a rejestr produktu i rejestr sprintu są taką specyfikację należy uwzględnić wymagania niefunkcjonalne. O ile sama historyjka użytkownika zazwyczaj […]
  • Sprint Burndown Chart – Wykres Spalania Sprintu Wykres Spalania Sprintu (ang. Sprint Burndown Chart) jest graficznym przedstawieniem pracy pozostającej do wykonania w trakcie trwania Sprintu. Zasada tworzenia wykresu spalania sprintu […]
Reklama

Zostaw komentarz

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