Una stima del tempo equivale a una promessa in Scrum?

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

In risposta alla tua domanda "come proprietario di un prodotto come posso consegnare i miei progetti senza tempo come riferimento?", la risposta è che tu puoi e dovresti avere tempo come riferimento (es. tu emetterà in una certa data). Quello che fai non ha è l'ambito esatto che sarà nella consegna.

Tieni presente che ciò che ho detto è vero per la ogni singola metodologia che utilizzi 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 obiettivo, e assicurarti che il team, in qualsiasi momento, sia:

1. Lavorare sulla funzione più importante (leggi: preziosa) non consegnata (compito, requisito, user story)
2. Ha completato con successo ogni funzione che è più importante di quella su cui sta lavorando attualmente (questo si riferisce alla definizione di fatto : ogni storia completata è testata, accettata, priva di bug e funzionalità completo).

Avendo ciò, ora puoi spedire, o consegnare, alla goccia di un cappello, sapendo che in qualsiasi momento , l'ultima build è il miglior prodotto che possa essere spedito. Ciò significa che alla data del tuo impegno di rilascio originale, fornirai il miglior prodotto possibile.

Naturalmente, questo non promette che consisterà in ogni storia che hai richiesto al team di sviluppare, ma sai che i restanti incompleti sono ovviamente i meno importanti, che potrebbero essere facilmente consegnati in un secondo momento data.

Inoltre, le stime fatte dal team saranno sempre migliori, permettendoti di avere una solida idea di cosa sarà lo scope alla fine del rilascio. Sarai in grado di spedire un buon prodotto solido in tempo, con alcune funzionalità aggiuntive meno importanti alcune settimane più tardi (sarai naturalmente in grado di stimare quando sarà).

Per quanto riguarda la quantità di ricerche richieste - qui c'è una legge di rendimenti decrescenti in gioco. Se rompi le tue storie abbastanza in piccolo, allora una piccola ricerca dovrebbe darti una stima abbastanza vicina. Se hai sbagliato, allora modifichi nel prossimo sprint e le stime saranno migliori. In 3-4 sprint, in media, dovresti avere una buona idea di quanto spazio può essere consegnato entro la scadenza (o quanto tempo ci vorrà per completare l'ambito).

Quando si stimano i punti storia in Scrum, si dovrebbe sapere abbastanza per essere in grado di iniziare effettivamente a scrivere la funzione. Non ci si aspetta che la stima sia completamente accurata, l'intero punto delle metodologie di sviluppo Agile è che riconoscono che non è possibile prevedere con precisione quanto tempo impiegherà lo sviluppo.

La fase in cui si effettua un impegno alla consegna è quando si accettano le storie dal backlog del prodotto in uno Sprint. Ti stai promettendo di pubblicare quelle storie nello sprint.

Se fai questo impegno, questo significa che sei disposto a fare qualche ora in più se sembra che tu non abbia intenzione di rispettare la tua promessa. In realtà, alcune storie impiegheranno più tempo di quanto pensassi e gli altri impiegheranno meno tempo di quanto pensassi.

Quando il team ha fatto una stima sufficiente, migliorerà.

Potresti anche voler guardare ...

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

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

If an estimate is not a promise then as a product owner how can I deliver my projects without knowing how long it will take?

Non lavori con una grande stima, ma con molte piccole stime a livello di storia. Gran parte degli errori di stima a livello di trama si aggirano mediamente. Non puoi promettere sia il contenuto che la data. Tuttavia, puoi essere abbastanza fiducioso che la parte superiore del backlog otterrà un rilascio (in alternativa, avere una data abbastanza precisa, ma non fissa, in quel momento l'intero backlog può essere consegnato).

Does a Scrum team work more efficiently if we treat time estimates as a promise?

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

How much research (preparation, effort to understand the problem) in a story is enough to come up the right estimate?

Dipende da quanto tieni alla precisione. Puoi dedicare le settimane a preparare con attenzione ogni stima, oppure dare una rapida stima in buona fede e sperare che gli errori si aggirino mediamente. Il primo modo è configurare il fallimento, perché stimare qualcosa che non hai mai fatto prima è davvero difficile, e l'ingegneria del software è tutta roba che non hai mai fatto prima.

Personalmente, non penso che ci sia molto beneficio nel cercare di ottenere stime molto accurate. Quello che cerco di fare è assicurarmi che le stime siano abbastanza accurate - cioè che non mi sia sfuggito qualcosa che potrebbe far sì che una storia si discosti dalla sua stima di un ordine di grandezza. (Vedi il prossimo punto).

What about unexpected technical problems (problems that can really mess your initial estimates) that come up after you estimate your work?

Piccole iterazioni. Arretrato ordinato. Piccole storie. Le cose pericolose sono ciò che non sai di non sapere. La mancanza di esperienza su un problema si tradurrà in stime scarse, ma è possibile adeguare sia acquisendo competenze (più elaborazione) sia ricorrendo a stime "abbastanza buone" - si tratta di gestione del rischio.

No.

La somma di tutte le stime su ciascuna attività completata in uno sprint si chiama velocità . La velocità è definita come "numero di punti completati per sprint", dove "punto" è l'unità in cui il tuo team stima.

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

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

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

Stiamo guardando in avanti in Agile. Gli impegni non aggiungono più valore alla pianificazione organizzativa rispetto alle previsioni.

Raccomanda vivamente la stima e pianificazione Agile di Mike Cohn

If an estimate is not a promise then as a product owner how can I deliver my projects without knowing how long it will take?

Questo è uno dei più grandi equivoci su Scrum. La domanda "Quanto durerà il mio progetto?" presuppone che è possibile definire, ad un certo punto nel tempo, esattamente ciò che il progetto comporterà per il completamento. Ma l'intera idea di Scrum è che riconosce che le cose che apprendi 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 a un progetto, ti rendi conto che 5 delle funzionalità identificate all'inizio non saranno necessarie, ma ci sono 7 funzionalità che le persone pensavano nei primi 6 mesi che avrebbero dovuto essere incluse? Che cosa fa alla domanda quanto tempo ci vorrà?

Un altro fattore è che le cose che impari cambiano la tua comprensione di come implementare determinate funzionalità e, man mano che ti avvicini all'implementazione di ciascuna funzione, le tue stime cambieranno. Personalmente, resisto alle stime numeriche su tutto ciò che non si avvicina all'orizzonte di essere implementato - magari usando stime descrittive come "tiny", "small", "medium", "large" e "huge" o "epic". Quindi non intendi un'accuratezza superiore a quella che sei in grado di stimare.

Sinceramente, "Quanto tempo ci vorrà?", non è più responsabile di "Cosa sarà quando verrà 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 devi parlare molto della velocità e delle metriche con un pizzico di sale. I progetti software hanno in sé una sorta di Principio di incertezza di Heisenberg, e se passi troppo tempo a mettere a punto le misure, finirai con un'assurdità estremamente precisa.

Quindi no, una stima non è una promessa. È una stima. La "promessa" è l'impegno che il team fa per completare un certo numero di caratteristiche o storie in uno Sprint particolare.

Le stime devono essere sufficientemente accurate da consentire al team di identificare il numero di caratteristiche (o storie) che possono essere contenute in uno Sprint. Ancora più importante dell'accuratezza delle stime è la coerenza, perché il team apprenderà quanto vale il lavoro di stime che possono essere contenute in uno Sprint, anche se il lavoro effettivo risulta essere solitamente il doppio di quanto stimato. Fintanto che è costantemente fuori, saranno in grado di pianificare.