Pianificazione dello sprint

Articolo
06/10/2015

Di Mitch Lacey. Titolare di Mitch Lacey & Associates, Inc, una società di consulenza specializzata nell'adozione e nell'ottimizzazione di framework di sviluppo di tipo Agile e Scrum.

Gennaio 2012

La pianificazione dello sprint non deve essere impegnativa. È spesso divertente e un momento per l'intero team scrum in cui sviluppare spirito di squadra 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 focalizzata ed efficace, nonché dettagli sulle potenziali soluzioni ai comuni problemi riscontrati dai team durante la pianificazione di uno sprint.

Si applica a

Application Lifecycle Management e Team Foundation Server

Contenuto dell'articolo:

Introduzione
Previsione e impegno
Che cos'è la pianificazione dello sprint?
Come si realizza?
Problemi comuni
- Scenario: Il team non può impegnarsi su tutte le storie richieste dal proprietario del prodotto.
- Scenario: Il proprietario del prodotto non è preparato.
- Scenario: La prima parte supera l'intervallo di tempo stabilito.
- Scenario: La seconda supera l'intervallo di tempo stabilito.
- Scenario: Il proprietario del prodotto non è disponibile.
- Scenario: Il team non ha i criteri di accettazione necessari.
- 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.

Noi 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, di qualsiasi cosa! 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 di Prodotto) e potenzialmente molto altro ancora.

Concentriamoci sulla pianificazione di uno sprint.

Previsione e impegno

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. Loro sostengono che i team possono prevedere il proprio lavoro, ma non impegnarsi nel realizzarlo.

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

L'impegno a realizzare qualcosa pone il team in una prospettiva diversa dalla semplice previsione. Se un team fa una previsione, è implicito che il fatto di non rispettare tutto quello che ha affermato di poter fare sia un comportamento accettabile. Sebbene i team possano imparare dalle previsioni, ottenendo alla fine una varianza inferiore della stima, ritengo che i team che si basano sulla previsione impiegano più tempo a ridurre la varianza rispetto ai team che si basano sull'impegno.
La previsione, o la stima, è appropriata per il Backlog di Prodotto. Tuttavia, quando i team spostano le storie dal Backlog di Prodotto al backlog dello sprint scomponendole, aggiungono un altro livello di granularità, scoprendo piccoli dettagli che consentono loro di chiedersi "Possiamo impegnarci?". La previsione corre il rischio di riportare il team a uno stato di inerzia e a fargli dire "Abbiamo solo bisogno di fare una previsione, non è un problema se ci perdiamo qualcosa, possiamo risolvere tutto successivamente".

In chiave più leggera è come immaginare di dire alla propria moglie, marito o partner "Prevedo che staremo insieme per 10 anni" anziché dire "Mi impegno con te", che sicuramente suona 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 usare quello che meglio si adatta alle vostre esigenze, al vostro team e alla vostra società.

Che cos'è la pianificazione dello sprint?

Abbiamo tenuto una riunione di pianificazione dello sprint per pianificare cosa il team farà nello sprint successivo e come lo farà. Sebbene sia denominata riunione di pianificazione dello sprint, in realtà è composta da due parti molto diverse. La prima parte è incentrata su cosa il team deve realizzare e vi partecipano sia il proprietario del prodotto che il team. La seconda parte è incentrata su come il team intende realizzare la funzionalità desiderata. Sebbene l'intero team debba partecipare alla seconda parte, la partecipazione del proprietario del prodotto è facoltativa. Se, per qualsiasi motivo, il proprietario del prodotto non partecipa alla seconda parte, dovrà rimanere disponibile per eventuali domande.

Nella prima parte 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 sull'oggetto delle storie. Il proprietario del prodotto presenta le storie, illustra le varie interazioni e descrive minuziosamente l'interfaccia. Può inoltre esaminare l'infrastruttura o gli elementi architetturali. L'obiettivo è fornire ai membri del team informazioni sufficienti con cui possano iniziare a pensare a come realizzare la funzionalità. Il team porrà una serie di domande per raccogliere informazioni per la riunione procedurale, ad esempio:

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

