Come posso visualizzare rapidamente il software nelle riunioni?

Migliora in questo modo ripetutamente.

L'ho fatto per anni e nessuno è perfetto. L'intero punto della "velocità di squadra" è ammettere e tenere traccia di quanto male ci stiamo facendo.

La velocità della squadra tiene traccia di quanto tempo reale ci vuole per far passare al team il tempo stimato. Dovresti prestare attenzione a questo e imparare.

Anche con anni di esperienza sarai comunque sorpreso, ma con il tempo avrai una sensazione migliore. Ciò significa che quando si scopre che le stime sono errate, lo individuerai e lo segnalerai prima.

Per quanto riguarda i punti poker, questi hanno il loro tasso di cambio da squadra a squadra. Basta usarli per esprimere come ti senti su una storia. Lo faccio principalmente contando il numero di cose che dovrò fare per la prima volta.

E ricorda, questo non è design. Questo è solo pianificazione.

Come afferma CandiedOrange, la capacità di "vedere" rapidamente la forma di un approccio progettuale è qualcosa che viene con l'esperienza (e ovviamente varia con la complessità del requisito).

Tuttavia, la vera risposta è questa non dovrebbe essere la prima volta che senti queste storie . In Scrum si fa comunemente riferimento a un processo denominato "Backlog Grooming" (chiamato "perfezionamento del product backlog" nella guida Scrum ) che dovrebbe verificarsi. Fondamentalmente, gli sviluppatori dovrebbero passare un po 'di tempo a guardare e chiarire le storie degli utenti che si trovano nel Product Backlog che non sono ancora nello sprint corrente. Questo potrebbe essere su base individuale o ci possono essere riunioni regolarmente programmate per farlo o riunioni possono essere programmate "su richiesta" se una storia particolare. Ci sono altri modi per organizzarlo; fai ciò che ha senso per la tua squadra.

Anche se non guardi le storie degli utenti al di fuori della riunione di Sprint Planning, dovresti comunque mantenere almeno un paio di sprint di lavoro stimati, perfezionati, ordinati per priorità e pronti all'uso. Dovresti non stimare quanto basta del Product Backlog per lo sprint che sta per iniziare. Ad esempio, se uno sprint sta andando bene, dovresti essere in grado di raccogliere storie dalla parte superiore del Product Backlog e spostarle nello sprint senza dover fare una mini-pianificazione (anche se aggiungere una storia allo sprint dovrebbe essere ancora qualcosa che il team è d'accordo nel suo insieme in una riunione di stand-up del giorno, per esempio). Dovresti anche re stimare storie (se qualcuno del team ritiene che valga la pena raccontarsi una storia per base) prima di essere aggiunto allo sprint nel caso qualcuno abbia imparato qualcosa di nuovo che potrebbe avere un impatto sul stima. Non sei obbligato ad alcuna stima fatta prima che una storia venga aggiunta allo sprint attuale. Anche con questo approccio minimale al grooming del backlog, avrai almeno due crepe per stimare la maggior parte delle storie e almeno uno sprint di tempo per pensarle prima che vengano accettate in uno sprint. (Naturalmente, il "pensare a loro" è esattamente il grooming degli arretrati.)

Dato questo approccio minimo, hai ancora il problema che stai descrivendo di aver bisogno di stimare rapidamente una storia fredda, ma ora le tue stime iniziali sono molto meno critiche. La stima di più di sprint di storie, anche con stime che potrebbero cambiare, consente ad altre parti interessate e in particolare al Product Owner di farsi un'idea di quando (e se) storie verranno pubblicate e quale sarà l'impatto dell'inserimento di nuove storie ad alta priorità.

Esistono diverse strategie per la stima, ed è importante capire la logica alla base.

L'approccio che hai utilizzato nel tuo precedente lavoro sembra essere un approccio bottom-up : si disegna un disegno con carta e penna, poi si valutano i diversi pezzi identificati e infine si aggiungono queste stime insieme:

• la tua capacità di stima dipenderà molto dalla tua comprensione del design dettagliato.
• devi fare questa analisi approfondita prima ancora che sia deciso se la storia verrà presa in carico o meno.
• una differenza significativa nel design reale (ad esempio alcuni pezzi mancanti) renderà le tue stime totalmente sbagliate, mettendo a repentaglio l'obiettivo dello sprint.
• ti ritrovi coinvolto nel tuo design, che hai fatto da solo senza il beneficio del potere della squadra. Non è una specie di approccio mini-cascata?

Il pianificazione del poker utilizza un approccio diverso . Funziona per analogia, confrontando la storia con storie simili o una combinazione di queste:

• Se si stima per analogia in solo, è possibile toccare solo nella propria esperienza.
• Il team ha comunque l'esperienza molto più diversificata di tutti i membri. Ciò aiuta a identificare meglio la somiglianza con le storie precedenti su cui alcuni membri del team hanno lavorato in passato.
• Se le stime dei membri del team sono troppo divergenti, il processo di discussione aiuterà a raggiungere un consenso, tutti rivedendo il proprio giudizio, tenendo conto di alcuni fatti di cui non era a conoscenza. Questo è il motivo per cui questa tecnica ha dimostrato di essere così efficace.

Il poker di pianificazione è anche uno strumento di apprendimento: ad ogni sprint, hai nuove stime, che puoi confrontare con i risultati raggiunti. La retrospettiva ti consente quindi di comprendere l'errore di stima e migliorare le abilità in questa materia.

Considerare di avere conversazioni individuali piuttosto brevi con i colleghi il giorno prima della riunione di pianificazione, per prepararsi a questo. Usa carta e penna durante tali conversazioni e fai riferimento alle tue note il giorno seguente.

Durante la riunione di pianificazione, invece di pianificare / comunicare con carta e penna, utilizzare una lavagna. Invita altri ad abbellire il tuo schema architettonico o le note sui nomi dei campi dati necessari. Voi sei in grado di raggiungere un consenso condiviso con le parole che sentite tutti, ma anche con un diagramma che tutti voi potete vedere. Dopo uno o due incontri, decidi quale approccio raggiunge il consenso più velocemente.