Una stima del tempo equivale a una promessa in Scrum?

Se un preventivo non è una promessa, allora come proprietario del prodotto come posso consegnare i miei progetti senza sapere quanto tempo ci vorrà?

Un team Scrum funziona in modo più efficiente se trattiamo le stime dei tempi come una promessa?

Quanta ricerca (preparazione, sforzo per comprendere il problema) in una storia è sufficiente per ottenere la stima giusta?

Che dire di problemi tecnici imprevisti (problemi che possono davvero rovinare le tue stime iniziali) che sorgono dopo aver valutato il tuo lavoro?

Le stime non sono promesse incise nella pietra. Sono la migliore ipotesi che il team può fare sullo sforzo richiesto per completare l'attività / storia.

In risposta alla tua domanda "come proprietario di un prodotto come posso offrire i miei progetti con fuori tempo come un punto di riferimento?", La risposta è che si può e si deve avere il tempo come riferimento (per esempio, si sarà rilascerà in una certa data). Quello che non hai è l' ambito esatto che sarà nella consegna.

Nota che ciò che ho detto è vero per ogni metodologia che usi per guidare il tuo sviluppo. La differenza tra Scrum e altre metodologie (come Waterfall) è che in Scrum questo fatto è riconosciuto e giustificato. Quello che farai, come PO, è dare la priorità al tuo ambito di applicazione e assicurarti che il team, in un dato momento, sia:

1. Lavorare sulla funzione più importante (leggi: preziosa) non consegnata (attività, requisiti, user story)
2. Ha completato con successo ogni funzione che è più importante di quella su cui stanno attualmente lavorando (questo fa riferimento alla definizione di Fine : ogni storia completata viene testata, accettata, priva di bug e completa di funzionalità).

Detto questo, ora puoi spedire o consegnare, con la caduta di un cappello, sapendo che in un dato momento , l'ultima build è il miglior prodotto che potrebbe essere spedito. Ciò significa che alla data dell'impegno di rilascio originale, consegnerai il miglior prodotto possibile.

Ovviamente, questo non promette che sarà composto da tutte le storie che hai richiesto al team di sviluppare, ma sai che quelle rimanenti incomplete sono ovviamente le meno importanti, che potrebbero essere facilmente consegnate in un secondo momento.

Inoltre, le stime fatte dal team saranno sempre migliori, consentendoti di avere una solida idea iniziale di quale sarà lo scopo alla fine del rilascio. Sarai in grado di spedire un buon prodotto solido in tempo, con alcune funzionalità aggiuntive meno importanti poche settimane dopo (sarai ovviamente in grado di stimare quando sarà).

Per quanto riguarda la quantità di ricerca richiesta, c'è una legge di rendimenti decrescenti in gioco qui. Se rompi le tue storie abbastanza piccole, allora una piccola ricerca dovrebbe darti una stima abbastanza vicina. Se li hai sbagliati, ti adeguerai allo sprint successivo e le stime saranno migliori. In 3-4 sprint, in media, dovresti avere una buona idea di quanto tempo può essere consegnato entro la scadenza (o quanto tempo ci vorrà per completare l'ambito).

Quando si stimano i punti della storia in Scrum, è necessario conoscere abbastanza per poter effettivamente iniziare a scrivere la funzione. La stima non dovrebbe essere del tutto accurata, il punto centrale delle metodologie di sviluppo Agile è che riconoscono che non è possibile prevedere con precisione il tempo necessario per lo sviluppo.

La fase in cui ti impegni a consegnare è quando accetti le storie dal portafoglio ordini del prodotto in uno Sprint. Stai promettendo di consegnare quelle storie all'interno dello sprint.

Se prendi questo impegno, questo significa che sei disposto a fare qualche ora in più se sembra che non manterrai la promessa. In realtà, alcune storie impiegheranno più tempo di quanto pensassi e altre richiederanno meno tempo di quanto pensassi.

Quando il team ha fatto abbastanza stime, migliorerà.

Potresti anche voler guardare ...

The Clean Coder (libro) - in questo libro c'è un capitolo intitolato "The Language Of Commitment" e anche un capitolo sulla stima, che è davvero sorprendente.

Kanban - Kanban è più uno stile pull di sviluppo in esecuzione - ci sono anche combinazioni di Scrum e Kanban chiamate "Scrumban", che attingono da entrambe le idee.

No.

La somma di tutte le stime su ciascuna attività completata in uno sprint è chiamata velocità . La velocità è definita come "numero di punti completati per sprint" dove "punto" è l'unità stimata dalla tua squadra.

Quindi la velocità ti consente di sapere quanto il tuo team può produrre nel prossimo sprint, supponendo che utilizzino lo stesso metodo per stimare e che il team sia stabile ecc.

Ed è così che puoi essere abbastanza sicuro di ciò che il team può offrire senza dover fare promesse casuali.

Le stime dello sforzo sono uno strumento per le previsioni. Una previsione non è né un impegno né una garanzia. Le previsioni vengono costantemente rivalutate per tenere conto delle nuove conoscenze e dovrebbero includere possibili alternative come variazioni ottimistiche e pessimistiche.

