In Scrum, gli sviluppatori dovrebbero parlare direttamente con i clienti (evitando l'OP)?

In che modo il proprietario di un prodotto in mischia dovrebbe rispondere a domande molto dettagliate del team sulle funzionalità che stanno implementando e che non può rispondere immediatamente? Quando sarebbe chiaramente la soluzione più veloce per lo sviluppatore parlare direttamente con il cliente stesso?

Mi chiedo se la comunicazione diretta tra il team e il cliente mina il ruolo del proprietario del prodotto. Credo che l'OP debba rappresentare esclusivamente il cliente e quindi rispondere a tutte le domande relative ai requisiti, anche se ciò richiede più tempo. Bypassarlo sembra indebolirlo e alla fine renderlo superfluo ...

Esiste una best practice nella mischia?

scrum communication product-owner

— tizenegy
fonte

Sono d'accordo con te sul fatto che il proprietario dovrebbe essere l'unico punto di contatto tra sviluppo e cliente. Non sono d'accordo sul fatto che rendere il proprietario del prodotto inutile sia la ragione, o che sia più veloce ignorare il ruolo. Lo metterò in questo modo: su un progetto con 10 sviluppatori non vuoi che 10 persone parlino costantemente con il cliente e trattino le funzionalità. In primo luogo, infastidisce il cliente, in secondo luogo ci vuole tempo lontano dallo sviluppo reale. Se vieni bloccato su tutte le attività perché hai bisogno di maggiori informazioni, devi correggere la fase di acquisizione dei requisiti e non provare a fissare la proprietà.

— Patrick Hughes,

"Quando sarebbe chiaramente la soluzione più veloce ..." Voglio solo sottolineare l'ovvio: più veloce non è necessariamente migliore.

— Eric King,

Risposte:

È sempre una buona idea (specialmente nei cosiddetti progetti Agile) non attenersi a qualche culto del carico o libro di testo che ti dice "chi dovrebbe (non) parlare con chi", ma accendere il cervello e fare tutto ciò che funziona meglio in un progetto.

Sebbene la comunicazione tra PO e il cliente debba essere lo standard (a causa dei motivi presi in considerazione da @PatrickHughes nel suo commento), potresti dover affrontare una situazione in cui un requisito commerciale complesso deve essere chiarito e la comunicazione diretta tra uno sviluppatore e un un esperto di affari accelererà molto le cose. In una situazione del genere, si dovrebbe evitare di giocare a "sussurro cinese" con l'OP nel mezzo e lasciare che lo sviluppatore e l'esperto aziendale parlino direttamente tra loro - per questo contesto ristretto.

Tuttavia, l'OP non dovrebbe mai essere escluso. Idealmente, prende parte a quella conversazione, probabilmente come moderatore. Può verificare che il cliente non presenti sul tavolo nuovi requisiti durante il talk o requisiti contrari a quanto concordato in precedenza.

Ciò dipende anche dalle persone coinvolte e dalla situazione. L'OP potrebbe avere abbastanza fiducia nello sviluppatore specifico e nell'esperto del cliente, per lasciare che i due parlino da soli su un argomento specifico e che lui o lei riferiscano ciò che è stato detto in seguito. In un'altra situazione, con altre persone coinvolte, potrebbe preferire prendere una parte più attiva. Prendere queste decisioni giuste è il fulcro di una buona gestione dei progetti.

— Doc Brown
fonte

"L'intera idea dello sviluppo Agile è: non attenersi a qualche culto del carico o libro di testo, ma accendere il cervello e fare tutto ciò che funziona meglio in un progetto.": Vero, ma questa idea non è specifica per l'agile.

— Giorgio,

+1 se si fa la mischia in modo agile, un esperto di affari probabilmente farebbe parte della squadra e sarebbe comunque disponibile ...

— Marjan Venema,

Giusto. L'OP non dovrebbe mai essere un guardiano del cancello. Invece, l'OP è il responsabile finale del prodotto.

— Gort the Robot il

@StevenBurnap significherebbe che l'OP deve essere un esperto nel settore fin dall'inizio ... nella mia esperienza, non è sempre così.

— Tizenegy,

@Giorgio: assolutamente, IMHO "Sviluppo agile" è solo una parola d'ordine che incorpora alcune buone abitudini che sono molto più vecchie del termine e non si limitano a se stesso.

— Doc Brown,

Devi ricordare che il cliente dell'azienda che ti impiega come sviluppatore ha obiettivi diversi rispetto all'azienda che ti impiega.

Il proprietario del prodotto deve rappresentare gli obiettivi della tua azienda piuttosto che gli obiettivi del cliente. Quindi, se gli sviluppatori vanno direttamente al cliente, possono minare la loro stessa compagnia.

— Ewan
fonte

l'obiettivo per tutti dovrebbe essere quello di fornire il miglior prodotto possibile nel rispetto del budget e del target. È solo come farlo che è una potenziale fonte di discussione.

— jwenting

non siamo ingenui però. La società potrebbe preferire eseguire le specifiche contrattuali minime e, ad esempio, passare a un progetto più redditizio. O più probabilmente nella mia esperienza il cliente vorrà aggiungere funzionalità ed espandere l'ambito mantenendo lo stesso prezzo

— Ewan,

Per gli sviluppatori, il proprietario del prodotto È il cliente. Idealmente (e so che non è sempre possibile) il proprietario del prodotto dovrebbe essere un rappresentante diretto del cliente, un esperto di dominio e futuro utente del sistema.
Questo è il modo migliore per garantire la disponibilità di informazioni dirette e corrette e le linee più brevi possibili nei loro processi.

L'esempio ideale è probabilmente la squadra con cui sto lavorando ora. Il proprietario del prodotto è un utente finale senior ed esperto di dominio con piena autorità per autorizzare le decisioni di progettazione in loco (e la volontà e la capacità di farlo effettivamente). È parte integrante del team e assiste direttamente l'analista e il progettista nello scrivere le storie degli utenti, nonché i programmatori e i tester nella costruzione del prodotto fornendo un feedback quasi immediato su domande di implementazione e scenari di test.
Le linee non possono essere più brevi di avere il tuo futuro utente seduto accanto a te durante la programmazione :)

