Sprint Agile significa sviluppare prodotti in un periodo di tempo prestabilito durante il quale un lavoro specifico deve essere completato e preparato per la revisione.
Qual è il processo di uno sprint Agile
Con il metodo Agile ogni sprint inizia con una riunione di pianificazione. Durante l’incontro, il product owner (la persona che richiede il lavoro) insieme al team di sviluppo concorda esattamente quale lavoro sarà realizzato durante lo sprint.
Sempre e in ogni caso:
- il team di sviluppo ha l’ultima parola quando si tratta di determinare quanto lavoro può essere realizzato realisticamente durante lo sprint
- il proprietario del prodotto ha l’ultima parola su quali criteri devono essere soddisfatti affinché il lavoro venga approvato e accettato
Il ruolo dello Scrum Master nella programmazione Agile
La durata di uno sprint è determinata dallo scrum master, ovvero il responsabile della gestione dello scambio di informazioni tra i membri del team. Per inciso, il termine deriva dal rugby, dove le squadre avversarie si stringono insieme durante una mischia per ricominciare il gioco. Nello sviluppo del prodotto, i membri del team si riuniscono ogni mattina per una riunione in cui esaminano i progressi e sostanzialmente ricominciano il progetto.
Lo Scrum è un framework di gestione del progetto che consente a un team di comunicare e auto-organizzarsi per apportare rapide modifiche, in conformità con i principi Agile.
Sprint Agile: quanto dura?
Una volta che il team raggiunge un consenso su quanti giorni dovrebbe durare uno sprint Agile, tutti gli sprint futuri dovrebbero seguire la stessa timeline. Tradizionalmente, uno sprint dura 30 giorni. Ma attenzione: sulla carta, la pianificazione dello sprint Agile sembra semplice. Nella pratica, invece, il processo è complicato, ma è necessario a un’efficace gestione di un progetto Agile.
Come attuare una pianificazione efficace dello sprint
La pianificazione dello spint Agile è un processo continuo. Richiede diligenza, organizzazione e previsioni realistiche dei tempi necessari. Per prepararsi a uno sprint, ad esempio, il leader Agile deve stabilire l’obiettivo e l’ambito dello sprint e quindi elaborare un piano per portare a termine ogni attività in tempo per l’iterazione a livello di timebox.
La sessione di pianificazione dello sprint iniziale ha un suo valore intrinseco, ma il team deve avere consapevolezza che il processo comunque non è concluso. Uno sprint Agile spesso implica un flusso continuo di:
- pianificazione e assegnazione di priorità
- ripianificazione e ridefinizione delle priorità
I team incontreranno sfide lungo il percorso, ma un piano chiaro li aiuterà a superare l’iterazione. Diamo un’occhiata al processo di pianificazione dello sprint Agile e alle migliori pratiche da seguire.
Chi dovrebbe partecipare alle riunioni di pianificazione
Gli incontri sono uno sforzo collaborativo che potrebbe tradursi in troppe voci in una sola stanza. Gli esperti sottolineano l’importanza di determinare chi invitare alla pianificazione dello sprint Agile e quanto spesso tenere le riunioni.
Il ruolo del product manager
In genere, a partecipare alle riunioni di pianificazione sono inclusi il product manager, gli sviluppatori e i professionisti o tester del quality assurance. In qualche caso possono partecipare anche il project manager, il responsabile dello sviluppo della qualità del software e lo Scrum Master.
Il project manager potrebbe partecipare per comprendere meglio lo stato del progetto, in modo da valutare il tempo necessario per completarlo secondo criteri di qualità. Spesso, il project manager ha una visione della sequenza temporale, mentre il resto del team ha una visione completamente diversa. I project manager possono mitigare i problemi di tempistica e prevenire date di rilascio a sorpresa quando partecipano alle riunioni di pianificazione dello sprint.
I responsabili dello sviluppo e del controllo
I responsabili dello sviluppo e del controllo qualità devono considerare il quadro generale ma anche conoscerne i dettagli. Le riunioni di pianificazione degli sprint Agile garantiscono la giusta prospettiva, offrendo ai manager informazioni su ciò che serve per raggiungere l’obiettivo generale. I responsabili dello sviluppo e del controllo qualità sono spesso sorpresi nello scoprire che le storie degli sprint non sono state completate o che gli sprint sono stati estesi o, ancora, che le storie sono state suddivise a scapito degli sprint più imminenti. La gestione Agile garantisce che le persone al di fuori del team di sviluppo abbiano una visione accurata del progetto e delle attività di lavoro, contribuendo a ridurre il numero di ipotesi errate generate sugli elementi in corso.
Detto questo, rimane una decisione del team scegliere chi invitare alla riunione. Molte squadre preferiscono non coinvolger alcun tipo di manager, limitandosi a invitare solo il responsabile del prodotto. In questo caso è fondamentale ricordarsi di designare qualcuno che aggiorni il resto del team di gestione.
Quando pianificare i tuoi sprint Agile
Il team deve anche decidere la frequenza con cui tenere le riunioni di pianificazione dello sprint. Tenendo conto che ogni sprint meeting si traduce in un numero equivalente di interruzioni rispetto al lavoro di sviluppo.
Ogni incontro dovrebbe avvenire prima che lo sprint Agile in essere finisca e inizi quello successivo. Di solito, le riunioni di pianificazione si verificano durante l’ultima settimana di un’iterazione in ottica di sprint Agile. Se il team necessita di più di un singolo incontro di pianificazione è necessario aggiungere un giorno libero tra i vari sprint, da usare come jolly quando si verifica la necessità di una sessione di pianificazione più esaustiva. Con questo approccio, è possibile incontrarsi rapidamente durante lo sprint Agile corrente solo quando necessario: non va mai dimenticato, infatti, che la velocità della squadra è un fondamentale della programmazione Agile. Per raggiungere risultati di successo e centrare tutti gli obiettivi è necessario mantenere le riunioni di supporto agli sprint Agile brevi, in modo da non interrompere il focus del team.
Come mantenere efficaci gli sprint Agile
In un processo di pianificazione dello sprint Agile la mancanza di lungimiranza può limitarne l’efficacia. Gli errori più comuni che si verificano durante le riunioni di pianificazione dello sprint Agile includono:
- mancata considerazione delle ferie aziendali, delle ferie della squadra e della possibile malattia;
- creazione di storie utente troppo grandi e contenenti più attività, invece di piccoli sforzi di codifica distinti;
- saltare la discussione sulla progettazione dello sviluppo (errore che si traduce in funzionalità che il team non può codificare secondo i desideri del product manager);
- non concedere tempo per i test (continuous testing);
- mancata considerazione dei difetti e tempo di ripetizione del test;
- definire un ambito troppo piccolo, quindi modificarlo a metà progetto.
A questo proposito gli osservatori suggeriscono di avvalersi di un’agenda o di uno strumento di check list per assicurarsi di smarcare tutti i punti emersi in riunione. Migliore è la preparazione del product manager e del team di sviluppo, minori saranno le interruzioni durante lo sprint.
Molti degli errori in questo elenco si riferiscono ai difetti. Anche i difetti vanno sempre contemplati e pianificati. Gli sviluppatori capaci creano progetti brillanti, ma ciò non significa che il codice abbia zero problemi. Gli sviluppatori possono anche creare inavvertitamente un bug quando lavorano insieme all’interno di una base di codice. Quando uno sviluppatore non comprende correttamente una funzione di sistema, le sue modifiche possono causare un bug in un’altra parte dell’applicazione. Anche dopo il test di unità integrato, i difetti appariranno nel flusso di lavoro dell’applicazione. È semplicemente la natura della programmazione; a meno che gli sviluppatori non comprendano il codice al 100% e i sistemi operativi back-end siano stabili al 100%, si verificheranno difetti del codice. Quindi, è importante dedicare del tempo per risolvere i difetti, ripetere il test in anticipo e fare code refactoring.
Perché le storie degli utenti sono importanti
All’inizio di uno sprint di sviluppo Agile, il product manager raccoglie gli elementi del backlog dello sprint, definisce le priorità della user story e arriva con l’obiettivo dello sprint. Quando le storie sono pronte, il team pianifica il prossimo sprint Agile. La riunione di pianificazione dello sprint Agile serve a confermare che l’intero team abbia ben compreso l’obiettivo del product manager, inserendo storie che si adattano a tale obiettivo. L’obiettivo dello sprint può aiutare a definire quali storie il gruppo può completare all’interno della pianificazione dello sprint. I team di sviluppo e QA dovrebbero quindi poter dare una stima del tempo che serve a finalizzare le user story.
Attenzione alla suddivisione delle user stories
Per mantenere sincronizzato uno sprint e un rilascio nei tempi previsti, bisogna sempre controllare l’ambito previsto. Spesso, gli sviluppatori devono suddividere storie troppo grandi perché una singola attività di sviluppo rimanga in linea con l’ambito definito. Gli sviluppatori dovrebbero organizzare le storie in set logici che creano una particolare funzionalità dell’applicazione. Ad esempio, un singolo sprint può contenere un mix di storie rudimentali che costruiscono la base di codice back-end e storie orientate alle funzionalità che migliorano l’applicazione.
Le storie, inoltre, potrebbero mancare di informazioni o dettagli necessari agli sviluppatori per la codifica e ai tester per i test. A dispetto di tutta la più grande pianificazione, bisogna anche essere sempre preparati a gestire l’imprevisto, ovvero ad avere più storie di quelle immaginate originariamente. Mantenerle in carreggiata e organizzate dall’inizio alla fine è una bella sfida.
In alcune aziende, uno Scrum Master si assicura che il team rimanga concentrato sull’obiettivo dello sprint Agile e sulle attività di lavoro pianificate. Se il team non ha questa figura sarà il responsabile dello sviluppo o il responsabile del team a poterne assumere il ruolo.
Quando la squadra dovrebbe finire il suo sprint
È importante definire esattamente come un team dovrebbe misurare il tempo per stimare l’effort relativo al lavoro di sviluppo. Ad esempio, un team potrebbe voler utilizzare gli story point invece delle ore. È bene assicurarsi che tutti i membri del team utilizzino lo stesso metodo temporale per garantire la coerenza di ogni progetto. Quando vengono utilizzate le ore, è opportuno includere del tempo libero per riunioni o altre attività lavorative meno produttive.
Come e perché stimare la lunghezza dello sprint Agile
La lunghezza di uno sprint Agile non deve essere precisa: deve essere realistica. In genere, lo sviluppo del codice richiede il doppio del tempo associato ai test di quel codice. In ogni caso, i membri del team svolgono il lavoro a velocità diverse. Un’ora impiegata da uno sviluppatore per fare qualcosa potrebbe richiedere tre ore a un altro sviluppatore. Il tempo investito dipende dall’esperienza dello sviluppatore con la base di un certo codice ma anche dalla quantità di test effettuati prima di spostare la storia in QA.
Per equalizzare il tempo di sviluppo, è possibile applicare la creazione di un’unità di test, che garantisce che il nuovo codice superi una serie di unit test integrati per ogni check-in del codice. Con questa strategia, tutti gli sviluppatori dedicano del tempo alla creazione di unit test che inviano un prodotto software di qualità superiore al QA per ulteriori test.
Come visualizzare il lavoro sulla tavola sprint
Una scheda di pianificazione Agile deve semplificare la comprensione visiva del flusso di lavoro. Lo sprint planning board, infatti, crea una visione condivisa del lavoro in corso. Al team basta dare uno sguardo alla lavagna per monitorare l’avanzamento del lavoro e vedere i compiti assegnati, aggiornando e spostando gli oggetti sulla scacchiera.
L’importante è mantenere aggiornata la scheda di sprint Agile in modo che l’intero team possa vedere come procede il lavoro e discutere degli elementi bloccati, verificando tutti gli errori. L’unico modo per superare gli ostacoli, infatti, è di eliminarli velocemente, non di ignorarli. I consigli alla squadra?
- Il product manager dovrebbe mettere sulla lavagna solo le attività assegnate per lo sprint. Non inserire tutti gli elementi del backlog del prodotto e cercare di ordinarli.
- I membri del team devono documentare e spostare le storie degli utenti in modo tempestivo come parte del loro processo di lavoro. Quando l’intero team tiene aggiornato il tabellone, tutti sanno dove si trova lo sprint corrente e se sarà necessario una ripianificazione prima del suo termine.
Lavagne e post it colorati nell’era della collaboration
Alcune squadre utilizzano una lavagna fisica con note o carte adesive che si spostano fisicamente su tutta la linea. Le schede di pianificazione degli sprint analogiche rendono i progressi facilmente visibili a chiunque abbia accesso all’ufficio. Tuttavia, queste schede analogiche non funzionano bene per l’accesso remoto. Sono anche vulnerabili: a un collega maldestro può capitare di cancellare un’attività lavorativa o mettere dei post it in un’area sbagliata sul tabellone.
Le schede di pianificazione dello sprint digitale sono più facili da aggiornare rispetto alle schede analogiche. Le bacheche digitali sono visibili ai membri del team presso la sede centrale, a casa o in qualsiasi altra parte del mondo. Sebbene la scelta del software di pianificazione Agile non sia importante quanto il modo in cui un team lo utilizza, ci sono numerosi strumenti di pianificazione dello sprint per visualizzare il lavoro, tra cui:
- ActiveCollab
- Atlassian Jira
- Software da rally
- SpiraTeam
- Trello
- VersionOne
Dopo aver selezionato una bacheca, fisica o online, impostala con le colonne su cui il team è d’accordo. Alcune opzioni di colonna comuni includono:
- Da fare: il lavoro di sviluppo tratto dagli elementi del product backlog per lo sprint corrente
- In corso: cosa stanno codificando gli sviluppatori
- QA / Test: le schede vengono spostate qui dopo lo sviluppo, per il test
- Fatto: funzionalità pronte per il rilascio.
Un team potrebbe optare per più colonne, ma gli esperti suggeriscono di cercare di semplificare il più possibile.
Con la pianificazione dello sprint Agile, anche se c’è tanto lavoro a livello di organizzazione e riorganizzazione, i team che lavorano sono decisamente più produttivi.
