Alcuni strumenti di gestione del software Scrum ti offrono questa opzione per nominare esplicitamente i tuoi sprint.
Hai un modo preferito di nominare i tuoi sprint o semplicemente usi uno schema semplice come 1, 2, 3, ...?
Chiedi al team .
Se pensano che sia divertente o utile nominare lo sprint, sceglierne uno insieme.
Poiché ogni sprint dovrebbe avere un obiettivo , non dovrebbe essere un problema trova un nome adatto.
La denominazione dello sprint potrebbe effettivamente aiutare il focalizzazione del team sull'obiettivo principale.
Personalmente mi piacerebbe questo genere di cose.
In una società in cui lavoravo, avevamo sprint / rilasci mensili e li abbiamo nominati alfabeticamente dopo i meme internet. Le versioni su cui ho lavorato di recente sono state:
Ciò ha aggiunto un po 'di divertimento al processo, specialmente quando è arrivato il momento di nominare l'iterazione imminente.
Dopo un po 'di tempo a pensarci, sono arrivato con la seguente convenzione:
<year> CW <starting calendar week> - <ending calendar week>: <goal> (<version>)
La versione è facoltativa.
Quindi si finisce con qualcosa di simile:
2013 CW 27-28: Improved reporting and dashboards (v1.5.1)
2013 CW 29-30: Redesigned gadgets (v1.5.2)
...
Questa sintassi risponde alle domande:
E anche:
Se l'intera faccenda ha uno scopo specifico ("aggiungi rapporti", "porta in luoghi europei"), allora c'è il tuo nome. Se si tratta di una raccolta di cose dal backlog, allora una data vaga ("l'uscita di giugno") funziona per noi. Questo ci consente di dire a un utente "Non credo che si possa inserire nella versione di giugno, è corretto inserirlo nel prossimo?" oppure "se lo desideri nella versione di giugno, dovremo accontentarci di [qualunque cosa] entro il 5 giugno". Sono solo etichette, ma servono a uno scopo.
Per noi ci divertiamo a mettere nomi divertenti, internamente comunque, alle nostre uscite numerate e ai progetti più grandi per spezzare un po 'la monotonia. Siamo sempre alla ricerca di nomi più divertenti e creativi per i nostri progetti e rilasci più grandi, ma ovviamente utilizziamo anche un sistema di numerazione tradizionale (1.0, 1.1) o basato sulla data per tenere traccia da una prospettiva di codice il nostro miglior risultato è rapper old school. Nessuno dice che lo sviluppo della mischia non possa essere un po 'divertente
Ex. Beastie Boys, Coolio, DJ Jazzy Jeff, Eazy-E, Flavor Flav, Ecc.
Nel mio team, gli sprint tendono ad essere nominati dopo la versione di rilascio di produzione che stiamo preparando. Nel caso di una versione di produzione che si estende su diversi sprint, aggiungiamo il numero di iterazione. Quindi, ad esempio,
ecc.
Date!
Il nostro processo utilizza un ramo di rilascio per ogni sprint che facciamo, quindi i nomi dei rami di sprint e release si allineano. Usiamo la data di rilascio pianificata come nome del ramo e dello sprint.
Questo rende la comprensione della storia un po 'più semplice allo stesso tempo - ad es. se stai guardando una vecchia email su un bug che pensavi fosse corretto, in base alla data dell'email, puoi facilmente saltare ai nomi dei rami più vicini per avere un'idea migliore del cambiamento. (Certo, dovresti sperare che questo sia rintracciato anche nel tuo bug tracker /, ma sappiamo tutti che non è sempre così.)
È anche molto bello che tutto il nostro team sappia sempre esattamente quale sia il nome, quindi siamo sempre sulla stessa pagina quando ci si riferisce a uno sprint oa un ramo. (Non c'è mai confusione tra "Is 'badger" di questa settimana o la scorsa settimana? ").
A mio parere, l'uso di numeri per il nome non fornisce alcun valore. Del resto, anche se può essere divertente, non fare nomi astratti. L'utilizzo di nomi orientati all'obiettivo potrebbe essere una bella aggiunta (ad esempio "2012-04-03: Aggiornato i widget del cliente"), ma non tornerei indietro usando solo nomi astratti.
Per ogni versione scegliamo un nome di città grande in ordine alfabetico (ad es. A tlanta, B oston, C hicago, D allas ...)
E alcuni nomi di college in quella città diventano i nostri nomi di sprint (Morehouse, Spelman, ..., Harvard, Cambridge, ecc.)
Non ho mai veramente pensato di nominarli. Di solito, alla fine abbiamo allegato un ID di build in modo da poter tenere traccia dei problemi, ma la denominazione in realtà non fa parte del processo. Con rilasci ogni due settimane bruceresti 26 nomi all'anno.
Suppongo che ciò renderebbe comunque una parte divertente della pianificazione sprint. Potrei doverlo provare per il nostro prossimo sprint.