Techniki i narzędzia usprawniające codzienną pracę Product Ownera

Artykuł

Techniki i narzędzia usprawniające codzienną pracę Product Ownera

Zwinne organizacje | Blog o Agile

Dobry właściciel produktu pamięta o empirycznym wymiarze Scruma i jego trzech filarach – przejrzystości, inspekcji i adaptacji – i robi wszystko, by maksymalizować wartość produktu.

W 2009 roku metodyka Scrum została oficjalnie zdefiniowana w dokumencie „The Scrum Guide”, w którym rolę właściciela produktu (ang. Product Owner) odzwierciedla jedno najważniejsze zdanie:

Właściciel produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy zespołu deweloperskiego.

To właśnie właściciel produktu jest odpowiedzialny za backlog produktu (ang. Product Backlog), w tym za jego treść, dostępność, przejrzystość i kolejność elementów. Zespół deweloperski odpowiada za wdrożenie tych elementów backlogu produktu, które znajdą się w backlogu Sprintu (ang. Sprint Backlog), dlatego tak ważne jest, by wszystkie elementy były w równym stopniu zrozumiałe dla członków zespołu deweloperskiego, a kolejność tych elementów pozwalała jak najlepiej zrozumieć cele i istotę produktu.

Zdając sobie sprawę z odpowiedzialności, jaka spoczywa na właścicielu produktu, możemy bez wątpienia powiedzieć, że w ogromnej mierze od niego właśnie zależy powodzenie projektu.

Jak więc usprawnić odpowiedzialną i złożoną pracę właściciela produktu?

Po pierwsze zastanówmy się, na jakie aspekty możemy podzielić codzienną pracę właściciela produktu. W celu zapewnienia zrozumienia, poprawnego podziału i ujęcia merytorycznego backlogu produktu, właściciel produktu w swojej pracy powinien wykorzystywać metodyki i techniki, które ułatwią osiągnięcie tych celów. W dalszej kolejności należy zastanowić się nad właściwymi narzędziami, które ułatwią dostępność i zarządzanie backlogiem produktu.

1. Czym jest produkt i czy wszyscy rozumiemy go tak samo, czyli mapowanie wpływu (ang. Impact Mapping)

Mapowanie wpływu to technika, która pozwala zespołowi Scrum zrozumieć, na jaką wartość dodaną dla organizacji przekłada się ich codzienna praca. Mapa wpływu nie skupia się, bowiem na produkcie, a przynajmniej nie tylko na nim – pozwala zobaczyć szerszy kontekst:

  • Dlaczego robimy to, co robimy, czyli jaki jest cel projektu,
  • Kto wpłynie na dostarczenie produktu i kim są jego potencjalni odbiorcy, czyli aktorzy,
  • Jak powinno zmienić się zachowanie aktorów po dostarczeniu produktu, czyli nasz wpływ na zmianę ich zachowania,
  • Co pozwoli nam wpłynąć na zmianę zachowania aktorów, czyli rozwiązania wspierające osiągnięcie oczekiwanych wpływów.

Mapa wpływu pozwala dostrzec rzeczywiste potrzeby docelowego odbiorcy produktu i skupić się na nich, zamiast na rozwiązaniu funkcjonalnym samym w sobie – rozwiązanie zawsze powinno mieć logiczne uzasadnienie. Dzięki pracy z mapą wpływu nie tylko jesteśmy w stanie zrozumieć istotę i cel wytwarzanego produktu, ale też zastanowić się, czy na pewno odpowiada on na potrzeby jego docelowych odbiorców i czy ich zachowanie zmieni się w oczekiwany sposób po wdrożeniu produktu. Mapa wpływu pozwala zrozumieć kontekst i poczynić zmiany strategiczne, na które w dalszych etapach projektu jest już po prostu za późno. Dlatego ważne jest, żeby mapowanie wpływu było pierwszym etapem prac projektowych nad produktem.

