Le sessioni di grooming del backlog contribuire a rafforzare un team di sviluppo perché spingono i suoi membri a comunicare e condividere i loro modi di progettare, codificare e testare un’applicazione
Il meeting dedicato al T è il momento in cui un team cerca di comprendere a fondo i requisiti di business richiesti e scopre quindi come progettare un prodotto consegnabile che funzioni come previsto e che lo faccia all’interno dell’architettura del codice esistente. Questo incontro è anche l’occasione per i professionisti/tester del QA di ricevere le informazioni di base sul design e i risultati attesi dagli altri membri del progetto.
Ci sono alcuni elementi particolarmente importanti del processo di grooming del backlog e si possono ricavare anche alcune indicazioni utili su come migliorare la produttività di un team e la qualità del software che produce.
Quando le sessioni di grooming diventano efficaci
In una sessione di backlog grooming, l’obiettivo principale del team lì riunito è quello di raggiungere una comprensione condivisa di una o più user story. In base a quella, potrà discutere i potenziali design prima che gli sviluppatori scrivano qualsiasi linea di codice. Dopo la riunione, è importante che restino ancora canali di comunicazione aperti tra i vari membri del team per mantenere alta la produttività e chiarire le modifiche man mano che si presentano.
Pensate alle riunioni di backlog grooming come all’effettuare un pagamento anticipato di qualcosa invece di pagare dopo. Per esempio, se un team arriva ad una comprensione condivisa prima che inizi la codifica, limita la possibilità di domande e interruzioni di design e funzione dopo che la codifica è iniziata. Per rendere la revisione efficace, però, i membri del team devono partecipare attivamente alla discussione, fare domande e discutere della validità di diverse idee o proposte.
Il numero di user story che un team presenta è un elemento importante: i team non vogliono incontrarsi troppo frequentemente per valutare queste storie ma è importante anche mantenere le sessioni di backlog grooming della massima lunghezza di un’ora trattando un numero di storie sufficiente per tenere occupato il team per un paio di sessioni.
Come fare il backlog grooming
Quando durante una sessione di grooming un team fa valutazioni di punteggio molto diverse per una stessa user story, è chiaro che manca allineamento. Per esempio, se lo sviluppatore A assegna alla storia tre punti, lo sviluppatore B otto punti, lo sviluppatore C cinque punti e il QA ne dà 13, è ovviamente necessario un chiarimento. Non è detto che tutti debbano essere esattamente d’accordo sul punteggio, ma il team dovrebbe essere sulla stessa lunghezza d’onda del bisogno del business e della funzionalità prevista.
Nel backlog grooming, trattate la user story come un business case con criteri di accettazione e null’altro per discutere i dettagli durante il grooming e comprendere il modo in cui una certa feature funzionerà. Facendo questo durante il backlog grooming, si può scoprire se il team ha una comprensione condivisa del risultato o se ci sono requisiti mancanti -o storie mancanti – necessari per creare la feature. È meglio scoprire presto se c’è bisogno di ulteriori storie di supporto, task o ricerche prima che il team di sviluppo possa implementarla con successo.
“Focalizzarsi sulla chiarezza in una sessione di backlog grooming – ha detto Timothy Hatcher, ingegnere software senior alla Apple – Se il team non capisce la richiesta allora gli sviluppatori non codificheranno il software correttamente”. Secondo Hatcher, può essere meglio suddividere le storie molto complesse – con caratteristiche integrate o requisiti di back-end – in storie più piccole dove il team può discutere e rivedere il design e i punti di integrazione per capire l’approccio ottimale.
Le user story integrate che sono altamente complesse possono gettare il team nello sconforto o fuori strada. Hatcher ha aggiunto che è meglio approfondire le user stories per assicurarsi che il piano di attacco sia chiaro a tutti i membri del team, altrimenti può accadere che una storia non sia trattata correttamente e porti a del lavoro aggiuntivo per il team.
L’importanza del backlog grooming
Un altro vantaggio del backlog grooming è conoscere lo scopo del lavoro del team: meno sorprese ci sono, più è probabile che il team produca codice di qualità. Meglio il team di sviluppo comunica, discute e approda a decisioni condivise, più forte diventerà il team.
Un team forte produce di più lavoro e garantisce un maggiore livello di qualità. Le sessioni di backlog grooming contribuiscono in modo significativo a costruire quella necessaria complicità nella squadra.
Si è tentati di saltare il backlog grooming e procedere direttamente alla pianificazione dello sprint, alla codifica e poi al test ma il rischio, così facendo, è di perdere tempo prezioso andando avanti e indietro per sentire i vari membri del team. Gli sviluppatori, ad esempio, non avranno le informazioni di cui hanno bisogno per codificare, e il QA non avrà i dettagli funzionali di cui ha bisogno per provare che i criteri di accettazione sono soddisfatti.
In questa situazione confusa, i team andranno avanti con la loro visione della user story o chiederanno costantemente chiarimenti al team di prodotto ma, in definitiva, è meglio discutere le storie utente insieme piuttosto che in conversazioni frammentarie. E’più efficiente per un team prendersi il tempo di parlare attraverso una sessione di backlog grooming piuttosto che “girare in tondo” cercando di essere allineati.
