Jak być dobrym Product Ownerem? – część 3 – Product Backlog (rejestr produktu)

W dwóch poprzednich częściach opowiadałem wam o klientach i produkcie. Dzisiaj chciałbym się skupić na rejestrze produktu, nazywanym z angielska backlogiem lub Product Ownerproduct backlogiem. Moim zdaniem jest to najważniejsze narzędzie pracy Ownera. Przede wszystkim dlatego, że backlog pokazuje, co w produkcie ma być zrobione. A jak ma być zbudowany i co ma w sobie mieć? Co czyni go narzędziem, bez którego trudno sobie wyobrazić dobrego Product Ownera? Zapraszam do przeczytania kolejnego artykułu oraz podzielenia się przemyśleniami.

Zacznijmy od cech charakterystycznych rejestru. Innymi słowy, jaki jest dobry backlog. Wydaje się, że jest:

  • przejrzysty– czyli możemy znaleźć to, co jest nam w danej chwili potrzebne, widać zadania które zespół będzie realizował “za chwilę” oraz takie, których realizacja jest dość odległa z uwagi na potrzebę udoskonalenia zadań,
  • umieszczony tak, aby każdy go widział (miał do niego dostęp)– product backlog to nie jest kartka papieru schowana w biurku Product Ownera. Nie jest wymagane, aby trzymać backlog na wielkiej tablicy, ale w taki sposób, aby móc do niego sięgnąć kiedy jest taka potrzeba,
  • wyrażony w sposób zrozumiały dla zespołu i interesariuszy– znaczy to tyle, że osoba postronna patrzy na zbiór historyjek, czy też innych zadań znajdujących się w rejestrze i wie, czego one dotyczą oraz co ma być efektem zrealizowania określonej grupy z nich,
  • uporządkowany– bardzo mi się podoba definicja Jeffa Sutherlanda dotycząca uporządkowanego backlogu. Na samej górze backlogu znajdują się zadań gotowe do realizacji, im niżej tym zadania się ca raz większe, mniej uszczegółowione,
  • wyestymowany– każde zadanie ma przypisaną wartość wyrażającą złożoność techniczną i/lub wartość biznesową. Zachęcam do poczytania artykułów Jacka dotyczących “No estimates” (recencja książki „No estimates” oraz artykuł o metodzie), ponieważ zasadnicze pytanie brzmi, czy zawsze musimy estymować.

Backlog zawiera różne zadania do zrobienia przez zespół developerski. Typy tych zadań to głównie historie użytkownika (user stories), czasami są to przypadki użycia (use cases), specyfikacje przez przykład (elementy zapisane w formacie Behaviour Driven Development), zadania techniczne oraz jakiekolwiek inne zadania.

To, co chcę wam przekazać to to, że nie jest istotne jak zapiszemy zadania w backlogu. Są zespoły, gdzie historie użytkownika są wymagane, ale są też zespoły, które wpisują tam tylko zadania techniczne ponieważ ich praca ma właśnie taką specyfikę. Najważniejsze wydaje się tutaj, aby elementy rejestru (zadania) były kawałkami “dostarczalnej” pracy. Czyli aby miały kryteria akceptacji (innymi słowy, jak zweryfikujemy dane zadanie, kiedy uznamy, że zostało ono skończone). Druga, nie mniej ważna sprawa, aby takie zadanie miało odpowiedni rozmiar.

Odpowiedni rozmiar zadania to kwestia, która martwi prawie wszystkie zespoły. Zadania za duże nie mogą zostać wykonane w skończonym czasie, co z jednej strony przekłada się na morale zespołu (ciągle od siebie nawzajem słyszą, że jeszcze trochę, już prawie skończyliśmy), a z drugiej strony Product Owner nie może dać interesariuszom wiarygodnej informacji, kiedy to lub następne zadania będą skończone.

