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.
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.
Reklama
