Czy właściciel produktu jest także programistą w twoim zespole?

Jestem zdezorientowany co do odpowiedzialności OP tutaj. Byłem programistą w Game Feature Team, ale także PO. Codzienna praca dewelopera trwa prawie na pełny etat, więc muszę pracować z czasem, aby zająć się moim obowiązkiem PO, a odpowiedzialność PO wydaje się być sprzeczna z myślami dewelopera.

Jako PO wybiorę więcej funkcji podczas następnego sprintu. W przeciwnym razie powiem sobie, żeby tego nie robić, ponieważ jestem członkiem zespołu, który opracowuje te funkcje. Ta sytuacja wprawia mnie w zakłopotanie, więc chcę usłyszeć od was kilka pomysłów.

Jestem nowy w Scrum i Game Dev (około półtora roku), a także nowy tutaj i po angielsku.

Może się to wydawać trochę akrealne, ale tak naprawdę nie powinno być żadnego powodu, aby łączyć te role. Po pierwsze, ktoś zaufał ci w tej roli, dlatego twój zespół musi to uszanować. Po drugie, jesteś teraz w sytuacji, w której możesz nadać priorytet pracy, która musi zostać wykonana, abyś zawsze mógł wyjaśnić, dlaczego wszystko idzie tak, jak jest. Po trzecie, jesteś w zespole, więc ponosisz część obciążenia pracą. Wreszcie jest to praca, jeśli musisz ciężko pracować, to dobrze. Zespół zawsze musi pamiętać o tym, aby wnieść wartość dodaną do swojego projektu, nie chodzi tu o wolne rozdanie.

Wszystko sprowadza się do pytania: „Czy masz towary do podjęcia tych decyzji?” Jeśli uważasz, że tak, zrób to!

Z mojego doświadczenia wynika, że ​​właścicielem produktu jest albo PM / TPM, albo członek zespołu biznesowego. Chociaż PO nie może być dev, istnieje pewne ryzyko konfliktu interesów. Jeśli Twój produkt jest wysoce techniczny, organizacja producentów powinna mieć doświadczenie w tworzeniu oprogramowania. Jeśli jest mniej techniczny i bardziej skupiony na użytkownikach końcowych, krytyczne jest zamówienie zakupu z doświadczeniem biz.

Jako programista (zakładając, że jesteś dobry) zostaniesz zainwestowany w swój kod. Jako właściciel lub menedżer musisz zainwestować w produkt.

Nie zawsze są to to samo. A kiedy nie będą, będziesz miał duże problemy.

Zawsze mówiłem, że rolą dobrego menedżera jest blokowanie bzdur z góry i kradzież mojego kodu ode mnie, gdy jest wystarczająco dobry. Bez menedżera mógłbym pracować nad jedną funkcją do końca życia, na zawsze ją ulepszając.

Właściciele muszą spojrzeć na ogólny obraz, programiści muszą przyjrzeć się szczegółom. Nie możesz zrobić obu, jeśli nie jesteś Bogiem!

Jak to jest zdefiniowane w tradycyjnym Scrumie, nie ma problemu, że Deweloper działa również jako Właściciel Produktu. Należy jednak zachować ostrożność, planując rozliczenie każdego, kto wykonuje swoją rolę w niepełnym wymiarze godzin, albo dlatego, że pracuje nad wieloma projektami, albo dlatego, że ma wiele ról w tym samym zespole. W twoim przypadku nie możesz liczyć na pełnoetatowego programistę, ponieważ musisz poświęcić budżet na każdą iterację, aby wykonać obowiązki właściciela produktu.

Myślę, że masz również niezrozumienie tego, co robi Właściciel produktu. Nie jesteś odpowiedzialny za wybranie, które funkcje będą się powtarzać. Zamiast tego Twoim zadaniem jest być głosem klienta w projekcie, jeśli chodzi o wprowadzanie nowych historii, przypisywanie priorytetów do tych nowych historii i zapewnienie, że wdrożenie każdej historii jest możliwe do zaakceptowania poprzez stworzenie i wykonanie testów akceptacyjnych. Wybór opowieści opiera się na szybkości zespołu i zaległych priorytetach, a nie na liczbie opowiadań, które właściciel produktu chce wdrożyć.

Interesujące, że udzielam rad facetowi o imieniu Charlie (Nazywam się Charles), ale mam pewne doświadczenie w podwójnej roli jako deweloper / PM, a z mojego doświadczenia BARDZO łatwo jest się zbyt pochłonąć jednym rola lub inna.

Jeśli jesteś w stanie nadążyć za obiema rolami, zrób to wszystko, ale budżetuj swój czas i utrzymuj przełączanie kontekstu między tymi dwiema rolami do absolutnego minimum, szczególnie w ciągu jednego dnia.

Idealnie polecam unikanie mieszania tych ról, ponieważ są one, jak zauważyliście, dość sprzeczne ze sobą.

Prawie zawsze zły pomysł. Mieliśmy kierownika projektu, który był właścicielem produktu, co było dość sprzeczne.

Rozumiem ogólne problemy z równowagą między dwiema rolami, ale nie rozumiem twoich konkretnych obaw.

Rozwój jest pełnoetatową rolą tylko wtedy, gdy to zrobisz. Jeśli liczysz się tylko jako 50% podczas planowania sprintu (licząc wszystkie dostępne godziny programistów / dni), powinieneś mieć dużo czasu na swoje obowiązki PO.