Come posso fornire indicazioni sulle scelte tecnologiche attraverso le storie degli utenti?

Esiste un capo architetto / tecnico che fa parte del team con cui puoi parlare?

In definitiva, penso che la proprietà tecnica ricada sul team di consegna. Come PO, puoi fornire indicazioni attraverso i tuoi criteri di accettazione, ma piuttosto che formulare il tuo AC attorno al "come", parlare del "perché" e di quali problemi risolverebbe il tuo ipotetico stack (forse ci sono alternative che soddisfano anche il tuo AC) .

Puoi sempre suggerire la direzione tecnica alla squadra, ma farei attenzione e permetto al team di scegliere ciò che funziona meglio per loro (questo include l'architetto / lead tecnologico). Se ci sono problemi tecnici, li inserirò nei criteri di accettazione. Un principio chiave di Agile / Scrum è che le squadre lavorano meglio quando hanno il potere e hanno l'autorità di prendere decisioni che le riguardano. Riconosco definitivamente la necessità di guidare la direzione (specialmente se pensi che la squadra stia facendo una scelta tecnica errata a lungo termine), ma c'è il compromesso se la squadra non è d'accordo e si forma una resistenza. Se la squadra è d'accordo, ottimo, tieni a mente i limiti del ruolo PO e fai attenzione che "l'eccezione alla regola" diventi una "aspettativa".

Inoltre, parla con il tuo Scrum Master, lui / lei dovrebbe essere una risorsa per questo genere di cose.

Spero che questo aiuti, l'ho buttato giù velocemente.

La mia esperienza è stata quella di avere un capo tecnico che fornisca questa direzione attraverso conversazioni e / o documentazione tecnica (quindi n. 1 sulla tua lista). Questa persona sarà anche in grado di fornire gli orientamenti tecnici necessari per le decisioni chiave. Potranno raccomandare / monitorare / rinforzare le migliori pratiche. Questo di solito non è il PO (Product Owner) in quanto richiede un diverso punto di vista.

Non mi piace che l'approccio basato su criteri / vincoli di accettazione sia troppo formale (il che richiede anche tempo ed energia). Ovviamente, l'intero punto di Agile non è quello di concentrarsi sulla creazione di procedure formali, ma di fornire storie e ottenere il codice scritto per questo.

Non puoi guidare le scelte tecnologiche attraverso le storie degli utenti; sono deliberatamente agnostici sulle decisioni tecnologiche. Questo è il punto: parlano solo di funzionalità, non di implementazione.

Le decisioni sulla tecnologia dovrebbero essere prese sulla base di ciò che il team già conosce, di ciò che vogliono sapere, di quali competenze sono disponibili, di cosa è già in atto, di quali interfacce con i sistemi esistenti è più semplice, ecc.

Chi si occupa dello sviluppo dovrebbe guidarlo, prendendo spunto da chiunque sappia qualcosa.

Benvenuti nel mondo di Scrum. Hai ragione nel supporre che fornire input tecnici nella storia dell'utente potrebbe essere sbagliato. Ecco perché. La User Story riguarda l'utente. L'utente non si cura delle informazioni tecniche. Tu non ti interesserebbe le informazioni tecniche se provenissi da un background meno tecnico. Ciò che tu, come l'AC vorrebbe fare, è che il team fornisca il valore che stai chiedendo. In ogni modo possibile (questo spesso significa che dovrebbero essere incoraggiati a pensare fuori dagli schemi e cercare una soluzione semplice).

Se, tuttavia, ci sono determinati criteri che la soluzione deve soddisfare affinché la storia sia considerata valida, ovviamente li fornirai nei criteri di accettazione (spesso scritti sul retro della story card , nel modulo GWT ). Ad esempio, forse hai bisogno che il servizio venga eseguito in meno di 2 secondi o a causa dei requisiti del cliente , come l'interfaccia con un altro sistema, il tuo servizio deve fornire un risultato basato su XML.

Altre opinioni tecniche (che potrebbero essere di parte, come per le tue abilità) dovrebbero essere mantenute non ufficiali. Ricorda che le storie degli utenti sono contratti non , ma piuttosto una promessa di conversare! Durante lo sprint tu, il PO, sei considerato un "pollo", quindi il tuo consiglio dovrebbe considerato, ma in definitiva dovrebbe essere fino al team per possedere la consegna della soluzione.

Spero che questo aiuti, e trovi la transizione da comando e controllo ad agile il più semplice possibile. È un viaggio da ragazzi, ma ne vale la pena.

Devi lasciar andare!

Non è più il tuo lavoro. È necessario affidarsi ai tecnici per prendere le giuste decisioni e concentrarsi sull'ottenere il prodotto direttamente dal punto di vista del marketing.

Dopo tutto, lo avresti odiato se il proprietario del prodotto avesse messo in dubbio il tuo giudizio quando eri a capo del team tecnico. Concentrandoti sul tuo "ultimo lavoro", ti esibirai male nel tuo nuovo lavoro. Essere il "Product Owner" non sembra così facile, e richiede di padroneggiare una nuova serie di competenze e sembra abbastanza grande di una sfida senza la distrazione di fare anche il lavoro di qualcun altro.

Non suggerire come risolvere il problema, ma FARE comunicare quali sono le motivazioni commerciali alla base della storia.

IMHO, una responsabilità chiave di una OP è di comunicare efficacemente il contesto aziendale e di mercato al team in modo che possano prendere decisioni valide e informate.

In questo caso, il time to market è fondamentale, quindi comunica al team: "Questa storia è molto importante per le aziende che vogliamo uscire molto presto, quindi prendi in considerazione se possiamo semplicemente utilizzare una soluzione off-the-shelf o libreria di terze parti. "

Quindi lascia che sia la squadra a prendere la decisione. Potrebbero scoprire che scrivere da soli è molto più veloce, o forse l'integrazione di una soluzione di terze parti è più veloce, quindi permetti loro di investigare e decidere.

Un buon team può cambiare la propria strategia di implementazione per allinearsi alle esigenze aziendali. Ma potrebbero non capire che il business ha bisogno. Come PO devi colmare questa lacuna.

Uno dei principi agili è Empower people e questo è ciò che devi seguire se vuoi andare con Scrum. In altre parole Scrum / Agile non è per le squadre in cui i membri del team non sono in grado di assumersi la responsabilità delle proprie decisioni = > dovresti avere alcuni membri del team esperti / esperti che si prendono cura dei tuoi dettagli tecnici.

Come PO puoi creare dei vincoli (chiamiamoli criteri di accettazione globali o requisiti non funzionali) e alcuni di essi possono essere tecnici. Ad esempio, se la tua azienda ha una strategia per avere ogni applicazione in Java, puoi creare un tale vincolo all'inizio del progetto ma non puoi guidare la progettazione / l'architettura di ogni singola storia utente - è responsabilità del team. Tali vincoli globali dovrebbero essere definiti in anticipo perché influenzano la stima di ogni story utente.