Risoluzione dei problemi PDF
Document Details
Uploaded by CostEffectiveThorium1709
University of Milan
Tags
Summary
Questo documento descrive la risoluzione dei problemi nelle riunioni Scrum. Si concentra su come migliorare le riunioni, focalizzandosi sull'importanza della comunicazione tra pari e sull'efficacia delle domande chiave. Contiene consigli pratici per i facilitatori e la checklist per avviare e gestire le riunioni Scrum.
Full Transcript
**Risoluzione dei problemi** Se, tuttavia, le vostre riunioni Scrum non stanno andando come speravate, è probabile che sia dovuto a uno dei pochi problemi comuni. Li descriviamo qui brevemente e con alcune potenziali soluzioni. **Concentratevi sullo Scrum Master:** gli organizzatori di efficaci...
**Risoluzione dei problemi** Se, tuttavia, le vostre riunioni Scrum non stanno andando come speravate, è probabile che sia dovuto a uno dei pochi problemi comuni. Li descriviamo qui brevemente e con alcune potenziali soluzioni. **Concentratevi sullo Scrum Master:** gli organizzatori di efficaci Scrum giornalieri sottolineano l\'importanza della comunicazione tra pari. Una comune insidia, soprattutto per i nuovi Scrum, è che le persone hanno la tendenza a rivolgersi allo Scrum Master quando parlano. Per aiutare a reindirizzare l\'attenzione sui compagni di squadra e sugli impegni presi con loro, il tuo Scrum Master può intenzionalmente interrompere il contatto visivo con l\'oratore. Un\'altra tecnica è quella di far stare lo Scrum Master fuori dal cerchio. **Le riunioni divagano:** il problema può essere la socializzazione, un oratore che entra troppo nei dettagli su un problema o la conversazione che si impantana su argomenti più adatti per una barra laterale. Alcuni team dicono una frase come \"toglilo offline\" come promemoria. Oppure potete provare ***la regola delle due mani***. Se qualcuno pensa che la riunione sia andata fuori tema, alza la mano. Quando una seconda persona alza la mano, la conversazione si interrompe e lo stand-up torna al suo flusso normale. **Non concentrarsi sulle domande**: le riunioni Scrum perdono la loro efficacia se non ruotano attorno alle tre domande di cui abbiamo discusso sopra. Può essere allettante per uno Scrum Master aprire una riunione parlando di un nuovo requisito o di un cambiamento di progetto appena emerso. Ciò porta inevitabilmente a una discussione su come gestire la nuova esigenza e le domande vengono trascurate. Allo stesso modo, se lo Scrum Master microgestisce o \"gestisce\" la conversazione a spese della comunicazione tra pari, l\'atmosfera collaborativa si perde e le riunioni perdono efficacia. Mantenete le riunioni Scrum focalizzate al massimo sul progresso del team verso gli obiettivi del progetto attenendoti alle domande. Le persone arrivano in ritardo, impreparate o non disposte a parlare molto: rallentano gli Scrum giornalieri e uccidono l\'energia. Le misure punitive dovrebbero essere evitate poiché minano lo spirito Scrum. Una soluzione migliore è scuotere la situazione cambiando il modo in cui fai ruotare gli oratori o come formuli le tue domande: (invece di: "cosa hai FATTO ieri", potresti chiedere "cosa hai OTTENUTO" o "su cosa ti sei IMPEGNATO"). Se il problema è più profondo, come una mancanza di fiducia o coesione nel team, scarsa comunicazione, duplicazione degli sforzi, microgestione da parte dello Scrum Master o ostacoli non risolti, potresti prendere in considerazione di mettere in pausa le tue riunioni Scrum per alcuni giorni e affrontare i problemi di fondo. Ciò contribuirà a evitare di peggiorare la situazione creando la percezione che lo Scrum giornaliero non sia un uso efficace del tempo. Con il supporto del management, un po\' di lavoro preparatorio per preparare il Team al cambiamento e un po\' di pianificazione, puoi ottenere uno Scrum efficace in breve tempo. In poco tempo, raccoglierete i frutti aiutando i team a concentrarsi sui processi che forniscono il massimo valore all\'azienda, chiarendo il flusso di lavoro, collaborando meglio e rendendo visibili progressi e problemi. In breve, lo Scrum giornaliero fatto nel modo giusto rafforzerà la vostra capacità di innovare! \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ **Checklist per avviare e far funzionare rapidamente il vostro Scrum Meeting** 1. Getta le basi a. Ottieni supporto dalla direzione b. Identifica il lavoro adatto a uno sprint 2. Forma il team c. Identifica chi farà parte dello Scrum d. Limita i numeri, meno di 10 persone e. Assegna i ruoli di Scrum master e product owner 3. Stabilisci la logistica f. Scegli un luogo vicino all\'area di lavoro in cui si terrà sempre la riunione g. Stabilisci un orario di inizio dello Scrum h. Se hai partecipanti remoti, stabilisci una videoconferenza/telefono i. Imposta una bacheca per visualizzare lo stato del lavoro e disponi di un timer j. Pensa di iniziare e terminare con segnali rituali come la musica k. Scegli un metodo per far ruotare l\'oratore 4. Orienta il team l. Organizza una riunione pre-lancio con il team m. Spiega lo scopo di Scrum n. Delinea le regole di base su come verrà gestito lo stand-up giornaliero o. Esamina le tre domande giornaliere p. Discuti del progetto che intraprenderai q. Fornisci esempi di quali conversazioni dovrebbero essere salvate per la barra laterale 5. Risolvi i problemi se necessario r. Valutare dopo alcuni giorni come sta andando s. Assicurarsi che la comunicazione sia peer-to-peer t. Controllare che le tre domande ricevano risposta da ogni partecipante u. Valutare se lo Scrum rimane in carreggiata e nei limiti di tempo v. Se uno di questi non funziona, implementare delle correzioni \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ **Strumenti di Scrum** Oltre a Ruoli ed Eventi, i progetti Scrum includono anche determinati Strumenti. Ad esempio, il team utilizza una Scrum board per visualizzare il backlog o un grafico burndown per mostrare il lavoro in sospeso. Gli artefatti e i metodi più comuni sono: **Scrum Board:** puoi visualizzare il tuo backlog dello sprint con una task board Scrum. La board può avere diverse forme; tradizionalmente include schede indice, Post-It o una lavagna. La Scrum board è solitamente divisa in tre categorie: da fare, lavoro in corso e fatto. Lo Scrum Team deve aggiornare la board durante l\'intero sprint. Ad esempio, se qualcuno propone una nuova attività, scriverà una nuova scheda e la inserirà nella colonna appropriata. **Grafico Burndown:** un Grafico Burndown rappresenta tutto il lavoro in sospeso. Il backlog è solitamente sull\'asse verticale, con il tempo lungo l\'asse orizzontale. Il lavoro rimanente può essere rappresentato da story point, giorni ideali, giorni del team o altre metriche. Un grafico burndown può avvisare il team se le cose non stanno andando secondo i piani e aiuta a mostrare l\'impatto delle decisioni. **Large-Scale Scrum (LeSS):** se vuoi estendere gli elementi di Scrum a centinaia di sviluppatori, il framework Large-Scale Scrum (LeSS) aiuta ad estendere le regole e le linee guida senza perdere il nucleo di Scrum. I principi sono presi direttamente da Scrum, tuttavia si concentrano sull\'aumento di scala senza aggiungere spese generali aggiuntive (come l\'aggiunta di più ruoli, artefatti o processi). **Timeboxing:** un Timebox è un periodo di tempo stabilito durante il quale un team lavora per raggiungere un obiettivo. Invece di lasciare che un team lavori fino al raggiungimento dell\'obiettivo, l\'approccio timebox interrompe il lavoro quando viene raggiunto il limite di tempo. Le iterazioni timebox sono spesso utilizzate in Scrum ed Extreme Programming. **Icebox:** tutte le User Story registrate ma non spostate nello sviluppo vengono archiviate nell\'icebox. Il termine \"Icebox\" è stato creato da Pivotal Tracker, uno strumento di gestione dei progetti Agile. **User Story (Storie utent):** una User Story descrive una funzionalità software dal punto di vista del cliente. Include il tipo di utente, cosa desidera e perché lo desidera. Questi racconti seguono una struttura simile: come \, voglio \ in modo da poter \. Il team di sviluppo usa questi racconti per creare codice che soddisfi i requisiti dei racconti.