Durante la seconda parte della riunione di pianificazione dello sprint, il team pone l'attenzione sulla creazione del backlog dello sprint, ovvero l'elenco delle storie e delle attività da completare durante lo sprint. Per creare il backlog, il team scompone ogni storia richiesta dal proprietario del prodotto a livello di attività e a ogni attività viene assegnata una stima oraria. Entro la fine della seconda parte, il team decide su quali storie impegnarsi durante lo sprint.

Le due parti della riunione di pianificazione dello sprint possono richiedere insieme dalle due alle otto ore. Come regola empirica generale, ciascuna parte dovrebbe durare un'ora per ogni settimana di durata dello sprint. Ciò significa che se si eseguono sprint di una settimana, la riunione richiederà in totale due ore (un'ora per la prima parte e un'ora per la seconda). Se, invece, si eseguono sprint di quattro settimane, la riunione richiederà in totale otto ore (quattro ore per la prima parte e quattro ore per la seconda).

Come si realizza?

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. Per fare in modo che ogni membro del team abbia dimestichezza con l'impegno assunto, sono tuttavia necessarie attività di pre-pianificazione e assistenza.

Il proprietario del prodotto ha un unico compito durante la pianificazione dello sprint: recarsi alla riunione ed essere in grado di descrivere un set di storie desiderate. L'obiettivo del team è comprendere le storie dal punto di vista del proprietario del prodotto e condividerne la visione. Lo ScrumMaster deve assicurarsi che il team ponga tutte le domande necessarie e che acquisisca tutti i dati risultanti, inclusi i criteri di accettazione, gli schizzi e tutte le premesse. Lo ScrumMaster deve inoltre far sapere al proprietario del prodotto che il team potrebbe avere altre domande dopo aver iniziato a scomporre le domande in attività. Sebbene il proprietario del prodotto presenti le storie i cui punti totali corrispondono approssimativamente alla velocità storica del team, sarà il team a decidere in definitiva se può accettare tutte le storie in un determinato sprint in base a ciò che apprende durante la prima e la seconda parte della riunione di pianificazione dello sprint.

Dopo che il team ha ottenuto tutte le informazioni dal proprietario del prodotto, deve scomporre le storie in attività e creare un backlog dello sprint che include tutte le storie, le note, i criteri di accettazione, le attività e le stime per un particolare sprint. Sebbene ci siano molti modi per raggiungere questo obiettivo, personalmente uso un metodo che sfrutta le idee di tutti i membri del team e dove tutti partecipano alla scomposizione delle attività.

Coloro che ricoprono il ruolo di ScrumMaster 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 di munirsi di blocchetto adesivo. Chiedere a ogni membro del team di scrivere una sola attività in ogni nota adesiva e di metterla al centro del tavolo.
- Appena una nota adesiva viene messa al centro del tavolo, l'autore ne annuncia l'attività. Se quindi nella nota è scritto "aggiornare stored procedure", viene detto ad alta voce. Ciò è importante perché determinerà la nascita di idee e di considerazioni da parte degli altri membri, come ad esempio l'idea di aggiornare l'origine dati. A questo punto, qualcuno scriverà "aggiornare l'origine dati" su un foglietto e lo metterà al centro del tavolo. Questa attività di brainstorming consente effettivamente di trovare tutte le attività associate. In questo momento non c'è da preoccuparsi dei duplicati. Scrivere tutte le attività mettendo i foglietti al centro del tavolo richiede in genere dai cinque ai dieci minuti per storia.
Una volta raccolti tutti i foglietti con le attività sul tavolo, occorre metterli in ordine. Attaccarli tutti su una parete, fare un passo indietro e osservarli. Iniziare a identificare eventuali duplicati. Sovrapporre tutte le note adesive che sembrano duplicate. Cercare quindi 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 sfalsarle come mostrato nella figura seguente:

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

