Come gestire le stime per i programmatori che si uniscono al team?

11

L'iterazione è già iniziata, il nuovo programmatore si unisce al team, l'attività X è già stata stimata in 30 ore da uno sviluppatore diverso.

Qual è la migliore pratica in questa situazione?

  • il nuovo sviluppatore gira con la stima data (l'idea è che qualsiasi discrepanza verrà corretta per quando viene calcolata la velocità?)
  • nuovo compito di ri-stima dello sviluppatore? (se sì, cosa succede se è significativamente più alto e non si adatta più all'iterazione?)
  • alza le mani e torna alla cascata?
  • qualcos'altro interamente?
posta Jeremy Heiler 19.06.2012 - 15:57
fonte

3 risposte

4

Quello che dico è:

Il nuovo sviluppatore ri-stima l'attività. Se deve essere spostato fuori dall'iterazione, viene rimosso.

Non sai se il nuovo sviluppatore sarà in grado o meno di farlo nel tempo in cui lo sviluppatore originale ci vorrà. E con metodologie agili è lo sviluppatore che fa il lavoro quello che dovrebbe dire quanto tempo ci vorrà.

Inoltre, applicherei un moltiplicatore (quanto grande a seconda dello sviluppatore), poiché lo sviluppatore deve inserirsi nel team / progetto / azienda.

    
risposta data 19.06.2012 - 16:25
fonte
15

Non aggiungerei questa persona a questo singolo sprint. Dagli invece un altro compito su cui lavorare per essere aggiornato sulla base di codice (forse alcuni bugaggi a bassa risoluzione?).

L'aggiunta di una nuova persona al team rallenterà probabilmente i tuoi progressi su questo particolare obiettivo, poiché dovrà abituarsi al tuo ambiente e imparare come funzionano le cose lì. Incorporalo nello sprint next , con stime appropriate basate sul nuovo team.

    
risposta data 19.06.2012 - 16:23
fonte
6

Prima di tutto, sento "Agile Task" e penso che il lavoro da uno a due giorni, non una settimana. I compiti sono ciò in cui infrangi le storie quando la storia stessa si inserisce nell'iterazione, ed è una vera rarità avere una storia che non può essere scomposta in parti più piccole.

In secondo luogo, stai sostanzialmente chiedendo a questo nuovo sviluppatore di andare a fondo. Se si può ragionevolmente aspettarsi di saltare a destra e mantenere il ritmo del resto della squadra, allora la stima originale dovrebbe valere. Se non può, probabilmente non dovrebbe essere tenuto a questa stima, almeno non da solo.

Terzo, qual è la situazione? Sono abbastanza sicuro che la situazione non fosse che il team stimava il loro lavoro, poi qualcuno è uscito e tu lo hai sostituito il giorno dopo. Quindi, penso che X ragazzi del team stimino il lavoro di questo sprint e abbiano preso ciò che pensavano di poter gestire, e poi hai introdotto il nuovo ragazzo e ora ci sono X + 1 ragazzi a fare il lavoro inizialmente impegnato da X ragazzi . A meno che il team non abbia scelto il proprio carico di lavoro e invece il backlog fosse pieno zeppo di dirigenti, non darei molto al nuovo ragazzo per questa settimana. Se la pianificazione è stata impostata dalla direzione, non è Agile.

Personalmente, avrei impostato questo ragazzo per accoppiarlo con un programmatore più esperto per il suo primo sprint (se i tuoi programmatori non si accoppiano in continuazione, cosa che non sto dicendo per il fatto che tu sia considerando di dare un compito a un ragazzo). Guardando da sopra la sua spalla e facendo domande, inizierà a imparare la base di codice, e se la sua abilità di programmazione generale è all'altezza, sarà un efficace revisore di codici quasi immediatamente, individuando bug, codice inefficiente, ecc.

    
risposta data 19.06.2012 - 16:40
fonte

Leggi altre domande sui tag