Menu

Artefakty Scruma: Backlog Produktu, Backlog Sprintu i Przyrosty Produktu

  • Główny
  • Inny
  • Artefakty Scruma: Backlog Produktu, Backlog Sprintu i Przyrosty Produktu

scrum artifacts product backlog

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Wprowadzenie do artefaktów Scruma:

W poprzednich artykułach z tej serii wprowadzono nas w zwinne i różne zwinne metodologie . Dowiedzieliśmy się również, jak różne metodologie różnią się na swój sposób.

W naszym ostatnim samouczku przeszliśmy do szczegółów Scruma, w którym omówiliśmy Role Scruma jak Product Owner, Scrum Master i zespół scrumowy i zobaczyli, jakie są ich indywidualne obowiązki.

W tym samouczku kontynuujemy pracę ze Scrumem i przechodzimy dalej do szczegółów dotyczących różnych artefaktów scrumowych.

Artefakty Scruma

Czego się nauczysz:

Różne artefakty Scruma

Trzy rodzaje artefaktów Scruma to:

  • Rejestr produktów
  • Backlog sprintu i
  • Przyrosty produktu

Teraz zobaczymy, co oznaczają te terminy i jak tworzyć te artefakty.

Typy artefaktów Scruma

Backlog Produktu

Mówiąc prościej, rejestr produktu to lista wszystkich rzeczy, które są wymagane w produkcie. Jest to ostateczny dokument, do którego zespół scrumowy odwołuje się w sprawach związanych z produktem. Jest to uporządkowana lista pozycji, która jest własnością właściciela produktu (PO).

Zamówienie zakupu jest odpowiedzialne za tworzenie, utrzymywanie i ustalanie priorytetów tej listy. OP używają tego rejestru produktu do wyjaśnienia zespołom scrumowym najważniejszych wymagań, które należy spełnić podczas sprintu.

Pozycje na tej liście mogą być w języku technicznym lub nie. Może to być nawet język laika, ale powinien zawierać wszystkie wymagania dotyczące produktu i towarzyszące im zmiany. Ponadto posiadanie zaległości produktowych nie oznacza, że ​​zespół scrumowy będzie miał tylko ten artefakt do śledzenia.

Mogą tworzyć własne szczegółowe artefakty, ale nie będą one sprzeczne ani nie zastąpią backlogu produktu. Będą raczej zgodne z wymaganiami dotyczącymi zaległości produktowych.

Poniżej znajduje się przykład tego, jak może wyglądać typowy rejestr produktu:

FabułaOszacowaniePriorytet
Chcę się zalogować41
Chcę się wylogowaćdwadwa
Chcę zmienić hasło13
Chcę zaktualizować adres34
Chcę dodać nowy numer telefonu domowego15

To prowadzi nas do pytania, jak stworzyć dobry backlog produktowy?

Backlog produktu powinien idealnie spełniać poniższe zasady:

(i) Powinien mieć priorytet - Pozycje z backlogu produktów należy zamawiać według ich priorytetu. O tym priorytecie mogą wspólnie decydować PO i zespół scrumowy. Czynnikami ustalania priorytetów mogą być dowolne korzyści wynikające z tematu, wysiłku związanego z tworzeniem, złożoności, priorytetu klienta itp.

Pomaga zespołowi w zrozumieniu, co musi zostać dostarczone w pierwszej kolejności.

(ii) Należy oszacować - Historie należy zawsze oceniać zgodnie z ustaloną definicją, cokolwiek by to nie było. Można to również wykorzystać do ustalenia priorytetów.

(iii) Powinien być wysoki - Historie w rejestrze produktu mają być na wysokim poziomie i nie powinny wchodzić w szczegóły. Tworzenie szczegółowych historyjek użytkownika zgodnie z wymaganiami należy do zespołu scrumowego, a nie do PO.

