Quindi, hai un progetto con una squadra in continua evoluzione e il tuo capo vuole che gli dia una stima accurata di quanto tempo ci vorrà? Puoi farlo, purché tenga presente la differenza tra precisione e precisione. La precisione dipenderà in gran parte dal numero di oggetti e dalla granularità (scomposta) di ciascun oggetto; più oggetti hai, più la Legge dei grandi numeri funziona per te, calcolando una media di sottovalutazioni e sottostime.
La precisione è una funzione di fiducia. Si noti che le stime non sono valori a punto singolo, sono un intervallo con numeri con una percentuale di confidenza. Per esempio, una stima corretta non sarebbe "2 settimane", sarebbe "50% di confidenza di 2 settimane, 80% di confidenza di 4 settimane".
Se fossi la persona assegnata con il non invidiabile compito di fornire una stima per il completamento di un progetto gestito come arbitrariamente come nel post originale, mi piacerebbe provare a capire un intervallo in base al numero minimo di persone assegnate (ad esempio, "da 48 a 66 settimane con 2 sviluppatori [dal 50% all'80% sicuro]") e un intervallo associato al numero medio di persone assegnate (ad esempio, "da 25 a 45 settimane con 5 sviluppatori [dal 50% all'80% fiducioso] "), e usa la cifra bassa del numero medio insieme alla cifra alta del numero minimo (ad esempio," da 25 a 66 settimane date da 2 a 5 sviluppatori [dal 50% all'80% sicuro "), e anche allora avrei inserito un disclaimer ("più il 10% per il tempo perso a causa del cambio di contesto").
Meglio ancora, spiegherei esattamente perché questo accordo è stato, per essere educato, non ottimale, e perché il multi-tasking è un segnale primario sulla strada per progettare l'inferno.
Come suggerito da altri, la modifica del flusso di lavoro da basata su iterazione a basata su flusso (Kanban) potrebbe essere una buona strategia. Con Kanban gestisci la modifica delle priorità del progetto modificando la priorità degli elementi nel backlog; una volta che un oggetto è stato afferrato dal team è generalmente finito (scorre attraverso il flusso di lavoro, alle parti interessate non è consentito interrompere la squadra rovinando il lavoro in corso). Ho usato Kanban per progetti di ingegneria sostenuti e ha funzionato molto bene. Per sapere come sarebbe utile con le stime, la chiave del flusso continuo è cercare di far sì che ciascun elemento di lavoro abbia approssimativamente le stesse dimensioni (1x, 2x, 3x, non 10x, 20x, 100x). È necessario tenere traccia dei movimenti degli oggetti attraverso il flusso di lavoro, rintracciando le date delle modifiche allo stato del processo, ad esempio, Coda 1/15, Design 1/22, Dev 1/24, Test 2/4, Integrazione 2/7, ecc., E quindi generando un diagramma di flusso cumulativo regolarmente per valutare le durate del tempo nello stato nel tempo. Calcolare quanto tempo il progetto dovrebbe prendere dato che si conosce la dimensione di ogni oggetto e il tempo che passa attraverso il flusso di lavoro per gli articoli è un banale esercizio computazionale lasciato al lettore.(La domanda più interessante è come individuare i vincoli ... e poi come rimuoverli Suggerimento: cercare lunghi tempi negli stati, perché il lavoro si accumula di fronte ai vincoli.)
... wiki della comunità ... – joshcomley
No, non wiki della comunità. Questa domanda avrà una risposta che funziona per wic e la sua squadra in queste condizioni. –
Sto votando per chiudere questa domanda come off-topic perché non si tratta di programmare –