Ad esempio, se rompo un progetto in n prodotti di lavoro discreti (ad esempio classi o funzioni o componenti) c'è un tempo t tale che n * t è una quantità adeguata di tempo da dedicare alla stima?
Se hai abbastanza informazioni per averlo scomposto a quel livello, non dovresti spendere più di un minuto per ognuna. Non avrai comunque ragione, ma dopo un minuto avrai la stessa precisione dopo un'ora.
Se, d'altra parte, stavi parlando di storie di utenti , suggerirei di coinvolgere le parti interessate una stanza e passare cinque minuti a fare domande prima di stimare.
Indipendentemente da ciò, non perdere molto tempo a fare stime. Non sono abbastanza utili o precisi per valerne la pena.
Nella mia esperienza, uno degli aspetti fondamentali di "sì, che funziona davvero" è un approccio "Le attività dovrebbero impiegare meno di un giorno". Se stai stimando cose che durano più di un giorno, sarai molto lontano.
Una volta che li hai suddivisi in modo da poterlo fare, hai fatto abbastanza; a prescindere davvero da cosa siano quelle cose.
Nel metodo della mischia agile, Pianificazione del poker è considerato un modo efficace per utilizzare l'intero team per stimare rapidamente sforzo richiesto per le storie degli utenti in uno sprint (presumendo che questo è ciò di cui si sta parlando). Altrimenti, non spenderei più di qualche minuto per stimare una singola attività che fa parte di una storia di un utente.
Consiglio vivamente di utilizzare questa tecnica basata sul consenso se si sta tentando di fare stime per un team di sviluppatori.
Pianificare il poker significa che puoi ottenere delle stime piuttosto buone per ogni singola storia utente in una singola sessione (non più di 1-2 ore).
Leggete su questo e provatelo!
Inoltre, come regola generale, nessuna attività in una trama utente deve superare le 7,5 ore (un singolo giorno di lavoro). In caso affermativo, è necessario suddividere l'attività in attività più piccole.
Penso che dipenda da ciò di cui hai bisogno. Se, per esempio, l'allocazione delle risorse del tuo progetto dipende da esso (come accadeva a volte qui a volte), è meglio farlo con attenzione. Al contrario, se stai facendo un progetto che non ha questo tipo di necessità, potresti non entrare troppo nel dettaglio. Trascorrere troppo tempo su di esso non è una buona idea, perché fare una stima accurata è molto difficile.
Esiste un concetto famoso chiamato Cono di incertezza e che dice quanto può essere accurata una stima di solito. Vale la pena leggere.
Che cosa ottieni dalle tue stime?
A seconda di ciò su cui lavori, le stime individuali accurate potrebbero essere rilevanti (il cliente ti paga alla fine della settimana o un'attività / la storia sta bloccando gli altri e è necessario un ETA preciso) (hai 200 storie in l'arretrato, nessuno morirà se una storia si sposta per una settimana, e stai contando su errori di stima per fare una media ok su un gran numero di loro).
Spendi solo il tempo minimo per ottenere una stima che sia abbastanza buona per le tue esigenze. Non esiste una formula.
Personalmente, ritengo che più di un minuto o due significhi che probabilmente stai stimando la cosa sbagliata (dividi o pianifica la scoperta).
In realtà hai bisogno di una stima per aiutare gli altri stakeholder a assegnare priorità relativa - quindi stime su base ampia che almeno dicono task1 è grosso modo 3 volte rispetto a task2, (anche se in termini di ore non molto accurate alla fine) utile. Spendi quanto tempo è necessario per capire quali sono questi compiti (per raggiungere determinati obiettivi) e poi avere stime approssimative per loro.
Una volta che hai una priorità relativa, concentrati solo sul fare le cose e aggiusta le stime in rotta. In altre parole, trascorri poco tempo in preventivi preventivi, ma raffina le tue stime con il passare del tempo in modo che il piano del progetto dia una buona idea su cosa fare.
Le buone stime sono quelle che sono in base ai fatti non sono ipotesi.
Pertanto, se hai già un progetto simile (s) e catturato il tuo tempo di stima precedente, che potrebbe server come una buona base di stima per iniziare . Tuttavia, a seconda del tuo ambito del progetto potrebbero esserci artefatti sconosciuti , che è meglio chiarire con BA o il proprietario del prodotto al più presto.
È anche vero che: la stima del progetto software è intrinsecamente imprecisa . Tuttavia, ci sono alcune pratiche di stima realistiche che potrebbero aiutare:
Leggi altre domande sui tag time-estimation