Procedure consigliate per sprint e scrum

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Scrum è un framework agile che consente ai team di offrire valore in modo incrementale tramite sprint con time boxing. Questo articolo illustra le procedure consigliate per la pianificazione dello sprint, le riunioni Scrum giornaliere, le revisioni sprint, le analisi retrospettive, la valutazione dei bug e il ruolo Scrum Master in Azure DevOps.

Riunioni di pianificazione sprint

La pianificazione dello sprint prevede una negoziazione tra il proprietario del prodotto e il team per determinare l'attenzione e il lavoro per lo sprint successivo. Limita la riunione di pianificazione a un massimo di 4 ore.

Nella prima parte della riunione, il proprietario del prodotto illustra le storie utente che potrebbero essere incluse nello sprint, condivide le informazioni e risponde alle domande. Queste conversazioni possono rivelare dettagli come origini dati, layout dell'interfaccia utente, aspettative del tempo di risposta e considerazioni sulla sicurezza o sull'usabilità. Inserire questi dettagli nel modulo per l'elemento del backlog. In questa parte della riunione, il team chiarisce cosa deve costruire.

Durante la pianificazione, potresti scoprire altri requisiti da aggiungere al tuo backlog. Mantenere il backlog ben definito e in ordine di priorità. L'impostazione di un obiettivo sprint aiuta il team a rimanere concentrati sugli aspetti più importanti per ogni sprint.

Dopo aver pianificato lo sprint, è possibile condividere il piano con gli stakeholder chiave.

Per ulteriori informazioni, vedere:

• Che cos'è Scrum?
• Guida scrum

Impostare gli obiettivi dello sprint

I team scrum usano gli obiettivi sprint per concentrare le attività sprint. Spesso impostano questo obiettivo durante la riunione di pianificazione dello sprint. L'obiettivo riepiloga ciò che il team vuole raggiungere entro la fine dello sprint. Dichiarando in modo esplicito l'obiettivo, si crea una comprensione condivisa all'interno del team e si aiutano a prendere decisioni quando si verificano conflitti in base alle priorità.

Suggerimenti dalle trincee: Definire gli obiettivi dello sprint

L'obiettivo sprint definisce ciò che il proprietario del prodotto e il team considerano come obiettivo finale per raggiungere tale sprint. Non è una selezione casuale di elementi backlog non correlati, ma un'istruzione breve che acquisisce ciò che il team deve eseguire. Normalmente il proprietario del prodotto definisce l'obiettivo sprint prima di selezionare gli elementi per lo sprint successivo. Gli elementi per tale sprint devono essere tutti adatti a tale obiettivo comune.

Gli obiettivi sprint possono essere orientati alle funzionalità, ma possono avere anche un componente di processo di grandi dimensioni, ad esempio l'automazione della distribuzione o l'automazione dei test.

Per esempio:

• Questo sprint è incentrato su una semplice storia utente per dimostrare il funzionamento della soluzione proposta.
• Questo sprint implementa funzionalità di sicurezza che proteggono correttamente la sezione di amministrazione del sito Web.
• Questo sprint integra i gateway di pagamento più importanti in modo che il team possa iniziare a raccogliere i pagamenti.

L'impostazione degli obiettivi dello sprint consente al team di rimanere concentrati, semplifica la definizione delle priorità delle attività all'interno di uno sprint e limita il numero di stakeholder coinvolti.

Durante la revisione dello sprint, la domanda più importante è se si è raggiunto l'obiettivo dello sprint. Il numero di storie completate arriva secondo. Se l'obiettivo viene raggiunto, lo sprint riesce, anche se non tutte le storie vengono completate.

Suggerimenti per le riunioni di triage riuscite

La correzione di bug rappresenta un compromesso con altri lavori. Usare la riunione di valutazione per determinare l'importanza di ogni bug rispetto ad altre priorità correlate all'ambito del progetto, al budget e alla pianificazione.

• Stabilire i criteri per valutare i bug da correggere e come assegnare priorità e gravità. I bug associati a funzionalità di valore elevato (o un costo significativo di ritardo delle opportunità) o altri rischi di progetto dovrebbero ottenere priorità e gravità più elevate. Archiviare i criteri di valutazione con altri documenti del team e aggiornarli in base alle esigenze.
• Usare i criteri di valutazione per determinare quali bug correggere e come impostare il relativo stato, priorità, gravità e altri campi.
• Modificare i criteri in base alla posizione del ciclo di sviluppo. All'inizio, è possibile correggere la maggior parte dei bug che si esaminano. Più avanti nel ciclo, alzare gli standard per diminuire il numero di bug da correggere.
• Dopo aver esaminato un bug, assegnarlo a uno sviluppatore per analizzare e implementare una correzione.

Gestire il debito tecnico

