Come possiamo ridurre i tempi di inattività al termine di un'iterazione?

Dove lavoro, pratichiamo agile guidato dalla mischia con iterazioni di 3 settimane. Sì, sarebbe bello se le iterazioni fossero più brevi, ma cambiare al momento non è un'opzione.

Alla fine dell'iterazione, di solito trovo che l'ultimo giorno vada molto lentamente. Il lavoro effettivo è già stato completato e accettato. Ci sono un paio di incontri (la retrospettiva e la prossima pianificazione dell'iterazione), ma a parte questo non sta succedendo molto.

Che tipo di tecniche possiamo usare come team per mantenere lo slancio nell'ultimo giorno? Dovremmo affrontare i difetti? Inizia comunque presto il lavoro della prossima iterazione? Qualcos'altro?

Ultimamente ho avuto qualche problema con la stessa domanda. Stiamo iniziando con la prossima iterazione, ma ritengo che ciò rimuova la soddisfazione di una iterazione ben eseguita.

Sto pensando all'opzione di lasciarlo agli sviluppatori, con l'avvertenza "fintanto che l'intento è di beneficiare l'azienda".

Esempi:

• Trascorri la giornata imparando qualcosa
• Spenderlo in un progetto di innovazione
• Spendi riordinando quel fastidioso pezzo di codice che non riesci mai a rimettere in sesto
• Esegui una buona corsa attraverso l'app in vista di UX (che non sembra mai trovare il tempo di fare altrimenti)

Qualunque cosa motiva il programmatore, dando loro un incentivo per consegnare il rilascio in tempo.

Prenditi il ​​giorno libero. Hai fatto il lavoro che dovevi fare, quindi perché lavori ancora?

Se fosse possibile modificare il processo, prendere in considerazione la possibilità di abbandonare le iterazioni, rilasciarle continuamente e continuare a estrarre storie dal backlog. Ma non meriti un po 'di tempo libero?

Ho notato lo stesso problema (e talvolta utilizziamo sprint di 2 settimane, il che lo aggrava ancora di più). Quello che cerco di fare in quei giorni (giornata di revisione dello sprint e giornata di pianificazione dello sprint) è risparmiare un po 'di lavoro che so che vorrò fare ma che non richiede molta pianificazione o comunicazione intrateam, come bug a bassa priorità, polacco, o miglioramenti degli strumenti. A volte questo in realtà diventa positivo, in quanto crea un buon momento per fare un lavoro importante ma non sexy per il quale sarebbe altrimenti difficile trovare il tempo.

Anche se le storie dei nostri utenti sono quasi sempre finite entro la fine di un'iterazione, alla fine abbiamo sempre un lungo elenco di "simpatici", insieme a un elenco di bug noti. Quindi quando le persone finiscono le loro storie c'è sempre molto da fare.

Penso che tenere un incontro retrospettivo sia il re, anche se si tratta principalmente degli stessi problemi sollevati, è molto importante dedicare un po 'di tempo a riflettere su come è andata l'iterazione, come si impara, se non si rendono conto dei propri errori e le cose che sono andate bene.

Se tutti i bug sono stati fatti, è stato fatto un lungo elenco di cose da fare meglio, insieme a punti d'azione, penso che sia bello riunire la squadra di fronte 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 risolvere eventuali problemi dell'ultimo minuto il venerdì. Ma quei venerdì (uno ogni 2 settimane) coincidono con i nostri venerdì della birra, quindi proviamo a prenderlo abbastanza tranquillamente. Risolvi alcuni bug minori, passa un po 'di tempo a leggere cose (libri, StackExchange, blog, ecc.) E rilassati con una birra alla fine della giornata. Altrimenti non si arriva a una sensazione di completamento o chiusura, e invece a sentirsi come un criceto che gira su una ruota senza sosta.

Non sono sicuro che vuoi finire sempre esattamente in tempo. Fare il tuo lavoro un po 'in anticipo ti consente di pensare a storie, capacità e caratteristiche future. Ti dà un po 'di pausa dopo un lavoro ben fatto che può essere più gratificante rispetto all'avvio anticipato o impegnarsi in più storie e avere sempre lavoro da riporto.

Ken Schwaber afferma nel suo blog http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

"Dio ci aiuti. Le persone hanno trovato il modo di rilassarsi in cascata, riposare ed essere creativi. Con Lean e Kanban, quei nascondigli vengono rimossi. Ora abbiamo una marcia progressiva della morte senza sosta."

Nei miei progetti, durante la pianificazione dell'iterazione selezioniamo sempre alcune attività extra e le etichettiamo come "attività bonus" su cui lavorare se tutto viene completato nell'iterazione. Pragmaticamente, questi "compiti bonus" sono generalmente quelli su cui si lavorerebbe prima nella prossima iterazione, ma chiamarli in modo psicologico "compiti bonus" funziona molto meglio, quindi semplicemente avendo sempre più lavoro pianificato, allora può essere completato.

Per altre cose come il tempo di apprendimento o innovazione, lasciamo semplicemente che ogni sviluppatore trascorra fino a un giorno alla settimana su quella roba come una cosa normale prevista. Può essere in 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à di sprint siano terminate) come "tempo di Google".

