Pianificazione dello sprint

Articolo
02/19/2013

Di Mitch Lacey.Proprietario, Mitch Lacey & Associates, Inc, un'azienda di consulenza che si specializza in adozioni e miglioramenti Agile e scrum.

Gennaio 2012.

La pianificazione dello sprint non deve essere impegnativa.È spesso divertente e un momento per l'intero team scrum di sviluppare familiarità collaborando per rispondere alla domanda "su cosa ci possiamo impegnare"? In questo articolo gli autori forniscono esempi e strategie per mantenere la pianificazione dello sprint concentrata ed efficace e fornire dettagli ai problemi comuni riscontrati dai team durante la pianificazione di uno sprint.

Si applica a

Application Lifecycle Management; Team Foundation Server

In questo articolo:

Introduzione
Previsioni e esecuzione del commit
Definizione di pianificazione di uno Sprint
Come ci si può riuscire?
Problemi comuni
- Scenario: Il team non può impegnarli per tutte le storie che il proprietario del prodotto ha richiesto.
- Scenario: Il proprietario del prodotto non è pronto.
- Scenario: La Parte 1 supera il relativo intervallo di tempo.
- Scenario: La Parte 2 supera il relativo intervallo di tempo.
- Scenario: Il proprietario del prodotto non è disponibile.
- Scenario: Il team non dispone dei criteri di accettazione richiesti.
- Scenario: Il proprietario del prodotto non sa cosa significa completato.
- Scenario: Il proprietario del prodotto o lo ScrumMaster stima/influisce sulle stime/lavoro del team.
Conclusione

Non pianifichiamo.Facciamo Scrum, pertanto eseguiamo semplicemente il lavoro.

Questa è un'affermazione ricorrente.Le persone pensano che scrum e Agile significhino assenza di pianificazione, di stima, di riunioni: nulla.Nulla di più lontano dalla verità.La pianificazione è presente a vari livelli in un progetto Agile: ci sono il piano giornaliero o la riunione quotidiana, i piani settimanali (sprint, iterazione, backlog), il piano di rilascio (backlog del prodotto) e altro ancora.

Concentriamoci sulla pianificazione di uno sprint.

Previsioni e esecuzione del commit

Nell'estate del 2011 Ken Schwaber e Jeff Sutherland hanno modificato la Guida Scrum.In tale guida, hanno rimosso un comportamento stabilito da tempo noto alla metodologia scrum, ovvero l'impegno del team verso il proprietario del prodotto e i clienti.L'impegno è stato sostituito dalla previsione.Essi sostengono che i team possono prevedere il proprio lavoro, ma non confermarlo.

Pur comprendendone la logica, preferisco l'impegno per i seguenti motivi:

L'esecuzione del commit pone il team in una prospettiva diversa dalla semplice previsione.Se un team esegue una previsione, è implicito che il fatto di non rispettare tutto quanto ha affermato di poter eseguire sia un comportamento accettabile.Sebbene i team possano imparare dalle previsioni, ottenendo in ultima analisi una varianza inferiore della stima, ritengo che i team che si basano sulle previsioni impiegano più tempo a ridurre la varianza rispetto ai team che si impegnano.
La previsione, o la stima, sono appropriate per il backlog prodotto.Tuttavia, quando i team spostano le storie dal backlog prodotto al backlog sprint e le suddividono, questi aggiungono un altro livello di granularità, grazie a piccoli dettagli che consentono loro di chiedersi "Possiamo riuscirci?". La previsione corre il rischio di far ricadere il team in uno stato differito invece di fargli dire "Abbiamo solo bisogno di una previsione, non è un problema se ci perdiamo qualcosa, possiamo riuscirci in seguito".

E immaginare di dire alla propria moglie, marito o partner "Prevedo che staremo insieme per 10 anni" piuttosto che "Mi impegno con te", questo sicuramente è molto meglio.

Alla fine, scrum è sinonimo di buonsenso.Consiglio di provare sia l'approccio basato sull'impegno che quello basato sulla previsione.Questa è la teoria. In pratica vi conviene sperimentare entrambi gli approcci e utilizzare quello che meglio si adatta alle vostre esigenze, al vostro team e alla vostra società.