Przydatne narzędzia: Nie zaleca się projektowania mapy wpływu na urządzeniach mobilnych, a raczej rozpisanie jej na dużej tablicy, w celu zwiększenia przejrzystości i ułatwienia komunikacji między członkami zespołu.

2. Treść backlogu produktu, czyli historyjki użytkownika (ang. User Stories)

Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.

 Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product

Każdy, kto choć raz próbował przygotować backlog produktu, wie, ile pytań i wątpliwości może się pojawić: Czy moje wymagania będą jasne dla zespołu deweloperskiego? Czy założyłem odpowiednią granulację? Jakie nałożyć kryteria akceptacji? Ile czasu zajmie zespołowi deweloperskiemu wdrożenie tego wymagania? W jaki sposób sprawdzę, czy im się to udało?

Kluczem jest prawidłowe przegotowanie historyjek użytkownika (ang. User Stories), w czym może pomóc technika „Inputs – Outputs”.

  • Inputs, czyli wszystko to, co będzie nam potrzebne do przygotowania jakiejś funkcjonalności dla użytkownika: pieniądze, zasoby, narzędzia, technologie, analizy.
  • Outputs, czyli wszystko to, z czego użytkownik będzie mógł skorzystać: funkcjonalności, usługi, produkty.
  • Backlog produktu powinien składać się z outputów, czyli „dostarczalnych” elementów, z jasnymi kryteriami akceptacji i możliwie jak najlepiej testowalnych. Często elementy te zapisujemy w postaci historyjek użytkownika, choć nie jest to narzucone przez Scrum Guide.

 

Spójrzmy na przykład:

Historyjka: „Jako użytkownik aplikacji bankowej chcę na bieżąco widzieć, ile pieniędzy wydałem w danym miesiącu, by móc lepiej planować swoje wydatki.”

Output: wyświetlanie bieżącego stanu wydanych środków w danym miesiącu

Inputs: analiza konkurencji, PoC frameworków, przygotowanie algorytmu wyliczającego stan środków po każdej transakcji, zapewnienie bezpieczeństwa przetwarzania danych itp.

Outcome i impact, czyli nie zapominajmy o najważniejszym.

Podczas gdy output jest tym, co wytwarzamy, outcome i impact są tym, co dzieje się, gdy coś wytworzymy. Outcome może być zmianą zachowania, impact z kolei rzeczywistą wartością dodaną, na jakiej nam zależy z perspektywy strategii biznesowej. To outcome i impact powinny wyznaczać drogę do tworzenia outputów i inputów, a nie odwrotnie.

At the end of the day, your job is to minimize output, and maximize outcome and impact.

― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product

 

pl_Techniki_i_narzedzia_usprawniajace_codzienna_prace_Product_Ownera_infografika_1.png (1075×538)

Źródło: https://www.jpattonassociates.com/read-this-first/

Przydatne narzędzia: Podobnie jak w przypadku mapy wpływu, warto najpierw rozpisać historyjki na kartkach typu post-it, by później przenieść je na User Story Map, o której mowa w punkcie 3. Jeżeli chodzi o samo zarządzanie elementami backlogu, wybór narzędzi jest szeroki: JIRA Software, Zoho Sprints, Pivotal Tracker itp.

3. „Czy na pewno dobrze rozpisałem backlog?”, czyli User Story Mapping od Jeffa Pattona.

Mapa historyjek (ang. User Story Map) to nic innego, jak wizualna prezentacja wszystkich historyjek użytkowników. Nie tylko pozwala zobaczyć, czy tworzą sensowną całość w postaci ścieżki użytkownika (ang. Customer Journey), ale odpowiada też na pytanie, czy wszyscy mamy wspólne rozumienie produktu, a także pozwala nadać odpowiedni priorytet elementom backlogu.

Stories are the building blocks of communication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process — which is the most critical part of software development itself.

― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product

 

Jak zbudować mapę historyjek?