(iv) Powinien być dynamiczny - Rejestr produktu nie jest ostatecznym dokumentem statycznym. Należy to ponownie przeanalizować, ponieważ PO otrzymuje informacje od zespołu scrum, a wymagania klientów stają się coraz bardziej jasne. W związku z tym wymagania dotyczące dokumentów nie są zamrożone od razu na początku, ponieważ w miarę postępu projektu oczekuje się dodania / usunięcia / modyfikacji.

Ostatni punkt jest najważniejszy. Zadaniem rejestru produktu jest bycie aktywnym źródłem wymagań. Nie należy go tworzyć na początku, a następnie przechowywać w miejscu przechowywania.

Zamiast tego mają być udostępniane wielokrotnie, w miarę pojawiania się zmian. W miarę postępów mogą pojawić się nowe wymagania, które mogą również zmienić priorytet pozycji z rejestru. Będą sytuacje, w których nowe wymaganie będzie zależne od innego elementu w zaległościach, więc priorytet elementu może wymagać przetasowania.

Lub może istnieć krytyczna historia użytkownika, która może być zaimplementowana jako pierwsza, ponieważ klient chce to zobaczyć przed innymi, nawet jeśli może to nie mieć wysokiego priorytetu zgodnie z czynnikami określonymi przez PO i zespół scrumowy.

W związku z tym rejestr produktu jest uporządkowaną listą wymagań biznesowych, których właścicielem jest PO, i które są regularnie odwiedzane w miarę postępu projektu.

Sprint Backlog

Być może pamiętasz, że zespoły scrumowe pracują w krótkich iteracjach od 2 do 4 tygodni zwanych sprintem. Podczas tych sprintów zespół scrumowy identyfikuje pozycje z backlogu produktu utworzonego przez PO, które planuje dostarczyć w ramach następnej iteracji. Elementy, nad którymi zespół scrumowy pracuje, stają się częścią rejestru sprintu.

W ten sposób decydują, jakie funkcjonalności będą dostępne w kolejnej iteracji produktu. Zespół scrumowy to ten, który decyduje, co znajdzie się w rejestrze sprintu, ponieważ to oni będą nad nim pracować.

Dlatego to oni powinni oszacować wysiłek włożony w realizację tych historii i zdecydować, ile mogą one dostarczyć.

Zespół nie tylko wybiera elementy z rejestru produktu do pracy, ale także szacuje, ile czasu zajmie im opracowanie tej funkcjonalności. Dodają również do historii użytkowników wysokiego poziomu, tworząc szczegółowe zadania wymagane do osiągnięcia celu sprintu.

jakiego narzędzia możesz użyć do wizualnej reprezentacji i analizy bazy danych?

Zespół scrumowy może również aktualizować rejestr sprintu, gdy jest to wymagane podczas sprintu, ale tylko zespół scrum może wprowadzać zmiany w rejestrze sprintu.

Typowy Backlog Sprintu będzie wyglądał tak, jak pokazano poniżej.

Sprint Backlog

Zespół może w idealnym przypadku aktualizować to raz dziennie, a mistrz scrum może wykorzystać te informacje do stworzenia wykresu wypalania sprintu. Ten wykres wypalania pomoże zespołowi zobaczyć, ile pracy pozostało jeszcze do sprintu, a zespół może odpowiednio zaplanować swoją pracę. W razie potrzeby mogą nawet dodawać lub usuwać zadania.

Oto kilka sprawdzonych metod tworzenia backlogu sprintu:

# 1) Podejmuj decyzje grupowe - To nie powinien być scrum master ani żaden inny członek zespołu scrum decydujący o zaległościach. Raczej to cały zespół powinien wspólnie decydować, które elementy uwzględnić w rejestrze sprintu i jak je zaplanować.

Każdy członek tego wielofunkcyjnego zespołu ma własne umiejętności i ważne jest, abyśmy wykorzystali ich doświadczenie, aby stworzyć jak najlepsze zaległości.

