Yesterday’s Weather: promuovi uno sviluppo sostenibile

Yesterday’s Weather è una pratica di Extreme Programming. È utilizzata per calcolare la capacità (capacity in inglese) di un team, con il fine di pianificare un’iterazione. Yesterday’s Weather si traduce in italiano con: “Il tempo di ieri”. Per tempo si intende tempo metereologico.

Come tutte le pratiche di Extreme Programming, Yesterday’s Weather si presta benissimo a essere integrato in Scrum e altre metodologie agili.

In un articolo precedente abbiamo già visto il concetto di velocity e come la media ricavata da almeno 4 o 5 Sprint sia considerata un’indicazione attendibile per fare previsioni a lungo termine. Ma la media aritmetica non è l’unico metodo che possiamo utilizzare in fase di pianificazione.

Perché si usa il tempo di ieri?

Yesterday’s Weather è un’ottima tecnica per cercare di ottenere una pianificazione realistica e per evitare che il team prenda in carico troppo lavoro, rischiando di lavorare extra per poter raggiungere lo Sprint Goal. 

D’altra parte, uno dei 12 principi fondamentali del manifesto per lo sviluppo agile di software è il seguente:

I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante 

La tecnica Yesterday’s Weather si basa sul principio che sostiene che farai tanto oggi, quanto hai fatto ieri. Questo principio è stato elaborato da Kent Beck e Martin Fowler nel libro: Planning Extreme Programming (in inglese).

Martin Fowler ricorda la storia, probabilmente letta ai tempi della scuola, di un Paese che decide di sviluppare un sofisticato sistema informatico per prevedere il tempo. Dopo aver fatto sforzi economici impensabili, viene annunciato con orgoglio che il sistema funziona a meraviglia ed è preciso al 70%. In seguito, qualcuno capì che in quello stesso Paese, se prevedi che il tempo di oggi sarà lo stesso di quello di ieri, hai il 69,5% di possibilità di essere accurato.

Il punto è che, nonostante Yesterday’s Weather sia un sistema di previsione rudimentale e indubbiamente non “a prova di bomba”, finisce per essere tanto accurato quanto metodi più sofisticati e complessi.

Adesso che abbiamo introdotto il concetto, vediamo finalmente un po’ di pratica.

Come si calcola lo Yesterday’s Weather

Il metodo è semplice. Si contano quanti Story Point (SP) il team è riuscito a completare al termine dello Sprint precedente e si utilizza il numero come indicazione per la pianificazione dello Sprint successivo.

Per esempio, se nell’iterazione precedente abbiamo completato 15 SP deduciamo che, al netto di assenze o cambiamenti all’interno del team, abbiamo una probabilità molto alta che lo Sprint successivo si concluda con lo stesso conteggio. 

È considerata una buona pratica utilizzare il numero ricavato con Yesterday’s Weather come il limite massimo di Story Point da impegnare in pianificazione (commitment), al fine di raggiungere lo Sprint Goal.

Aggiustamenti al calcolo dello Yesterday’s Weather

Aggiungere sviluppatori al team non richiede aggiustamenti in fase di previsione. Se invece hai un team di 5 sviluppatori e uno è assente per il prossimo Sprint, riduci la tua prossima iterazione del 20% (semplicemente perché se 5 sviluppatori sono il 100%, 4 sono l’80%).

Perché aggiungere sviluppatori non richiede aggiustamenti? Cosa succede se il team, indipendentemente dal fatto che siano stati aggiunti sviluppatori o meno, termina il lavoro nel mezzo dello Sprint, con anticipo rispetto a quanto pianificato con lo Yesterday’s Weather?

In questo caso c’è un accordo con il Product Owner (perché succede che le priorità cambino) per prendere in carico la prossima user story con priorità più alta dal Product Backlog. Se completata, quest’ultima user story andrà ad aumentare la velocity e cambierà lo Yesterday’s Weather di domani.

E in caso di team particolarmente ambiziosi, che puntano a migliorare continuamente le proprie performance? Yesterday’s Weather è uno strumento da utilizzare per proteggere il team da una pianificazione eccessiva. Nonostante ciò, nulla vieta di aggiungere qualche punto in più al conteggio degli Story Point da pianificare. A patto che sia realistico e non vada a influenzare negativamente lo Sprint Goal, producendo carichi di lavoro eccessivi (over commitment).

Yesterday's Weather

Yesterday’s Weather vs Velocity media

