È Scrum basato su "report giornalieri"?

Un punto davvero importante è che lo stand-up quotidiano non riguarda i membri del team che riferiscono allo Scrum Master, ma il fatto di fare il check-in l'uno con l'altro. Di fatto, uno dei trucchi per essere uno Scrum Master è trovare i modi per evitare che la squadra ti riferisca.

Il ruolo dello Scrum Master è di assicurarsi che le regole siano seguite. Quindi per quanto riguarda gli Scrum quotidiani, l'unica vera funzione dello Scrum Master è assicurarsi che siano tenuti ogni giorno. Non ha nemmeno bisogno di badare a se stesso.

Tecnicamente, l'altro ruolo dello Scrum Master è quello di chiarire gli impedimenti che vengono svelati durante lo stand-up. Personalmente, preferirei che il Team guardasse ogni ostacolo e capisse da solo ciò che volevano fare al riguardo. Ciò potrebbe effettivamente implicare che l'SM sta facendo qualcosa per eliminare l'impedimento, ma solo se è così che il TE

Per prima cosa, non confondiamo Scrum e Agile. Scrum è un processo Agile, ma non equivale a Agile. Quello che stai descrivendo è Scrum.

Se Scrum è basato sul rapporto quotidiano che descrivi è aperto al dibattito. Non sarei sorpreso se esiste una catena evolutiva di tecniche dall'una all'altra, ma Scrum non si basa su un sistema di soggiogamento.

Scrum è significativamente diversa da "Giornaliera" nel senso che non stai segnalando tutti i giorni da monitorare o punito se hai commesso degli errori, si sta riportando perché se non lo fai poi la tendenza dello sviluppatore medio è di non chiedere aiuto quando è nei guai.

Senza Scrum, qualcosa che è apparso dovrebbe aver preso un giorno a volte fluirà perché manca la base di conoscenze dello sviluppatore. Ma è determinato a risolverlo da solo. Spesso, si avverte che gli sviluppatori attenderanno 3-4 giorni e quindi, rendendosi conto che avrebbero dovuto chiedere aiuto in precedenza, permetteranno a quel problema di trascinarsi per tutto il tempo necessario. Sarò onesto, ci sono stato.

In questi casi, gli standup avrebbero identificato che dopo un giorno, quando qualcosa promesso non viene consegnato e un altro sviluppatore può dire "Posso aiutarti".

Ci sono molti altri blocchi per il lavoro di uno sviluppatore, oltre alla mancanza di conoscenza. Queste cose possono portare allo stesso modo. L'idea di Scrum è di avere qualcuno che rimuove quei blocchi senza umiliare lo sviluppatore che li ha colpiti.

Tornando ai rapporti giornalieri, è stato proprio l'approccio opposto. Era per costringere le persone a lavorare di più sapendo che, se non lo facessero, si sarebbero messi nei guai quella notte. E per finire, non sono nemmeno riusciti a fare le proprie stime, quindi un supervisore poteva impostare le aspettative che desideravano.

Nessuno di questi si riferisce a Scrum.

Per rispondere alla tua domanda finale, penso che la differenza tra la segnalazione all'inizio di ogni giorno e la segnalazione due volte al giorno riassuma questa differenza psicologica. C'è fiducia che tu abbia fatto del tuo meglio. Vai a casa e dormi, torna e raccontaci come stanno andando le cose al mattino.

Forse. Se lo scopo è sconfiggere gli sviluppatori, allora uno "stand-up" probabilmente non è una buona idea. Se invece lo scopo è assicurarsi che tutti abbiano la stessa immagine dello stato del progetto, potrebbe esserci qualche merito.

Se esegui Scrum correttamente, fai segnalazioni per tutto il giorno. Hai il tuo Scrum board e tutti possono venire a vedere il tuo stato attuale = chiunque può vedere cosa è fatto, cosa è in corso e cosa è in sospeso a causa di un impedimento. La tabella di mischia dovrebbe contenere anche il grafico di burndown in modo che chiunque possa anche vedere come stanno cambiando i tuoi progressi e la tendenza.

Se utilizzi carte con colori diversi puoi anche mostrare immediatamente quali sono le attività più comuni, quali sono i compiti di infrastruttura, i bug, ecc.

Il punto importante è che tutti possono vederlo, ma durante lo sprint non dovrebbero esserci cambiamenti o lamentele sulle prestazioni della squadra. Sprint è la zona sicura del team e i membri del team hanno il potere di impegnarsi a livello di funzionalità fornite durante lo sprint. Conoscono al meglio quante funzioni sono in grado di fornire.

Hai anche stand in cui chiunque può venire e ascoltare come i membri del team rispondono a tre domande ogni giorno:

• Che cosa ho fatto ieri?
• Che cosa farò oggi?
• Che impedimenti ho?

È importante che tutti possano venire e ascoltare, ma solo i membri del team possono parlare. Se qualcuno al di fuori della squadra interrompe il meeting, lo Scrum master dovrebbe chiedergli di andarsene. La responsabilità dello Scrum Master è anche quella di risolvere gli impedimenti il più rapidamente possibile o di aumentarli. Il tempo per lo stand-up è la decisione della squadra, ma dovrebbe essere sempre nello stesso tempo.

Se disponi di un sistema elettronico per il tracciamento di attività / storie utente probabilmente puoi anche avere una lavagna virtuale e abbonamenti email per i grafici di burndown in modo che chiunque sia coinvolto nel progetto possa controllarlo dal suo computer.

Hai sprint brevi (2 settimane in media) e ripassa l'incontro dopo ogni primavera in cui chiunque può venire e vedere nuove funzionalità nel prodotto.

Mischia come molte altre metodologie agili forniscono reporting continuo e trasparenza senza burocrazia che puoi vedere in molte aziende.

Modifica

Ci sono alcune cose aggiuntive che possono essere considerate come "reporting" ma non sono prescritte dal processo generale Scrum - sono semplicemente aggiunte considerate utili = miglioramento continuo.

Una di queste funzionalità è la descrizione dei rischi. Durante la riunione retrospettiva, ogni membro del team riceverà una grande lista di documenti e scriverà o disegna qualsiasi cosa consideri un rischio per il progetto o il prossimo sprint. Queste foto dovrebbero essere bloccate su un muro in ufficio in modo che chiunque possa venire a vedere i rischi trovati dalla squadra. Anche il team vedrà questi rischi sempre visibili, quindi non li dimenticheranno: il proprietario del prodotto può definire nuove storie di utenti in base ai rischi rilevati. Dopo che il team di sprint può rimuovere i rischi risolti o obsoleti e aggiungere nuovi documenti con nuovi rischi.

Sappiamo tutti che il Daily Scrum è molto più di una semplice segnalazione. Anche i rapporti non sono esattamente la parola giusta da usare qui. l'id piuttosto usa comunicare, anche solo uno alla volta. La mischia quotidiana è il compito più importante della giornata, per far entrare tutti nel circuito di ciò che è successo, che cosa accadrà e come è successo.

Offre a tutti la possibilità di sapere chi aiutare, a chi indirizzare le domande nel caso in cui qualcosa si rompa e debba risolversi, soprattutto se c'è un problema che richiede la sovrapposizione di due o più sviluppatori e, a sua volta, ognuno ottiene l'intera panoramica del obiettivi di un determinato sprint.