Gestisci l'elenco dei bug e il debito tecnico come parte delle attività di miglioramento continuo del team. Le risorse seguenti offrono indicazioni utili:

• Buono e cattivo debito tecnico (e come TDD aiuta) di Henrik Kniberg
• Gestione del debito tecnico di Sven Johann & Eberhard Wolff

Suggerimenti delle trincee: Gestione dei bug

Agile Bug Management: Not an Oxymoron
di Gregg Boer, principal program manager, Visual Studio Cloud Services presso Microsoft

Risolvere qualsiasi debito di bug noto ogni sprint

Ogni sprint, il team esamina i bug rimanenti nel backlog dei bug e dedica la propria capacità per ridurre questo set noto a zero o vicino a zero. Se questo processo richiede un giorno, una settimana o l'intero sprint, il team corregge prima i bug. I bug trovati più avanti all'interno dello sprint non fanno parte dell'impegno iniziale. A meno che non siano prioritari, passano al backlog dei bug per lo sprint successivo.

Molti team lavorano in organizzazioni basate sull'impegno in cui la gestione valori la capacità del team di soddisfare gli impegni. La pianificazione della capacità rispetto a un set noto di bug rende la pianificazione dello sprint più deterministica e aumenta la probabilità di soddisfare gli impegni. I nuovi bug individuati durante lo sprint non fanno parte dell'impegno iniziale e possono essere risolti nello sprint successivo.

Gestire il debito tecnico in tutta l'azienda

Le organizzazioni che passano a una cultura in cui eliminano continuamente il debito spesso affrontano questa domanda: Come si ottengono i team per ridurre il numero di bug senza dirgli esattamente cosa fare? La leadership vuole che il team cambi, eppure concede al team l'autonomia di determinare come farlo. Un'opzione consiste nell'usare un cappuccio per insetti.

Si consideri, ad esempio, un limite di bug di tre bug per ogni tecnico. Un team di 10 persone non dovrebbe avere più di 30 bug nel backlog dei bug. Se il team supera il limite, interrompe il lavoro sulle nuove funzionalità fino a quando non rientra sotto il limite. La squadra dovrebbe rimanere sempre sotto il suo limite, ma decide come farlo. La soglia di bug garantisce che i team non portino il debito di bug per troppo tempo e possano imparare dagli errori che hanno causato i bug.

Il limite per i bug copre solo quelli nel backlog. I bug trovati e corretti all'interno dello sprint in cui viene sviluppata una funzionalità sono considerati lavoro incompleto, non debito tecnico.

Anche se i bug contribuiscono al debito tecnico, non rappresentano tutto il debito. Anche la progettazione di software scadente, il codice scritto male o le correzioni a breve termine contribuiscono al debito tecnico , il lavoro di sviluppo aggiuntivo che nasce da questi problemi.

Tenere traccia del lavoro per risolvere il debito tecnico come PBI, storie utente o bug. Per tenere traccia dello stato di avanzamento in caso di debito tecnico, valutare come classificare l'elemento di lavoro e i dettagli da tenere traccia. È possibile aggiungere tag a qualsiasi elemento di lavoro per raggrupparlo in una categoria di propria scelta.

Ruolo del master Scrum

Scrum Masters crea e mantiene i team sani usando i processi Scrum. Guidano, allenano, insegnano e aiutano i team scrum nell'uso appropriato dei metodi Scrum. Scrum Masters agisce anche come agenti di cambiamento per aiutare i team a superare gli ostacoli e favorire un aumento significativo della produttività.

Le responsabilità principali di Scrum Masters includono:

• Supportare il team nell'adozione e nel seguire i processi Scrum. Ad esempio, non lasciare che la riunione scrum giornaliera diventi una discussione aperta che dura 45 minuti.
• Proteggersi dal proprietario del prodotto o dai membri del team che aggiungono lavoro dopo l'inizio dello sprint.
• Cancellare i problemi di blocco che impediscono lo stato di avanzamento. Questo lavoro potrebbe richiedere il completamento di piccole attività, ad esempio l'approvazione di un ordine di acquisto per un nuovo computer di compilazione o la risoluzione di un conflitto all'interno del team.
• Aiutare il team a risolvere i conflitti e i problemi che si verificano e apprendere dal processo.
• Porre domande che rivelano problemi nascosti e verificare che le comunicazioni siano ben comprese dall'intero team.
• Identificare e risolvere potenziali problemi prima che diventino problemi principali. È più semplice e meno problematico risolvere un problema del team quando è piccolo e gestibile.
• Impedire al team di presentare storie utente incomplete durante una riunione di revisione sprint.
• Raccogliere, analizzare e presentare i dati agli stakeholder aziendali per dimostrare come il team sta migliorando. Ad esempio, se il team ha aumentato il valore che offre generando meno bug, rendete tale miglioramento visibile tramite comunicazioni regolari.