Definizione di pianificazione di uno Sprint

Abbiamo tenuto una riunione di pianificazione dello sprint per pianificare gli elementi che il team compilerà nello sprint successivo e la modalità con cui sarà eseguita la compilazione.Sebbene sia denominata riunione di pianificazione dello sprint, in realtà è composto da due parti molto diverse.La parte 1 è incentrata su ciò che viene chiesto al team di compilare e vi partecipano sia dal proprietario del prodotto che il team.La parte 2 è incentrata su come il team prevede di compilare la funzionalità desiderata.Sebbene l'intero team deve prendere parte alla sezione 2, la partecipazione da parte del proprietario del prodotto è facoltativa.Se, per qualsiasi motivo, il proprietario del prodotto non partecipa alla parte 2, dovrà rimanere disponibile per eventuali domande.

Nella parte 1 della riunione di pianificazione dello sprint il proprietario del prodotto ha la possibilità di descrivere al team un set di storie desiderato.Si tratta di una sessione approfondita sulla parte delle storie relativa all'oggetto.Il proprietario del prodotto presenta le storie, illustra le varie interazioni e illustra l'interfaccia.Possono verificare inoltre l'infrastruttura o gli elementi dell'architettura.L'obiettivo è fornire ai membri del team informazioni sufficienti con cui possano iniziare a pensare a come creare la funzionalità.Il team porrà una serie di domande per raccogliere informazioni per la riunione procedurale. Porrà domande del tipo:

“Quali sono i criteri di accettazione di tutte le storie?"
“Quali origini dati si pensa che stiamo utilizzando?"
“Come deve apparire l'interfaccia su questo componente?"

