Separare cosa e come - Progettare in un ambiente Agile [chiuso]

Question

In un ambiente agile (mischia), come si fa a far sì che la gestione del prodotto crei elementi o storie di backlog sufficientemente piccoli senza che loro si occupino di tutta la progettazione, che non è la loro specialità?In altre parole, come si separa il cosa (requisiti aziendali) dal come (progettazione) nello sviluppo agile?

Answer 1

Con la mischia, il gestione del prodotto dovrebbe essere una persona:IL proprietario del prodotto .

Ciò che vuoi fare viene fatto durante il pianificazione dello sprint, dove dovrebbe essere presente l'intero team (proprietario del prodotto, scrummaster, sviluppatori).

IL Che cosa dovrebbe essere definito come storie degli utenti dal proprietario del prodotto .Le storie degli utenti dovrebbero essere di alto livello, limitando il proprietario del prodotto a esprimere i requisiti aziendali le storie di una frase dovrebbero bastare.

per esempio. Come utente StackOverflow, vorrei vedere la mia reputazione

Uno degli obiettivi della pianificazione dello sprint è decidere le storie che dovrebbero essere realizzate durante lo sprint.Quindi quando le storie vengono scelte dal product Owner, il team può suddividerle, parlare brevemente del design (il come) e stimarli.

In poche parole, il Che cosa dovrebbe essere fatto dal proprietario del prodotto, il Come dalla squadra.Se questo processo viene spiegato chiaramente al proprietario del prodotto, questi non proverà a progettare tutto.Se ci prova comunque, il direttore di mischia lo fermerà.

Answer 2

La prima cosa che devi fare, e che è la causa di un gran numero di fallimenti dei progetti Scrum, è insegnare al tuo product management a svolgere il ruolo di Product Owner.Devi dimostrargli che è responsabile del ROI del progetto e, per questo, è responsabile di dare priorità alle storie/utenti/esigenze/caratteristiche aziendali o qualunque cosa tu stia utilizzando per comporre il tuo Product Backlog in un modo che il più gli oggetti di valore hanno priorità più elevate.

Sono favorevole all'utilizzo delle storie degli utenti come elementi del product backlog e poi, durante la pianificazione dello sprint, a suddividere in attività più piccole le storie selezionate per comporre lo sprint backlog.

Ciò che dovresti sempre tenere a mente quando scrivi, o aiuti il ​​tuo PO a scrivere, le tue storie utente è che le storie dovrebbero essere INVESTITE. IOindipendente, Nnegoziabile, Vvantaggioso per i clienti, Estimabile, Scentro commerciale e Tstabile.

Penso che all'inizio utilizzare il modello seguente potrebbe essere utile per mantenere il PO concentrato sugli obiettivi aziendali:

"Come -tipo di utente-, voglio -qualche obiettivo- affinché -qualche ragione-."

Un esempio potrebbe essere "Come utente StackOverflow, voglio votare su una risposta in modo che la risposta più preziosa possa essere facilmente trovata".

Non dimenticare di far scrivere al PO o definire il test di accettazione per ogni storia del tuo Sprint Backlog poiché può essere utilizzato come criterio di base per determinare se una storia è completamente implementata.

Per l'esempio sopra, due possibili test di accettazione sono:

"Test per votare una risposta"

"Prova per votare una risposta"

Con questa storia e due test di accettazione il team sa che l'utente StackOverflow può votare le risposte e per aggiornare lo stato della storia con Fatto, è necessario che il sistema consenta all'utente di votare su e giù per una risposta senza generare eccezioni.

Answer 3

Non dimenticare che gli elementi del product backlog devono essere classificati in ordine di importanza, utilizzando un sistema di ponderazione (numeri primi, Fibonacci,..), in modo che se nel tuo backlog sono presenti elementi di importanza simile (ad es.2 elementi con un peso di 21), allora in teoria dovrebbero entrambi provare ad inserirsi nello sprint davanti ai 13 e agli 8.

Answer 4

Durante la (ri)stima del backlog (dopo la definizione delle priorità) il team dovrebbe eseguire la modellazione per comprendere l'intera portata della User Story ed essere in grado di stimare accuratamente la complessità.Questa non è l'intera portata della modellazione che potrebbe aver luogo (i team potrebbero fare di più nello sviluppo), ma è un ottimo punto di partenza e sarà possibile trarre vantaggio dalla presenza del cliente/proprietario del prodotto per rispondere alle domande lì poi.

Di conseguenza, la discussione risultante ti aiuterà a collaborare con il Product Owner per suddividere i suoi requisiti fino a raggiungere una granularità significativa e adeguata.