Quanto tempo dedicare alla stima delle attività di programmazione?

Ad esempio, se divido un progetto in n prodotti di lavoro discreti (ad esempio classi o funzioni o componenti), esiste un tempo t tale che n * t è un periodo di tempo adeguato da dedicare alla stima?

Se hai abbastanza informazioni per averle suddivise a quel livello, non dovresti dedicare più di un minuto a ognuna. Non sarai comunque corretto, ma sarai corretto dopo un minuto come dopo un'ora.

Se invece parlassi delle storie degli utenti , suggerirei di mettere le parti interessate in una stanza e di dedicare cinque minuti a fare domande prima di effettuare una stima.

Indipendentemente da ciò, non perdere molto tempo a fare stime. Non sono abbastanza utili o precisi da valere lo sforzo.

Nella mia esperienza, una delle linee guida "sì, che funzionano davvero" di un approccio agile è la linea guida "I compiti dovrebbero richiedere meno di un giorno". Se stai valutando cose che richiedono più di un giorno, sarai abbastanza lontano.

Una volta che li hai suddivisi in modo da poterlo fare, hai fatto abbastanza; indipendentemente da ciò che sono veramente.

Nella metodologia agile della mischia, Planning Poker è visto come un modo efficace di utilizzare l'intero team per stimare rapidamente lo sforzo richiesto per le storie degli utenti in uno sprint (supponendo che questo sia ciò di cui stai parlando). Altrimenti, non passerei più di qualche minuto a stimare una singola attività che fa parte di una user story.

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 abbastanza buone per ogni singolo utente in una singola sessione (non più di 1-2 ore).

Leggete un po 'su questo e provatelo!

Inoltre, come regola generale, nessuna attività in una user story dovrebbe superare le 7,5 ore (un singolo giorno di lavoro). In tal caso, è necessario suddividere l'attività in attività più piccole.

Penso che dipenda da ciò di cui hai bisogno. Se, ad esempio, l'allocazione delle risorse del tuo progetto dipende da esso (come accadeva a volte qui), è meglio farlo con attenzione. Altrimenti, se stai realizzando un progetto che non ha questo tipo di necessità, potresti non entrare troppo nei dettagli. Trascorrere troppo tempo non è una buona idea perché fare una stima accurata è molto difficile.

C'è un famoso concetto chiamato Cone of Uncertainty e Cone of Uncertainty su Wikipedia che dice quanto può essere accurata una stima di solito. Vale la pena leggere.

Cosa ottieni dai tuoi preventivi?

A seconda di ciò su cui lavori, potrebbero essere rilevanti stime individuali accurate (il cliente ti paga alla fine della settimana o l'attività / la storia si blocca agli altri e è necessario un ETA preciso) oppure no (hai 200 storie nel backlog, nessuno morirà se una storia cambia per una settimana e contate sugli errori stimati per fare una media ok su un gran numero di essi).

Basta spendere il minimo tempo per ottenere un preventivo che sia abbastanza buono 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 (suddividila o pianifica la scoperta).

In realtà hai bisogno di una stima per aiutare le altre parti interessate ad assegnare una priorità relativa - quindi stime su base ampia che almeno dicono che l'attività1 è circa 3 volte lo sforzo rispetto all'attività2, (anche se in termini di ore alla fine non è molto precisa) sono utili. Trascorrere tutto il tempo necessario per capire quali sono tali compiti (per raggiungere determinati obiettivi) e quindi avere stime approssimative per essi.

Una volta che hai la priorità relativa, concentrati solo sul fare le cose e regola le stime lungo il percorso. In altre parole, dedica poco tempo alle stime iniziali, ma affina le tue stime con il passare del tempo, in modo che il piano di progetto dia una buona idea su cosa verrà fatto.

Le buone stime sono una volta basate su fatti e non su ipotesi.

Pertanto, se avevi già un progetto o progetti simili e hai acquisito il tuo tempo di stima precedente, questo potrebbe iniziare come una buona base di stima . Tuttavia, a seconda dell'ambito del progetto, potrebbero essere presenti artefatti sconosciuti , il che è meglio chiarire con BA o il proprietario del prodotto al più presto.

È anche vero che: la stima dei progetti software è intrinsecamente imprecisa . Tuttavia, esistono alcune pratiche di stima realistiche che potrebbero aiutare:

• Le persone che svolgono il lavoro dovrebbero partecipare alla stima del progetto
• Coinvolgi gli esperti: il giudizio degli esperti è fondamentale per il successo del progetto
• Stimare i pezzi di grandi dimensioni come intervallo
• Usa la tecnica Delphi: questo è un metodo che aiuta a far convergere le opinioni del team in caso di conflitto nella stima del progetto software.
• Tieni presente il costo
• Tenere presente le risorse allocate disponibili per eseguire il lavoro