2012-02-23 9 views
5

Abbiamo appena iniziato a fare scrum nella mia azienda. Passiamo un po 'di tempo a stimare lo sforzo usando la pianificazione del poker e poi, quando i compiti dettagliati vengono elaborati, viene assegnata una stima del tempo per ogni attività.Stima del tempo nelle attività

Il problema è che le stime di tempo sono costantemente errate (di solito oltre le stime). Anche se siamo tutti d'accordo su uno sforzo, far sì che una squadra sia d'accordo sul tempo per un compito è molto più difficile: ciò che richiede 1 persona all'ora potrebbe richiedere a qualcun altro 3 ore. Finiamo per andare da qualche parte nel mezzo.

Chi dovrebbe essere in arrivo la stima del tempo per un'attività e quando succede?

Questo è solo qualcosa a cui abbiamo bisogno di più pratica o stiamo sbagliando?

risposta

8

Le persone che stanno effettivamente facendo il lavoro stimano il costo. Se si utilizza il tempo grezzo come parametro per la stima, le metodologie Agile aggrottano le sopracciglia su di esso. La tua squadra dovrebbe usare un'astrazione per stimare il costo, come "punti". Puoi iniziare con una linea di base approssimativa di 1 ora per punto con un minimo di 1 punto. Quindi gli sviluppatori possono fare stime grezze di quanto tempo dovrebbe prendere qualcosa. Schiaffali o chiunque altro al polso se parlano in ore o in qualsiasi altra unità di tempo.

Il punto è che mentre lo sviluppo procede attraverso più sprint, i project manager possono aggiustare le stime del tempo "punto" fornite dal team in modo che corrispondano alla realtà - Questo può essere fatto anche per singolo sviluppatore. I partecipanti diverranno migliori e migliori con la stima man mano che i progetti progrediscono. Quindi, poiché gli Sprint sono un processo iterativo, le stime temporali migliorano con più iterazioni.

Questo fa sorgere un'altra domanda: perché sei preoccupato per il tempo? Il tempo è sostanzialmente un costo nel modello Waterfall. In Agile, l'obiettivo è lo sviluppo di software su VALUE senza costi. La ragione per cui vengono utilizzati i punti è che si tratta di una base di paragone astratta che i proprietari di imprese, i project manager e i creatori (sviluppatori) possono vedere tutti in una luce astratta. (Inequivocabile dalle percezioni culturali, sociali o psicologiche del tempo dei diversi partecipanti.) I proprietari di attività possono dare un'occhiata ai punti disponibili in un dato sprint e, conoscendo i punti disponibili, possono scegliere la funzionalità più importante. È sempre una decisione difficile, ma, ancora una volta, l'obiettivo è quello di sviluppare verso il valore e lontano dal pugilato del tempo o il riempimento delle funzionalità.

+0

Grazie per la risposta .Stiamo usando il modello agile TFS e ha Effort su un PBI/Bug, ma le singole attività hanno tempo. Tutto il burn-down avviene dal tempo. E 'solo una breve venuta del modello Microsoft? Se non impostiamo il tempo non otteniamo un burn-down per dirci come stiamo andando – Greg

+2

Come diceva, non dovresti usare il tempo grezzo per la tua stima - o meglio: non puoi usare il tempo come valore di costo in Scrum. Soluzione per il tuo problema: attenersi ai punti per gli storys, ma non stimare i singoli storytasks. Se vuoi creare il tuo burndown, conta le attività e dividi i punti storia con il conteggio delle attività - ad es., Story è 8 punti, hai 4 compiti, quindi ogni attività ha un valore di 2 punti. Se risolvi 2 compiti durante il giorno, il tuo burndown scenderà di 4 punti. –

+1

Come hai sottolineato, il tempo impiegato per un compito dipende dalla persona che ci lavora. Ma l'idea dei punti della storia è di non dipendere dalle persone. Il team è a fuoco. Quindi i punti riflettono quanto sforzo ha bisogno la squadra per realizzare questa storia. Fai lo stesso con i compiti. Se vuoi stimare lo sforzo di ciascuna attività individualmente, usa solo il punto della storia. La somma dovrebbe quindi arrotondare ai punti della storia della storia. – RaphMclee

-1

"Chi dovrebbe venire con la stima del tempo per un'attività e quando succede?" Dipende da come gestisci la tua squadra. Consenti ai membri del team di autogestirsi veramente, quindi le attività vengono assegnate quando una persona la afferra durante lo sprint? Potrebbe essere necessario continuare a utilizzare il tempo necessario per completare in base alle capacità di uno sviluppatore medio del team. Hai un team leader che assegna i compiti alle persone così come sono state create durante la riunione di Sprint Planning? Lascia che la persona assegnata stimino il tempo per completare l'attività.

Accetto che rimuovere il tempo dalla stima dello sforzo sia un po 'confuso. La grande domanda è: cosa importa che tu stia sopravvalutando il tempo di attività? La squadra è in giro per 4-5 giorni alla fine di uno sprint con niente da fare? In tal caso, vai al proprietario del prodotto e informalo che il team desidera aggiungere uno o due piccoli articoli nello Sprint. Normalmente non aggiungi roba a uno sprint in corso, ma Scrum è un framework per gestire il lavoro, e fintanto che il team si firma per aggiungere nuovi elementi, non è necessario che Scrum funzioni per il tuo team ... non forzare la tua squadra a lavorare per Scrum.

Inoltre, le tue domande sembrano indicare che la tua squadra ha una velocità maggiore di quella pianificata. Se il tuo sprint di 2 settimane (10 giorni lavorativi) ha una velocità di 10, ma il tuo team sta finendo di tutto entro il giorno 7, imposta i tuoi punti storia sul prossimo sprint a 11 o 12.

+0

Vorrei sapere perché la mia risposta non è stata votata. –