Non vediamo l'ora di Agile. Gli impegni non aggiungono più valore alla pianificazione organizzativa delle previsioni.

Consiglio vivamente la stima e la pianificazione agili di Mike Cohn

Se un preventivo non è una promessa, allora come proprietario del prodotto come posso consegnare i miei progetti senza sapere quanto tempo ci vorrà?

Non lavori con una grande stima, ma con molte piccole stime a livello di trama. Molti errori di stima a livello di storia sono in media fuori. Non puoi promettere contenuto e data. Puoi, tuttavia, essere abbastanza sicuro che la parte superiore del backlog arriverà in una versione (in alternativa, avere una data abbastanza accurata - ma non fissa - in cui è possibile consegnare l'intero backlog).

Un team Scrum funziona in modo più efficiente se trattiamo le stime dei tempi come una promessa?

No. Questo porta a stime di sandbagging e trasforma i grafici di velocità / burndown in dati inutili, il che impedisce al team di migliorare.

Quanta ricerca (preparazione, sforzo per comprendere il problema) in una storia è sufficiente per ottenere la stima giusta?

Dipende da quanto ti interessa la precisione. Puoi trascorrere settimane preparando con cura ogni preventivo, oppure fornire stime rapide in buona fede e sperare che gli errori si aggirino nella media. Il primo modo è preparare l'errore, perché stimare qualcosa che non hai mai fatto prima è davvero difficile e l'ingegneria del software si basa su cose che non hai mai fatto prima.

Personalmente, non penso che ci siano molti vantaggi nel cercare di ottenere stime molto accurate. Quello che cerco di fare è assicurarmi che le stime siano abbastanza accurate, ovvero che non ho perso qualcosa che potrebbe far deviare una storia dalla sua stima di un ordine di grandezza. (Vedi il prossimo punto).

Che dire di problemi tecnici imprevisti (problemi che possono davvero rovinare le tue stime iniziali) che sorgono dopo aver valutato il tuo lavoro?

Piccole iterazioni. Backlog ordinato. Piccole storie. Le cose pericolose sono ciò che non sai di non sapere. La mancanza di esperienza su un problema comporterà stime scarse, ma è possibile adattarsi acquisendo esperienza (maggiore elaborazione) o andare con stime "abbastanza buone" - si tratta solo di gestione del rischio.

Se un preventivo non è una promessa, allora come proprietario del prodotto come posso consegnare i miei progetti senza sapere quanto tempo ci vorrà?

Questo è uno dei maggiori fraintendimenti su Scrum. La domanda "Quanto durerà il mio progetto?" presuppone che sia possibile definire, ad un certo punto nel tempo, esattamente cosa comporterà il progetto per completarlo. Ma l'idea generale di Scrum è che riconosce che le cose che impari su un progetto, mentre lavori al progetto, cambieranno la definizione del progetto.

Il modo più comune per definire un progetto è elencare le funzionalità che avrà. In genere, un progetto viene completato quando tutte le funzionalità sono state implementate. Ma cosa succede se, mentre lavori su un progetto, ti rendi conto che 5 delle caratteristiche identificate all'inizio non saranno necessarie, ma ci sono 7 caratteristiche a cui la gente ha pensato nei primi 6 mesi che dovrebbero davvero essere incluse? Cosa fa questo alla domanda su quanto tempo ci vorrà?

Un altro fattore è che le cose che impari cambieranno la tua comprensione di come implementare determinate funzionalità e man mano che ti avvicini all'implementazione di ogni funzione le tue stime cambieranno. Personalmente, resisterei a fare stime numeriche su qualsiasi cosa non si avvicini all'orizzonte dell'implementazione, magari usando stime descrittive come "minuscola", "piccola", "media", "grande" e "enorme" o "epica". Quindi non stai insinuando una precisione maggiore di quella che sei in grado di stimare.

Sinceramente, "Quanto tempo ci vorrà?", Non è più responsabile di "Cosa sarà quando sarà fatto?". Ragionieri e uomini d'affari tradizionali odiano questo, motivo per cui è molto difficile allontanarsi da Waterfall in alcune organizzazioni.

È anche il motivo per cui è necessario prendere un sacco di discorsi su velocità e metriche con un granello di sale. I progetti software hanno una sorta di Principio di incertezza di Heisenberg integrato e, se passi troppo tempo a mettere a punto le misurazioni, finirai per avere delle assurdità estremamente precise.

Quindi no, una stima non è una promessa. È una stima La "promessa" è l'impegno che il Team prende per completare un certo numero di funzioni o storie in un determinato Sprint.

Le stime devono essere abbastanza precise da consentire al team di identificare quante funzioni (o storie) possono adattarsi perfettamente a uno Sprint. Ancora più importante della precisione nelle stime è la coerenza, perché il Team apprenderà quanto lavoro valgono le stime che possono rientrare in uno Sprint, anche se il lavoro effettivo risulta di solito il doppio di quanto stimato. Finché è costantemente spento, saranno in grado di pianificare.