Ordinando le note adesive, il team può selezionare l'elenco di attività e visualizzare le relazioni tra quelle rimanenti.
Una volta messe in ordine le attività, occorre assegnare loro una stima. Personalmente uso la tecnica denominata planning poker per la stima delle attività, con una differenza: i numeri sulle carte rappresentano le ore anziché i punti. Adotto questo metodo perché le persone tendono a concentrarsi su dettagli inutili per quanto riguarda le ore, specialmente per le attività più grandi. C'è un valido motivo per la loro ansia. Troppo spesso le società usano la stima per tenere sotto pressione i team. "Hai detto che ci sarebbero volute 8 invece ne hai impiegate 12. Qual è il problema?" oppure “Hai detto che ci sarebbero volute 8 ore e invece ne hai impiegate solo 4. Hai gonfiato le stime".

Allo stesso modo in cui le carte consentono di mantenere astratte le stime dei punti della storia, l'uso delle carte per la stima delle attività consente al team di usufruire della libertà che deriva dall'avere un set di numeri fissi da cui scegliere, portando alla fine il team a fare una scelta. Elimina inoltre le discussioni animate 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 usata dal team semplicemente per aumentare la propria fiducia determinando se è in grado di eseguire il lavoro richiesto dal proprietario del prodotto in base alla velocità. Le stime delle attività non sono metriche e non devono essere usate come tali. Non usare mai le stime come arma contro il team.
Dopo aver eseguito la stima delle attività, il team deve determinare se ha la capacità di accettare altro lavoro. A tale scopo, è necessario conoscere la capacità del team, ovvero 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 da personale part-time suddiviso tra più progetti. Chiedere a ogni membro di annotare il numero di ore giornaliere che può dedicare al progetto (o le ore totali per tutto lo sprint). Aggiungere tutti i numeri insieme per ottenere il numero complessivo di ore disponibili per il team. Immaginiamo che la capacità del team è risultata essere di 200 ore. Se la somma delle attività per una storia prevede l'utilizzo di 30 ore, chiedere al team: "Possiamo accettare altro lavoro"? In questa fase iniziale, la risposta è ovviamente sì.

Poiché si ha ancora capacità disponibile, passare alla storia successiva e ripetere i passaggi da uno a cinque.

Per informazioni su come eseguire questa attività con Team Foundation Server, vedere Collaborare [reindirizzamento].

A un certo punto, sarà difficile rispondere alla domanda "Possiamo accettare altro lavoro"? Questo perché ci si sta avvicinando alla capacità del team. Durante tutto questo processo, tenere sempre presente che l'obiettivo non è quello di riempire la capacità dello sprint. 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 successivamente nello sprint viene individuata una nuova attività, la capacità verrà superata. È necessario lasciare spazio per le attività che potranno scaturire.

Per valutare l'impegno richiesto da uno sprint, è utile considerare i dati retrospettivi degli sprint passati. Il team deve sistematicamente aggiungere altro lavoro? Forse il team potrebbe impegnarsi di più durante la pianificazione dello sprint. Il team è sistematicamente incapace di completare tutto il lavoro di uno sprint? Probabilmente il team dovrebbe essere più attento a valutare i propri impegni finché non risolve la causa alla base degli sprint incompleti.

Un modo per rispondere alla domanda di "quanto basta per riempire un bicchiere" è considerare la crescita delle dimensioni del piano. La crescita delle dimensioni del piano misura come sono state impiegate le ore effettive rispetto alle stime iniziali. Immaginiamo, ad esempio, che il nostro team abbia una capacità di 200 ore disponibili. In base alle stime, il team ritiene di poter svolgere il lavoro in 190 ore. Alla fine dello sprint, il team calcola che le storie contenevano 240 ore di lavoro effettivo, comportando quindi una crescita delle dimensioni del piano del 20%.

Un team che trova questa discrepanza deve impiegare un po' di tempo durante l'analisi retrospettiva per esaminarne i motivi:

Sono state individuate troppe attività durante l'esecuzione non identificate durante la pianificazione?
Il team ha sottovalutato le attività basate sull'attuale insieme di competenze?
Il team ha sopravvalutato la propria capacità?
E così via.