Durante la seconda parte della riunione di pianificazione dello sprint, il team pone la propria attenzione sulla compilazione del backlog sprint (l'elenco delle storie e delle attività richieste per il completamento durante lo sprint).Per compilare il backlog, il team suddivide ogni storia richiesta dal proprietario del prodotto a livello di attività; a ogni attività viene assegnata una stima oraria.Per la fine della parte 2, il team decide di quali storie è consentito eseguire il commit del completamento durante lo sprint.

Insieme, le due parti della riunione di pianificazione dello sprint possono richiedere da due a otto ore.Come regola generale, ciascuna parte dovrebbe durare un'ora per ogni settimana della lunghezza dello sprint.Ciò indica che se eseguo uno sprint di una settimana, la riunione richiederà in totale due ore (un'ora per la Parte 1 e un'ora per la parte 2).Se, invece, eseguo sprint di quattro settimane, la riunione richiederà complessivamente in otto ore (quattro ore per la Parte 1 e quattro ore per la Parte 2).

Come ci si può riuscire?

Se il team chiude la riunione di pianificazione dello sprint impegnandosi a completare un elenco di storie, ha raggiunto lo scopo della pianificazione dello sprint.È tuttavia necessaria una pianificazione anticipata e una facilitazione per fare in modo che ogni membro del team abbia familiarità con l'esecuzione del commit.

Il proprietario del prodotto ha un compito durante la pianificazione dello sprint: recarsi alla riunione in grado di descrivere un set di storie desiderate.L'obiettivo del team è comprendere le storie dal punto di vista del proprietario del prodotto, condividerne la visione.Lo Scrum Master deve assicurarsi che il team ponga domande sufficienti e che acquisisca tutti i dati risultanti, inclusi i criteri di accettazione, gli schizzi e tutte le premesse.Lo Scrum Master deve inoltre far sapere al proprietario del prodotto che il team potrebbe avere ulteriori domande dopo che si è iniziato a trasformare le domande in attività.Sebbene il proprietario del prodotto presenti le storie i cui totali del punto corrispondono approssimativamente alla velocità cronologica del team, questo infine deciderà se può assumere tutte le storie in uno sprint specificato in base a ciò che impara durante le sezioni 1 e 2 della riunione di pianificazione dello sprint.

Dopo che il team ha ottenuto tutte le informazioni dal proprietario del prodotto, deve suddividere le storie in attività e creare un backlog sprint che acquisisce tutte le storie, le note, i criteri di accettazione, le attività e le stime per uno sprint particolare.A tal proposito esistono diversi modi. Personalmente utilizzo un metodo che trae vantaggio dalle idee di tutti i membri del team e dove tutti partecipano alla scomposizione delle attività.

Coloro che ricoprono il ruolo di ScrumMuster o facilitatore della riunione devono leggere una storia e chiedere "Qualcuno l'ha capita?" Poiché il team ne ha già discusso con il proprietario del prodotto, dovrebbe rispondere affermativamente.Se qualche membro del team non ha capito, riesaminare la storia, ponendo tutte le domande necessarie al proprietario del prodotto.
Chiedere quindi a ogni membro del team munirsi di blocchetto adesivo.Chiedere a ogni membro del team di scrivere una sola attività in ogni nota adesiva nel centro del tavolo.
- Quando una nota adesiva viene lanciata nel centro della tavola, colui che ha eseguito il lancio annuncia l'attività.Se pertanto è scritto "aggiornare stored procedure", viene detto ad alta voce.Ciò è importante perché determinerà la nascita di idee e di considerazioni, come quella di aggiornare l'origine dati. A questo punto, qualcuno scriverà "aggiornare l'origine dati" su un bigliettino e lo poserà al centro.Questa attività di "brainstorming" consente effettivamente di eliminare tutte le attività associate.Non preoccuparsi dei duplicati in questo momento.Individuare tutte le attività richiede in genere da cinque a dieci minuti per storia.
Una volta raccolti tutti i bigliettini con le attività sul tavolo, occorre metterli in ordine.Inserirle tutte su una parete, fare un passo indietro e osservare: numerose note adesive!Iniziare identificando qualsiasi duplicato; sovrappongono tutti gli adesivi che sembrano duplicati.Quindi, cercare attività che potrebbero essere associate tra loro o per similitudine o per dipendenza reciproca.Ad esempio, se due note adesive hanno una relazione simile, metterle insieme ma eseguirne l'offset come illustrato nella figura seguente:

Se due attività sono così strettamente correlate da essere quasi identiche, sovrapporle quasi completamente, come illustrato di seguito:

Ordinando le note adesive, il team può eliminare l'elenco di attività e visualizzare le relazioni tra quelle rimanenti.
Una volta messe in ordine le attività, occorre assegnare loro una stima.Io utilizzo la tecnica denominata planning poker per la stima delle attività, con una differenza: i numeri sulle carte rappresentano ore anziché punti.Adotto questo metodo perché le persone tendono a concentrarsi su dettagli inutili per quanto riguarda le ore, specialmente per le attività più grandi.Hanno un valido motivo per la loro trepidazione.Troppo spesso le società utilizzano la stima per tenere sotto pressione i team.“Hai detto che si sarebbero volute 8 invece ne sono passate 12.Qual è l'errore?" o “È stato detto che avrebbe richiesto 8 ore e invece ne sono bastate 4.Si la spaziatura interna le stime".

Allo stesso modo in cui le carte consentono di mantenere astratte le stime dei punti della storia, l'utilizzo di carte per la stima delle attività consente al team di usufruire della libertà che deriva dall'avere un set di numeri fissi da scegliere, forzandoli infine per effettuare una selezione.Elimina inoltre le dispersive discussioni per stabilire se un'attività deve essere stimata a 6 o 6,5 o 7 ore.

Qualsiasi sia la stima finale, è importante ricordare che la stima viene eseguita dal team e viene utilizzata dal team semplicemente per aumentare la propria sicurezza e determinare se è in grado di eseguire il lavoro richiesto dal proprietario del prodotto in base alla velocità.Le stime di attività non sono metriche e non devono essere utilizzate come tali.Non utilizzaremai le stime come arma con il team.
Ora che le attività vengono stimate, il team deve determinare se ha la possibilità di eseguire più lavoro.A tale scopo, è necessario conoscere la capacità del team, le ore totali che il team ha a disposizione durante lo sprint.La determinazione della capacità è semplice se si dispone di un team completamente dedicato, ma diventa più difficile se si dispone di un team composto di personale part-time suddiviso in più progetti.Chiedere a ogni membro di annotare il numero di ore giornaliere che ognuno può lavorare sul progetto (o in totale per tutto lo sprint).Aggiungere tutti i numeri insieme per ottenere il numero complessivo di ore disponibili per il team.Diciamo che la capacità del team è risultata di 200 ore.Se la somma delle attività per una storia prevede l'utilizzo di 30 ore, chiedere al team, “È possibile accettare altro lavoro"? In questa fase iniziale, la risposta è ovviamente un sì.

Poiché si dispone di maggiore capacità di riempimento, passare alla storia seguente e ripetere i passaggi da uno a cinque.

(Per informazioni su come eseguire questa attività tramite Team Foundation Server, vedere Pianificazione Agile e iterazioni).

A un certo punto, sarà difficile rispondere alla domanda "Possiamo avere più lavoro?" Questo perché ci si sta avvicinando alla capacità del team.Mentre si lavora in questo processo, consideri la possibilità che non si desidera riempire lo sprint fino alla capacità massima.Se riempie un bicchiere d'acqua fino all'orlo, è molto probabile che trabocchi.Lo stesso vale per gli sprint.Se le ore stimate utilizzano tutto il tempo disponibile e una nuova attività viene identificata in una fase successiva dello sprint, la capacità verrà superata.È necessario lasciare spazio alle attività emergenti.

Per considerare l'impegno richiesto da uno Sprint, è utile considerare i dati retrospettivi degli sprint passati.Il team deve introdurre coerentemente più lavoro?Forse il team potrebbe impegnarsi di più durante la pianificazione dello sprint.Il team è coerentemente incapace di completare tutto il lavoro di uno sprint?Il team potrebbe dover essere più cauto con i propri impegni fintanto che non ha risolto la causa radice degli sprint incompleti.

Un modo per inserire un numero alla domanda di "quanto deve essere completo per riempire il bicchiere" è di considerare la crescita di dimensioni del piano.Pianificare le misure della crescita di dimensioni delle effettive ore e passare alle stime iniziali.Diciamo, ad esempio, che il nostro team dispone di una capacità di 200 ore disponibili.In base alle stime, il team ritiene di poter svolgere un lavoro in 190 ore.Alla fine dello Sprint, il team calcola che le storie contenevano 240 ore di lavoro effettivo, con una crescita di dimensione del piano del 20%.

Un team che cerca questa discrepanza deve impiegare un po' di tempo durante la retrospettiva a esaminare i motivi:

Sono state individuate troppe attività durante l'esecuzione che non sono state identificate durante la pianificazione?
Il team sta sottovalutando le attività basate sull'insieme di competenze corrente?
Il team ha sopravvalutato la sua capacità?
E così via.

Il team deve inoltre considerare la crescita delle dimensioni del piano durante la riunione di pianificazione del successivo sprint quando determina se può impegnarsi in una storia.Ritornando all'esempio precedente, se il team prevede una capacità di 200 ore, deve sottrarre il 20% per compensare la crescita della dimensione del piano "prevista" in base ai dati cronologici.In altre parole, almeno per questo sprint, per impedire superamenti di capacità, quando il team raggiunge 160 ore deve dichiarare di aver raggiunto la capacità massima.

La valutazione della la crescita di dimensione del piano rappresenta un modo per quantificare quanto deve essere completo lo sprint.Tenere presente, tuttavia, che l'obiettivo non è un'esatta corrispondenza con la capacità.Piuttosto si tratta di consentire al team si impegnarsi tranquillamente su un numero appropriato di storie, in numero che stimola il team senza sovraccaricarlo.La crescita di dimensione del piano è semplicemente un modo per determinare quanto approssimativamente completo lo sprint successivo deve essere, se tutti gli altri fattori rimangono uguali.

Quando tutte le storie vengono stimate o quando si esaurisce il tempo delle storie, condividere con il proprietario del prodotto il backlog dello sprint che il team si è impegnato a rispettare.È il momento di mettersi al lavoro, lo sprint inizia ora.

Problemi comuni

Durante gli anni di consulenza con i team per aiutarli ad adottare scrum, ho potuto osservare molti dei problemi che impediscono il corretto completamento di una pianificazione dello sprint.Sebbene la pianificazione dello sprint sembri diretta, i team che stanno iniziando uno scrum tendono ad avere dei conflitti.Molti di questi problemi e le soluzioni possibili sono descritti in questa sezione.

Scenario: Il team non può impegnarli per tutte le storie che il proprietario del prodotto ha richiesto.

È necessario prevedere che questo venga occasionalmente.Se nella parte precedente di questo argomento il team può eseguire il backup dell'impegno con i dati dalle fasi quattro e cinque, il proprietario del prodotto dovrebbe essere soddisfatto.Potrebbe essere necessario impedire l'immissione di un occhio per assicurarsi che questa impossibilità di eseguire il commit non sia un risultato sia di riempimento o di grandi.Lo Scrum Master deve mettere in discussione le stime che sembrano essere troppo caute per assicurarsi che siano precise.Il proprietario del prodotto deve porre domande in merito a qualsiasi attività che abbia una stima a due cifre.Qualsiasi attività che si prevede richieda più tempo di due giorni lavorativi deve essere suddivisa in attività più piccole ed essere nuovamente stimata.Ciò vale per tutti i progetti ma è particolarmente preoccupante per i team che eseguono sprint di una o due settimane.

Scenario: Il proprietario del prodotto non è pronto.

Un valore scrum è il rispetto.Non è rispettoso partecipare a una riunione non preparati.Cosa deve quindi fare un team se il proprietario del prodotto si presenta con le informazioni richieste dal team?Sebbene un'opzione sia di posticipare la riunione finché il proprietario del prodotto non è pronto, in tal modo si incoraggia a comportarsi nello stesso modo, per cui evitare di farlo.Un'altra opzione consiste nell'annullare lo sprint.Sebbene ciò possa funzionare, si tratta di un'opzione estrema.

Ritengo che la soluzione migliore sia duplice.Innanzitutto, il backlog del prodotto deve trovarsi in un certo ordine di priorità, in questo modo se il proprietario del prodotto non dispone di un particolare set di storie, il team e il proprietario del prodotto possono illustrare le storie in ordine di priorità fino al raggiungimento di un punto in cui credono di aver raggiunto o oltrepassato le proprie capacità.Il team può quindi decidere l'impegno effettivo durante la Parte 2 della riunione, come di consueto.

Dopo la riunione, lo ScrumMaster deve cercare di capire perché il proprietario del prodotto non era preparato.Se il problema è stata una mancanza di impegno, lo ScrumMaster può indicare al proprietario del prodotto l'importanza di presenziare alla riunione preparato con un set di storie.Se, invece, il problema è che il proprietario del prodotto è stato incapace di prepararsi, probabilmente perché il team non ha contribuito alla fase di pulitura, lo ScrumMaster dovrà risolvere anche questi problemi.

Scenario: La Parte 1 supera il relativo intervallo di tempo.

Un altro valore è lo stato attivo.Se il tempo riservato alla Parte 1 viene superato, è sintomatico dalla mancanza di concentrazione.Talvolta il proprietario del prodotto non è concentrato a causa della mancanza di preparazione, di priorità o a causa del tentativo di espandere troppe storie.In altri casi, la mancanza di attenzione può provenire dallo dalla mancata associazione di specifici "come" alle conversazioni di tipo "cosa".

Lo Scrum Master deve stimolare la riunione insistendo che il proprietario del prodotto schematizzi tutte le storie che non possono essere descritte in modo esaustivo e che il team assimili le discussioni dettagliate sull'implementazione della Parte 1.Una correzione semplice per una discussione non focalizzata è l'utilizzo di un cronometro o un timer.

Scenario: La Parte 2 supera il relativo intervallo di tempo.

Ancora una volta lo stato attivo.Se si dispone di un team che discute molto, talvolta imporre una disciplina che limiti le discussioni è tutto ciò che serve per riportare in linea la riunione.Portare un timer e fare in modo che la conversione duri un minuto o due tra le stime di attività.L'obiettivo è la precisione, non la precisione al 100%.

In altri casi, una mancanza di attenzione durante la parte 2 è sintomatica dalla mancanza di backlog del prodotto che controlla durante l'esecuzione dello sprint.La pulitura è una fase in cui il team può esaminare le storie future e può lavorare con il proprietario del prodotto in modo da aggiungere storie o picchi per bloccare le direzioni di progettazione o per indirizzare le domande relative all'architettura.Senza il controllo regolare del backlog del prodotto, la pianificazione del backlog sprint può diventare pesante e tormentata.

Scenario: Il proprietario del prodotto non è disponibile.

Se il proprietario del prodotto non può presenziare alla riunione per un motivo qualsiasi e non ha nominato un sostituto, agire come se il proprietario del prodotto fosse presente alla riunione impreparato.Occorre esaminare gli elementi principali e assegnarli al meglio.La tentazione per modificare il momento della riunione di adattare la pianificazione del proprietario del prodotto.Don’tSpostando l'ora della riunione soddisfa le esigenze di uno a scapito di molti.Non vale la pena.

Scenario: Il team non dispone dei criteri di accettazione richiesti.

Consiglio sempre ai team di chiedere al proprietario del prodotto durante la sezione 1 "Quali sono i criteri di accettazione?" oppure “Cosa dobbiamo fare per convincerti ad accettare il lavoro?". Se questo non appare nella sezione 2, quando il team sta determinando delle attività, non avrà idea di come chiudere la storia.Se il team deve fare supposizioni, in base a quanto ha ascoltato nella Parte 1, corre il rischio che alla fine dello sprint il proprietario del prodotto decida che la storia non è completata.Richiedere i criteri di accettazione dall'inizio per ogni storia.ScrumMaster: fornisce istruzioni ai proprietari del prodotto per fornire questi dati.

Scenario: Il proprietario del prodotto non sa cosa significa completato.

Così come il team desidera criteri di accettazione, il proprietario del prodotto richiede una descrizione aggiornata di ciò che il team definisce "la storia è completata". Questo elenco di fasi completate dovrebbe essere inviato in modo rilevante, aggiornato e disponibile al proprietario del prodotto.Un elenco di esecuzione non aggiornato rende difficile la pianificazione poiché non si conosce comunemente come sarà una volta eseguito.Assicurarsi di aggiornare l'elenco di eseguito come parte di ogni revisione o retrospettiva dello sprint.

Scenario: Il proprietario del prodotto o lo ScrumMaster stima/influisce sulle stime/lavoro del team.

Il proprietario del prodotto arriva nella seconda parte della riunione ma il suo ruolo a questo punto dovrebbe essere limitato al chiarimento di una richiesta o a rispondere a una domanda specifica.Il proprietario del prodotto non deve mai interferire nella discussione del team su come implementare una storia e non deve intervenire sulla stima di un'attività.Il proprietario del prodotto deve ritenere il team in grado di eseguire il lavoro.

Se il proprietario del prodotto non agisce secondo queste linee guida, lo ScrumMaster dovrà dare istruzioni al proprietario del prodotto affinché assuma un ruolo più appropriato.Se il proprietario del prodotto rifiuta di accettare un ruolo più passivo, lo ScrumMaster dispone dell'autorità per chiedere al proprietario del prodotto di lasciare la riunione.

La pianificazione dello sprint non deve essere impegnativa.È spesso divertente e un momento per l'intero team scrum di sviluppare familiarità collaborando per rispondere alla domanda "su cosa ci possiamo impegnare"? Tenere presente che, se la riunione si prolunghi eccessivamente, la causa radice del problema probabilmente ne è l'origine.Lo ScrumMaster mantiene concentrata la riunione assicurando che il proprietario del prodotto e il team eseguano la pulitura del backlog del prodotto.Aiutare il proprietario del prodotto a essere preparato avendo pronti i criteri di accettazione prima della riunione.Infine, aiutare a mantenere l'attenzione del proprietario del prodotto e del team su attività a disposizione, determinando su cosa è possibile eseguire il commit per lo sprint.