Qual è il ruolo del proprietario di un prodotto in scrum?

Il Product Owner non ha un ruolo attivo nella riunione giornaliera di stand-up in Scrum. Lui / lei può ascoltare per capire cosa sta succedendo nel team e come stanno facendo il loro impegno.
Il Product Owner dovrebbe rimanere sullo sfondo durante questi incontri e non parlare. Se il proprietario del prodotto ha serie preoccupazioni, lo / la deve prendere con lo Scrum Master dopo l'incontro.
Se il Product Owner è presente, è possibile che venga richiesto qualche chiarimento su alcune delle storie. Anche questo dovrebbe essere posticipato fino a dopo la riunione per evitare di discuterne durante lo stand-up.

Se il cliente effettivo non può essere presente abbastanza spesso da assumere il ruolo di Proprietario del prodotto, è possibile nominare un proxy. Le caratteristiche più importanti per il proxy sono:

• Hanno informazioni sufficienti su ciò che il cliente vuole realmente trasmettere al team questa visione
• Hanno abbastanza autorità per prendere decisioni sul posto e difendere tali decisioni sia dal team che dal cliente.

Specialmente il secondo punto di solito significa che il proxy deve essere uno sviluppatore molto anziano o qualcuno dei circoli di gestione.

Non ho familiarità con il termine "Coinvolgimento degli stakeholder esterni" (che non è un termine usato in Scrum), quindi non posso dire in modo definitivo come si riferisce a un Product Owner, ma a prima vista l'obiettivo sembra essere lo stesso.

Risponderò alle domande in un ordine leggermente diverso da quello che hai chiesto loro, dal momento che penso che aiuti a costruire la risposta.

Product Owner is the person who is customer. A team member can be nominated as a proxy of product owner?

Un Product Owner non deve essere un cliente, ma semplicemente un rappresentante delle parti interessate che ha l'autorità di prendere decisioni sulla priorità del lavoro nel Product Backlog. Il Product Owner non è una posizione tecnica. È una posizione commerciale. La persona nel ruolo di Proprietario del prodotto deve comprendere il cliente e le sue esigenze. Dopotutto, la loro funzione principale è scrivere e dare la priorità agli articoli del Product Backlog, rispondere alle domande e coordinarsi con le parti interessate e rivedere le consegne incrementali per assicurarsi che soddisfino le esigenze degli utenti nell'ambiente previsto.

Un consiglio è che Scrum Master e Product Owner non devono essere la stessa persona (vedi qui e qui per maggiori informazioni). Quei ruoli sono in disaccordo l'uno con l'altro. Il Product Owner è responsabile della gestione delle esigenze aziendali mentre lo Scrum Master è responsabile per il team. A volte, le esigenze dell'azienda sono in contrasto con le esigenze della squadra.

What is role of Product Owner in daily Scrum, if he/she is part of this meeting?

Non c'è nulla che impedisca al Product Owner di partecipare al Daily Scrum meeting. Il Daily Scrum è l'opportunità per il team di sviluppo di auto-organizzarsi attorno alle attività della giornata e allo Scrum Master di coordinarsi con il team su quali problemi devono essere risolti per non rallentare lo sviluppo. Tuttavia, non c'è molto da fare per il Product Owner in riunione, tranne che per osservare il team. Lo Scrum Master garantisce che le persone esterne al team di sviluppo che frequentano il Daily Scrum non interrompano il processo di sviluppo del team per la riunione.

Il tempo immediatamente successivo al Daily Scrum può essere utilizzato per discussioni più approfondite tra i membri del Team di sviluppo o per regolare il piano per lo Sprint. Persone esterne al team di sviluppo possono partecipare a questa attività.

Can we say that a Project Manager who directly interacts with customer is nominated as proxy of Product Owner?

Non esiste una mappatura diretta tra un Project Manager tradizionale e i ruoli in Scrum.

