Product owner: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Infobox update) |
(LinkTitles.) |
||
| Linia 16: | Linia 16: | ||
'''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 Produkct 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 <ref> Pfahl D. (2014). [https://courses.cs.ut.ee/MTAT.03.094/2015_fall/uploads/Main/SE2014-handout11.pdf ''Lecture 11: Agile/Lean Methods''], s. 5</ref>. | '''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 Produkct 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 <ref> Pfahl D. (2014). [https://courses.cs.ut.ee/MTAT.03.094/2015_fall/uploads/Main/SE2014-handout11.pdf ''Lecture 11: Agile/Lean Methods''], s. 5</ref>. | ||
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]]. | ||
==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). [http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-pl.pdf Scrum Guide, ''Przewodnik do Scrumie: Regułu gry''], s. 5</ref>: | Podczas pracy z Backlogiem Product owner powinien skupiać się na następujących aspektach<ref>Schwaber K. (2013). [http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-pl.pdf Scrum Guide, ''Przewodnik do Scrumie: Regułu gry''], s. 5</ref>: | ||
<google>t</google> | <google>t</google> | ||
* '''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 sprioretyzowany''': 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, | * '''Product [[Backlog]] powinien być poprawnie sprioretyzowany''': 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. | ||
==Prawa i obowiązki Product ownera== | ==Prawa i obowiązki Product ownera== | ||
| Linia 32: | Linia 32: | ||
==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). [https://www.academia.edu/6670352/The_role_of_the_product_owner_in_scrum_-comparison_between_theory_and_practices ''The role of the product owner in scrum - comparision between theory and practices''], "Procedia - Social and Behavioral Sciences", nr 119, s. 260</ref>: | 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). [https://www.academia.edu/6670352/The_role_of_the_product_owner_in_scrum_-comparison_between_theory_and_practices ''The role of the product owner in scrum - comparision between theory and practices''], "Procedia - Social and Behavioral Sciences", nr 119, 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ść''': Produkt owner musi samodzielnie umieć podejmować decyzję, jaka powinna być priorytetyzacja zadań i kiedy zadanie należy odrzucić oraz przyjmować konsekwencje tych decyji, | * '''decyzyjność''': Produkt owner musi samodzielnie umieć podejmować decyzję, jaka powinna być priorytetyzacja zadań i kiedy [[zadanie]] należy odrzucić oraz przyjmować konsekwencje tych decyji, | ||
* '''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łą prace nad projektem. | * '''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łą prace nad projektem. | ||
==Bibliografia== | ==Bibliografia== | ||
Wersja z 06:15, 21 maj 2020
| Product owner |
|---|
| Polecane artykuły |
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 Produkct 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 [1]. Do najważniejszych odpowiedzialności product ownera należy prowadzenie i zarządzanie Backlogiem Produktu.
Zarządzanie Product Backlogiem
Podczas pracy z Backlogiem Product owner powinien skupiać się na następujących aspektach[2]:
- 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 sprioretyzowany: 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
{{#ev:youtube|QhhbMR385zA|480|right|Role w Scrum (Sławomir Wawak)|frame}} 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ć [3]:
- 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ść: Produkt owner musi samodzielnie umieć podejmować decyzję, jaka powinna być priorytetyzacja zadań i kiedy zadanie należy odrzucić oraz przyjmować konsekwencje tych decyji,
- 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łą prace nad projektem.
Bibliografia
- Pfahl D. (2014). Lecture 11: Agile/Lean Methods, s. 5
- Schwaber K. (2013). Scrum Guide, Przewodnik do Scrumie: Regułu gry, s. 5
- Sverrisdottir H. (2014). The role of the product owner in scrum - comparision between theory and practices, "Procedia - Social and Behavioral Sciences", nr 119, s. 260
Przypisy
- ↑ Pfahl D. (2014). Lecture 11: Agile/Lean Methods, s. 5
- ↑ Schwaber K. (2013). Scrum Guide, Przewodnik do Scrumie: Regułu gry, s. 5
- ↑ Sverrisdottir H. (2014). The role of the product owner in scrum - comparision between theory and practices, "Procedia - Social and Behavioral Sciences", nr 119, s. 260
Autor: Paweł Ciupek