# 2) Nie przydzielaj zadań - Jak wielokrotnie powtarzano w literaturze zwinnej, nigdy nie przydzielaj zadań członkom zespołu. Zespół scrumowy ma być samowystarczalny i powinien umieć samodzielnie zorganizować swoją pracę.

Dlatego zamiast przydzielać pracę, powinniśmy pozwolić zespołowi wybrać pracę dla siebie i zdecydować między sobą, jak chcą dalej postępować.

# 3) Definicja gotowego - Powinien być nie tylko uzgodniony przez interesariuszy, ale również powinien być wyraźnie widoczny dla zespołu we wszystkich punktach, gdy muszą podjąć jakąkolwiek decyzję dotyczącą celów sprintu. Będzie to służyć jako przypomnienie, co dokładnie należy zrobić, zanim będą mogli dostarczyć działający produkt do wysyłki.

# 4) Kontynuuj aktualizowanie zaległości - Konieczne jest, aby w miarę rozwoju sprintu zespół zyskał większe zrozumienie i dlatego powinien odpowiednio zaktualizować zaległości sprintu, aby odzwierciedlić również to większe zrozumienie. W żadnym momencie nie powinien stać się statycznym dokumentem.

# 5) Dodaj dowolne zadanie - Zadanie musi być nie tylko związane z kodowaniem, ale może mieć kluczowe znaczenie dla dostarczenia gotowego do wysyłki produktu. Stąd też wspomnij o takich zadaniach w zaległościach.

Przyrost produktu

To prowadzi nas do ostatniego artefaktu scruma, jakim są przyrosty produktu. Zgodnie z definicją zawartą w przewodniku po Scrumie, Przyrost jest sumą wszystkich Elementy rejestru produktu ukończone podczas a Sprint oraz wartość przyrostów wszystkich poprzednich Sprintów. Jak już dobrze wiemy, Scrum jest procesem iteracyjnym.

Wynikiem każdej iteracji jest przyrost produktu, a każdy taki przyrost produktu pomaga zespołowi zbliżyć się o krok do dostarczenia produktu końcowego.

Oznacza to, że cokolwiek było wynikiem sprintu, jest przyrostem. Oczywiście, aby wynik mógł być uznany za przyrost, powinien najpierw spełniać wcześniej zdefiniowaną definicję wykonania, tj. Wynikiem końcowym powinien być produkt nadający się do użycia, który można „wysłać”.

Można go sprawdzić, użyć i przetestować, aby upewnić się, że jest rzeczywiście „zrobione” zgodnie z definicją i jeśli Właściciel Produktu sobie tego życzy, może również zostać dopuszczony do użytku.

Najważniejszą rzeczą w dostarczaniu tego produktu jest wspólne zrozumienie „definicji wykonania”, która jest zrozumiała dla wszystkich.

Zespół scrumowy nigdy nie powinien mieć wątpliwości, czy to, co robi, zostanie zaakceptowane, czy nie. W przypadku jakichkolwiek wątpliwości definicja ukończenia powinna być na tyle kompletna, aby wskazywała, jak postępować dalej. Opierając się tylko na tej definicji, zespół scrum decyduje, ile elementów backlogu produktu wybrać do sprintu.

Jest to minimum, czego oczekuje się od sprintu.

Wniosek

Z tego samouczka dowiedzieliśmy się, czym są 3 artefakty Scruma, kto jest ich właścicielem, a także niektóre z najlepszych praktyk, które pomogłyby nam tworzyć artefakty lepszej jakości. W naszych następnych samouczkach z tej serii omówimy zdarzenia Scruma i zobaczymy, jak je wykonać.

W naszym nadchodzącym samouczku „Scrum Wydarzenia , ”Szczegółowo omówimy każde zdarzenie Scrum!

POPRZEDNIA samouczek | NEXT Tutorial

rekomendowane lektury

^