Come possiamo ridurre i tempi di fermo alla fine di una iterazione?

Ultimamente ho lottato con la stessa domanda un po '. Stiamo iniziando dalla prossima iterazione, ma ritengo che ciò rimuova la soddisfazione di un'iterazione ben fatta.

Sto pensando all'opportunità di lasciarlo agli sviluppatori, con l'avvertenza "finché l'intento è di aiutare l'azienda."

Esempi:

• Trascorri la giornata imparando qualcosa
• Spendilo in un progetto di tempo di innovazione
• Spendilo riordinando quel fastidioso pezzo di codice che non hai mai utilizzato per il refactoring
• Avere una buona corsa attraverso l'app in vista di UX (che non sembra mai trovare il tempo per fare altrimenti)

Qualunque sia la motivazione del programmatore, dando loro un incentivo a consegnare l'uscita in tempo.

Prendi il giorno libero. Hai fatto il lavoro che avresti dovuto fare, quindi perché lavori ancora?

Se fosse possibile modificare il processo, prendere in considerazione la possibilità di rilasciare iterazioni, rilasciare continuamente e continuare a estrarre storie dall'arretrato. Ma non ti meriti un po 'di tempo libero?

Ho notato lo stesso problema (e talvolta usiamo sprint di 2 settimane, cosa che lo esaspera ancora di più). Quello che cerco di fare per quei giorni (sprint review day e sprint planning day) è risparmiare un po 'di lavoro che so che vorrò fare ma non richiede molte comunicazioni di pianificazione o intrateam, come bug a bassa priorità, lucido, o miglioramenti degli strumenti. A volte questo diventa effettivamente positivo, poiché crea un buon momento per fare un lavoro importante ma non sexy che altrimenti sarebbe difficile trovare il tempo per farlo.

Anche se le nostre storie utente sono quasi sempre terminate entro la fine di un'iterazione, alla fine abbiamo sempre una lunga lista di "simpatie", insieme a un elenco di bug noti. Quindi quando le persone finiscono le loro storie c'è sempre molto da fare.

Penso che fare un incontro retrospettivo sia il re, anche se i suoi problemi sono per lo più gli stessi, è molto importante dedicare un po 'di tempo a riflettere su come è andata l'iterazione, come imparare, se non lo fai renditi conto dei tuoi errori e delle cose che sono andate bene.

Se tutti i bug sono finiti, è stato fatto un lungo elenco di cose da fare meglio, insieme ai punti azione, penso che sia bello riunire la squadra davanti a un grande schermo e provare a giocare con il software che è stato costruito, insieme ad alcune birre. Non è estremamente produttivo, ma è bello parlare di ciò che è stato implementato e di come funziona effettivamente.

Se hai giorni, allora proverei a trovare qualcosa di nuovo da imparare e proverei a giocarci, forse è la prossima grande cosa. Ma poi di nuovo se ci sono giorni, allora c'è probabilmente una user story nel backlog da fare

Le nostre iterazioni terminano il giovedì, per essere in grado di correggere qualsiasi problema dell'ultimo minuto il venerdì. Ma quei venerdì (uno ogni 2 settimane) coincidono con il nostro venerdì di birra, quindi cerchiamo di prenderlo abbastanza calmo. Risolvi alcuni bug minori, passa un po 'di tempo a leggere articoli (libri, StackExchange, blog, ecc.) E rilassati con una birra alla fine della giornata. Altrimenti non raggiungi la sensazione di completamento o chiusura, e invece ti senti come un criceto che gira su una ruota senza sosta.

Non sono sicuro che vuoi per finire sempre esattamente in orario. Fare in modo che il tuo lavoro sia svolto un po 'presto ti consente di pensare a storie, funzionalità e funzionalità future. Ti dà un po 'di pausa dopo un lavoro ben fatto che può essere più gratificante che iniziare presto o impegnarsi in più storie e avere sempre il riporto del lavoro.

Ken Schwaber afferma nel suo blog link

"Dio ci aiuti, le persone hanno trovato il modo di avere un po 'di respiro in cascata, di riposare e di essere creativi. Con Lean e Kanban, quei nascondigli sono stati rimossi." Ora abbiamo una progressiva marcia della morte senza pause. "

