Revisioni degli sprint Agile

Le revisioni degli sprint non sono retrospettive. Una revisione dello sprint ha lo scopo di dimostrare il duro lavoro dell'intero team di progettisti, sviluppatori e owner di prodotto. Qui in Atlassian, ci piace mantenere le nostre revisioni degli sprint informali: i membri del team si riuniscono intorno a una scrivania per demo informali e parlano del lavoro svolto per quella iterazione specifica. È un momento per fare domande, provare nuove funzioni e fornire feedback. La condivisione del successo gioca un ruolo fondamentale nella creazione di un team Agile.

Per prima cosa, vediamo insieme perché la definizione del team del concetto di "completato" è così importante per questa cerimonia Agile.

Come utente abituale di Jira, non esiste niente di più soddisfacente per me che spostare un task da "Revisione del codice" a "Completato". Lo spostamento di una scheda Agile rappresenta il completamento di un lavoro che ci eravamo prefissati di eseguire come team.

Per raggiungere l'obiettivo e completare il lavoro, sono necessarie una buona pianificazione, una definizione chiara del concetto di "completato" e un'esecuzione mirata. Tutto ciò avviene principalmente durante la pianificazione dello sprint ma, per fare in modo che una revisione dello sprint e uno sprint abbiano successo, i team non possono limitarsi a pianificare: devono sviluppare una cultura chiara su come consegnare un lavoro e su cosa significhi il concetto di "completato".

I team efficaci portano processi chiari e una cultura dello sviluppo in ogni singolo elemento di lavoro. Usa queste domande per valutare il tuo processo e assicurarti che funzioni in modo ottimale per il tuo team:

• Le story vengono definite in modo chiaro dall'owner di prodotto, dal progettista e dal team di progettazione prima dell'implementazione?

• Tutti comprendono e vivono la cultura e i valori di progettazione del team?

• Sono stati stabiliti definizioni e requisiti chiari in merito alla revisione del codice, ai test automatizzati e alla continuous integration per incoraggiare uno sviluppo Agile sostenibile?

• Dopo che il team ha completato una story, emergono molti bug? In altre parole, "completato" significa veramente "completato"?

La cultura del team in materia di qualità e completamento dovrebbe superare ogni storia utente, elemento di lavoro della progettazione e bug. Questa cultura riflette il modo in cui il team si approccia al software e lo fornisce.

Una definizione chiara del concetto di "completato" aiuta i team a concentrarsi sull'obiettivo finale di ogni elemento di lavoro. Quando l'owner di prodotto aggiunge lavoro al backlog del team, la definizione dei criteri di accettazione rappresenta una parte fondamentale del suo processo. Cosa significa che una storia utente è stata "completata"? Qui in Atlassian, il team Jira monitora i criteri di accettazione e le note sui test perfettamente in linea con il resto della storia utente all'interno di Jira. In questo modo, l'intero team ha una visione chiara del successo su ogni ticket. Ma cosa sono i criteri di accettazione e le note sui test?

• Criteri di accettazione: metriche utilizzate dall'owner di prodotto per confermare che la story è stata implementata in modo soddisfacente.

• Note sui test: una guida breve e mirata del team di assistenza per la qualità che consente all'ingegnere di sviluppo di scrivere codice di funzione e test automatizzati migliori.

Se i ticket sono ben definiti durante l'implementazione, tutti avranno successo. Con Jira, aggiungere campi in fila è semplicissimo. Se hai il ruolo di amministratore, clicca sul pulsante "amministratore" sul ticket.

Qui in Atlassian, uno dei nostri valori fondamentali è "Fai squadra". Le revisioni degli sprint sono un ottimo momento per celebrare il team e i successi di ciascun membro durante un'iterazione. Solitamente li organizziamo il venerdì pomeriggio, quando tutti in ufficio iniziano a rilassarsi in vista del fine settimana. Le revisioni degli sprint non sono retrospettive, quindi assicurati di organizzare la revisione dopo un'iterazione, ma prima della tua retrospettiva. I partecipanti esterni sono sempre i benvenuti, ma generalmente partecipano alla riunione l'owner di prodotto, il team di sviluppo al completo e lo Scrum Master. Come best practice, ti consigliamo di dedicare da 30 minuti a un'ora per ciascuna iterazione nella riunione.

Ciò che più ci piace delle revisioni degli sprint è che tutelano la salute e il morale del team. Infatti, hanno a che fare con il team building. La revisione non è un contraddittorio, né tantomeno un esame: è un evento collaborativo in cui i membri del team illustrano il proprio lavoro, fanno domande e ricevono feedback.

Se una revisione dello sprint non diventa un'attività positiva per il team, il motivo potrebbe essere uno dei seguenti:

• Il team si sovraccarica di lavoro e non riesce a completarlo durante un'iterazione

• Il team lotta contro un debito tecnico esistente

• Le funzioni non sono sviluppate in modo sostenibile per garantire che non vengano introdotti nuovi bug nel codice

• Le pratiche di sviluppo del team potrebbero essere ottimizzate di più

• L'owner di prodotto sta modificando le priorità all'interno di un'iterazione e il team di sviluppo viene emarginato dallo scope creep

Nota: tutti i team sperimentano a volte un'iterazione difficile. Prenditi del tempo per capire per quale motivo un'iterazione cambia nella retrospettiva del team e creare un piano per gestire i ticket nello sprint successivo.

Le aziende con team distribuiti devono affrontare sfide speciali connesse alla scalabilità delle cerimonie Agile in diverse aree geografiche. Le revisioni degli sprint non fanno eccezione. Il team Jira è composto da membri che risiedono in tutto il mondo: Sydney, Danzica, Saigon e San Francisco. Pur trattandosi di un team distribuito, le revisioni degli sprint rappresentano una parte molto importante della cultura del nostro team. I membri del team creano video informali e li condividono su una pagina Confluence affinché l'intero team possa vederli.

Grazie a questi video informali, tutti sono sempre aggiornati sui progressi dello sviluppo nonostante le differenze di fuso orario. Poter vedere una demo delle funzioni creata direttamente dallo sviluppatore rafforza il team in due modi:

• Comprensione del prodotto: l'intero team apprende l'intenzione, la logica e l'implementazione della funzione. Questo contribuisce ad ampliare la conoscenza da parte di tutti dell'intero prodotto.

• Team building: i video creano connessioni più personali all'interno del team. Ciascuno di noi può vedere chi c'è dietro ogni aspetto di un prodotto. I ponti creati da questa pratica ci rendono un gruppo più solido e coeso indipendentemente dall'area geografica di ciascun membro.

Spesso i team che non hanno familiarità con le revisioni degli sprint cedono alla tentazione di inglobare la revisione dello sprint nella retrospettiva. Una revisione dello sprint è una cerimonia indipendente da una retrospettiva sprint. Prenditi del tempo per goderti il frutto del tuo lavoro e festeggia liberamente i traguardi raggiunti. Una revisione dello sprint efficace rafforza il morale e la motivazione del team. Per noi del team Jira questa idea di celebrazione è così importante che abbiamo deciso di incorporare il valore "Fai pure, festeggia" nella nostra vision aziendale.