Scrum e migliori pratiche

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Riunioni di pianificazione sprint

Gran parte della pianificazione sprint prevede una negoziazione tra il proprietario del prodotto e il team per determinare l'attenzione e il lavoro da affrontare nello sprint successivo. È utile impostare un limite di tempo per la riunione di pianificazione, limitandola a 4 ore o meno.

Nella prima parte della riunione, il proprietario del prodotto incontra il team per discutere le storie utente che potrebbero essere incluse nello sprint. Il proprietario del prodotto condivide le informazioni e risponde alle domande che il team ha su tali storie. Questa conversazione potrebbe rivelare dettagli quali origini dati e layout dell'interfaccia utente. Oppure potrebbe rivelare le aspettative del tempo di risposta e considerazioni per la sicurezza e l'usabilità. Il team deve acquisire questi dettagli all'interno del modulo degli elementi di backlog. Durante questa parte della riunione, la tua squadra apprende cosa deve costruire.

Durante la pianificazione degli sprint, è possibile individuare altri requisiti da acquisire e aggiungere al backlog. Assicurarsi che sia ben definito e in ordine di priorità.

Inoltre, l'impostazione di un obiettivo sprint nell'ambito delle attività di pianificazione può aiutare il team a rimanere concentrati su ciò che è più importante per ogni sprint.

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

Per altre informazioni, vedere queste risorse:

• Che cos'è Scrum?
• White paper sulla pianificazione dello sprint
• Guida scrum
• Creare e gestire il white paper sul backlog del prodotto

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 dello scopo principale. L'obiettivo dello sprint può anche aiutare a guidare il team quando sorgono conflitti relativi 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 del backlog che non hanno realmente una relazione, ma un breve frammento di testo che cattura ciò che il team dovrebbe cercare di raggiungere. Normalmente il proprietario del prodotto definisce l'obiettivo dello sprint prima di selezionare molti 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 verrà incentrato su una semplice storia utente. Verrà usato per dimostrare che la soluzione proposta funziona.
• Questo sprint si basa sull'implementazione delle funzionalità di sicurezza che proteggono correttamente la sezione di amministrazione del sito Web.
• Questo sprint riguarda l'integrazione dei gateway di pagamento più importanti in modo da poter iniziare a raccogliere denaro.

L'impostazione degli obiettivi dello sprint consente al team di rimanere concentrati. Semplifica la definizione della priorità delle attività all'interno di uno sprint e probabilmente consente di limitare il numero di stakeholder e utenti finali coinvolti.

Durante la revisione dello sprint, la domanda più importante da porsi è se si è riusciti a raggiungere 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 sono state completate.

Contributo di Jesse Houwing, Visual Studio devops Ranger e consulente senior che lavora per Avanade Paesi Bassi.

Suggerimenti per le riunioni di triage riuscite

La correzione di bug rappresenta un compromesso con altri lavori. Usa la riunione di valutazione per determinare quanto sia importante correggere ciascun bug rispetto ad altre priorità legate al rispetto dell'ambito del progetto, del budget e delle tempistiche.