Good Scrum Masters sviluppa eccellenti capacità di comunicazione, negoziazione e risoluzione dei conflitti. Ascoltano attivamente le parole che dicono e scrivono, così come recapitano messaggi - linguaggio del corpo, espressioni facciali, ritmo vocale e altre comunicazioni nonverbali.

Riunioni quotidiane Scrum

Le riunioni scrum giornaliere aiutano a mantenere un team concentrato su ciò che deve fare successivamente. Scrum Master applica la struttura della riunione e garantisce che inizi in tempo e finisca in meno di 15 minuti.

Tre aspetti delle riunioni scrum riuscite:

• Tutti si alzano. Stare in piedi aiuta a mantenere la riunione concentrata e breve.
• La riunione inizia e termina puntualmente, alla stessa ora e nello stesso luogo ogni giorno.
• Tutti partecipano. Ogni membro del team risponde alle tre domande scrum:
  • Cosa ho realizzato dall'ultimo Scrum?
  • Cosa realizzerò prima del prossimo Scrum?
  • Quali problemi di blocco o ostacoli potrebbero influire sul lavoro?

I membri del team rispondono alle loro domande in modo rapido e conciso. Le risposte valide indicano che cosa è stato completato, cosa è pianificato in seguito e se è necessario qualsiasi aiuto o sblocco. Evitare risposte vaghe come "Ho lavorato sulla classe"; indicate quale attività specifica è stata svolta e cosa rimane da fare.

Nessuno interrompe durante le presentazioni. Salvare discussioni approfondite per dopo la riunione. Molti team usano un "parcheggio", una lavagna o un flipchart in cui gli argomenti che necessitano di completamento vengono elencati durante la riunione e affrontati in seguito.

Riunioni di revisione sprint

Organizzare riunioni di revisione dello sprint l'ultimo giorno dello sprint. Il team illustra ogni elemento del backlog di prodotto completato durante lo sprint. Il proprietario del prodotto, i clienti e gli stakeholder accettano le storie utente che soddisfano le proprie aspettative e identificano nuovi requisiti. I clienti spesso comprendono le loro esigenze in modo più completo dopo aver visto le dimostrazioni e potrebbero identificare le modifiche desiderate.

Sulla base di questa riunione, accettare alcune storie degli utenti come complete. Mantenere le storie utente incomplete nel backlog del prodotto e aggiungere nuove storie utente. Valutare entrambi i set di storie ed eseguire una stima o una ri-stima nella prossima riunione di pianificazione dello sprint.

Dopo questa riunione e la retrospettiva, il team pianifica lo sprint successivo. Poiché le esigenze aziendali cambiano rapidamente, usare questa riunione per esaminare le priorità del backlog del prodotto con il proprietario del prodotto, i clienti e gli stakeholder.

Riunioni sprint retrospettive

Le retrospettive, se eseguite bene e a intervalli regolari, supportano il miglioramento continuo.

Lo sprint retrospettivo si verifica in genere l'ultimo giorno dello sprint, dopo la riunione di revisione dello sprint. In questa riunione, il team esplora l'esecuzione di Scrum e ciò che potrebbe essere necessario modificare.

In base alle discussioni, il team potrebbe modificare uno o più processi per migliorare l'efficacia, la produttività, la qualità e la soddisfazione. Questa riunione e i miglioramenti risultanti sono fondamentali per il principio agile dell'auto-organizzazione.

Affrontare queste aree durante le analisi retrospettive dello sprint:

• Problemi che hanno interessato l'efficacia, la produttività e la qualità del team.

• Elementi che hanno influenzato la soddisfazione del team e il flusso del progetto.

• Cosa ha causato elementi del backlog incompleti? Quali azioni possono essere eseguite dal team per prevenire questi problemi in futuro?

  Si consideri, ad esempio, un team che ha diverse attività che possono eseguire una sola persona. La competenza isolata ha creato un percorso cruciale che ha minacciato il successo dello sprint. Il membro del team ha lavorato ore aggiuntive mentre gli altri membri non potevano aiutare. In futuro, il team ha deciso di praticare eXtreme Programming per risolvere questo problema nel corso del tempo.

In qualità di team, determinare se adattare uno o più processi per ridurre al minimo i problemi durante lo sprint.

Il team potrebbe anche dover lavorare per implementare un miglioramento. Ad esempio, un team interessato negativamente da troppe build non riuscite ha deciso di implementare l'integrazione continua. Configurano una build di prova prima di attivarla nell'ambiente di produzione. Per rappresentare questo lavoro, hanno creato un picco e lo hanno organizzato rispetto al resto del backlog del prodotto.

Contenuti correlati

• Fine delle attività sprint
• Che cos'è Scrum?
• Retrospettive Agile: Creazione di team efficaci