Condividi tramite

Procedure consigliate e scrum

  • Articolo

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 pianificare la riunione, 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, il team apprende cosa deve creare.

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:

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 il team a guidare il team 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 che non hanno realmente una relazione, ma un breve frammento di testo che acquisisce ciò che il team deve provare a eseguire. Normalmente il proprietario del prodotto si presenta con l'obiettivo 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.

Ad 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 valutazione riuscite

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

  • 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.
  • Modificare i criteri di valutazione in base alla posizione del ciclo di sviluppo. In anticipo, è possibile decidere di correggere la maggior parte dei bug che si valutano. 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:

Suggerimenti dalle trincee: Gestione dei bug

Agile Bug Management: Not an Oxymoron
di Gregg Odbc, Principal Program Manager, Visual Studio Servizi cloud 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 la capacità per ottenere il set noto di bug fino 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. La pianificazione della capacità rispetto a un set noto di bug rende la pianificazione sprint più deterministica, aumentando la possibilità di soddisfare 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 bug in un'azienda

Un'organizzazione che passa a una cultura in cui il debito viene continuamente eliminato probabilmente si occupa della domanda seguente: Come si ottengono i team per ridurre il numero di bug senza dirle esattamente cosa fare? La leadership vuole che il team cambi, ma offra all'autonomia del team di determinare come cambiano. Un'opzione consiste nell'usare un limite di bug.

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, è previsto che interrompa il lavoro sulle nuove funzionalità e si sottometta al limite di bug. Ci si aspetta che un team sia sempre sotto il limite, ma il team decide come vuole farlo. Il limite di bug garantisce che i team non portino un debito di bug troppo lungo. 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 non annullato, 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 dal proprietario del prodotto o dai membri del team dall'aggiunta di lavoro dopo l'inizio dello sprint.

  • Cancellare i problemi di blocco che impediscono al team di inoltrare lo stato di avanzamento. 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 recapitato durante la generazione di meno bug, rendere 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 giornaliere 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 dopo l'ultima scrum?
    • Cosa posso realizzare prima del prossimo scrum?
    • Quali problemi di blocco o ostacoli potrebbero influire sul lavoro?

Nota

L'attenzione per le riunioni scrum è sullo stato del lavoro che deve essere passato da un membro del team a un altro membro del team.

I membri del team devono cercare di rispondere alle loro domande in modo rapido e conciso. Ad 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, si garantisce che il nuovo elemento dati stia calcolando correttamente con la stored procedure e gli altri elementi 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 realizzata non è mai venuto in piedi.

È 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 i soggetti arrivano che un membro del team pensa che ha bisogno di ulteriore discussione, possono tranquillamente camminare a una lavagna o flipchart e elencare l'oggetto nel parcheggio. 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 utente 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 retrospettive sprint

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.

Nota

Per supportare la retrospettiva del team, è consigliabile installare l'estensione Analisi retrospettive del Marketplace. Questa estensione supporta la raccolta di commenti e suggerimenti sulle attività cardine del progetto, l'organizzazione e la definizione delle priorità del feedback e la creazione e il rilevamento di attività eseguibili per aiutare il team a migliorare nel tempo.

Esaminare queste aree durante le analisi retrospettive dello sprint del team:

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

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

  • Cosa è successo a causa di 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. L'esperienza isolata ha creato un percorso critico che ha minacciato il successo dello sprint. Il singolo membro del team ha messo in più ore mentre altri membri del team erano frustrati che non potevano fare di più per aiutare. In futuro, il team ha deciso di praticare la programmazione eXtreme per risolvere questo problema nel 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 un picco e organizzato che funzionano con il resto del backlog del prodotto.