È qui che ogni sviluppatore lavora sulla propria idea / progetto fintanto che avvantaggia la società. Consiglio vivamente di mettere in atto un sistema come questo, che ha davvero aumentato i livelli di soddisfazione sul lavoro all'interno del nostro team.

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

Uno degli obiettivi della mischia è quello di aumentare la produttività - non lo farai se sei sotto tiro per ogni sprint.

Per risolvere questo, pianifica più storie di quante tu abbia mai visto. Impegnati 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 lo sprint successivo. Pianifica sempre un po 'più di quanto ti impegnerai, o almeno avrai alcune storie in fila, per ogni evenienza.

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

Mi piace la risposta di Todd di prendermi il giorno libero, tuttavia direi che provate a fare la pianificazione dello sprint e la retrospettiva al mattino e impostare una sfida per farlo in tempo per il pranzo e poi fare un lungo pranzo in squadra. A pranzo incoraggia la discussione sullo sprint in modo da ottenere gratuitamente una retrospettiva informale.

Se non riesci quindi a dare il via al pomeriggio (e intendo come andare a casa nel primo pomeriggio libero, non un giorno prefissato per i tuoi obiettivi), allora affronta il debito tecnico in quanto è l'unica cosa che deprime uno sviluppatore più di ogni altra cosa (fonte : la mia opinione) dovendo aggirare il debito tecnico quando sanno esattamente come affrontarlo e semplificare la vita.

Personalmente trovo che le retrospettive non valgano davvero la pena passare del tempo, di solito ci sono alcuni temi ricorrenti comuni (storie di utenti poveri, cattive stime, ecc.) E li accetti semplicemente come aree problematiche e vai avanti. Cerchiamo anche di affrontare i problemi non appena si presentano, piuttosto che aspettare la retrospettiva (che abbiamo avuto la tendenza a fare nelle prime fasi dell'adozione di Scrum).

Ora invece di avere una retrospettiva, ogni coppia di sviluppatori seleziona un oggetto eccezionale dal backlog di retrospettiva esistente e ci lavora.

Manteniamo anche un arretrato di debito tecnico in corso, che funge da elemento bonus per gli sprint (se l'azienda non è pronta a implementare qualcosa dal proprio backlog in anticipo).

Questo si è già dimostrato abbastanza positivo, in quanto tutti i piccoli oggetti che continuano a gorgogliare ricevono una giornata di attenzione ogni sprint.

Partecipa a una sessione di progettazione sulla lavagna bianca e condividi idee di implementazione per storie interessanti sul prossimo sprint. Fallo dopo e separati dalla sessione di pianificazione, dove le storie erano ancora chiare nei dettagli e giudicate in base ai punti della storia o alle stime delle dimensioni delle magliette. Mantieni informale la sessione e incoraggia la creatività.