Il team deve anche considerare la crescita delle dimensioni del piano durante la successiva riunione di pianificazione dello sprint per determinare se può impegnarsi su una storia. Ritornando all'esempio precedente, se il team prevede sempre 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, per evitare il superamento della capacità, quando il team raggiunge le 160 ore deve dichiarare di aver raggiunto la capacità massima, almeno per questo sprint.

La valutazione della crescita delle dimensioni del piano rappresenta un modo per quantificare quanto riempire uno sprint. Tenere presente, tuttavia, che l'obiettivo non è un'esatta corrispondenza con la capacità. Si tratta piuttosto di consentire al team di impegnarsi tranquillamente su un numero giusto di storie, ovvero un numero che stimola il team senza sovraccaricarlo. La crescita delle dimensioni del piano è semplicemente un modo per determinare approssimativamente quanto riempire lo sprint successivo, se tutti gli altri fattori rimangono uguali.

Dopo aver eseguito una stima di tutte le storie o aver esaurito tutto il tempo per le storie, condividere con il proprietario del prodotto il backlog dello sprint che il team si è impegnato a rispettare. È il momento di mettersi al lavoro: che lo sprint abbia inizio!

Problemi comuni

Durante gli anni di consulenza con i team per aiutarli ad adottare il metodo scrum, ho potuto osservare molti degli stessi problemi che impediscono la corretta pianificazione dello sprint. Sebbene la pianificazione dello sprint sembri semplice, i team che si stanno avvicinando al metodo scrum tendono a muoversi con fatica. Molti di questi problemi e le relative soluzioni possibili sono descritti in questa sezione.

Scenario: Il team non può impegnarsi su tutte le storie richieste dal proprietario del prodotto.

Bisogna fare in modo che tale situazione si verifichi occasionalmente. Fin quando il team può avvalorare l'impegno con i dati riportati ai passaggi quattro e cinque, descritti in precedenza in questo argomento, il proprietario del prodotto dovrebbe essere soddisfatto. Si vorrà controllare che il fatto di non aver rispettato l'impegno non sia dovuto a stime gonfiate o ad attività di dimensioni più grandi. Lo ScrumMaster deve mettere in discussione le stime che sembrano essere troppo prudenti per assicurarsi che siano precise. Il proprietario del prodotto deve mettere in dubbio qualsiasi attività che abbia una stima a due cifre. Qualsiasi attività che preveda più di due giorni lavorativi deve essere scomposta in attività più piccole e sottoposta a una nuova stima. 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 è preparato.

Un valore dello scrum è il rispetto. Non è rispettoso partecipare a una riunione non preparati. Cosa deve quindi fare un team se il proprietario del prodotto si presenta senza le informazioni richieste dal team? Sebbene una possibilità sia quella di rimandare la riunione finché il proprietario del prodotto non sia pronto, è consigliabile evitarla perché così facendo si incoraggia solo lo stesso comportamento. Un'altra possibilità consiste nell'annullare lo sprint. Sebbene ciò possa funzionare, si tratta dell'ultima soluzione da adottare.

Ritengo che la soluzione migliore sia doppia. Innanzitutto, il Backlog di Prodotto deve avere un determinato ordine di priorità, in modo tale che, se il proprietario del prodotto non ha un particolare set di storie, il team e il proprietario del prodotto possono parlare semplicemente delle storie in ordine di priorità finché non arrivano al punto in cui credono di aver raggiunto o oltrepassato la capacità. Il team può quindi stabilire l'impegno effettivo durante la seconda parte 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 è una mancanza di impegno, lo ScrumMaster può spiegare al proprietario del prodotto l'importanza di partecipare alla riunione preparati con un set di storie. Se, invece, il problema è che il proprietario del prodotto non è stato in grado di prepararsi, probabilmente perché il team non ha contribuito con la pulizia, sarà compito dello ScrumMaster risolvere anche questi problemi.

Scenario: La prima parte supera l'intervallo di tempo stabilito.

Un altro valore è la concentrazione. Se il tempo riservato alla prima parte viene superato, è sintomatico della mancanza di concentrazione. Talvolta il proprietario del prodotto non è concentrato a causa della mancanza di preparazione, di organizzazione in base alle priorità o a causa del tentativo di spiegare troppe storie. In altri casi, la mancanza di concentrazione può derivare dal fatto che il team sposta la conversazione dal "cosa sarà completato nello sprint" al "come sarà svolto il lavoro".