• Stabilire i criteri del team per valutare i bug da correggere e come assegnare priorità e gravità. Ai bug associati a funzionalità di valore significativo (o un costo significativo di ritardo dell'opportunità) o ad altri rischi del progetto, è necessario assegnare priorità e gravità più elevate. Archiviare i criteri di valutazione con altri documenti del team e aggiornare 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.
• Modifica i criteri di triage in base alla fase del ciclo di sviluppo. All'inizio, potresti decidere di correggere la maggior parte dei bug che valuti. Tuttavia, più avanti nel ciclo, è possibile aumentare i criteri di valutazione per ridurre il numero di bug che è necessario correggere.
• Dopo aver triageato un bug, assegnarlo a uno sviluppatore. Lo sviluppatore può quindi analizzare e determinare come implementare una correzione.

Gestire il debito tecnico

Valutare la possibilità di gestire la barra dei bug e il debito tecnico come parte del set complessivo di attività di miglioramento continuo del team. È possibile trovare queste risorse di interesse:

• Buono e cattivo debito tecnico (e come TDD aiuta) di Henrik Kniberg
• Gestione del debito tecnico pubblicato da 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 tutti i bug rimanenti nel backlog dei bug e dedica risorse per ridurre il numero noto di bug a zero o quasi zero. Che si tratti di un giorno, una settimana o l'intero sprint, corregge prima i bug. I bug trovati in un secondo momento, all'interno dello sprint, non sono considerati parte di tale impegno iniziale. A meno che non siano prioritari, vengono inseriti nel backlog dei bug per lo sprint successivo.

Molti team lavorano in un'organizzazione basata sull'impegno. Spesso, la gestione pone un valore elevato sulla capacità di un team di soddisfare i propri impegni. Effettuare la pianificazione della capacità basandosi su un set noto di bug rende la pianificazione dello sprint più deterministica, aumentando la probabilità di rispettare gli impegni. Eventuali 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

Un'organizzazione che passa a una cultura in cui il debito viene continuamente eliminato probabilmente si trova ad affrontare la seguente domanda: Come si può indurre i team a ridurre il numero di bug senza dire loro esattamente cosa fare? La leadership vuole che il team cambi, ma concede al team l'autonomia di determinare come cambiare. Un'opzione consiste nell'usare un cappuccio per insetti.

Si consideri, ad esempio, un limite di bug di tre bug per ogni tecnico. Di conseguenza, un team di 10 persone non dovrebbe avere più di 30 bug nel backlog dei bug. Se il team ha superato il limite, si prevede che sospenda il lavoro sulle nuove funzioni e rientri nel limite di bug. Ci si aspetta che una squadra sia sempre sotto il limite, ma la squadra decide come farlo. Il limite di bug garantisce che i team non accumulino bug irrisolti per troppo tempo. Il team può imparare dagli errori che causano l'iniezione dei bug al primo posto.

Tenere presente che il limite di bug rappresenta i bug nel backlog di bug. Non include bug rilevati e corretti all'interno dello sprint in cui viene sviluppata una funzionalità. Questi bug sono considerati lavoro incompleto, non debito.

Anche se i bug contribuiscono al debito tecnico, potrebbero non rappresentare tutti i debiti.

La progettazione software scadente, il codice scritto in modo non corretto o le correzioni a breve termine possono contribuire al debito tecnico. Il debito tecnico riflette un lavoro di sviluppo aggiuntivo che nasce da tutti questi problemi.

Tenere traccia del lavoro per risolvere il debito tecnico come PBI, storie utente o bug. Per tenere traccia dello stato di avanzamento di un team nell'affrontare il debito tecnico, è necessario considerare 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 aiuta a creare e mantenere i team sani usando i processi Scrum. Guidano, allenano, insegnano e aiutano le squadre scrum nell'impiego appropriato dei metodi Scrum. Scrum Masters agisce anche come agenti di cambiamento per aiutare i team a superare gli ostacoli e a guidare il team verso un aumento significativo della produttività.

Le responsabilità principali di Scrum Masters includono:

• Supportare il team per adottare e seguire i processi scrum. Ad esempio, non è consigliabile lasciare che la riunione scrum giornaliera diventi una discussione aperta che dura 45 minuti.

• Proteggersi dall'inserimento di lavoro aggiuntivo da parte del proprietario del prodotto o dei membri del team dopo l'avvio dello sprint.

• Risolvere i problemi di blocco che impediscono al team di fare progressi. Questo lavoro potrebbe richiedere di completare piccole attività, ad esempio approvare un ordine di acquisto per un nuovo computer di compilazione o risolvere un conflitto all'interno del team.

• Aiutare il team a lavorare per risolvere i conflitti e i problemi che si verificano e imparare dal processo.

• Porre domande che rivelano problemi nascosti e confermare che ciò che le persone comunicano è ben compreso dall'intero team.

• Identificare e proteggere il team da potenziali problemi che stanno diventando problemi importanti. Proprio come è più economico correggere un bug poco dopo che è stato individuato, è anche 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 e crescendo. Ad esempio, se il team ha aumentato la quantità di valore che ha fornito generando meno bug, renda visibile il valore tramite comunicazioni regolari agli stakeholder aziendali.

Good Scrum Masters hanno o sviluppano eccellenti capacità di comunicazione, negoziazione e risoluzione dei conflitti. Ascoltano attivamente le parole che dicono e scrivono. Ascoltano anche come recapitano i loro messaggi, ad esempio il linguaggio del corpo, le espressioni facciali, il ritmo vocale e altre comunicazioni nonverbali.

Proprio come è più economico correggere un bug poco dopo che è stato scoperto, è anche più semplice e meno problematico risolvere un problema del team quando è piccolo e gestibile prima di crescere in un problema importante.

Riunioni quotidiane Scrum

Le riunioni scrum giornaliere aiutano a mantenere un team concentrato su ciò che deve fare il giorno successivo. Rimanere concentrati aiuta il team a massimizzare la capacità di soddisfare gli impegni sprint. Il master Scrum deve applicare la struttura della riunione e assicurarsi che inizi in tempo e finisca in meno di 15 minuti.

Tre aspetti delle riunioni Scrum riuscite sono:

• Tutti si alzano. Alzarsi aiuta a mantenere le riunioni incentrate e brevi.
• Iniziano e terminano all'ora e si verificano contemporaneamente nello stesso luogo ogni giorno
• Tutti partecipano, ogni membro del team risponde alle tre domande scrum:
  • Cosa ho realizzato dall'ultimo Scrum?
  • Cosa posso realizzare prima del prossimo scrum?
  • Quali problemi di blocco o ostacoli potrebbero influire sul lavoro?

I membri del team devono cercare di rispondere alle loro domande in modo rapido e conciso. Per esempio:

"Ieri, ho aggiornato la classe per riflettere il nuovo elemento dati che abbiamo estratto dal database e ho ottenuto che venga visualizzato nell'interfaccia. Questa attività è stata completata. Oggi, mi assicuro che il nuovo elemento di dati venga calcolato correttamente tramite la stored procedure e gli altri elementi di dati nella tabella. Credo di poter svolgere questo compito oggi. Ho bisogno di qualcuno per rivedere i miei calcoli. Non ho ostacoli o problemi di blocco."

Questa risposta indica il risultato ottenuto dal membro del team, i piani che il membro del team deve eseguire e che il membro del team vuole che alcuni aiutino a esaminare il codice.

Contrasto con questo esempio successivo:

"Ieri, ho lavorato alla classe, e funziona. Oggi lavoro sull'interfaccia. Nessun problema di blocco."

Il membro del team non fornisce dettagli sufficienti sulla classe su cui ha lavorato né sui componenti dell'interfaccia che completeranno. Infatti, la parola menzionata non è mai stata discussa.

È importante che nessuno interrompa durante i report out. Ogni persona deve avere tempo sufficiente per rispondere alle tre domande.

Le discussioni più approfondite e di follow-up dovrebbero avvenire dopo la riunione, in quanto le persone tornano ai loro banchi o, se è necessaria una notevole quantità di conversazione, in una riunione di completamento.

Molti team ritardano le discussioni usando il metodo "parcheggio virtuale". Quando emergono argomenti che un membro del team ritiene necessitino di ulteriori discussioni, possono tranquillamente avvicinarsi a una lavagna o lavagna a fogli mobili ed elencare il soggetto nella lista di attesa. Al termine della riunione, il team determina come gestirà gli elementi elencati.

Riunioni di revisione sprint

Condurre le riunioni di revisione dello sprint nell'ultimo giorno dello sprint. Il team dimostra ogni elemento di backlog del prodotto completato nello sprint. Il proprietario del prodotto, i clienti e gli stakeholder accettano le storie utente che soddisfano le proprie aspettative e identificano eventuali nuovi requisiti. I clienti spesso comprendono le loro esigenze in modo più completo dopo aver visto le dimostrazioni e possono identificare le modifiche che vogliono vedere.

In base a questa riunione, alcune storie utente vengono accettate come complete. Le storie utente incomplete rimangono nel backlog del prodotto. Le nuove storie degli utenti vengono aggiunte al backlog. Entrambi i set di storie vengono classificati e stimati o rivalutati nella prossima riunione di pianificazione dello sprint.

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

Riunioni sprint retrospettive

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

La riunione retrospettiva dello sprint 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 la propria efficacia, produttività, qualità e soddisfazione. Questa riunione e i miglioramenti risultanti sono fondamentali per il principio agile dell'auto-organizzazione.

Affrontare questi aspetti durante l'analisi retrospettiva dello sprint di squadra.

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

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

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

  Si consideri, ad esempio, un team che ha avuto diverse attività che possono essere eseguite da un solo utente del team. La competenza isolata ha creato un percorso cruciale che ha minacciato il successo dello sprint. Un membro del team ha lavorato più ore mentre gli altri erano frustrati di non poter fare di più per aiutare. In futuro, il team ha deciso di praticare eXtreme Programming per risolvere questo problema nel corso del tempo.

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

Il team potrebbe dover eseguire alcune operazioni per implementare un miglioramento. Ad esempio, un team che si è trovato interessato negativamente da troppe build non riuscite ha deciso di implementare l'integrazione continua. Poiché non volevano interrompere il processo, ci sono volute alcune ore per configurare una build di prova prima di attivarla nella compilazione di produzione. Per rappresentare questo lavoro, hanno creato uno spike e lo hanno organizzato rispetto al resto del backlog del prodotto.

Articoli correlati

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