Product owner: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Dodanie TL;DR) |
mNie podano opisu zmian |
||
| (Nie pokazano 15 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''Product owner''' (pol. [[właściciel]] produktu) jest jedną z trzech ról wchodzących w skład [[Metodyka SCRUM|zespołu Scrumowego]]. Podczas pracy reprezentuje on klienta, a więc to jego zadaniem jest czuwanie nad pracą [[Zespół deweloperski|zespołu deweloperskiego]] w taki sposób, aby korzyści płynące z rozwoju projektu, a co za tym idzie, jego [[wartość]] była jak najwyższa. Właściciel projektu decyduje co powinno zostać zaimplementowane podczas najbliższej pracy zespołu oraz do kiedy powinien zostać dostarczony następny inkrement produktu. Podczas swojej pracy Product owner zbiera wszystkie [[potrzeby]] zgłaszane przez klienta po czym, na ich podstawie, tworzy pełne opisy wymagań, które przekazuje potem zespołowi developerskiemu. Obowiązkiem [[Produkt]] ownera jest też [[akceptacja]] efektów pracy zespołu. | |||
'''Product owner''' (pol. [[właściciel]] produktu) jest jedną z trzech ról wchodzących w skład [[Metodyka SCRUM|zespołu Scrumowego]]. Podczas pracy reprezentuje on klienta, a więc to jego zadaniem jest czuwanie nad pracą [[Zespół deweloperski|zespołu deweloperskiego]] w taki sposób, aby korzyści płynące z rozwoju projektu, a co za tym idzie, jego [[wartość]] była jak najwyższa. Właściciel projektu decyduje co powinno zostać zaimplementowane podczas najbliższej pracy zespołu oraz do kiedy powinien zostać dostarczony następny inkrement produktu. Podczas swojej pracy | |||
Do najważniejszych odpowiedzialności product ownera należy prowadzenie i [[zarządzanie]] [[Backlog produktu|Backlogiem Produktu]]. | Do najważniejszych odpowiedzialności product ownera należy prowadzenie i [[zarządzanie]] [[Backlog produktu|Backlogiem Produktu]]. | ||
| Linia 23: | Linia 6: | ||
==Zarządzanie Product Backlogiem== | ==Zarządzanie Product Backlogiem== | ||
Podczas pracy z Backlogiem Product owner powinien skupiać się na następujących aspektach<ref>Schwaber K. (2013) | Podczas pracy z Backlogiem Product owner powinien skupiać się na następujących aspektach<ref>Schwaber K. (2013), s. 5</ref>: | ||
* '''każdy z elementów Backlogu Produktu powinien być jasno określony''': to czy [[zespół]] developerski poprawnie zrozumie jakie stawia się przed nim zadania jest kluczem do poprawnego ich wykonania, | * '''każdy z elementów Backlogu Produktu powinien być jasno określony''': to czy [[zespół]] developerski poprawnie zrozumie jakie stawia się przed nim zadania jest kluczem do poprawnego ich wykonania, | ||
* '''Product [[Backlog]] powinien być poprawnie | * '''Product [[Backlog]] powinien być poprawnie spriorytetyzowany''': ponieważ zadaniem zespołu deweloperskiego jest ciągły [[rozwój]] produktu ważnym jest, aby zadania wykonywane były w kolejności od najbardziej do najmniej priorytetowego co pozwoli osiągać jak największą [[korzyść]] z aktualnie zamierzonych celi, | ||
* '''[[zdolność]] do pracy zespołu developerskiego powinna być maksymalnie wykorzystana''': jednym z najbardziej specyficznych aspektów zadań powierzonych zespołowi developerskiemu jest ich [[zapotrzebowanie]] na ilość osób, które mogą pracować nad problemem równocześnie. Sprawia to, iż mimo posiadania jasno zoptymalizowanej pod względem wartości dla całego projektu kolejki zadań, właściciel projektu powinien tak dobierać kolejność oraz ilość zadań dla zespołu, aby jak największa liczba osób mogła pracować równolegle oraz tak, aby zadania wykonywane przez poszczególne osoby z zespołu developerskiego nie blokowały się wzajemnie, | * '''[[zdolność]] do pracy zespołu developerskiego powinna być maksymalnie wykorzystana''': jednym z najbardziej specyficznych aspektów zadań powierzonych zespołowi developerskiemu jest ich [[zapotrzebowanie]] na ilość osób, które mogą pracować nad problemem równocześnie. Sprawia to, iż mimo posiadania jasno zoptymalizowanej pod względem wartości dla całego projektu kolejki zadań, właściciel projektu powinien tak dobierać kolejność oraz ilość zadań dla zespołu, aby jak największa liczba osób mogła pracować równolegle oraz tak, aby zadania wykonywane przez poszczególne osoby z zespołu developerskiego nie blokowały się wzajemnie, | ||
* '''[[dostępność]] Product Backlogu''': powyższe kryteria opisują jak powinien wyglądać [[Backlog produktu]] co do jego struktury, jednak jego najważniejszym aspektem jest jego dostępność. [[Planowanie sprintu|Sprint planning]] jest momentem, gdy Product owner osobiście przedstawia i tłumaczy aktualny [[plan]] pracy dla zespołu. Po tym wydarzeniu w trakcie [[Sprint|sprintu]] mogą wydarzyć się momenty, gdy Product owner nie jest dostępny dla zespołu, aby zapobiec przestojowi prac rozwojowych niezwykle ważne jest to, aby cały zespół miał dostęp do Backlogu produktu, aby móc odnieść się do niego w każdym momencie. | * '''[[dostępność]] Product Backlogu''': powyższe kryteria opisują jak powinien wyglądać [[Backlog produktu]] co do jego struktury, jednak jego najważniejszym aspektem jest jego dostępność. [[Planowanie sprintu|Sprint planning]] jest momentem, gdy Product owner osobiście przedstawia i tłumaczy aktualny [[plan]] pracy dla zespołu. Po tym wydarzeniu w trakcie [[Sprint|sprintu]] mogą wydarzyć się momenty, gdy Product owner nie jest dostępny dla zespołu, aby zapobiec przestojowi prac rozwojowych niezwykle ważne jest to, aby cały zespół miał dostęp do Backlogu produktu, aby móc odnieść się do niego w każdym momencie. | ||
<google>n</google> | |||
==Prawa i obowiązki Product ownera== | ==Prawa i obowiązki Product ownera== | ||
Jak wspomniano wcześniej celem pracy właściciela produktu jest maksymalizowanie wartości prac nad produktem. Aby Product owner był przy tym efektywny, każda osoba związana z projektem musi '''respektować i podporządkowywać''' się jego decyzjom. Oznacza to, że nikt inny nie ma prawa zlecać dodatkowych prac, niebędących uwzględnionych w Backlogu produktu, zespołowi deweloperskiemu (w tym zmiany priorytetów zadań, które się już w nim znajdują) oraz sam zespół nie może podejmować dodatkowych działań bez wiedzy i akceptacji ze strony Product ownera. Warto zaznaczyć w tym miejscu, że Product owner nie posiada żadnego autorytetu nad samą pracą zespołu deweloperskiego, tzn. nie ma wpływu na to, jak zadania zostaną rozdysponowane już wewnątrz samego zespołu. Zadania wykonywane przez właściciela projektu mogę być delegowane do innych członków zespołu deweloperskiego, jednak wciąż to Product owner będzie odpowiadał za ich poprawne wykonanie. | Jak wspomniano wcześniej celem pracy właściciela produktu jest maksymalizowanie wartości prac nad produktem. Aby Product owner był przy tym efektywny, każda osoba związana z projektem musi '''respektować i podporządkowywać''' się jego decyzjom. Oznacza to, że nikt inny nie ma prawa zlecać dodatkowych prac, niebędących uwzględnionych w Backlogu produktu, zespołowi deweloperskiemu (w tym zmiany priorytetów zadań, które się już w nim znajdują) oraz sam zespół nie może podejmować dodatkowych działań bez wiedzy i akceptacji ze strony Product ownera. Warto zaznaczyć w tym miejscu, że Product owner nie posiada żadnego autorytetu nad samą pracą zespołu deweloperskiego, tzn. nie ma wpływu na to, jak zadania zostaną rozdysponowane już wewnątrz samego zespołu. Zadania wykonywane przez właściciela projektu mogę być delegowane do innych członków zespołu deweloperskiego, jednak wciąż to Product owner będzie odpowiadał za ich poprawne wykonanie. | ||
==Cechy dobrego Product ownera== | ==Cechy dobrego Product ownera== | ||
Analizując zadania jakie niesie ze sobą [[praca]] Właściciela produktu można określić pewien uniwersalny zestaw cech jakie powinien on posiadać <ref>Sverrisdottir H. (2014). | Analizując zadania jakie niesie ze sobą [[praca]] Właściciela produktu można określić pewien uniwersalny zestaw cech jakie powinien on posiadać <ref>Sverrisdottir H. (2014). , s. 260</ref>: | ||
* '''[[umiejętności]] komunikacyjne oraz negocjacyjne''': ponieważ codzienna praca Produkt ownera niesie ze sobą codziennie trudne decyzje do podjęcia dla dobra projektu, | * '''[[umiejętności]] komunikacyjne oraz negocjacyjne''': ponieważ codzienna praca Produkt ownera niesie ze sobą codziennie trudne decyzje do podjęcia dla dobra projektu, | ||
* '''[[autorytet]]''': w codziennej pracy musi on koordynować życzenia klienta i dowodzić pracą zespołu deweloperskiego, co wymaga posiadania odpowiedniego autorytetu i posłuchu zarówno u pierwszych jak i u drugich, | * '''[[autorytet]]''': w codziennej pracy musi on koordynować życzenia klienta i dowodzić pracą zespołu deweloperskiego, co wymaga posiadania odpowiedniego autorytetu i posłuchu zarówno u pierwszych jak i u drugich, | ||
* '''[[kwalifikacje]]''': aby dostarczać produkty najlepszej jakości musi dokładnie rozumieć ich istotę, | * '''[[kwalifikacje]]''': aby dostarczać produkty najlepszej jakości musi dokładnie rozumieć ich istotę, | ||
* '''decyzyjność''': | * '''decyzyjność''': Product owner musi samodzielnie umieć podejmować decyzję, jaka powinna być priorytetyzacja zadań i kiedy [[zadanie]] należy odrzucić oraz przyjmować konsekwencje tych decyzji, | ||
* '''umiejętność planowania długoterminowego''': ponieważ każda źle podjęta [[decyzja]] w teraźniejszości będzie niosła konsekwencje w przyszłości i będzie miała wpływ na przyszłą | * '''umiejętność planowania długoterminowego''': ponieważ każda źle podjęta [[decyzja]] w teraźniejszości będzie niosła konsekwencje w przyszłości i będzie miała wpływ na przyszłą pracę nad projektem. | ||
== | {{infobox5|list1={{i5link|a=[[Zespół deweloperski]]}} — {{i5link|a=[[Kształtowanie zespołu]]}} — {{i5link|a=[[Velocity]]}} — {{i5link|a=[[Sprint]]}} — {{i5link|a=[[Zarządzanie czasem]]}} — {{i5link|a=[[Prawo Parkinsona]]}} — {{i5link|a=[[Planowanie sprintu]]}} — {{i5link|a=[[Motywacja pracowników w zespole projektowym]]}} — {{i5link|a=[[Praca zespołowa]]}} — {{i5link|a=[[Agencja rozwoju regionalnego]]}} }} | ||
==Przypisy== | ==Przypisy== | ||
<references /> | <references /> | ||
==Bibliografia== | |||
<noautolinks> | |||
* Schwaber K. (2013), ''Scrum Guide, Przewodnik do Scrumie: Reguły gry'' | |||
* Sverrisdottir H. (2014), ''The role of the product owner in scrum - comparision between theory and practices'', Procedia - Social and Behavioral Sciences, nr 119 | |||
</noautolinks> | |||
{{a|Paweł Ciupek}} | {{a|Paweł Ciupek}} | ||
[[Kategoria:Role projektowe]] | |||
{{#metamaster:description|Product owner w SCRUM to rola reprezentująca klienta, dbająca o wartość projektu i zarządzająca Backlogiem Produktu. Decyduje o implementacji i dostarczaniu kolejnych wersji produktu.}} | |||
Aktualna wersja na dzień 08:32, 8 gru 2023
Product owner (pol. właściciel produktu) jest jedną z trzech ról wchodzących w skład zespołu Scrumowego. Podczas pracy reprezentuje on klienta, a więc to jego zadaniem jest czuwanie nad pracą zespołu deweloperskiego w taki sposób, aby korzyści płynące z rozwoju projektu, a co za tym idzie, jego wartość była jak najwyższa. Właściciel projektu decyduje co powinno zostać zaimplementowane podczas najbliższej pracy zespołu oraz do kiedy powinien zostać dostarczony następny inkrement produktu. Podczas swojej pracy Product owner zbiera wszystkie potrzeby zgłaszane przez klienta po czym, na ich podstawie, tworzy pełne opisy wymagań, które przekazuje potem zespołowi developerskiemu. Obowiązkiem Produkt ownera jest też akceptacja efektów pracy zespołu. Do najważniejszych odpowiedzialności product ownera należy prowadzenie i zarządzanie Backlogiem Produktu.
TL;DR
Product Owner jest rolą w Metodyce SCRUM, reprezentującą klienta i zarządzającą pracą zespołu deweloperskiego. Odpowiada za tworzenie opisów wymagań, akceptację efektów pracy zespołu i zarządzanie Backlogiem Produktu. Kluczowe odpowiedzialności Product Ownera to jasne określenie zadań, poprawna priorytetyzacja, maksymalne wykorzystanie zespołu deweloperskiego i dostępność Backlogu. Posiada autorytet decydowania, a dobre cechy to umiejętności komunikacyjne, autorytet, kwalifikacje, decyzyjność i umiejętność planowania.
Zarządzanie Product Backlogiem
Podczas pracy z Backlogiem Product owner powinien skupiać się na następujących aspektach[1]:
- każdy z elementów Backlogu Produktu powinien być jasno określony: to czy zespół developerski poprawnie zrozumie jakie stawia się przed nim zadania jest kluczem do poprawnego ich wykonania,
- Product Backlog powinien być poprawnie spriorytetyzowany: ponieważ zadaniem zespołu deweloperskiego jest ciągły rozwój produktu ważnym jest, aby zadania wykonywane były w kolejności od najbardziej do najmniej priorytetowego co pozwoli osiągać jak największą korzyść z aktualnie zamierzonych celi,
- zdolność do pracy zespołu developerskiego powinna być maksymalnie wykorzystana: jednym z najbardziej specyficznych aspektów zadań powierzonych zespołowi developerskiemu jest ich zapotrzebowanie na ilość osób, które mogą pracować nad problemem równocześnie. Sprawia to, iż mimo posiadania jasno zoptymalizowanej pod względem wartości dla całego projektu kolejki zadań, właściciel projektu powinien tak dobierać kolejność oraz ilość zadań dla zespołu, aby jak największa liczba osób mogła pracować równolegle oraz tak, aby zadania wykonywane przez poszczególne osoby z zespołu developerskiego nie blokowały się wzajemnie,
- dostępność Product Backlogu: powyższe kryteria opisują jak powinien wyglądać Backlog produktu co do jego struktury, jednak jego najważniejszym aspektem jest jego dostępność. Sprint planning jest momentem, gdy Product owner osobiście przedstawia i tłumaczy aktualny plan pracy dla zespołu. Po tym wydarzeniu w trakcie sprintu mogą wydarzyć się momenty, gdy Product owner nie jest dostępny dla zespołu, aby zapobiec przestojowi prac rozwojowych niezwykle ważne jest to, aby cały zespół miał dostęp do Backlogu produktu, aby móc odnieść się do niego w każdym momencie.
Prawa i obowiązki Product ownera
Jak wspomniano wcześniej celem pracy właściciela produktu jest maksymalizowanie wartości prac nad produktem. Aby Product owner był przy tym efektywny, każda osoba związana z projektem musi respektować i podporządkowywać się jego decyzjom. Oznacza to, że nikt inny nie ma prawa zlecać dodatkowych prac, niebędących uwzględnionych w Backlogu produktu, zespołowi deweloperskiemu (w tym zmiany priorytetów zadań, które się już w nim znajdują) oraz sam zespół nie może podejmować dodatkowych działań bez wiedzy i akceptacji ze strony Product ownera. Warto zaznaczyć w tym miejscu, że Product owner nie posiada żadnego autorytetu nad samą pracą zespołu deweloperskiego, tzn. nie ma wpływu na to, jak zadania zostaną rozdysponowane już wewnątrz samego zespołu. Zadania wykonywane przez właściciela projektu mogę być delegowane do innych członków zespołu deweloperskiego, jednak wciąż to Product owner będzie odpowiadał za ich poprawne wykonanie.
Cechy dobrego Product ownera
Analizując zadania jakie niesie ze sobą praca Właściciela produktu można określić pewien uniwersalny zestaw cech jakie powinien on posiadać [2]:
- umiejętności komunikacyjne oraz negocjacyjne: ponieważ codzienna praca Produkt ownera niesie ze sobą codziennie trudne decyzje do podjęcia dla dobra projektu,
- autorytet: w codziennej pracy musi on koordynować życzenia klienta i dowodzić pracą zespołu deweloperskiego, co wymaga posiadania odpowiedniego autorytetu i posłuchu zarówno u pierwszych jak i u drugich,
- kwalifikacje: aby dostarczać produkty najlepszej jakości musi dokładnie rozumieć ich istotę,
- decyzyjność: Product owner musi samodzielnie umieć podejmować decyzję, jaka powinna być priorytetyzacja zadań i kiedy zadanie należy odrzucić oraz przyjmować konsekwencje tych decyzji,
- umiejętność planowania długoterminowego: ponieważ każda źle podjęta decyzja w teraźniejszości będzie niosła konsekwencje w przyszłości i będzie miała wpływ na przyszłą pracę nad projektem.
| Product owner — artykuły polecane |
| Zespół deweloperski — Kształtowanie zespołu — Velocity — Sprint — Zarządzanie czasem — Prawo Parkinsona — Planowanie sprintu — Motywacja pracowników w zespole projektowym — Praca zespołowa — Agencja rozwoju regionalnego |
Przypisy
Bibliografia
- Schwaber K. (2013), Scrum Guide, Przewodnik do Scrumie: Reguły gry
- Sverrisdottir H. (2014), The role of the product owner in scrum - comparision between theory and practices, Procedia - Social and Behavioral Sciences, nr 119
Autor: Paweł Ciupek
