Come strutturare uno sprint di sviluppo?[Chiuso]

Question

Quindi ho un arretrato di funzionalità e stiamo per iniziare un progetto considerevole.Sto lavorando per definire la struttura dei nostri sprint e sono interessato al feedback delle community.

Quello che penso è:

• Pianificazione dello sprint di un giorno
  • Riempi il backlog e scopri cosa andrà ogni sviluppatore dopo questo sprint
• Tre settimane di sviluppo
  • ANDARE!ANDARE!ANDARE!
• Incontro quotidiano in piedi
  • Controlla se qualcuno ha bisogno di aiuto o si sente fuori strada
• Due giorni di sprint review
  • le revisioni del codice avvengono qui, le presentazioni delle parti interessate
• Retrospettiva sullo sprint di un giorno
  • cosa abbiamo fatto nell'ultimo sprint?come possiamo fare meglio la prossima volta?

Gli sprint dovrebbero sempre terminare di martedì (per evitare troppo stress nel fine settimana).

Qualunque altra cosa?Ovviamente c'è di più nell'agile oltre a questo.Voglio fornire al team una semplice descrizione di come opereremo non appena avvieremo questo progetto.

Answer 1

Prenderei in considerazione la possibilità di sperimentare sprint più brevi di un mese.

Personalmente trovo che le iterazioni di una o due settimane siano più efficaci per ottenere rapidamente un feedback efficace.Inoltre, impedisce che eventuali problemi che potrebbero causare problemi a livello di iterazione raggiungano livelli che diventano più difficili da gestire.

Anche per lo sprint di 30 giorni: due giorni sembrano un giorno troppo lungo per la revisione dello sprint...e un giorno sembra circa mezzo giorno di troppo per la retrospettiva.Ho scoperto che se hai bisogno di molto di più ci sono stati problemi di comunicazione durante le iterazioni, quindi potresti considerare la necessità di revisioni lunghe come una possibile bandiera rossa.

Ovviamente questa è stata solo la mia esperienza: sviluppare principalmente app Web con team di piccole dimensioni (4-12 persone).La tua esperienza può variare.

Detto questo, proverei sicuramente gli sprint più brevi.Come le build di integrazione, molte cose diventano più facili se le fai più spesso.

Answer 2

Disattiva le app di posta elettronica, cellulare e messaggistica istantanea per dedicare tempo al codice di base.Dalle 10:00 alle 13:00 e dalle 14:00 alle 17:00 potrebbero essere buoni blocchi per questo.

Ordina cibo e bevande per la squadra quando sono nella "zona".

Annullare tutte le altre riunioni per i giorni precedenti, successivi e successivi alla sessione di pianificazione e ai giorni di revisione.

Answer 3

• Assicurati che lo "stand-up" rimanga uno STAND-up.È molto facile scivolare in riunioni sempre più lunghe.
• Un giorno di pianificazione dello sprint e tre giorni alla fine potrebbero essere troppi.Pianifica solo il tempo di cui hai bisogno.
• +1 all'idea di iterazioni più brevi.Personalmente, quattro iterazioni di una settimana all’interno di uno sprint hanno funzionato bene.Le persone sono brave a stimare i compiti a breve termine;passato questo diventa sempre più una supposizione.

Answer 4

Sembra un buon approccio.Condivido ciò che hanno detto Adrianh e Jedidja riguardo a iterazioni possibilmente più brevi.A me piace 1 settimana.Oltre a una migliore stima, mantiene anche l'idea di "software funzionante" su un ciclo molto più breve.

Alcune domande:

Perché le revisioni del codice vengono lasciate fino alla fine?Abbina il programma o fai le tue revisioni mentre procedi.

3 settimane di sviluppo significano "sviluppo, test, documentazione, installatori, ecc"?Cioè.tutto ciò di cui hai bisogno per essere fatto davvero?

Answer 5

Strutturiamo i nostri sprint in modo molto simile al tuo schema, tranne per il fatto che le nostre revisioni degli sprint si svolgono l'ultimo giorno dello sprint e generalmente durano circa un'ora.La revisione dello sprint è il momento in cui esponi il tuo lavoro ai clienti e ad altre parti interessate, non il momento per eseguire revisioni del codice.Le revisioni del codice, se si sceglie di eseguirle, dovrebbero essere eseguite periodicamente durante lo sprint.Avevamo un blocco di un'ora ogni settimana in cui esaminavamo il codice nominato dallo sviluppatore, il che significa che non perdevamo tempo a rivedere ogni LOC scritto.

Inoltre, terminiamo i nostri sprint di martedì e iniziamo di giovedì, lasciando mercoledì per concludere le questioni in sospeso e affrontare il debito tecnico creato durante lo sprint.

Answer 6

Non consiglio di posticipare le revisioni del codice fino a dopo lo sprint, dovrebbero essere parte integrante del processo di sviluppo.In altre parole, un'attività non viene eseguita a meno che il codice non sia stato rivisto (e testato, documentato e...).

Answer 7

È importante evitare di gestire per il gusto di gestire.SCRUM richiede solo 1 riunione al giorno, ed è breve.Inoltre, durante ogni sprint, gli unici altri incontri sono la retrospettiva di primavera e la pianificazione dello sprint.Ciò ci consente di implementare ROWE, o un ambiente di lavoro orientato ai risultati.Lascia che i tuoi sviluppatori decidano come, dove e quando effettueranno il loro sviluppo.Usa i tuoi stand-up giornalieri per verificare che stanno svolgendo il loro lavoro.Oltre a questo, stai indietro e lasciati stupire dalla loro produttività.

Idee come "spegnere i cellulari, disattivare le app di messaggistica istantanea, ecc. durante la codifica" sono tutte cattive idee.Quando assumi la tua squadra, la assumi con la certezza che sappiano svolgere correttamente il loro lavoro.Se li assumessi con questa consapevolezza, perché vorresti limitare la loro capacità di svolgere il loro lavoro nel miglior modo possibile?Se utilizzi SCRUM, ogni sviluppatore avrà scelto il lavoro che ritiene di essere in grado di svolgere, il tuo lavoro come Scrum-Master è rimuovere gli ostacoli, non crearli.

Recensioni del codice:Assolutamente necessario.Le revisioni tra pari del codice sono un ottimo strumento didattico per gli sviluppatori junior che partecipano alle riunioni e per le persone che hanno rivisto il loro codice.

Documenti di progettazione:Personalmente ritengo che documenti di progettazione dettagliati che coprano ciò che lo sviluppatore intende fare siano molto importanti e ritengo anche che siano una parte importante del processo di sviluppo.Ora, questo non è specificamente in linea con lo sviluppo agile, ma personalmente faccio regolarmente riferimento ai documenti di progettazione creati anni fa per vedere cosa pensava lo sviluppatore originale quando codificava i propri moduli.