Il Product Owner è anche uno sviluppatore del tuo team?

Potrebbe sembrare un po 'imbarazzante, ma in realtà non dovrebbero esserci motivi per combinare questi ruoli. Per esempio, qualcuno ti ha creduto in questo ruolo, quindi il tuo team deve rispettarlo. In secondo luogo, ora sei in una posizione in cui puoi dare priorità al lavoro che deve essere svolto in modo da poter sempre spiegare perché le cose stanno andando come sono. Terzo, sei nella squadra, così ti stai portando la parte del carico di lavoro. Infine, è un lavoro, se devi lavorare duro va bene. Una squadra ha sempre bisogno di ricordare di aggiungere valore al proprio progetto, non si tratta di una mano libera.

Ciò che viene in mente è "Hai i beni per fare queste decisioni?" Se pensi di averlo, fallo!

Nella mia esperienza, il proprietario del prodotto è un PM / TPM o un membro del team aziendale. Sebbene non sia impossibile per il PO essere un dev, esiste il pericolo di conflitto di interessi. Se il tuo prodotto è altamente tecnico, l'ordine di acquisto dovrebbe avere uno sfondo di sviluppo. Se è meno tecnico e più focalizzato sull'utente finale, un PO con esperienza di biz è fondamentale.

Come programmatore (supponendo che tu sia un bravo) sarai investito nel tuo codice. In qualità di proprietario o responsabile, devi essere investito nel prodotto.

Queste non sono sempre la stessa cosa E quando non lo sono avremo grossi problemi.

Ho sempre detto che il ruolo di un buon manager è quello di bloccare la schifezza dall'alto e di sottrarre il mio codice a me quando è abbastanza buono. Senza un manager potrei lavorare su una singola funzione per il resto della mia vita, migliorandola per sempre.

I proprietari devono guardare al quadro generale, i programmatori devono guardare i dettagli. Non puoi fare entrambe le cose a meno che tu non sia Dio!

Come è definito in Scrum tradizionale, non c'è un problema con uno sviluppatore che funzioni anche come proprietario del prodotto. Tuttavia, è necessario fare attenzione quando si pianifica di rendere conto a chiunque svolga il proprio ruolo part-time, sia perché lavorano su più progetti o perché hanno più ruoli nello stesso team. Nel tuo caso, non puoi considerarti uno sviluppatore a tempo pieno perché devi pianificare il budget in ciascuna iterazione per svolgere i compiti del Product Owner.

Penso che tu abbia anche un fraintendimento di ciò che fa il Product Owner. Non è responsabilità dell'utente scegliere quali caratteristiche vanno in una iterazione. Invece, è il tuo lavoro essere la voce del cliente sul progetto, quando si tratta di introdurre nuove storie, assegnare priorità a queste nuove storie e assicurare che l'implementazione di ciascuna storia sia accettabile attraverso la creazione e l'esecuzione di test di accettazione. La scelta delle storie si basa sulla velocità del team e sul backlog priorizzato, non sul numero di storie che il Product Owner desidera implementare.

Interessante che sto dando consigli a un ragazzo di nome Charlie, (Mi chiamo Charles) ma ho una certa esperienza nel dual-roleing come dev / PM, e nella mia esperienza, è MOLTO facile da ottenere troppo avvolto in un ruolo o nell'altro.

Se sei in grado di tenere il passo con entrambi i ruoli, fallo comunque, ma pianifica il tuo tempo e mantieni il cambio di contesto tra questi due ruoli al minimo assoluto, soprattutto in un solo giorno.

Idealmente, ti consiglio di evitare di mescolare questi ruoli, perché sono, come hai notato, abbastanza in conflitto tra loro.

Quasi sempre una cattiva idea. Avevamo un project manager che era proprietario di un prodotto e che era abbastanza conflittuale.

Capisco i problemi di equilibrio generale tra i due ruoli, ma quello che non capisco sono i tuoi dubbi specifici.

Lo sviluppo è solo un ruolo a tempo pieno se lo fai. Se ti consideri solo del 50% durante la pianificazione dello sprint (quando contali tutte le ore / gli orari di sviluppo disponibili), dovresti avere tutto il tempo che ti occorre per i tuoi doveri.