In Scrum, gli sviluppatori dovrebbero parlare direttamente con i clienti (bypassando l'ordine di acquisto)?

È 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 accendi il cervello e fai qualunque cosa funzioni meglio in un progetto.

Anche se la comunicazione tra l'OP e il cliente dovrebbe essere lo standard (a causa delle ragioni scartate da @PatrickHughes nel suo commento), potresti dover affrontare una situazione in cui un requisito aziendale complesso deve essere chiarito e la comunicazione diretta tra un dev e un esperto di business accelereranno molto le cose. In una situazione del genere, si dovrebbe evitare di giocare "sussurro cinese" con il PO nel mezzo e lasciare che lo sviluppatore e l'esperto di business parlino direttamente tra loro - per questo contesto ristretto.

Tuttavia, l'ordine di acquisto non dovrebbe mai essere ignorato. Idealmente, prende parte a quella conversazione, probabilmente come moderatore. Può verificare che il cliente non presenti requisiti completamente nuovi sul tavolo durante la discussione o requisiti contrari a quanto concordato in precedenza.

Questo dipende anche dalle persone coinvolte e dalla situazione. L'OP potrebbe avere sufficiente fiducia nello specifico dev e nell'esperto del cliente, per lasciare che i due parlino da soli su un argomento specifico, e lasciare che lui o lei riferisca quanto è stato detto in seguito. In un'altra situazione, con altre persone coinvolte, potrebbe preferire una parte più attiva. Affinché queste decisioni siano corrette è il fulcro di una buona gestione del progetto.

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 un futuro utente del sistema.
Questo è il modo migliore per assicurarti di avere informazioni dirette e corrette disponibili e le linee più brevi possibili nei loro processi.

L'esempio ideale è probabilmente la squadra con cui lavoro ora. Il proprietario del prodotto è un utente esperto e un 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 creazione del prodotto fornendo un feedback quasi istantaneo 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 codifica:)

Devi ricordare che il cliente dell'azienda che ti assolda come sviluppatore ha obiettivi diversi per la società che ti assolda.

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 azienda.