Sono d'accordo che gli aspetti di interazione con il cliente del ruolo di Project Manager si associno al ruolo di Product Owner. Tuttavia, altri aspetti del ruolo di Project Manager, come la gestione della pianificazione e del budget, sono più di una funzione Scrum Master. Altre funzioni di gestione del progetto, come la stima, la gestione dei rischi e la comunicazione interna, appartengono all'intero team di sviluppo.

When we use term "External Stakeholders Engagement", are we referring to Product Owner or something else?

Molto probabilmente il Product Owner, sì.

Il Product Owner è la persona che parla per conto dei clienti e degli utenti del software in fase di sviluppo. Il proprietario del prodotto deve capire le sue esigenze per poter scrivere storie di utenti, rispondere alle domande del team su quelle storie degli utenti che dovrebbero sorgere, dare la priorità al Product Backlog e altro.

Il Product Owner non dovrebbe sapere tutto, ma gestisce la comunicazione con il mondo esterno. Se non hanno una risposta, sanno a chi impegnarsi per ottenere la risposta al team di sviluppo.

Il proprietario del prodotto è sempre il proxy per il cliente. Potrebbero essere un vero rappresentante del cliente, ma non c'è ragione per cui debbano esserlo. In effetti, ci sono buone ragioni per il proprietario del prodotto di non essere un cliente. Il proprietario del prodotto è responsabile della distillazione dei bisogni del cliente nelle storie, non è necessario essere il cliente. Essere un buon product owner richiede abilità che il cliente tipico probabilmente non ha.

Direi che il proprietario del prodotto non dovrebbe mai essere uno sviluppatore, perché essere proprietario del prodotto è un lavoro a sé stante. Può facilmente essere un lavoro a tempo pieno, e nel peggiore dei casi dovrebbe essere un lavoro a metà tempo. Se si nomina uno sviluppatore come proprietario del prodotto, le attività di sviluppo verranno ridotte a metà o più.

Il proprietario del prodotto non dovrebbe avere un ruolo attivo negli standup , ma ha un ruolo attivo nel processo generale. Dovrebbe esserci un dialogo continuo tra il team di sviluppo e il proprietario del prodotto. È solo che gli stand up sono specifici per il team di sviluppatori che comunicano in sé i progressi verso gli obiettivi di sprint e niente di più.

Lo stand up giornaliero dovrebbe essere breve, ed è strettamente per tenere tutti informati su quanto sta bene il team verso gli obiettivi di sprint. Non è il momento di chiedere chiarimenti, anche se è il momento di aumentare il fatto che è necessario un chiarimento. Una volta terminato lo stand-up, è il momento per il team di interagire con il proprietario del prodotto.

Per quanto riguarda la tua domanda sulle parti interessate esterne, quelle sono persone che non sono direttamente coinvolte nello sviluppo del prodotto. Non sono sviluppatori o proprietari di prodotti, ma praticamente chiunque abbia un interesse per il prodotto in fase di sviluppo. Un team di marketing, per esempio, potrebbe essere uno stakeholder esterno. È responsabilità del proprietario del prodotto comunicare le informazioni sul prodotto a quel team (quando sarà pronto, quali vantaggi fornisce al cliente, ecc.).

Direi che il collegamento tra proprietario del prodotto e cliente non è così esplicito come suggerito nella maggior parte delle risposte. Il proprietario del prodotto decide in ultima analisi cosa sarà in cima all'arretrato e quindi cosa verrà implementato nel prodotto. Non sarebbe una buona cosa che sarebbe una mappatura uno-a-uno delle richieste dei clienti (cosa che spesso accade, che è uno dei motivi per cui molti negozi fanno casino con la mischia).

Il proprietario del prodotto dovrebbe tenere conto dell'interesse a lungo termine del prodotto che potrebbe significare "No, non lo faremo ora". oppure "Ti daremo qualcosa di diverso in seguito che dovrebbe essere altrettanto utile."

Il prodotto perirà se il cliente non riconosce i suoi bisogni in esso. Ma probabilmente diventerà irrilevante se il proprietario del prodotto non sta pensando e sta trasmettendo solo l'ultima richiesta dal campo. Il proprietario del prodotto non rappresenta principalmente il cliente, ma rappresenta il (successo del) prodotto.