Come si fa una stima del punto di una storia per una storia a cui si è solo parzialmente familiari?

Question

Come si fa una stima del punto di una storia per una storia a cui si è solo parzialmente familiari?

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

4

Sono uno sviluppatore che sta ancora imparando le complessità di un sistema software su un team di SCRUM che mi sono iscritto di recente.

Mi verrà chiesta una stima del punto storia per un pezzo di lavoro che tocca aree del sistema su cui non ho mai lavorato prima. Ho familiarità con la tecnologia utilizzata per costruire queste aree, tuttavia dovrò leggere il design / i pattern usati, parlare con altri sviluppatori e quindi eseguire alcuni test / passaggio attraverso il codice, in modo da capire come funzionano queste aree e il modo migliore per apportare le mie modifiche.

Il team ha una storia di base di 2 SP che usiamo per la stima relativa. Diciamo che il mio sforzo di stima per la nuova storia è di 12 punti, consentendo lo sforzo aggiuntivo necessario per esercitare "l'apprendimento al volo". L'altro sviluppatore stima 5 punti poiché ha familiarità con il sistema e non richiede uno sforzo di apprendimento aggiuntivo.

In questa situazione le nostre stime di sforzo sono entrambe corrette, per noi . Quindi come è risolto?

Semplicemente non so con molta fiducia quanta più fatica sarà la nuova storia, rispetto alla storia di base. 12 SP è davvero un'ipotesi, sperando solo che la storia non sia più di 6 volte lo sforzo della linea di base.

Le opzioni che posso vedere sono:

La mia stima viene utilizzata poiché sono lo sviluppatore assegnato al lavoro (a causa di risorse limitate).
Non fornisco una stima in quanto non ho esperienza / sufficiente e usiamo la stima degli altri sviluppatori.

In una nota correlata, il manager di iterazione mi ha spiegato che non usano né misurano velocità. Ho anche sentito da un altro membro del team che una storia di 13 punti è la più adatta a uno sprint (3 settimane). Che valore c'è nell'usare i punti storia per le stime in questo caso?

project-management agile scrum

posta Ash 17.12.2016 - 06:16

fonte

3 risposte

Leggi altre domande sui tag project-management agile scrum

Come dovrei segnalare più errori come risultato della convalida? Come eseguire VCS su un refactoring "atomico" su larga scala?

score 5 · Answer 1

Prima di tutto, quando valuti una storia dovresti cercare di mantenere il tempo di apprendimento il più possibile. Se ti trovi ad aumentare la tua stima a causa della non familiarità con l'area in cui la trama deve essere implementata, allora dovresti considerare quale sarebbe la tua stima se avessi l'opportunità di familiarizzare con il codice prima di iniziare con questo storia.
La ragione per cui non hai familiarità con il codice della tua stima è perché

Alla fine, devi arrivare a una stima del team, non alla stima per uno sviluppatore individuale. Ciò significa che la stima dovrebbe essere indipendente da chi finisce per lavorare sulla storia
le storie vengono spesso valutate con un certo anticipo. Non aver familiarità con il codice al momento della stima non significa che sarai ugualmente non familiarizzato con il codice nel momento in cui inizia effettivamente il lavoro sulla storia.

Il processo di stima delle storie dovrebbe essere come questo:

Dopo che tutti gli sviluppatori hanno dato la loro stima, allora le stime sono vicine o ci sono alcune stime che differiscono significativamente dalle altre.
Se le stime sono ravvicinate, puoi semplicemente stabilire una stima del team che è solo la media (o la più data) delle singole stime.
Se vi sono grandi differenze nelle stime, almeno gli sviluppatori con le stime più alte e più basse dovrebbero spiegare cosa hanno considerato nel fare le loro stime.
Alcuni motivi comuni per la stima di alto sono

vedere le complicazioni che gli altri potrebbero aver trascurato,
avere una diversa interpretazione della storia
essere incerti su ciò che è esattamente necessario
essere incerti su come realizzare la storia

Il motivo più comune per stimare i bassi è che alcune parti sono state semplicemente trascurate o che sono eccessivamente ottimistiche.

Quando si discutono le stime, l'obiettivo è garantire che tutti abbiano la stessa comprensione della storia. Nella mia esperienza, durante queste discussioni le persone inizieranno ad adeguare le loro stime e si può ottenere un consenso per le stime di un team.

score 1 · Answer 2

1

Il tuo ambito è troppo grande. Se è difficile o irrealistico fare una buona stima per la ricerca e lo sviluppo insieme, dovresti avere la parte di ricerca in sprint n e la parte di sviluppo in sprint n + 1.

risposta data 17.12.2016 - 14:13

fonte

score 0 · Answer 3

Quando faccio stime per le storie che riguardano una parte dei nostri sistemi sconosciuta per me (sono il nuovo membro del team, da poco più di un anno a questa parte) cerco di familiarizzare con il codice un po 'prima di entrare in un stima. Se questa non è un'opzione, chiedo semplicemente agli altri come questo sistema o parte di un sistema sia comparabile alle parti su cui ho già lavorato. In questo modo posso avere un'idea approssimativa di quanto sarebbe complesso modificarlo.

Le stime avranno una grande inesattezza in questo modo, ma se la complessità non può essere riassunta dagli altri sviluppatori in un paio di sentencens, direi che le stime hanno comunque una buona dose di inaccuratezza.

Se la velocità del tuo sprint è il modo, puoi sempre tornare a questa storia nella Retrospettiva e pensare a come migliorare il flusso di lavoro.

Forse aggiungi tempo per te stesso al prossimo sprint per familiarizzare con il codice che non hai ancora toccato. Mi piace scrivere alcuni test per codice che non conosco. Oppure seleziono una piccola storia e dedico un po 'di tempo in più a leggere il codice che la circonda.