— jwenting
fonte

"Le linee non possono in realtà essere più brevi di avere il tuo futuro utente seduto accanto a te durante la programmazione :)": è discutibile se questo sia sempre buono.

— Giorgio,

@Giorgio ovviamente, dipende dalle persone coinvolte. Ma è quello che promuove SCRUM (e le pratiche Agile in generale), le linee brevi, il rapido processo decisionale. Nel nostro caso funziona perché il cliente è davvero entusiasta e vuole che il prodotto abbia successo, ma sono anche abbastanza realistici da rendersi conto che non tutto è possibile (certamente non entro i limiti di budget e tecnici con cui dobbiamo lavorare).

— jwenting,

Certo, e penso che dipenda anche dal tipo di progetto. Alcuni progetti richiedono feedback più spesso di altri. Inoltre, in alcuni progetti / prodotti desideri conservare alcune informazioni per te stesso. Ma sì, per alcuni progetti avere il cliente seduto con te nello stesso ufficio e seguire lo sviluppo è probabilmente la migliore impostazione possibile.

— Giorgio,

@Giorgio: "Il proprietario del prodotto è un utente finale senior ed esperto di dominio con piena autorità per autorizzare le decisioni di progettazione in loco" Sembra che il tuo PO possa rispondere a quasi tutte le domande che gli sviluppatori potrebbero avere. Mi riferivo a una situazione diversa: un PO che non è ancora allo stesso livello di competenza dei clienti stessi e quindi deve tornare da loro su base regolare per rispondere a domande più difficili.

— Tizenegy,