Come gestire i programmatori anomali durante la pianificazione dello sprint?

Question

Come gestire i programmatori anomali durante la pianificazione dello sprint?

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)

6

È generalmente accettato che i migliori programmatori producono almeno un ordine di grandezza superiore a quelli medi . Sembra che ciò potrebbe causare problemi con i soliti approcci alla pianificazione dello sprint incentrati sulle metriche dell'intero team, principalmente sulla stima e la velocità.

Per stima, è probabile che il grande programmatore voti diversamente rispetto a quello medio. Idealmente, il team sta usando i punti storia, quindi i programmatori sono più propensi ad accettare la "relativa complessità" di una storia, ma anche lì, il grande programmatore ha più probabilità di conoscere uno strumento / trucco che permetterà loro di semplificare problema. Generalmente, la squadra vota nel suo insieme e vince in media / maggioranza. Questo risolve la stima imprecisa - a meno che il grande programmatore non raccolga quella storia.

"Ma non importa!" Ho sentito dire "Il grande programmatore ottiene solo più punti storia per sprint". Il che ci porta al problema n. 2. Le velocità sono molto spesso misurate per l'intera squadra, non le persone per aiutare a livellare le differenze dallo sprint allo sprint. La velocità viene quindi utilizzata come una sorta di velocità per tenere conto delle vacanze, degli orari delle riunioni, ecc. Il problema deriva dal fatto che il grande programmatore influisce in modo sproporzionato sulla velocità della squadra. Se sono in vacanza, molto meno lavoro sarà fatto del previsto dai calcoli di velocità. Se un programmatore medio è in vacanza, verrà eseguito più lavoro del previsto dai calcoli di velocità.

Quindi come affrontare questo tipo di ingiustizia nelle prestazioni durante la pianificazione dello sprint? Una sorta di effetto di ponderazione? Lascia che gli errori si verifichino e si uniformino nel tempo?

management estimation sprint

posta Telastyn 25.06.2015 - 20:35

fonte

3 risposte

Leggi altre domande sui tag management estimation sprint

Test delle unità eloquente al di fuori di Laravel Ricerca di opinioni sull'utilizzo dell'albero del dispositivo per la definizione I / O

score 3 · Answer 1

La stima (ad esempio i punti storia) viene effettuata in base al tempo e all'impegno di un programmatore tipico. Quando si calcola la velocità, si passa da una squadra di programmatori tipici. Questo viene fatto per diversi motivi:

Gli alti e i bassi dovrebbero uscire di livello medio. Forse hai una rockstar, ma le probabilità sono che hai anche un dragone. O due programmatori sotto la media ma non terribili.
A volte i migliori sviluppatori vengono a volte falsificati. Ho visto fantastici programmatori impiegare metà del tempo in ogni attività, quindi colpire quel muro di mattoni dove un'attività di 4 ore richiede tre giorni. Forse è stato a causa di una difficoltà imprevista, forse lo sviluppatore stava attraversando problemi personali, forse è venuto a lavorare sospeso. Chissà. Succede.
La velocità può cambiare in base agli sprint precedenti. Se conosci puoi fare più di quanto pensi, forse dovresti pianificarlo (ma non necessariamente, vedi il mio prossimo punto).
Niente di tutto questo è importante, perché se vai avanti puoi sempre inserire storie dal backlog e anticipare il programma.

Continua a fare quello che stai facendo e il tuo altro problema non ha importanza. Se la tua rockstar rappresenta il 20% delle ore della tua squadra ed è in vacanza, pianifica il 20% in meno di punti in questa sprint. Finché non stai gonfiando la tua velocità, ciò compenserà automaticamente.

La chiave qui è che non stai solo osservando ogni iterazione in isolamento, ma pianificando l'intero progetto di una iterazione alla volta per aiutare a compensare le irregolarità che inevitabilmente si verificano.

score 0 · Answer 2

Tutti gli sprint non vengono creati uguali e i grandi programmatori hanno influenza al di là della propria tastiera.

Questo è solo un problema se ti aspetti che tutti gli sprint abbiano la stessa quantità di lavoro completata. Se tutti sono presenti i primi 5 sprint, alla fine dovrai adeguarti quando qualcuno se ne va e, soprattutto, il miglior sviluppatore.

I grandi programmatori sfruttano la loro esperienza in un determinato progetto ben oltre il codice reale che scrivono. Influenzano altri membri del team e la progettazione generale del progetto. Alcuni di questi vengono nascosti in un progetto. Come misurate tutte le cose che il team ha deciso di "non" fare a causa dell'esperienza del programmatore migliore?

Nel corso del tempo, potresti scoprire questo basso livello di produttività quando il tuo programmatore migliore è assente. Oltre a confermare la tua valutazione di questa persona, cos'altro hai guadagnato oltre a un paio di sprint all'anno, avrai meno risultati.

score 0 · Answer 3

Penso che la migliore risposta onestamente sia che non c'è un buon modo per spiegare questo. È una specie di situazione "non c'è cucchiaio", però. Questo è solo veramente un problema se stai mettendo più peso alla velocità di quello che effettivamente detiene. La velocità è una stima del numero di punti storia che una squadra può fare in uno sprint. I punti storia sono una stima dello sforzo richiesto, che si basa su precedenti stime di sforzo per ciò che si stima siano compiti simili. In altre parole, è una stima di una stima di una stima di una stima, ed è praticamente esattamente quello che ti ha urlato il tuo insegnante di matematica della scuola elementare quando hai introdotto errori di arrotondamento in una serie di calcoli.

Il lungo e corto è che la velocità è meglio che avere nessuna idea , ma francamente non molto. Puoi usarlo per prevedere le date di completamento, perché alla gestione piacciono le date difficili, ma sarà sempre solo una previsione e se hai mai portato con te il tuo ombrello tutto il giorno nel giorno più soleggiato di sempre , sei pienamente consapevole che le previsioni sono spesso sbagliate. Se si finisce con il lavoro avanzato alla fine dello sprint, va bene . Potrebbe essere un concetto pazzo, ma è qualcosa che puoi coprire nella retrospettiva e imparare da una stima migliore in futuro. Il team non ha fallito ; erano appena fuori le loro previsioni. Se si esaurisce il lavoro prima che lo sprint sia finito, è sempre possibile semplicemente inserire altri elementi del backlog. Solo perché non pensavi di avere la capacità, non significa che devi solo fermarti quando lo sprint backlog è vuoto. Tratta la velocità come misura fragile, e non preoccuparti per questo.