Misurazioni quotidiane di Scrum: differenza tra Reporting e Check-In?

Scrum considera il Daily Scrum come una riunione di ispezione e pianificazione. Lo scopo è quello di ispezionare il lavoro svolto contro gli Sprint Goals e pianificare il valore del lavoro del giorno successivo. Le tre domande sono solo un metodo per eseguire un Daily Scrum e non sono richieste. Lo Scrum Master dovrebbe insegnare al team di sviluppo un modo efficace per eseguire il Daily Scrum in modo tale che gli obiettivi di controllare i progressi rispetto agli Sprint Goals, ispezionare i progressi contro lo Sprint Backlog e adattare o pianificare le modifiche siano in grado di raggiungere lo Sprint Gli obiettivi sono soddisfatti.

Anche il timebox di 15 minuti è un intervallo di tempo massimo. A seconda delle dimensioni della tua squadra, potrebbe essere più breve. Un team di sviluppo in Scrum è tra 3 e 9 persone. Un team di sviluppo di 9 persone dovrebbe essere in grado di completare l'ispezione e la pianificazione in 15 minuti. Una squadra di 3 potrebbe aver bisogno di un periodo di tempo più breve per fare lo stesso.

Un altro elemento chiave della Guida di Scrum è che "il team di sviluppo oi membri del team spesso si incontrano immediatamente dopo il Daily Scrum per discussioni dettagliate, o per adattare, o sostituire, il resto del lavoro dello Sprint". Alcune cose potrebbero sorgere nel Daily Scrum che richiedono un lavoro aggiuntivo per capire cosa fare o potrebbe richiedere il coinvolgimento del Product Owner. In questi casi, il problema non dovrebbe essere risolto immediatamente nella Daily Scrum, ma dalle persone giuste dopo la Daily Scrum.

Se stai semplicemente "verificando" o "riportando" lo stato di lavoro, ritengo che sia la metà di quello che dovrebbe essere il Daily Scrum. Dovresti anche prendere in considerazione gli Sprint Goals e trovare i modi per raggiungere gli Sprint Goals o la Sprint Goals o lavorare con il Product Owner per riallineare gli Obiettivi di Sprint a qualcosa che sia realizzabile. La Sprint Retrospective è una grande opportunità per rivisitare e riflettere sul perché alcuni problemi hanno avuto un impatto sul lavoro del team e su come prevenirli in futuro.

Non è una quantità enorme per andare avanti senza conoscere l'interno del tuo progetto, ma alcuni commenti generali sui punti che hai delineato:

more often, "I am still working on task Z"

Forse il problema qui è che le tue storie non sono abbastanza dettagliate - se ti accorgi di dire la stessa cosa per più di qualche giorno, le campane di allarme dovrebbero suonare. Le opinioni cambiano su come dovrebbero essere grandi storie, ma come regola generale non dovrebbero essere più grandi di 2-3 giorni.

These reports every day make little sense to me

Forse non lo fanno se le storie sono ben definite e stai attraversando il lavoro e sei sul bersaglio. Si può quindi, si vuole considerare di averli meno frequentemente. Il processo dovrebbe funzionare per te, non viceversa.

Consiglierei di non abbandonarli del tutto. Queste cose tendono ad essere più difficili da organizzare per la seconda volta se sono state abbandonate prima - semplicemente a causa del fatto che le persone riempiono i loro diari con altre cose o non prendono seriamente le posizioni.

Se è il momento in cui ti sta prendendo in considerazione, considera se sarebbe meglio dividere lo stand up su linee funzionali o comunque tu scelga.

Non si suppone che stia segnalando, è una conversazione con altri sviluppatori per aiutare a pianificare la giornata e assicurarsi che la squadra sia sulla buona strada. Forse sono la stessa cosa, ma avere la mentalità della condivisione e della segnalazione aiuta a mantenere l'IMO semplice e utile.

Su quasi tutti i team di scrum ad alto funzionamento in cui sono stato, quasi tutti attendevano con impazienza la mischia mattutina perché era la possibilità di vedere il grande lavoro svolto dai nostri colleghi.

Some people say it's for Check-In instead of Reporting, but is there a difference? Apart from Reporting possibly leading to immediate rating. And if, what is the difference?

Se c'è qualcuno in piedi che ha il potere di fare "valutazione immediata", dovrebbe essere rimosso. Lo stand up è solo per la squadra, non per la gestione.

They have a tendency to become 10 or 15 minutes of boredom. Or is there a different meaning in the first 2 of the 3 questions, that qualifies "check-in" in a different way?

Se sono "da 10 a 15 minuti di noia", è perché la tua squadra sta scegliendo di farli in quel modo. Se i tuoi standup non funzionano, discutili nelle retrospettive e trova i modi per migliorarli.

Lo scopo e il valore dell'evento espresso in La guida di Scrum sono mancanti.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.

Il ruolo guida nelle tre domande è stato migliorato nel 2017.

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.

Il reporting dello stato nel Daily Scrum è un semplice indicatore del fatto che lo scopo e il valore dell'evento Daily Scrum non sono compresi.

Camminare sulla scacchiera esaminando ogni articolo del Product Backlog è spesso il prossimo passo verso la maturità e fornisce una migliore realizzazione del valore.

...

Idealmente il team di sviluppo sta collaborando durante tutto il giorno, forse con la programmazione pair e mob, a tal punto che l'evento Daily Scrum diventa una rapida conversazione per il team di sviluppo per convalidare la loro comprensione condivisa riguardo al piano emergente e al progresso verso il Sprint Goal.

Potrebbe essere usato in qualsiasi modo. Probabilmente ci sono molti manager tradizionali che hanno adottato Scrum perché suona bene o sono stati costretti a fare affidamento sui loro vecchi comandi e processi di controllo. A loro, stai segnalando.

Questo è il caso in cui una squadra in generale o in relazione a un progetto specifico deve esaminare quello che sta facendo, perché lo fa e se ne sta uscendo o meno di quello che ti serve. Riguarda il team che ha portato a termine il progetto.

Alla maggior parte dei programmatori piace pensare che non lascerebbero eseguire una routine nel loro codice che non ha portato a termine nulla, ma poi ci sono quelli che costruiscono cose non nei requisiti perché non si sa mai.

Non farlo con Scrum. Gli stand up sono visti come un modo semplice e veloce per comunicare le informazioni potenzialmente necessarie. Sentiti libero di liberartene e / o trovare un'alternativa. In alcuni casi il team sa quando condividere informazioni e quando no.

Personalmente, se mi venisse richiesto di tenere traccia di tutto ciò su cui sto lavorando in un sistema e poi ho dovuto alzarmi ogni giorno e praticamente ripetere a tutti quello che ho inserito, sarebbe diventato vecchio, ma lo sappiamo tutti, nessuno è leggendo cosa c'è nell'altro sistema. L'incontro di stand up non ti dà una scelta.