Guida Scrum | 35. Daily Scrum

Il Daily Scrum dura non più di quindici minuti e si tiene sempre nello stesso luogo e allo stesso tempo per ridurre la complessità non necessaria. Vi partecipano tutti gli Sviluppatori che lavorano insieme sul Prodotto e, facoltativamente, lo Scrum Master. Lo scopo principale di questo Evento Scrum è pianificare i compiti su cui si concentreranno per la giornata.

Daily Scrum – sommario:

1. introduzione
2. La formula Daily Scrum
3. Problemi con Daily Scrum e il metodo 5W
4. Domande di supporto
5. 5 Perché
6. Riepilogo

introduzione

Il Daily Scrum è il più breve e il più frequente degli Scrum Event, una panoramica dei quali può essere trovata in un articolo separato. Il compito degli sviluppatori che partecipano a Daily Scrum è di fissare rapidamente obiettivi di lavoro per le prossime 24 ore. In questo modo, ognuno di loro sa su cosa stanno lavorando gli altri e come stanno lavorando verso uno Sprint Goal comune.

La formula Daily Scrum

Non esiste una formula corretta per il Daily Scrum. Ogni team di sviluppo sviluppa un formato di riunione che funziona per esso. Tuttavia, esiste un quadro generale per semplificare la conduzione.

Un Daily Scrum ben condotto dovrebbe consentire a ciascun partecipante di rispondere a due domande :

• Qual è il compito più importante che svolgerò oggi?
• Quali sono gli ostacoli per portare a termine questo compito?

Tuttavia, chiederli direttamente non è una formula obbligatoria. Queste sono domande di esempio che definiscono l'asse della riunione. Daily Scrum ha lo scopo di migliorare la comunicazione nel Team di Sviluppo, dare priorità alle attività e ridurre il rischio di colli di bottiglia.

Il Daily Scrum è un evento equivalente al Daily Standup in altri metodi Agile. E spesso funziona in modo molto simile, anche se la Guida Scrum ufficiale non richiede agli sviluppatori di stare in piedi durante questo breve Evento. Molto spesso i suoi partecipanti stanno semplicemente in piedi mentre parlano in un gruppo informale.

Anche se può sembrare che 15 minuti al giorno siano molti per discutere delle attività quotidiane, la pratica dimostra che un tale incontro è il migliore per l'efficacia del Team di sviluppo. Con aggiornamenti frequenti e regolari su obiettivi e impegni, tutti gli sviluppatori si concentrano sulle attività prioritarie e danno la priorità al progresso regolare del team rispetto ai risultati individuali.

Problemi con Daily Scrum e il metodo 5W

Uno dei problemi con Daily Scrum è che gli sviluppatori prolungano il tempo della riunione. Se questo è il caso, è una buona idea introdurre una politica per scrivere su una board – fisica o virtuale – questioni problematiche che non sono centrali per il Daily Scrum ma sono importanti per il Team. In questo modo sarà possibile tornare sui problemi lasciati da discutere durante le discussioni informali della giornata. E anche, se necessario, durante la Sprint Retrospective, che descriveremo più dettagliatamente in un articolo a parte.

Un altro problema che spesso si pone durante i Daily Scrum è trasformarli in incontri per riassumere il lavoro della giornata precedente. Gli sviluppatori si concentrano quindi sulla discussione dei risultati già raggiunti. Questa non è una buona pratica. Certo, l'attuale orientamento degli Sviluppatori sullo stato del lavoro che porta allo Sprint Goal è molto importante. Tuttavia, dedicare il Daily Scrum a compiti già completati non promuove l'efficienza.

Domande di supporto

Se il Team non trae vantaggio dal Daily Scrum, lo Scrum Master può aiutare gli Sviluppatori a identificare i problemi osservando il meeting per trovare le risposte alle seguenti domande:

5 Perché

Dopo l'identificazione iniziale del problema, una tecnica efficace per determinare la causa del problema può essere il metodo 5 Why, chiamato anche 5 Whys o 5W di Sakichi Toyoda. Si tratta di chiedere a diversi "Perché?" domande di fila. Ciò consente di diagnosticare la causa più profonda del problema e quindi di risolverlo più facilmente.

Prendiamo ad esempio l'ultimo punto della tabella: il problema sorge nell'area di impegno per la risoluzione dei problemi da parte del Team di Sviluppo. Le cinque domande potrebbero essere le seguenti:

1 x PERCHE'?

D: Perché gli sviluppatori non offrono modi diversi per risolvere i problemi che si presentano?

R: Perché lo sviluppatore Harry è sempre il primo a proporre una soluzione.

2 x PERCHE'?

D: Perché lo sviluppatore Harry è sempre il primo a proporre una soluzione?

A: Perché nessun altro sta parlando.

3 x PERCHE'?

D: Perché nessun altro parla?

R: Perché altri Sviluppatori non hanno alcun desiderio di cercare soluzioni migliori.

4 x PERCHE'?

D: Perché altri sviluppatori non hanno voglia di cercare soluzioni migliori?

A: Perché trovare soluzioni richiede concentrazione ed è più facile considerare la soluzione di Harry abbastanza buona.

5 x PERCHE'?

D: Perché hanno considerato la soluzione di Harry abbastanza buona?

R: Dal momento che non vengono ricompensati per la proposta di alternative, hanno discusso i loro piani per oggi all'inizio dell'incontro e stanno pensando di iniziare.

In questo caso, il problema della mancanza di impegno nella risoluzione dei problemi può essere risolto modificando l'ordine del Daily Scrum e partendo da questo problema. Oppure inventare un sistema per premiare la soluzione migliore, ad esempio introducendo una ricompensa simbolica per l'autore del maggior numero di soluzioni accettate dal Team in un dato Sprint.

Riepilogo

Daily Scrum è una parte fondamentale del lavoro quotidiano del Team di Sviluppo. Tuttavia, ogni Team deve elaborare da sé la formula ottimale per questo incontro. Un Daily Scrum ben condotto consente l'impostazione continua di sotto-obiettivi per raggiungere lo Sprint Goal. Consente inoltre di diagnosticare rapidamente i problemi di comunicazione e migliorare la cooperazione tra gli sviluppatori.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog