Sprint pianificazione e accomodamento allentato

Scrum leans towards eliminating slack

Sì e No.

Scrum ti costringe a fare un "tempo intelligente per l'innovazione e altre cose buone".

1. "Altre cose buone" sono le retrospettive e le alzate quotidiane.

2. "innovazione" è ciò che gli spikes tecnologici o le soluzioni spike sono per

Non vanno via. Non sono sepolti.

Diventano parti di alto livello e di valore elevato del processo.

Essere reattivi al cambiamento - con un piccolo vincolo - è l'intero punto di un metodo Agile e di una mischia in particolare.

L'unico piccolo vincolo (attendere fino alla fine dello sprint) non richiede la costruzione di un tempo di allentamento o comunque di armeggiare con scrum o il team di sviluppo.

È facile essere reattivi (aspettando fino alla fine dello sprint) senza costruire inutili spese generali.

L'innovazione è supportata da soluzioni spike.

Altre buone cose sono supportate da stand up e retrospettive giornalieri.

Come qualcuno che ha trascorso quasi dieci anni a studiare i requisiti della forza lavoro, posso dirti che nessuno in nessuna professione dovrebbe mai essere pianificato al 100% per il lavoro diretto. Abbiamo utilizzato una cifra di poco più di 30 ore di lavoro diretto a settimana per persona. Devi tenere conto delle riunioni, delle pause, del ritardo inevitabile (le esercitazioni antincendio vengono in mente come esempio), dei compiti non diretti (cose come gli sviluppatori chiamati a fare una correzione per qualcun altro o compilare moduli HR o spostare la tua scrivania ), e ferie, tempo di malattia e altri tipi di congedo, come il congedo dal lutto. La mancanza di considerazione di ciò è uno dei motivi principali per cui la maggior parte dei progetti software non rispettano le scadenze promesse (o rendono la data ma con meno funzionalità rispetto a quella promessa originariamente), indipendentemente dall'utilizzo di metodi Cascile o Agile.

In Agile Estimating and Planning Mike Cohn parla di rallentamenti in modo approssimativo descrivendo la differenza tra" tempo ideale "e" tempo trascorso ":

Ideal time is the amount of time that something takes when stripped of peripheral activities.

Elapsed time [...] is the amount of time that passes on a clock.

More examples of why ideal time does not equal elapsed time are:

• Supporting the current release
• Sick time
• Meetings
• ...Phone calls
• ...Email [your friends]
• ...Task switching

Un consiglio che dà è di stimare in base al tempo ideale, per ogni story utente.

In SCRUM, viene generalmente indicato come velocità .

Velocity incorpora tutti i concetti che hai citato - fattore di fuoco, "allentamento", ecc. Il punto è che dovresti non modificare artificialmente le tue stime o bloccare i giorni come "allentati". Cerchi di stimare il più consistentemente possibile e alla fine di ogni sprint, modifichi la velocità in base a ciò che hai realizzato.