Come funziona Sprint [chiuso]

Vorrei iniziare dicendo che non hai specificato una metodologia. Agile è più un tipo di modo di fare le cose, una filosofia se vuoi. Come tale, non c'è "Dovrebbe fare questo o quello".

Vuoi lavorare in sprint. Ciò significa che stai mettendo a punto i tuoi sforzi e fai ciò che puoi all'interno di quel timebox. All'interno di uno sprint, sarebbe saggio consentire di testare e correggere bug per qualsiasi lavoro svolto.

Ora verrà un momento in cui viene rilevato un errore dopo che uno sprint è stato completato o per modifiche ancora più vecchie. Per questi bug, ci sono alcune scelte che puoi fare. Direi, prima di tutto, vorresti valutare l'impatto di un bug. Se c'è una soluzione accettabile o l'impatto è basso, puoi decidere di pianificare la correzione di questo errore in uno sprint.

Se l'impatto è elevato e non è possibile escogitare soluzioni accettabili, è probabile che tu voglia risolverlo il prima possibile. Il modo in cui lo farei è prendere la capacità necessaria dallo sprint e correggere il bug. Quindi accetta qualsiasi impatto abbia su ciò che può essere consegnato da quello sprint.

A seconda della complessità del bug e della quantità di tempo necessaria, potresti prendere in considerazione prima la creazione di una soluzione alternativa, se possibile, e correggerla correttamente nel prossimo sprint.

Per quanto riguarda la scrittura di storie utente per un bug, mi auguro che chiunque abbia segnalato il bug o abbia preso il report dall'utente, abbia riportato un percorso di riproduzione e un comportamento previsto in quel momento, quindi non è necessario che un PO scriva effettivamente nulla.

La cosa che devi ricordare è che lo scopo degli sprint è quello di aiutarti a impostare e raggiungere le scadenze.

In sostanza, stai cercando di capire quanto velocemente puoi programmare "funzionalità". Quindi puoi prendere la tua lista di funzionalità, moltiplicarla per questa "velocità" e dire "dovremmo essere fatti entro questa data, quindi il costo del software è X"

All'inizio di uno sprint, prendi un sacco di funzioni e dì, "sì, posso ricominciare a farlo in uno sprint". Alla fine dello sprint si dice "hmm sembra che eravamo fuori dal X% sulle nostre stime! Fattore migliore che nella prossima volta e dire al cliente che potremmo essere in ritardo!"

Il motivo per cui raggruppate le cose nello sprint piuttosto che in ogni singolo compito, è perché c'è molta interazione tra le caratteristiche quando le programmate. È più facile raggrupparli insieme durante la programmazione e la stima.

Se aggiungi o rimuovi elementi da uno sprint, cancelli i numeri e respingi la linea morta. A volte qualcosa sarà abbastanza importante da dover prendere il colpo. Ma dovresti evitarlo se possibile.

Alcune persone lasciano x% gratis per cose non pianificate, ma secondo me non funziona davvero. Stai solo aggiungendo un fattore di violino nel calcolo della stima. "Oh non ce l'abbiamo fatta, ma perché c'erano più bug del previsto." bene era? non puoi dirlo davvero.

La cosa peggiore che può succedere è che tu aggiunga e rimuovi costantemente le cose dallo sprint in corso, quindi non sai mai se le tue stime sono buone. Quando la scadenza arriva, scopri che hai ancora un sacco di funzioni originariamente pianificate da fare.

È molto più facile lasciare tutti quei bug fino alla fine e avere un set limitato di bug noti da chiarire. Almeno sarai gestito solo da una quantità nota.

Se sei preoccupato del ritardo tra la ricerca e la correzione di un bug, può essere lungo. L'approccio migliore è fare sprint più brevi. Uno sprint di 2 settimane significa 4 settimane prima che venga rilasciata una correzione. Uno sprint di 1 settimana significa 2 settimane. è una grande differenza a sua volta.