Quali sono i confini del proprietario del prodotto in scrum?

In generale, il ruolo dell'OP durante uno sprint dovrebbe essere passivo, cioè fornire un feedback quando richiesto, ma non eseguire il microgestione del lavoro del team. Qualsiasi cambiamento derivante da tale feedback deve essere valutato rispetto ad altre priorità. Ma alla fine, l'OP rappresenta quelli che pagano per il progetto e quindi chiama i colpi. Per quanto riguarda le tue domande specifiche:

1. Se l'ordine di acquisto ha aspettative dettagliate sulla progettazione, queste dovrebbero essere fornite come guida di branding / CI prima dell'avvio dello sviluppo. Richiedere molte modifiche ai dettagli solo dopo aver visto l'interfaccia utente in fase di sviluppo non è l'ideale, ma se l'OP ritiene che questi cambiamenti siano molto importanti e sia disposto ad accettare le conseguenze, ovvero le funzionalità abbandonate da un'iterazione perché le persone dovevano implementare le modifiche desiderate va bene anche
2. La scelta di elementi specifici dell'architettura è certamente il dominio dell'OP, ma molto deve essere fatto prima dell'inizio dello sviluppo. Cambiamenti fondamentali in seguito causeranno enormi ritardi (è praticamente garantito che dovrai abortire l'attuale Sprint e usare almeno il prossimo principalmente per implementare tali cambiamenti). Di nuovo, se l'OP accetta le conseguenze, è una sua decisione. Se no, inizia a sembrare che al progetto manchi la base principale di Scrum: il presupposto che tutti stiano lavorando su un obiettivo comune e prendano decisioni razionali su come ottenere il miglior risultato possibile.
3. Di nuovo, è in definitiva la decisione dell'OP, e questo tipo di cose è perfettamente OK per discutere con il PO se ci sono domande aperte, dal momento che potrebbe avere una conoscenza di dominio che i tuoi analisti non hanno. Ma se insiste nel fare le cose in modo diverso rispetto a quelli che hanno studiato il problema, raccomandare, e senza fornire una motivazione, allora che suggerisce strongmente anche a qualcuno che non si adatta bene al lavoro.
4. Se implementare qualcosa come una procedura guidata o una singola pagina complessa è un ottimo esempio per qualcosa che il team potrebbe chiedere all'OP di prendere una decisione. Ma avere un feedback costante sui dettagli non è efficiente. Fondamentalmente l'idea è di far sì che il team implementa un caso d'uso completo e solo occasionalmente riceve feedback su cose di cui non sono sicuro o quando ha completato un lavoro significativo. Per tornare al tuo esempio: dopo aver preso la decisione dell'OP, il Team potrebbe creare un mock-up della GUI per la procedura guidata o la pagina completa, mostrarlo al PO per ottenere feedback, cambiare una o due cose e implementarlo, quindi mostrare il completa implementazione nella recensione sprint.

1.Should PO interfere the UI design, when there are designers at work in scrum team?

Penso di sì, l'OP ha il mondo ultimo nell'interfaccia utente / problemi di usabilità. Ovviamente, è responsabilità degli sviluppatori valutare le possibili opzioni dal punto di vista tecnico e persino indicare potenziali usabilità o qualsiasi tipo di problema. Ma alla fine, se il PO è disposto a pagare il prezzo (in contanti, perdita di sviluppo / tempo di utilizzo, minore produttività o ...), è il suo diritto di scegliere.

Gli sviluppatori possono anche provare a dimostrare l'infallibilità di un approccio con un prototipo rapido e / o usando il ciclo di feedback delle versioni iniziali e regolari. E naturalmente è sempre utile cercare di capire perché l'OP preferisce una soluzione specifica - potrebbe essere che abbia una buona ragione per questo. La comunicazione è sempre un fattore primario nell'essere agili.

Ma alla fine, ci sono OP che (a volte o regolarmente) prendono decisioni stupide. Non penso che sia un problema del processo in sé. In effetti, Scrum / Agile offre molte possibilità di discutere i pro e i contro di approcci specifici e consente all'OP di cambiare la propria mente in modo relativamente facile. Questo è molto più di ciò che offrono gli approcci tradizionali per i processi.

2.Should PO interfere in Design and architecture of coding?

Dipende dalla definizione di "interferire" :-) È responsabilità degli sviluppatori valutare tutte le possibili scelte architettoniche (ad esempio utilizzando Oracle vs utilizzando MySQL) e scoprire tutti i potenziali costi, rischi e benefici. Dopodiché, anche se gli sviluppatori formulano suggerimenti / preferenze, che normalmente dovrebbero essere presi seriamente in considerazione, alla fine spetta al PO scegliere. Per esempio. potrebbe essere che, anche se Oracle è molto più costoso di MySQL e tecnicamente non superiore per l'attività in corso, l'OP sceglie Oracle perché tutta la sua infrastruttura esistente è basata su Oracle.

3.Should PO interfere in validation mechanisms? For example, this field should be required, or we don't need to get this piece of information from user.

Penso che questo sia fondamentalmente un problema di usabilità, quindi è una sottoclasse della domanda 1.

4.How granular could/should PO get into the analysis and design?

