-
Gość
Rola Product Ownera
Rola Product Ownera
Przegląd sekcji
-
Po zapoznaniu się z tym modułem będziesz potrafił prosto przedstawić wizję produktu z którym pracujesz, dzięki czemu lepiej go zrozumiesz i będziesz potrafił zainspirować innych. Zaczniemy jednak od tego, co robi Product Owner, żebyś wiedział, czy to co dziś robisz lub robią Product Ownerzy w Twoim otoczeniu, oparte jest na transparencji inspekcji i adaptacji, które decydują o tym czy Scrum daje oczekiwane rezultaty. To pozwoli Ci kształtować proces dostarczania wartości, tak aby był coraz skuteczniejszy.
-
Po zapoznaniu się z tym rozdziałem będziesz mógł sam zdecydować, czy w twoim środowisku Scrum i podejście produktowe jest potrzebne, by pracować inaczej. Dowiesz się także, że praca z użyciem Scruma jest nieustannym uczeniem się. Dzięki temu zobaczysz, że Scrum jest czymś znacznie głębszym niż trzy artefakty, trzy role i pięć zdarzeń.
-
Po zapoznaniu się z tym rozdziałem zbudujesz model biznesowy dla produktu. Będzie to na pewno przydatne, kiedy następnym razem wpadniesz na pomysł, o którym pomyślisz "to byłby startup". Wtedy będziesz mógł to szybko rozpisać, by wiedzieć czy faktycznie warto w to inwestować. W codziennej pracy zrobienie takiego ćwiczenia daje nowe, świeże spojrzenie na budowany produkt.
-
Temat 4: Wyciągajmy wnioski z tego co wiemy - Przyrost. Znaczenie definicji ukończenia dla Produktu.
W tym rozdziale dowiesz się, dlaczego Przyrost jest najważniejszym artefaktem Scruma? Czy za dostarczenie Przyrostu odpowiada ktoś poza Zespołem Developerskim? Dlaczego koncentrujemy się na skończonym Przyroście a nie na wykonanej pracy? Jaka jest różnica pomiędzy wytwarzaniem przyrostowym a iteracyjnym? Dlaczego praca w sprintach pozbawiona ukończonego przyrostu to nie Scrum?
-
Po zapoznaniu się z tym rozdziałem objaśnisz, jakie znaczenie ma Product Backlog dla działania Zespołu Scrumowego. Dowiesz się, jak napisać historyjkę użytkownika. Poznasz model INVEST, który pozwoli ci powiedzieć, czy twoje historyjki są dobrej jakości. Usłyszysz o tym, dlaczego pisanie szczegółowej dokumentacji nie jest tak ważne jak rozmowa z Zespołem Developerskim. Zobaczysz, dlaczego warto grupować elementy Product Backlogu i poznasz osiem sposobów na cięcie historii.
-
Po zapoznaniu się z tym modułem będziesz wiedział na czym polega główne zadanie Product Ownera. Dowiesz się, jakie narzędzia mogą ci pomóc w porządkowaniu Product Backlogu. Będziesz wiedział, jak oddzielić to co pilne i ważne od tego co pilne i nieważne. Usłyszysz, jak można z zespołem rozmawiać o wartości dla klienta. Będziesz potrafił dzielić rzeczy na te, które trzeba zrobić i te, które można zrobić.
-
Po zapoznaniu się z tym modułem zrozumiesz, jak działa Planowanie Sprintu. Będziesz wiedział, z czego wynika jego znaczenie dla osiąganego rezultatu. Przeczytasz o tym, kto decyduje ile pracy Zespół Deweloperski wykona w sprincie. Będziesz wiedzieć jakich ram samoorganizacji potrzeba, żeby Planowanie zadziałało skutecznie. Usłyszysz, co powinno się wydarzyć podczas tego zdarzenia i dzięki temu będzie ci łatwiej pracować w roli PO.
-
Ten rozdział pozwoli ci zrozumieć znaczenie Przeglądu Sprintu dla skutecznego użycia Scruma. Dowiesz się co, poza pokazaniem przyrostu, składa się na dobry Przegląd. Zobaczysz, dlaczego to zdarzenie zamyka produktową pętlę uczenia. Będziesz wiedział, jak przekłada się Przegląd Sprintu na aktualizację Product Backlogu. Dostaniesz kolejne narzędzia – tym razem do wizualizacji dostarczanej wartości.
-
Po zapoznaniu się z tym rozdziałem połączysz ostatnie kropki związane z Pracą Product Ownera. Dowiesz się, kto może przerwać sprint i dlaczego. Będziesz wiedział, czy nadzorowanie codziennej pracy Zespołu Scrumowego jest potrzebne. Zobaczysz, czego możesz oczekiwać od Scrum Mastera, z którym będziesz współpracować.
-
Ten rozdział przyniesie ci wiedzę o podstawowych miarach używanych w pracy Product Ownera. Dowiesz się dlaczego ich użycie jest tak ważne dla oceny pracy w tej roli. Zapoznasz się z zestawem uproszczonych miar. Na koniec, dowiesz się, jakie miary proponuje Zarządzanie Oparte na Dowodach (Evidence Based Management).