Informazioni sul valore delle stime Sforzo e usabilità

-2

Abbiamo discusso del valore reale della stima dello sforzo (EE) per le attività di sviluppo SW, e mi piace ricevere un feedback dalla comunità.

Le principali domande in mano sono:

  • Il team di R & D dovrebbe fornire la stima dello sforzo per le attività di R & D?
  • Puoi imparare e migliorare in EE, estrapolando dall'EO dell'attività A rispetto al tempo di sviluppo effettivo, per eseguire l'EE di B?

Le persone che supportano EE (e rispondono "sì" alle domande precedenti) danno questi motivi :

  • devi avere una specie di EE per pianificare le prossime attività / sprint

  • se sai che l'attività è piccola / grande, puoi decidere se ti piace svilupparla o meno

  • se si stima il task A in X e ci sono voluti 3X, si sarà in grado di estrapolare meglio la stima del task B e migliorare la velocità / accuratezza / ...
  • Uno sviluppatore dovrebbe avere una sorta di periodo di tempo per l'attività su cui sta lavorando

Le persone che non supportano EE (e rispondono "no" alle domande precedenti) danno questi motivi :

  • Quasi ogni EE è una pura ipotesi. Ci sarà appena una relazione tra l'EE e la realtà.

  • Le attività di sviluppo sono in genere molto uniche e non è possibile estrapolarle dall'attività A di E per eseguire l'EE di B.

  • Se un'attività è necessaria, dovrebbe essere data la priorità e fatta, indipendentemente dal tempo che impiegherà.

  • EE si trasformano rapidamente in impegno e accuse. "hai detto che ci vorrebbe 1 settimana, ma ci sono voluti 1 giorno / 1 mese"

  • L'unico dipartimento dell'organizzazione a cui viene chiesto di fornire EE è R & D. Di solito, il prodotto non è EE il tempo necessario per scrivere le specifiche.

  • EE sembra essere un altro modo per dire "R & D sono un gruppo di fannulloni e solo se diamo EE, finiranno le attività in un tempo ragionevole"

Non sono sicuro che ci sia una risposta giusta / sbagliata a queste domande, ma mi piace ricevere un feedback dalla community.

    
posta riorio 10.10.2018 - 16:39
fonte

1 risposta

1

Should R&D team provide effort estimation to R&D tasks?

Sì, mi sembra una parte naturale del processo di decomposizione dei problemi.

Can you learn and get better at EE, by extrapolating from task A's EE vs. actual development time...

Sì, ogni sviluppatore che pensa ai problemi e al modo in cui si decompongono può migliorare in questo modo.

Se non esercitiamo la decomposizione e la stima dei problemi, non miglioreremo. Ogni sviluppatore che effettua una stima potrebbe tenere un registro o un diario su ciò che ha sottovalutato: se la decomposizione del problema non è andata a buon fine, la scomposizione del problema non è stata sufficientemente approfondita o più difficile del previsto (API esterna scarsamente documentata / compresa, nuova tecnologia con curva di apprendimento più ripida), o, forse, problemi di processo / metodologia, divario di competenze nella squadra, mancanza di attrezzature, debito tecnico (codice spaghetti), test di regressione insufficienti, ecc. Fare stime - e tenere traccia di come facciamo / abbiamo fatto e perché - rappresenta un'opportunità: grist per il mulino di miglioramento continuo. Le lezioni possono essere condivise nelle retrospettive!

...by extrapolating from task A's EE vs. actual development time, to task B's EE?

Alcuni sviluppatori sono molto più bravi di altri (e alcuni molto peggio), quindi c'è molta differenza nella qualità di queste stime. A causa di questa realtà, non dovremmo davvero aspettarci di poter dedurre qualcosa dall'accuratezza della stima di A alla precisione di stima di B. Nel migliore dei casi, miglioriamo l'accuratezza di ogni individuo, e il capo squadra può ottenere una nozione di accuratezza individuale e come combinare insieme le stime.

Le stime sono ipotesi istruite . Nessuno dovrebbe prendere una stima come garanzia o impegno - è una stima! Se qualcuno vuole un impegno, non usare la parola stima.

    
risposta data 10.10.2018 - 20:03
fonte

Leggi altre domande sui tag