Convalida delle storie degli utenti: quanto è eccessivo il cambiamento?

Sono favorevole a chiudere le storie abbastanza velocemente nel loro ciclo di vita. I requisiti dovrebbero essere impostati dopo meno di un giorno di discussione nella maggior parte dei casi. Dopo questo punto, spetta al proprietario del prodotto decidere se quei requisiti sono effettivamente qualcosa che vogliono. Se non lo sono, cancella la storia. Se sono qualcosa che vogliono o in parte ciò che vogliono, completa la storia e crea una nuova storia per i seguenti cambiamenti.

In caso di dubbio, combatti per creare una nuova storia. Il costante cambiamento dei requisiti continua a spostare i post degli obiettivi per gli sviluppatori. Non è giusto per loro, e fa male al morale.

Penso che dipenda dal tuo ambiente e dal modo in cui i proprietari del prodotto reagiscono alle scadenze mancate. Perché in ultima analisi, la modifica dei requisiti aumenta le probabilità di mancato rispetto delle scadenze.

Il nostro compito come programmatori è quello di costruire ciò di cui l'azienda ha bisogno. Quindi è sempre appropriato per modificare i requisiti della storia utente in base alle esigenze dell'azienda. È inoltre opportuno documentare le modifiche in modo che una revisione post mortem possa identificare tali modifiche come un fattore che contribuisce.

I criteri per giudicare l'impatto del cambiamento sono gli stessi criteri che utilizzi per stimare la user story in primo luogo. Lo sviluppatore che lavora su quella user story dovrebbe capire il cambiamento e riuscire a ridimensionare l'impatto. Se il nuovo dimensionamento aumenta l'ambito oltre il resto dello sprint, la user story modificata deve essere suddivisa in componenti più piccoli. È lo stesso processo utilizzato per ridimensionare e gestire le storie degli utenti prima che raggiungano il backlog del prodotto.

Quindi torniamo all'ambiente. Se il proprietario del prodotto non è in grado di gestire le scadenze mancanti, allora è meglio annullare il lavoro da loro sprint e riprogrammare. Questo diventa parte della conversazione sulla gestione del cambiamento. Se il proprietario del prodotto è a posto con qualche slippage, lo sviluppatore lavora così tanto nello sprint come fattibile, e crea una nuova storia per il prossimo sprint con il lavoro rimanente o lascia sanguinare la storia esistente. Il nuovo | la decisione del bleed-over è quella del team basata su ciò che funziona meglio per la gestione delle stime.

Ma il nostro compito è costruire ciò di cui l'azienda ha bisogno. Il cambiamento è positivo. Ci tiene occupati. E ottiene il business di cui hanno bisogno.

Un'altra domanda che potremmo porci è: cosa costituisce una buona user story?

Prima colazione Scrum: ottenere buone storie utente suggerisce che una buona user story risponde alle tre domande di Who? Che cosa? e perché? e che può essere presentato a una squadra in qualsiasi ordine; che sarà facile da stimare, è piccolo e controllabile.

Le storie degli utenti che sono troppo vaghe richiedono più tempo di progettazione e di solito finiscono per sprecare tempo prezioso per sprint. Uno degli attributi di un programmatore professionista è la capacità di essere onesti con la gestione. Molte volte questo significa che dobbiamo essere abbastanza coraggiosi da assicurarci che discussioni difficili avvengano quando una storia non è ancora pronta per l'implementazione, perché una volta che sarà pronto, saremo in grado di stimare accuratamente quando può essere fatto. Ci sentiremo quindi a nostro agio nel prendere un deciso impegno in merito alla consegna.

Tentare di stimare una storia che ha troppe incognite finirà per nuocere alla tua relazione con i tuoi manager, perché, come puoi consegnare ciò che vogliono quando ancora non riescono a definirlo completamente. Storie come questa solitamente richiedono più tempo per la progettazione. Può essere d'aiuto il tempo di progettazione durante uno sprint, ma questo è solo il primo passo. Il design non è la consegna. Finché non hai una storia che puoi offrire, dobbiamo stare al tavolo da disegno.

Dal manifesto agile: "Collaborazione del cliente per la negoziazione del contratto"

Se consideri una storia come un contratto a cui ti sei impegnato all'inizio dello sprint, non puoi cambiare molto senza rinegoziare il tuo impegno. Ma penso che sia l'approccio sbagliato.

È veloce ed economico chiedere una nuova stima del nuovo contenuto della storia in qualsiasi momento. La stima (lavoro rimanente) è cambiata? Allora sei a posto. In caso contrario, la pianificazione dello sprint potrebbe richiedere un aggiustamento e, a condizione che qualcuno ne sia informato, non dovrebbe essere un problema.