Jest kilka technik pomagających zespołom tworzyć zadania, które da się szybko zrealizować. Innymi słowy tak “ciąć” funkcjonalność, aby kończyć zadania w przewidywalnym czasie i aby nie było problemów jak napisałem wyżej. Najbardziej wartościowe są trzy podstawowe techniki:

  • hamburger method wymyślony przez Gojko Adzicia- metoda pokazuje przez analogię do jedzenia hamburgera (wiele warstw takich jak warzywa, mięso, bułka), że zespół powinien się skupić na przeprowadzeniu implementacji przez wszystkie warstwy aplikacji. Skupienie się na tym, aby klient zobaczył jak najszybciej kawałek systemu, nawet jeśli przykładowo zastosujemy w nim ręczne przesyłanie plików, a nie automatyczne,
  • elephant carpacio, do którego scenariusz zrobił Henrik Kniberg oraz Alistair Cockurn– metoda ucząca zespół jak należy pisać software, aby jak najszybciej uzyskać wartość biznesową. Polecam Wam zrobienie opisanego ćwiczenia z zespołem tak, aby jak najwięcej nauki wyciągnąć z ćwiczenia dotyczącego pisania kalkulatora,
  • technika cięcia historyjek użytkownika zaproponowana przez Richarda Lawrenca– metoda pokazuje pewnego rodzaju checklistę, której wykonanie powinno w krokach doprowadzić nas do zadań w odpowiednim rozmiarze (czyli małych).

dilbert_po

Dobry element rejestru to także taki, który nie tylko jest mały, ale również spełnia inne kryteria. Metoda INVEST pokazuje, co jeszcze jest istotne. Nazwa tej techniki jest skrótem od pierwszych liter poszczególnych charakterystyk dobrego elementu rejestru. I tak:

  • Independent– każde nasze zadanie powinno być niezależne. Oznacza to, że w idealnym świecie zadania nie posiadają żadnych elementów uzależniających skończenie naszego zadania od innych zespołów,
  • Negotiable– zadania są negocjowalne. Oznacza to, że do momentu rozpoczęcia prac, można nad treścią i zakresem zadania pracować, zadanie jest jest ostatecznie spisane i zamknięte,
  • Valuable– zadanie jest wartościowe. Dostarcza nowej wartości, przede wszystkim dla użytkownika,
  • Estimable– zadanie jest estymowalne, czyli inaczej, że da się je wycenić. Każde zadanie, o czym pisałem wyżej, powinno (ale nie musi) mieć wycenioną przez zespół złożoność, czy to w skali Fibonacciego czy jakikolwiek inny sposób,
  • Sized appropriately or small– zadania jak najmniejsze, o czym pisałem wyżej,
  • Testable– zadanie jest testowalne, czyli zespół potrafi przetestować dane zadanie. Brzmi to może dziwnie, ale widziałem już wiele zadań, nad którymi zespół rozmyślał i dochodził do wniosku, że jednak tego się przetestować nie da. Przykładem może być tutaj postawienie nowego klastra z przypisanymi zasobami.

Jeżeli już mamy przejrzysty backlog wraz z zapisanymi w nim zadaniami, powinny one być spriorytetyzowane. Tak jak pokazuje to Sutherland, wysoko w backlogu znajdują się zadania już omówione, gotowe do wzięcia przez zespół. Im niżej w backlogu, tym zadania mogą być większe, jeszcze nieomówione, jak choćby pomysły dotyczące przyszłych realizacji. Priorytetyzację backlogu omówiłem w jednym z wcześniejszych wpisów. Zachęcam do zapoznania się z nim, ponieważ priorytetyzacja jest jednym z elementów zarządzania backlogiem. Najważniejszą kwestią jest tutaj fakt, aby Owner był świadomy możliwości porządkowania backlogu w różny sposób, wg różnych metod i kryteriów. I aby było to robione na bieżąco.

Na koniec chyba najważniejsze odnośnie priorytetyzacji. Zawsze o kolejności zadań w product backlogu decyduje właściciel produktu. Zespół, interesariusze i opinie użytkowników mają oczywiście wpływ na kolejność zadań, jednak po to mamy Ownera, aby na końcu to on wziął na siebie odpowiedzialność związaną z powiedzeniem, co zespół w danej chwili powinien robić.

Dodaj komentarz

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

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x