Chi dovrebbe partecipare alla stima del tempo?

In un progetto IT:

1. Chi dovrebbe partecipare alla stima del tempo? Sviluppatore, team leader, scrum master ed ecc?
2. Di chi dovrebbe essere il maggior numero di voti ?

Non si tratta tanto delle persone coinvolte quanto delle competenze che devono essere presenti:

• Una buona conoscenza del dominio problematico - 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 relativo alle classi di biglietti su un aereo e presumerà che ce ne siano 3 o 4 (economia, affari, prima ecc.) Ma se hai lavorato in viaggio saprai che ce ne sono dozzine. Ciò può significare che è coinvolto un analista aziendale o un utente esperto, anche se nel tempo gli stessi sviluppatori svilupperanno questo tipo di conoscenza.

• Comprensione della tecnologia e del lavoro che sarà coinvolto - di solito uno sviluppatore, sebbene un manager con esperienza recente che abbia la fiducia del team, spesso può fare il lavoro. Idealmente, però, ottieni la persona che effettivamente svolgerà il lavoro in quel modo in cui vengono acquistati nel preventivo.

• Comprensione del processo di stima: questa è la chiave. È necessario comprendere come fare una stima decente, come assicurarsi che sia corretta, controllare i livelli di contingenza appropriati, verificare il doppio conteggio o il riempimento eccessivo. 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.

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

Detto questo, generalmente cercherò più di due persone, poiché si desidera avere la certezza aggiuntiva che due o più persone che si controllano a vicenda lavorano.

Per quanto riguarda il 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, deve spiegare perché e sfidare (non esercitare pressioni) lo sviluppatore per giustificarlo e devono raggiungere un consenso. Nel caso in cui non sia possibile raggiungere tale accordo, direi due cose per esperienza:

(a) Non andare con il numero che "vuoi", sta solo chiedendo problemi e ciò che vuoi non ha alcun impatto materiale sulla velocità con cui il lavoro può essere svolto.

(b) In quasi tutti i casi in cui ho visto dove uno sviluppatore è stato sovrastato in base a una stima, il numero finale è risultato più vicino a quello che pensava lo sviluppatore rispetto a chiunque li sovrastasse, in gran parte perché hanno ignorato il punto (a) sopra.

(Detto questo 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 c'è una risposta unica per tutti a questa domanda. Dove lavoro, di solito ci sono due ingegneri del team che implementeranno la funzione / correzione che forniscono un preventivo. Quindi due ingegneri forniscono ciascuno una stima "min", "max" e "prevista". Di solito ci aspetteremmo che entrambe le stime siano ragionevolmente coerenti, quindi se sono selvaggiamente diverse, potrebbero essere necessarie ulteriori discussioni (forse un ingegnere aveva ipotizzato che l'altro no, ecc.).

Nella nostra situazione, il "voto" di nessuno è conteggiato come tale. Generalmente calcoliamo solo una media delle due stime (ricordate, se non sono già nello stesso campo di gioco, quindi rifiutiamo entrambe e ricominciamo da capo con le discussioni, quindi prendere la media non è un grande salto). Le stime sono solo stime, dopotutto, quindi non devono essere esatte .

Nella mia esperienza, le stime tendono ad essere fatte dalla persona che molto probabilmente farà il compito da sola. I team di SCRUM dovrebbero sforzarsi di essere interfunzionali, ma dopo un po ', alcuni tipi di compiti vengono generalmente svolti dalle stesse persone.

Di vitale importanza è ottenere un'accettazione dal team su tutte le stime. Se uno sviluppatore ritiene di possedere un preventivo, lavorerà per soddisfarlo. Se gli sviluppatori ricevono una stima del fatto che non si sono comportati da soli e non hanno avuto alcun input o influenza, non sentiranno lo stesso livello di responsabilità nei suoi confronti e gli scoperti verranno spiegati con "Te l'avevo detto che ci sarebbe voluto più tempo".

Un progetto ha requisiti aziendali e scadenze provenienti dall'alto verso il basso. Quelle sono "stime fornite" per la prima iterazione.

Questi requisiti devono essere partizionati per le attività più grandi con un costo noto al 100% (come "abilita registrazione" = 2 ore = "scarica log4j / SLF4J e collega").

La stima dovrebbe essere effettuata al più alto livello possibile che dispone già di competenze tecniche sufficienti per farlo.

Le stime corrette devono risalire sotto forma di "caratteristica visibile dall'azienda" = "questa quantità di tempo" fino a quando raggiungono il proprietario dell'azienda a un livello adeguato, in grado di eliminare / modificare i requisiti o di allentare le scadenze. Quindi tornare indietro. Fino alla convergenza finale. In pratica, le persone tendono a ignorare questa fase o a 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, team leader, scrum master ed ecc?

Preferisco che tutti ci fossero nella stima del tempo e facciamo lo stesso qui

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

Lo sviluppatore, ma è ancora tutto basato sul lavoro di gruppo

GLI SVILUPPI INCARICATI DELL'ATTUAZIONE DEL PROGETTO! NESSUN ALTRO!

Gli sviluppatori che fanno le vere mani sul lavoro e i leader del team di sviluppo sono gli unici in grado di stimare correttamente quanto tempo ci vorrà davvero. Solo i programmatori che hanno familiarità con la base di codice attuale possono comprendere le potenziali difficoltà e insidie ​​che possono essere incontrate nel corso dello sviluppo. Tutti gli altri sono "spettatori".

Inoltre, l'unico modo in cui gli sviluppatori possono fidarsi di fornire stime accurate è quando gli uomini d'affari si fidano di loro e fanno affidamento sulla loro esperienza in modo tale che gli sviluppatori sappiano che non saranno penalizzati se la loro stima non soddisfa le aspettative dell'azienda.

Regola empirica: ci vorranno almeno 3 volte il tempo necessario per la stima di qualsiasi project manager o uomo d'affari che non abbia familiarità con le sfide dello sviluppo manuale e della base di codice in questione.

Come qualcuno che ha lavorato come sviluppatore sia come libero professionista che come impiegato in grandi aziende per quasi 20 anni, lo dico con la massima certezza e il beneficio di una grande esperienza amara.