Dla przykładu weźmy mapę historyjek łatwą do przedstawienia w Scrumie. Na samej górze znajdą się historyjki zbyt duże, by można było je wycenić i wdrożyć w przeciągu jednego sprintu, które nie odzwierciedlają jednego outputu, a raczej ich zbiór. Takie historyjki na naszej Scrumowej mapie historyjek będą na samej górze – to epiki. Jednocześnie epiki stworzą logiczną całość ścieżki klienta. Pod każdą epiką znajdą się historyjki, o których była mowa w punkcie poprzednim. Zbiór historyjek pod jedną epiką powinien odzwierciedlać zbiór wymagań potrzebnych do jej zrealizowania. I tak pod epiką „znajdź produkt” może znaleźć się szereg historyjek, z których część okaże się krytyczna do realizacji epiki, a część będzie odzwierciedlać funkcjonalności niewymagane. To z kolei pozwoli nam uporządkować nasz backlog produktu, dzięki czemu łatwo zdecydujemy, które historyjki należy uwzględnić w najbliższym Sprincie, a które możemy odłożyć na późniejsze Sprinty. User Story Map pozwala nam zobaczyć szerszy kontekst, zrozumieć proces i może być przydatna na Sprint Planningach oraz podczas doskonalenia backlogu (ang. Backlog Refinement).

pl_Techniki_i_narzedzia_usprawniajace_codzienna_prace_Product_Ownera_infografika_2.png (1099×550)

Przydatne narzędzia: I w tym przypadku zalecane jest w pierwszej kolejności ułożenie historyjek na tablicy, by ułatwić dyskusję i ewentualne nanoszenie zmian. Gdy nasza mapa historyjek będzie gotowa, możemy przenieść ją do Easy Agile User Story Maps for Jira i z tego miejsca łatwiej nią zarządzać.

4. Krok w stronę priorytetyzacji, czyli MoSCoW

Sama technika nie jest częścią Scrum Guide’a, a „A Guide to the Business Analysis Body of Knowledge”, czyli świętej księgi analizy biznesowej. MoSCoW jest wykorzystywane szerzej – w analizie biznesowej i przy tworzeniu oprogramowania, w celu osiągnięcia wspólnego zrozumienia, co do wagi każdego z wymagań. Według „A Guide to the Business Analysis Body of Knowledge”, wersja 2.0, sekcja 6.1.5.2, wyróżnia się następujące kategorie MoSCoW:

  • M – MUST (musi być): wymaganie MUSI być spełnione.
  • S – SHOULD (powinien być): wymaganie ma wysoki priorytet i POWINNO BYĆ spełnione, jeżeli jest to możliwe.
  • C – COULD (może być): wymaganie jest pożądane i MOŻE BYĆ spełnione, ale nie musi. Jeżeli nie pozwolą na to zasoby, nie zostanie ono spełnione.
  • W – WON’T (nie będzie): wymaganie NIE BĘDZIE realizowane w danej iteracji, ale może zostać wzięte pod uwagę w przyszłej.

Technika MoSCoW wspiera jeden z trzech filarów Scrum, czyli przejrzystość. Dzięki nadaniu priorytetów cały zespół jest w stanie łatwiej planować pracę, lepiej zrozumieć potrzeby i cele produktu, a backlog staje się lepiej zarządzany. 

5. Historyjka historyjce nierówna, czyli estymacje i wyceny

Jeżeli projekt przechodzi w kolejną fazę, ale z podobnymi wymaganiami, pracuje nad nim ten sam zespół Scrum i trwa to już od jakiegoś czasu, ta część nie powinna sprawiać problemów. Wyzwania pojawiają się wtedy, gdy zespół nie zna siebie nawzajem ani swoich kompetencji, nie każdy wcześniej pracował w Scrumie, a produkt to coś zupełnie nowego w organizacji. Udało się go zrozumieć, rozpisać backlog i ustalić priorytety, ale to nie wszystko, bo wyniki trzeba mierzyć i raportować. Przejdźmy, zatem do estymacji i wycen.