Nei miei progetti, durante la pianificazione dell'iterazione selezioniamo sempre alcuni compiti extra e li etichettiamo come "compiti bonus" su cui lavorare se tutto è finito nell'iterazione. Pragmaticamente, questi "compiti bonus" sono in genere ciò che dovrebbe essere svolto per primo nella successiva iterazione comunque, ma chiamarli psicologicamente "compiti bonus" funziona molto meglio quindi semplicemente avere sempre più lavoro pianificato che può essere completato.

Per altre cose come il tempo di apprendimento o di innovazione, semplicemente lasciamo che ogni sviluppatore spenda fino a un giorno alla settimana su quella roba come una normale cosa attesa. Può essere qualsiasi giorno della settimana (cioè non deve essere alla fine di ogni settimana).

Tutti gli sviluppatori del mio team utilizzano il tempo libero verso la fine di uno sprint (a condizione che tutte le attività sprint siano terminate) come "Google time".

Questo è il luogo in cui ogni sviluppatore lavora sulla propria idea / progetto purché benefici per l'azienda. Suggerisco caldamente di mettere in atto un sistema come questo, questo ha davvero aumentato i livelli di soddisfazione del lavoro all'interno del nostro team.

Se finisci costantemente tre giorni prima, mi suggerisce che non stai pianificando abbastanza storie per lo sprint.

Uno degli obiettivi della mischia è aumentare la produttività: non lo farai se stai sparando a ogni sprint.

Per risolvere questo, pianificare più storie di quante non lo siano state. Impegna solo per la tua velocità precedente, ma se finisci quelle storie inizia a lavorare su quelle extra. Se completi di più, aumenta la velocità per il prossimo sprint. Pianifica sempre per un po 'più di quanto ti impegni, o almeno fai in modo che alcune storie siano allineate, per ogni evenienza.

Questo è uno dei motivi per cui siamo passati a Kanban. Tutti i benefici della mischia senza dover interrompere il progetto.

Mi piace la risposta di Todd di prendermi una giornata libera, tuttavia direi di provare e fare una pianificazione di sprint e una retrospettiva al mattino e impostare una sfida per farlo in tempo per il pranzo e poi fare un lungo pranzo in gruppo. Al pranzo incoraggia la discussione sullo sprint in modo da ottenere gratuitamente una retrospettiva informale.

Se non riesci a rinunciare al decollo (e intendo dire che andare a casa nel primo pomeriggio non è un set per i tuoi obiettivi pomeridiani) poi affrontare il debito tecnico in quanto è l'unica cosa che deprime uno sviluppatore più di ogni altra cosa altrimenti (fonte: la mia opinione) dovendo lavorare attorno al debito tecnico quando sanno esattamente come affrontarlo e semplificarsi la vita.

Personalmente ritengo che le retrospettive non valgano davvero la pena di passare del tempo, di solito ci sono alcuni temi ricorrenti comuni (storie di utenti scadenti, stime sbagliate, ecc.) e le accetti solo come aree problematiche e vai avanti. Cerchiamo anche di affrontare i problemi come / quando sorgono, piuttosto che aspettare la retrospettiva (che avevamo la tendenza a fare nelle prime fasi dell'adozione di Scrum).

Ora invece di avere una retrospettiva, ogni coppia di sviluppatori sceglie un oggetto in sospeso dal backlog retrospettivo esistente e ci lavora sopra.

Manteniamo inoltre un arretrato del debito tecnico in corso, che funge da bonus per gli sprint (se l'azienda non è pronta a implementare qualcosa dal suo arretrato in anticipo).

Questo si è già dimostrato abbastanza positivo, in quanto tutti i piccoli oggetti che continuano a ribollire ottengono un giorno di attenzione ogni sprint.

Avere una sessione di progettazione di lavagna bianca e condividere idee di implementazione per storie interessanti sul prossimo sprint. Fallo dopo e separalo dalla sessione di pianificazione, dove le storie erano ancora chiare sui dettagli e giudicate dai punti della storia o dalle stime delle taglie della maglietta. Mantieni la sessione informale e incoraggia la creatività.