Visual Paradigm Desktop | 
Visual Paradigm Online
Tworzenie uporządkowanego listy zadań jest fundamentem 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 ustalenie 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, jaką należy wprowadzić w produkcie. 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 pracowanie nad niskowartościowymi funkcjami, pominięcie kluczowych zależności lub wyczerpanie się z powodu rozrostu zakresu. Ten poradnik zapewnia Ci sólidy punkt wyjścia.
Zanim zaczniesz wypełniać listę, upewnij się, że masz następujące elementy gotowe. Ta przygotowawcza praca oszczędza czas podczas fazy rzeczywistego tworzenia.
Zdefiniuj długoterminowy cel produktu. Jakie problemy rozwiązujesz? Kto jest docelowym odbiorcą? 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, wspólny 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 [typ użytkownika], chcę [cel], ponieważ [powód].
Przykład podziału 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 priorytetyzacji, 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 „Pozwól użytkownikom pobrać dane ich profilu”. 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 głosować nad szacunkami. 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 | Łatwy w obsłudze, mieści się w widoku | Tysiące niepołączonych elementów |
| Aktualizacje | Aktualizowane co tydzień lub co dwa tygodnie | Stałe przez miesiące |
Tworzenie złożonej listy zadań Agile to podstawowa umiejętność w dostarczaniu wartości. Postępując zgodnie z tymi krokami, 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.