Come includi il supporto nel tuo Sprint?

Abbiamo adottato un approccio molto simile designando un "programmatore di supporto" che ruotava attraverso gli sviluppatori più giovani (o più recenti) del team. Sono stati incoraggiati a provare davvero a capire il problema prima di chiedere agli altri sviluppatori, anche se sarebbe stato più veloce passarlo allo sviluppatore che conosceva meglio il codice. In questo modo sono stati costretti ad apprendere la base di codice e hai evitato di far uscire le persone dalla "zona" e di distruggere la produttività. Inoltre, devi creare un meccanismo che impedisca alle persone di dare una svolta ai programmatori non di supporto per farlo funzionare.

Un punto chiave è che il team deve capire che quello che potrebbe essere il modo più veloce per chiudere i problemi di supporto non è sempre l'uso più efficiente del tempo del team. Assicurati che l'intero team sappia che l'obiettivo di questa struttura è di ridurre al minimo le interruzioni alle persone che si trovano in quella modalità produttiva a tutti i costi.

Detto questo, il programmatore di supporto non era dedicato al 100% alle chiamate di supporto. Hanno lavorato su casi nello sprint, ma avrebbero dovuto lavorare sugli elementi con priorità più bassa in modo che se fossero rimasti bloccati su molti problemi di supporto il fatto che non avessero terminato le loro cause non sarebbe stato un problema così grande .

Come puoi includere andare al bagno nel tuo Sprint? Come consideri gli sviluppatori di tempo spendere a casa giocando con i loro figli? Che dire di aver dormito tempo?

Ovviamente sono sarcastico, la risposta è che IMHO non dovresti includere il tempo di supporto nella pianificazione dello sprint. L'unica volta che dovrebbero essere inclusi nella pianificazione dello sprint sono attività direttamente associate ai deliverable di sprint.

Se una risorsa deve dedicare così tanto tempo al supporto allora hai meno ore di risorse disponibili da quello sviluppatore, quello sprint. Il set di funzionalità incluso in quello sprint dovrebbe riflettere questo fatto.

Penso che la cosa più semplice da fare sia aggiungere le attività di supporto direttamente all'elenco di elementi inclusi nello sprint. Se queste attività di supporto sono correzioni di bug, saranno prioritizzate nel backlog nello stesso modo in cui lo fai per i miglioramenti. Se sono basati sul tempo (come la gestione dei report di fine mese), anche questi possono essere facilmente programmati. Questo è quello che facciamo e funziona bene.

Nella mia mente, ci sono due diversi tipi di lavoro di "supporto". Il primo tipo è un'emergenza che deve essere riparata ORA. È molto più lavoro di tipo operativo, materiale antincendio che non può essere pianificato e stimato come parte di uno sprint. Il secondo tipo è una segnalazione di bug, che viene valutata, assegnata una priorità e pianificata in uno sprint. È trattato come qualsiasi altra storia. Spesso, il primo tipo risulterà nel secondo tipo; spegni il fuoco e crei un bug report per fare una correzione reale, in modo che non accada di nuovo. Per il resto di questo post, sto parlando del primo: lavoro di emergenza non pianificato che deve essere fatto ORA.

Prendersi del tempo lontano dal Team per svolgere il lavoro di supporto riduce la velocità della squadra. Dovresti usare la tua velocità storica per determinare la tua capacità per il prossimo sprint. Il cambio di contesto richiesto per passare dal lavoro di rilascio a quello di supporto significa che c'è un sovraccarico, ma dal momento che il lavoro che si esegue per uno sprint dovrebbe tenere conto di quanto lavoro si fa storicamente in uno sprint, la quantità di tempo tipica hai messo in supporto, e l'overhead di commutazione del contesto dovrebbe essere automaticamente preso in considerazione.

Non ritengo che questo sia un lavoro di sprint. È separato e dovrebbe avere la priorità rispetto al lavoro sprint. Quindi, mangia nella velocità della squadra, ed è "pianificato per" usando quella velocità ridotta quando si decide quanto lavoro può essere fatto durante il prossimo sprint.