Visual Paradigm Desktop | 
Visual Paradigm Online
Tworzenie uporządkowanego listy zadań jest podstawą każdej skutecznej inicjatywy Agile. Ten dokument przedstawia proces tworzenia funkcjonalnego Agile Product Backlog. Skupiamy się na praktycznych krokach, które można szybko wykonać, zachowując przy tym jakość i jasność. Celem jest stworzenie jasnego szlaku dla zespołu bez zanurzania się w nadmiarze administracyjnych obowiązków.
Agile Product Backlog to uporządkowana lista wszystkiego, co jest znane jako potrzebne w produkcie. Jest to jedyny źródło wymagań dla każdej zmiany, która ma zostać wprowadzona w produkt. Nie jest to po prostu lista zadań do wykonania; jest to dynamiczny artefakt, który ewoluuje wraz z produktem i zmieniającymi się warunkami rynkowymi.
Bez dobrze utrzymywanego backlogu zespół ryzykuje pracować nad niskowartościowymi funkcjami, pominąć kluczowe zależności lub wyczerpać się z powodu rozrostu zakresu. Ten poradnik zapewnia Ci sólidy punkt wyjścia.
Zanim zaczniesz wypełniać listę, upewnij się, że masz poniższe elementy ustawione. Ta przygotowawcza praca oszczędza czas podczas fazy tworzenia.
Zdefiniuj długoterminowy cel produktu. Jakie problemy rozwiązujesz? Kto jest docelową grupą odbiorców? Bez jasnej wizji elementy backlogu będą miały brak kierunku.
Zbierz początkowe wymagania od kluczowych stakeholderów. Nie potrzebujesz każdej szczegółowości, ale potrzebujesz ogólnych potrzeb, aby rozpocząć tworzenie epik.
Zidentyfikuj przestrzeń fizyczną lub cyfrową, gdzie zespół może oglądać i edytować backlog. Może to być tablica, udostępniony dokument lub tablica zarządzania. Unikaj konkretnych nazw dostawców; skup się na przydatności narzędzia.
Ten rozdział szczegółowo opisuje proces skutecznego wypełniania Twojego backlogu. Naszym celem jest ukończenie podstawowej struktury w ciągu 30 minut.
Zacznij od dużego obrazu. Epiki to duże obszary pracy, które można podzielić na mniejsze zadania. Nie martw się jeszcze szczegółami.
Przykład:
Epic nie mogą być zbyt duże na jeden sprint. Podziel je na historie użytkownika. Historia użytkownika opisuje funkcję z perspektywy osoby, która ją chce.
Użyj standardowego formatu:
Jako [rodzaj użytkownika], chcę [cel], ponieważ [powód].
Przykładowy podział z Epica A:
Historia użytkownika nie jest ukończona bez jasnych kryteriów sukcesu. Są to warunki, które muszą zostać spełnione, aby historia była uznana za zakończoną.
Użyj punktów wyboru, aby wypisać konkretne wymagania. To usuwa niepewność podczas rozwoju i testowania.
| Składnik | Definicja | Przykład |
|---|---|---|
| Wejście | Jakie dane są wymagane? | Adres e-mail, hasło |
| Proces | Co się dzieje, gdy zostanie podjęta działanie? | Sprawdzenie walidacji, e-mail wysłany |
| Wyjście | Jaki jest wynik? | Komunikat sukcesu, przekierowanie do pulpitu |
Uporządkuj elementy backlogu na podstawie wartości i priorytetu. Elementy na szczycie powinny być najważniejsze dla kolejnego sprintu. Użyj frameworku priorytetów, aby podejmować obiektywne decyzje.
Powszechnie stosowane metody to:
Aby upewnić się, że budujesz właściwe rzeczy, użyj strukturalnego podejścia do porządkowania elementów. Ta tabela przedstawia dwa powszechnie stosowane metody.
| Metoda | Najlepiej używane do | Jak to działa |
|---|---|---|
| MoSCoW | Zgodność z przepisami lub ścisłe terminy | Podziel każdy element na jedną z czterech kategorii. Skup się wyłącznie na „Muszą mieć” w pierwszej wersji. |
| Wartość wobec wysiłku | Zespoły ograniczone zasobami | Oceniaj elementy według skali 1–5 pod względem wartości i według skali 1–5 pod względem wysiłku. Ustal priorytety dla elementów o wysokiej wartości i niskim wysiłku. |
Jakość Twojego backlogu zależy od jakości Twoich historii użytkownika. Nieprecyzyjne historie prowadzą do marnotrawstwa wysiłku i niezgodnych oczekiwań. Postępuj zgodnie z tymi wskazówkami, aby zapewnić jasność.
Upewnij się, że Twoje historie spełniają te standardy:
Pisz dla użytkownika końcowego, a nie dla programisty. Zamiast mówić „Zaimplementuj punkt końcowy API”, powiedz „Zezwól użytkownikom na pobranie ich danych profilowych”. To utrzymuje skupienie na wartości.
Dołącz zrzuty ekranu, mockup-y lub linki do plików projektowych, jeśli są dostępne. Pomoc wizualna znacznie zmniejsza błędy interpretacji.
Tworzenie backlogu to nie jednorazowy wydarzenie. Wymaga ciągłego doskonalenia, często nazywanego przetwarzaniem. Zapewnia to, że górna część listy pozostaje gotowa do następnego sprintu.
W trakcie tych sesji zespół powinien:
Nawet doświadczone zespoły popełniają błędy podczas ustawiania swojego backlogu. Bądź na baczności przed tymi częstymi błędami.
Gdy Twój backlog zostanie wypełniony, musisz oszacować wymagane wysiłki. Pomaga to w planowaniu sprintów.
Używaj porównania względnego zamiast godzin. Przypisz punkty (np. ciąg Fibonacciego: 1, 2, 3, 5, 8) w zależności od złożoności, wysiłku i ryzyka.
Zbierz zespół, aby zagłosować na szacunki. Zachęca to do dyskusji i zapewnia wspólną rozumienie wymagań.
Dług techniczny akumuluje się, gdy wybiera się szybkie rozwiązania zamiast solidnych. Musi być jawnie zarządzany w backlogu.
Ignorowanie długu w końcu spowolni rozwój. Traktuj go jako pierwszorzędną kwestię w planowaniu.
Backlog to dokument żywy. Wymaga opieki, aby pozostać użytecznym.
Spójność to klucz. Jeśli przestaniesz aktualizować backlog, stanie się on rekordem historycznym, a nie narzędziem planowania.
Backlog to narzędzie komunikacji. Mostuje luki między potrzebami biznesowymi a wykonaniem technicznym.
Upewnij się, że backlog jest widoczny dla wszystkich. Jeśli stakeholderzy nie mogą zobaczyć planu, nie mogą udzielić feedbacku.
W trakcie sesji dopasowania upewnij się, że deweloperzy i właściciele produktu zgadzają się, jak wygląda „gotowe”.
Upewnij się, że informacje są łatwo dostępne. Unikaj chowania kluczowych szczegółów w długich dokumentach.
Wymagania będą się zmieniać. Jest to normalne w Agile. Nie opieraj się zmianie; dostosuj swój backlog.
Nigdy nie ignoruj prośby stakeholdera, jeśli przynosi wartość. Przeprowadź ponowną ocenę kolejności i odpowiednio dostosuj plan.
Jak możesz wiedzieć, czy Twoja lista zadań jest zdrowa? Szukaj tych wskaźników.
| Wskaźnik | Stan zdrowy | Stan chory |
|---|---|---|
| Górne elementy | Dokładnie zdefiniowane, gotowe do sprintu | Nieokreślone, brak kryteriów akceptacji |
| Dolne elementy | Niski priorytet, możliwe archiwizowanie | Wysoki priorytet, zatopione głęboko w liście |
| Rozmiar | Umiarkowany, mieści się w widoku | Tysiące niepowiązanych elementów |
| Aktualizacje | Aktualizowane co tydzień lub co dwa tygodnie | Stałe przez miesiące |
Tworzenie Agile listy zadań produktu to podstawowa umiejętność w dostarczaniu wartości. Przestrzegając tych kroków, tworzysz jasny kierunek dla Twojego zespołu. Proces jest iteracyjny. W miarę nabywania doświadczenia dopasujesz własne metody.
Skup się na przejrzystości, współpracy i ciągłym doskonaleniu. Dobrze utrzymywana lista zadań umożliwia zespołowi spójnie dostarczać wysokiej jakości produkty. Zacznij od podstaw przedstawionych tutaj i rozwijaj swój proces wraz z rozwojem produktu.
Pamiętaj, że celem nie jest doskonałość od pierwszego dnia. Celem jest postęp. Zacznij od wizji, rozłóż ją na części, ustal priorytety i zacznij pracować. Lista zadań dojrzeje razem z Twoim produktem.