L'esempio che porti è di nuovo un problema di progettazione dell'interfaccia utente, non di un programma di progettazione. Quindi di nuovo, si applica il caso 1. La progettazione del programma, tuttavia, dovrebbe essere l'area dello sviluppatore poiché l'OP solitamente non ha né l'esperienza né l'interesse per essere coinvolti in questo.

Aggiornamento

Come linea di fondo, ritengo che tu abbia un problema con le persone qui: il tuo PO specifico potrebbe essere il microgestione del progetto, il che non è davvero positivo. Tendo ad accettare le risposte alla tua domanda precedente che questo sembra aver creato un processo distorto, "scrum ma", che potrebbe essere risolto, se prendi l'iniziativa e inizi a comunicare con i tuoi compagni di squadra e il PO. Se l'ordine di acquisto non è recettivo alle tue preoccupazioni, forse è meglio iniziare a cercare un progetto / posto di lavoro migliore ...?

Il proprietario del prodotto ha la responsabilità finanziaria del prodotto.

Questo dice tutto. Significa che il proprietario del prodotto è la prima persona che verrà incolpata se:

• Il prodotto non farà soldi
• Il prodotto non soddisfa i requisiti
• Il prodotto non soddisfa le aspettative
• Il prodotto non soddisfa gli stakeholder
• Il prodotto non soddisfa gli utenti finali

Quindi cosa ne pensi ora?

1. Sì, il proprietario del prodotto può interferire con la progettazione. Il PO dovrebbe sapere cosa si aspetta l'utente finale. Forse l'utente finale utilizza un'interfaccia utente simile in altre applicazioni e si aspetta semplicemente che la nuova applicazione abbia la stessa esperienza utente.
2. Sì, il proprietario del prodotto può richiedere la tecnologia. Questo è chiamato requisito non funzionale ed esiste anche in Scrum. Se il cliente ha solo l'applicazione server Linux in ASP.NET MVC sarà inutile.
3. Sì, forse il cliente non vuole la magia dietro.
4. Al livello necessario per conservare le informazioni per ulteriori discussioni sulla storia dell'utente. Questo di solito dipende dal tipo di progetto e dalle sue dimensioni. A volte bastano poche note e talvolta ti serve un po 'di più.

In ogni caso Scrum e qualsiasi metodologia agile riguardano la comunicazione. Non si dovrebbe essere in conflitto con il proprietario del prodotto e il proprietario del prodotto dovrebbe fare solo l'interferenza necessaria per soddisfare i criteri del cliente. Non dovrebbe mettere il suo coinvolgimento personale nel lavoro degli sviluppatori. Questa è la loro responsabilità. Chi è responsabile del controllo di tale squadra non è usurpato dal proprietario del prodotto? The Scrum Master: è suo compito difendere la squadra anche contro il Product Owner che trascende il suo ruolo.

C'è un commento eccellente a una delle risposte alla domanda a cui hai fatto riferimento, che a mio parere lo riassume bene. Credito a @StevenV che ha scritto:

Scrum (as all Agile methodologies) be heavier on conversation than direction. The PO should be describing what the end result needs to be able to accomplish, then engaging the designers and developers on ways to get there. – StevenV Aug 16 '11 at 12:17

Il proprietario del prodotto dovrebbe indicare i requisiti. I requisiti devono essere indicati con sufficiente precisione in modo da poter decidere in modo obiettivo che i requisiti siano soddisfatti o meno. Nell'esempio fornito, i requisiti possono avere una dichiarazione "ci dovrebbe essere un elenco a discesa con due scelte sì o no", o potrebbe avere una dichiarazione "ci dovrebbe essere un'opzione per l'utente di fare una scelta" sì o no "". Nel primo caso, l'OP vedendo la casella può dire "non soddisfare i requisiti". Nel secondo caso, l'OP che vede la casella può chiudere o modificare i requisiti (e prendere la colpa per il ritardo). L'OP non dovrebbe dire ai progettisti come implementare le richieste.

In generale, l'OP dovrebbe sapere cosa vogliono i clienti e cosa sono disposti a pagare, e dovrebbe avere qualche idea sui costi di implementazione (gli sviluppatori possono sicuramente dare un feedback su quanto sono difficili da implementare e possono consigliare requisiti modificati il mio vantaggio per enormi riduzioni dei costi). Gli sviluppatori e i progettisti dovrebbero sapere come sviluppare il software e come progettare le interfacce utente, e dovrebbero essere migliori rispetto all'OP.

Se i requisiti del proprietario del prodotto fanno e gli implementatori consegnano ai requisiti ... perché gli implementatori non possono incontrare, progettare e vedere come verranno consegnati (architettura, design, codice) senza l'ordine di acquisto?  Se il Product Owner deve essere presente, significa che non ha descritto il requisito in modo sufficientemente chiaro, per quegli Architetti / Designer / Coders che fanno il loro lavoro.  Il Product Owner inoltre non conosce i pro / contro, né le specifiche di come il codice viene eseguito: sono impegnati a parlare con i clienti, a raccogliere i requisiti.

Abbiamo visto il danno causato dal proprietario del prodotto - presupponendo di conoscere Architettura / Design / Coding ... attenersi a ciò che è il tuo lavoro primario (clienti, requisiti), farlo bene ... e lasciare i nostri lavori primari che siamo stati assunti per (Architettura, Design e Coding) alla nostra esperienza - "siamo una squadra complementare (non in disaccordo, o sovrapposti nella responsabilità per cui siamo stati assunti)"