Lo ScrumMaster deve far procedere la riunione chiedendo al proprietario del prodotto di rinviare tutte le storie che non possono essere descritte in modo esaustivo e al team di tenere fuori dalla prima parte le discussioni dettagliate. Una soluzione semplice per una discussione non focalizzata è usare un cronometro o un timer.

Scenario: La seconda supera l'intervallo di tempo stabilito.

Ancora una volta la concentrazione. 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 conversazioni durino un minuto o due tra le stime delle attività. L'obiettivo è la precisione, non la precisione al 100%.

In altri casi, una mancanza di concentrazione nella seconda parte è sintomatica della mancanza di pulizia del Backlog di Prodotto durante l'esecuzione dello sprint. La pulizia è una fase in cui il team può esaminare le storie future e lavorare con il proprietario del prodotto per aggiungere storie o picchi per individuare le indicazioni di progettazione o per risolvere i problemi di architettura. Senza la pulizia regolare del Backlog di Prodotto, la pianificazione del backlog dello sprint può diventare pesante e faticosa.

Scenario: Il proprietario del prodotto non è disponibile.

Se il proprietario del prodotto non può partecipare alla riunione per un motivo qualsiasi e non ha nominato un sostituto, agire come se il proprietario del prodotto fosse presente alla riunione impreparato. Esaminare gli elementi principali e impegnarsi al meglio su di essi. Si potrebbe essere tentati di cambiare la data e/o l'ora della riunione per venire incontro alla pianificazione del proprietario del prodotto. Non farlo. Spostando la data e/o l'ora della riunione si va incontro alle esigenze di una sola persona a scapito di molti. Non ne vale la pena.

Scenario: Il team non ha i criteri di accettazione necessari.

Consiglio sempre ai team di chiedere al proprietario del prodotto durante la prima parte "Quali sono i criteri di accettazione?" oppure "Cosa dobbiamo fare per convincerla ad accettare il lavoro?". Se queste informazioni non sono presenti nella seconda parte, quando il team deve stabilire le attività, non avrà idea di come chiudere la storia. Se il team deve fare supposizioni, in base a quanto ha ascoltato nella prima parte, corre il rischio che alla fine dello sprint il proprietario del prodotto decida che la storia non è finita. Richiedere i criteri di accettazione sin dall'inizio per ogni storia. Lo ScrumMaster deve indicare ai proprietari del prodotto di fornire questi dati.

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

Così come il team vuole i criteri di accettazione, il proprietario del prodotto richiede una descrizione aggiornata di ciò che il team intende con "la storia è completata". Questo elenco delle cose fatte dovrebbe essere pubblicato in primo piano, aggiornato e disponibile per il proprietario del prodotto in ogni momento. Un elenco di cose fatte non aggiornato rende difficile la pianificazione poiché non si ha una conoscenza comune del risultato finale. Assicurarsi che l'aggiornamento dell'elenco di cose fatte sia incluso in ogni revisione o analisi retrospettiva dello sprint.

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

Il proprietario del prodotto è benvenuto nella seconda parte della riunione ma il suo ruolo a questo punto dovrebbe essere limitato a chiarire un requisito o a risolvere un dubbio specifico. 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 avere fiducia nel team che esegue 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 ha l'autorità di 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 in cui sviluppare spirito di squadra collaborando per rispondere alla domanda "su cosa ci possiamo impegnare"? Tenere presente che, se la riunione si prolunga eccessivamente, la causa alla base del problema probabilmente ne è l'origine. Lo ScrumMaster mantiene la riunione concentrata assicurando che il proprietario del prodotto e il team eseguano la pulizia del Backlog di Prodotto. Aiuta il proprietario del prodotto a essere preparato avendo pronti i criteri di accettazione prima della riunione. Infine, aiuta a mantenere la concentrazione del proprietario del prodotto e del team sull'attività in oggetto, stabilendo su cosa possono impegnarsi per lo sprint.