Najpopularniejszą metodą estymacji w Scrum są tzw. Story Points. Nie jest to jedyna metoda, ale nie bez przyczyny zyskała ona największą popularność. Story Points to metoda estymacji relatywnej, w której my, ludzie, jesteśmy zdecydowanie lepsi, niż w estymowaniu bezwzględnym. Jeden Story Point jest więc względną jednostką miary, która pozwala zespołowi deweloperskiemu na oszacowanie wysiłku włożonego w dostarczenie danego elementu backlogu produktu w stosunku do jego pozostałych składowych. Znając dodatkowo prędkość (ang. Velocity) zespołu deweloperskiego w dostarczaniu prac, będziemy w stanie określić, ile elementów backlogu produktu będzie osiągalnych w trakcie jednego Sprintu.

Warto podkreślić, że za wszystkie szacowania odpowiedzialny jest zespół deweloperski, bo to właśnie jego członkowie będą tę pracę dostarczać. Jednak właściciel produktu w swojej kompetencji może, a nawet powinien pomagać zespołowi deweloperskiemu w dokonywaniu odpowiednich wyborów – w końcu to on jest odpowiedzialny za maksymalizację ich pracy.

Przydatne narzędzia: Agile Poker for Jira Planning and Estimation Tool, zwłaszcza, kiedy zespół deweloperski jest w kilku różnych lokalizacjach. Jeżeli zespół może się spotkać, wystarczą fizyczne kartki z rozpisanymi punktami.

6. “Mamy to! Nie ruszajmy, bo popsujemy”, czyli kilka słów o doskonaleniu backlogu (ang. Backlog Refinement).

Zgodnie ze Scrum Guidem, Backlog Refinement to „działanie polegające na dodawaniu szczegółów, oszacowań i porządkowaniu Product Backlogu”. Doskonalenie backlogu nie jest więc wydarzeniem (ang. Event), a ciągłą pracą, jako że elementy backlogu produktu mogą być uaktualniane przez właściciela produktu lub za jego zgodą w każdym momencie trwania projektu. Nie jest również powiedziane, kto jest odpowiedzialny za Backlog Refinement, z tego względu, że za pewne części odpowiedzialność ponosi zespół deweloperski, za inne – właściciel produktu, za jeszcze inne – Scrum Master. Właściciel produktu powinien przede wszystkim zadbać o to, by produkt był zrozumiały, nie tylko na początku projektu, ale cały czas – zespół deweloperski powinien mieć jasną wizję celu ich pracy. Poniżej kilka przykładowych czynności, które powinny być inicjowane w trakcie doskonalenia backlogu przez właściciela produktu:

  1. Upewnienie się, że mapa wpływu jest aktualna i zrozumiała dla wszystkich członków zespołu Scrumowego,
  2. Dyskutowanie na temat produktu i jego użyteczności nie tylko z zespołem Scrumowym, ale ze wszystkimi aktorami,
  3. Przegląd elementów backlogu i doskonalenie go, by uzyskać jak najwyższą jakość prac zespołu deweloperskiego,
  4. Analiza i ustalenie wysokopoziomowych celów produktu, a także tych na najbliższy Sprint,
  5. Wykorzystanie wszystkich technik i narzędzi, które pomogą w maksymalizacji wartości produktu.

Podsumowanie

Należy pamiętać, że wymienione techniki to jedynie narzędzia w pracy właściciela produktu, które mogą pomóc mu usprawnić jego codzienna pracę. Nic jednak nie zastąpi ciągłej chęci doskonalenia swoich umiejętności, zwiększania wiedzy, a także nauki na błędach, by być jak najlepszym właścicielem produktu. Dobry właściciel produktu pamięta o empirycznym wymiarze Scruma i jego trzech filarach – przejrzystości, inspekcji i adaptacji – i robi wszystko, by maksymalizować wartość produktu.

Autor:
Paulina Lipska, Ekspert w zespole doradztwa technologicznego, Deloitte

„Zwinne organizacje”
Skuteczna pigułka wiedzy o agile

Nie przegap najnowszych treści

Czy ta strona była pomocna?