Chi è responsabile di contestare il proprietario di un prodotto? [duplicare]

Question

Chi è responsabile di contestare il proprietario di un prodotto? [duplicare]

#1 da (11 voti)
#2 da (3 voti)
#3 da (2 voti)

5

Sono relativamente nuovo a Scrum e non sono chiaro sui confini del proprietario di un prodotto.

Il proprietario del prodotto con cui sto lavorando al momento sembra comportarsi più come un manager di qualcuno che fornisce i requisiti agli sviluppatori. Quando parla con me o con altri membri della squadra senza il comando della squadra presente, si comporta diversamente, ad es. non ci consente di mettere in discussione nessuna richiesta o il valore di ciò che viene chiesto. Quando ci interroghiamo su quale sia il bisogno o l'urgenza di qualcosa mentre lui non può davvero sostenere il suo caso, è evidente che è arrabbiato soprattutto perché penso che consideri che gli sviluppatori sono "inferiori" al rango di lui.

Mentre potrei occuparmene con il mio team lead, preferirei capire se è così che si comportano normalmente i proprietari dei prodotti poiché non ho esperienza in Agile.

Il team è l'unico responsabile a "sfidare" il proprietario di un prodotto in Scrum?

teamwork agile scrum product-owner

posta Jim 23.11.2014 - 21:00

fonte

3 risposte

Leggi altre domande sui tag teamwork agile scrum product-owner

Nel contesto della programmazione funzionale, quali sono le funzioni "totali" e le funzioni "parziali"? Controlla se una variabile è uguale a uno qualsiasi dei diversi valori

score 11 · Answer 1

In Scrum non esiste il ruolo di TL come ruolo ufficiale, quindi lasciatemi prima rispondere alla domanda da una prospettiva Scrum. Tutti i membri del team possono "sfidare" un PO per ottenere maggiori informazioni, ma è l'OP che è responsabile della decisione di "cosa" deve essere fatto. È importante che il team si fidi delle decisioni del PO su "cosa" deve essere fatto, e il PO si fida del team di "come" è fatto. Se ci sono conflitti, lo Scrum Master entra in scena. È il "difensore del processo", e il processo è definito in un modo che nella maggior parte dei casi i conflitti possono essere trasformati in discussioni basate sul processo e sui fatti concordati, quindi lo Scrum Master agirà come una sorta di moderatore in questo caso .

Ma Scrum non dice che i ruoli che non definisce non hanno alcuna autorità. Se hai un TL (Team Lead), puoi chiedere aiuto al tuo Team Lead. Il modo migliore dipende dalla tua situazione e dal ruolo effettivo del Team Lead. Di solito, prima provavo me stesso, poi tramite uno sviluppatore esperto nel team, poi tramite lo Scrum Master, poi tramite il Team Lead.

Non è solo il tuo diritto, ma il tuo compito come membro del team Scrum Dev di chiedere dettagli e ulteriori informazioni sui requisiti / storie degli utenti, nonché sul valore. Il Product Backlog deve essere ordinato per Business Value per User Story, e se c'è qualcosa di poco chiaro a riguardo, non è solo un tuo diritto, è tuo dovere fare domande al riguardo.

score 3 · Answer 2

Prima lasciatemi dire che il Product owner è colui che decide quale storia ha una priorità più alta, come sviluppatore diamo la nostra prospettiva nelle riunioni di release e sprint planning ma lui / lei è ancora colui che ha l'ultima parola nel dare priorità all'utente storie. La ragione è semplice, lui / lei conosce meglio il business. Come sviluppatore agile, dobbiamo dare il nostro feedback e lavorare sul compito che creiamo per noi stessi.

Detto questo, qui sembra che tutto il tuo team sia nuovo per Agile. È importante capire che Agile è molto diverso dalla nostra impostazione di lavoro tradizionale. Prima di tutto, tutti i membri del team, incluso il proprietario del prodotto e i maestri di mischia, dovrebbero sapere qual è il loro ruolo e devono comprendere il manifesto Agile ei principi Agile. La metà del problema si risolve quando il team sa di cosa si tratta Agile. Nella tua situazione particolare, penso che i seguenti principi debbano essere ricordati al proprietario del prodotto.

1) Costruisci progetti attorno a persone motivate. Offri loro l'ambiente e il supporto di cui hanno bisogno e fidati di loro per portare a termine il lavoro.

2) A intervalli regolari, il team riflette su come diventare più efficace, quindi sintonizza e regola il suo comportamento di conseguenza.

Come menzionato nel primo dei due principi, "Date loro l'ambiente e il supporto di cui hanno bisogno" è molto importante. In questo momento non si ottiene un ambiente in cui si possa lavorare con piena dedizione e per risolvere il problema è necessaria una maggiore interazione con il proprio team, compreso il proprietario del prodotto, ed è qui che entra in azione il 2 ° principio.

Avere conflitti non è una brutta cosa. Agile aiuta a risolvere questi problemi avendo retrospettive regolarmente. Spero che col tempo la tua squadra inizi a capirsi meglio.

score 2 · Answer 3

it is evident that he is upset mainly because I think he considers that developers are “lower” rank than he is

Credo che questo sia il problema principale. Dovresti far parlare il tuo Scrum Master della sua posizione. Tutti i membri del team, incluso il Product Owner, hanno lo stesso rango e nessuno ha più autorità di chiunque altro.

Credo che Agile sia principalmente sul fatto che chiunque lavori su un software è un essere umano razionale e che i problemi possono essere risolti con una discussione razionale supportata da fatti. Come sviluppatori dobbiamo ammettere che non abbiamo una buona idea di quali siano le esigenze di business. D'altra parte, mi aspetto che il proprietario del prodotto abbia una vera ragione per cui alcune funzionalità hanno una priorità elevata. Se questo motivo non esiste, metterei in discussione la sua decisione e richiedere fatti concreti a riguardo.