Yesterday’s Weather si utilizza prevalentemente per previsioni a breve termine, per esempio il prossimo Sprint. È un metodo estremamente intuitivo ed è perfetto quando la dimensione del team e il contesto rimangono costanti. In caso di cambiamenti, per esempio in caso di assenze di uno o più sviluppatori, è una tecnica che richiede aggiustamenti. Abbiamo visto un esempio nel paragrafo precedente.

E questi aggiustamenti devono essere fatti solo per grandi deviazioni. Ad esempio, una riunione aziendale di 2 ore o mezza giornata di permesso non dovrebbero essere computate. L’assenza di uno sviluppatore per uno Sprint, invece sì.

Ma in caso di aggiustamenti, a mio modesto parere, ha meno senso parlare del tempo di ieri.

Un metodo di previsione in teoria meno soggetto a fluttuazioni è la velocity media degli ultimi 4 o 5 Sprint. Per ulteriori informazioni ti rimando all’articolo dedicato alla velocity, in particolare a questo paragrafo.

Si scelgono convenzionalmente 4 o 5 Sprint come base di riferimento, in quanto sono considerati un periodo di tempo sufficientemente ampio per consentire al team di stabilire un proprio ritmo.

La media aritmetica è il metodo più indicato per fare previsioni a lungo termine.

Valgono solo gli Story Point?

Finora abbiamo visto come gli Story Point, e di conseguenza la velocity, siano la base del calcolo dello Yesterday’s Weather. Tuttavia alcuni team utilizzano la tecnica del Story Counting (il conteggio delle user story) per stimare e pianificare. Invece di contare gli Story Point, si conta il numero di user story completate al termine dell’iterazione.

Questa logica di conteggio delle user story deriva dall’esperienza e dalla pratica. Nel corso del progetto, molti team scoprono che le loro stime in Story Point non sono più accurate di quanto non lo sia il semplice conteggio delle user story presenti in ogni iterazione. In pratica, al termine di ogni Sprint, rilasciano sempre più o meno lo stesso numero di story.

Certo, ogni user story ha dimensioni diverse, ma nel corso del tempo le story più piccole e quelle più grosse si annullano a vicenda.

Con il conteggio delle story, il concetto di velocity rimane invariato, con l’unica differenza che la velocity è solo la somma del numero di story piuttosto che una somma di Story Point. In questo contesto, anche il concetto di Yesterday’s Weather è applicabile.

Cosa fare quando non si conosce la velocity

Quando si devono fare previsioni e non si conosce la velocity, come nel caso di un team appena formato, un buon metodo è suddividere in task. Ho spiegato come fare in questo paragrafo.

Lo Yesterday’s Weather, in questo caso, verrà utilizzato a partire dalla seconda iterazione.

Considerazioni finali

Yesterday’s Weather è una tecnica veloce che non richiede calcoli matematici. È un’ottimo metodo in caso di contesti stabili e per pianificare il prossimo Sprint. Un’alternativa efficace è il calcolo della media aritmetica della velocity degli ultimi 4 o 5 Sprint, periodo necessario a un team di sviluppo per trovare la propria stabilità. Questa tecnica si presta molto bene per previsioni più a lungo termine.

In ogni caso, indipendentemente dal metodo che scegli di seguire, è importante che rimanga uno strumento in mano al team per capire i loro punti di forza, i progressi e dove migliorare. Ogni altro utilizzo (o abuso) da parte di persone esterne al team con finalità di controllo o altri intenti equivoci, è considerata una pratica errata. 

È FINALMENTE DISPONIBILE IL VIDEOCORSO DI AGILE WAY!

videocorso agile way su scrum e sulle metodologie agili

CORSO APPROFONDITO SU SCRUM E SULLE METODOLOGIE AGILI

3,5 ore di video lezioni su Scrum, ideale per prepararsi a un esame di certificazione PSM-I e per comprendere i valori, i principi e le pratiche dei metodi Agili. In questo corso imparerai:

  • Origine, nascita e significato delle metodologie Agili
  • Differenze tra Scrum e i modelli tradizionali
  • Tutte le componenti del framework Scrum, i valori, le pratiche e le metriche
  • Come gestire al meglio un progetto e un prodotto con Scrum
  • Come mantenere un’attenzione continua al valore generato e al cliente
  • Simulatore di esame di certificazione (80 domande)
  • Tanto altro…

* Prezzo del corso €109,99 – iscriviti adesso e risparmia l’82%. Offerta limitata nel tempo.

Subscribe
Notificami
guest
0 Commenti
Inline Feedbacks
View all comments