Chi dovrebbe partecipare alla stima del tempo?

Non sono tanto le persone coinvolte quanto le abilità che devono essere presenti:

• Una buona conoscenza del dominio del problema - questo è particolarmente importante quando i requisiti sono ambigui o di alto livello. Come programmatore che non ha mai lavorato in viaggio per stimare il lavoro riguardante le classi di biglietti su un aereo e presumerà che ci siano 3 o 4 (economia, affari, prima ecc.) Ma se hai lavorato in viaggio saprai che ce ne sono dozzine Ciò può significare che un analista di affari o un utente esperto è coinvolto, anche se nel tempo gli sviluppatori stessi accumuleranno questo tipo di conoscenza.

• Comprensione della tecnologia e del lavoro che sarà coinvolto - di solito uno sviluppatore, anche se un manager con esperienza recente che ha la fiducia della squadra può spesso fare il lavoro. Idealmente, però, otterrai la persona che effettivamente eseguirà il lavoro nel modo in cui sono stati acquistati nella stima.

• Comprensione del processo di stima: questa è la chiave. Ci deve essere una comprensione di come fare una stima decente, come assicurarsi che sia giusto, verificare i livelli appropriati di contingenza, verificare il doppio conteggio o troppa imbottitura. Solitamente un PM, un responsabile dello sviluppo o uno sviluppatore senior lo porteranno, sebbene in alcuni processi un solido modello di stima possa fornire la guida necessaria.

Quelle abilità possono essere in una sola persona, anche se a volte ne avranno bisogno tre o più, ma la cosa fondamentale è assicurarsi che quelle abilità siano presenti, non che siano presenti persone particolari.

Detto questo, in generale, anche se cercherò più di due persone come desideri, la garanzia aggiuntiva che due o più persone si controllano a vicenda porta il lavoro.

Nei termini del cui voto viene conteggiato di più, non funziona così. È una discussione e una negoziazione. Se un manager ritiene che la stima degli sviluppatori sia troppo alta, ha bisogno di spiegare perché e sfida (non la pressione) lo sviluppatore a giustificarlo e devono raggiungere un consenso. Nel caso in cui non si riesca a raggiungere quell'accordo, direi due cose per esperienza:

(a) Non andare con il numero che "vuoi", è solo chiedere dei guai e ciò che vuoi non ha alcun impatto materiale sulla rapidità con cui il lavoro può essere svolto.

(b) In quasi tutti i casi in cui ho visto dove uno sviluppatore è stato dominato su una stima, il numero finale è venuto più vicino a quello che pensava lo sviluppatore di chiunque altro li avesse giudicati - in gran parte perché ignoravano il punto (a) sopra.

(Ciò detto in agile credo, e certamente in XP, la regola è che gli sviluppatori controllano le stime e questo è definitivo. Se gli utenti vogliono abbassare le stime devono cambiare il requisito per qualcosa di più semplice.)

Non so se esiste una risposta valida per tutti a questa domanda. Dove lavoro, di solito ci sono due ingegneri del team che implementeranno la funzione / correzione che fornisce una stima. Quindi due ingegneri forniscono ciascuno una stima "min", "max" e "prevista". Normalmente ci aspettiamo che entrambe le stime siano ragionevolmente coerenti, quindi se sono molto diverse, potrebbe essere necessaria un'ulteriore discussione (forse un ingegnere ha fatto delle ipotesi che l'altro no, ecc.).

Nella nostra situazione, il "voto" di nessuno è considerato come tale. Generalmente calcoliamo solo le due stime (ricordate, se non sono già nello stesso ballpark, quindi le rifiutiamo entrambe e ricominciamo le discussioni, quindi prendere la media non è un grande salto). Le stime sono solo stime, dopo tutto, quindi non è necessario essere exact .

Nella mia esperienza, le stime tendono ad essere fatte dalla persona che molto probabilmente farà il compito stesso. I team SCRUM devono sforzarsi di essere interfunzionali, ma dopo un po 'di tempo alcuni tipi di attività vengono solitamente svolti dalle stesse persone.

Di vitale importanza è ottenere un consenso dal team su tutte le stime. Se uno sviluppatore ritiene di possedere una stima, lavorerà per soddisfarlo. Se gli sviluppatori ricevono una stima che non hanno fatto da soli e non hanno avuto alcun input o influenza, non sentiranno lo stesso livello di responsabilità e gli scoperti saranno spiegati con "Ti ho detto che ci sarebbe voluto più tempo".

Un progetto ha requisiti aziendali e scadenze dall'alto verso il basso. Quelli sono "dati stimati" per la prima iterazione.

Questi requisiti devono essere partizionati per le attività più importanti con il 100% di costo noto (come "abilita la registrazione" = 2 ore="download log4j / SLF4J e plug-in ").

La stima dovrebbe essere fatta al più alto livello possibile che abbia già abbastanza competenze tecniche per farlo.

Le stime corrette devono tornare indietro sotto forma di "business visible feature"="questo lasso di tempo" fino a quando raggiungono il proprietario dell'azienda ad un livello appropriato, in grado di eliminare / modificare i requisiti o di allentare le scadenze. Quindi torna giù. Fino alla convergenza finale. In pratica, le persone tendono a ignorare questa fase oa semplificarla, il che a sua volta può creare rischi associati a scadenze e opportunità mancate.

Chi o chi dovrebbe partecipare alla stima del tempo? Sviluppatore, capo squadra, scrum master ed ecc.

Preferisco che tutti siano presenti nella stima del tempo e facciamo lo stesso qui

Chi o il cui voto dovrebbe essere conteggiato di più?

Lo sviluppatore, ma continua a lavorare sul team di nuovo

GLI SVILUPPATORI IMPEGNATI DI REALIZZARE IL PROGETTO! NESSUNO!

Gli sviluppatori che fanno le vere mani sul lavoro ei leader del team di sviluppo sono gli unici in grado di stimare correttamente quanto tempo impiegherà veramente. Solo i programmatori che hanno familiarità con la base di codice effettiva possono comprendere le potenziali difficoltà e insidie che potrebbero verificarsi nel corso dello sviluppo. Tutti gli altri sono "spettatori".

Inoltre, l'unico modo in cui gli sviluppatori possono essere considerati attendibili per fornire stime accurate è quando gli uomini d'affari si fidano di loro e fanno affidamento sulle loro competenze in modo tale che gli sviluppatori sappiano che non saranno penalizzati se la loro stima non soddisfa le aspettative del business.

Regola empirica: ci vorranno almeno 3 volte il tempo che la stima di un project manager o di un uomo d'affari non conosce intimamente le sfide dello sviluppo delle mani e della base di codice in questione.

Come qualcuno che ha lavorato come sviluppatore per le mani sia come free-lance che come impiegato nelle grandi aziende per quasi 20 anni, lo dico con la massima sicurezza e il beneficio di una grande quantità di esperienza amara.