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/metodyka-scrum/ . 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.

Zostaw odpowiedź

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

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close