Che cosa fai alle stime per storie agili in cui gli sviluppatori sono in coppia?

Per come la capisco, un punto della storia è una stima di sforzo relativo , non delle ore di lavoro. Lo sforzo richiesto per una storia non cambierà solo perché una coppia ci sta lavorando, quindi non ha senso che i punti della storia cambino ...

Inoltre, la velocità deriva dalla cronologia di ciò che è stato fatto negli sprint precedenti. Se si accoppiano alcune storie e non altre, nel tempo la velocità media rifletterà la capacità media dello sprint, tenendo automaticamente conto delle abitudini di abbinamento della propria squadra. Non è necessario regolare manualmente le stime di sprint in base a quanto pensi di accoppiare in determinate attività il prossimo sprint.

In effetti, sono questi schermaglie manuali che molto spesso causano il deragliamento degli sforzi di scrum, perché nessuno si fida più delle "stime", a causa di tutti i "giochi" dei numeri.

TL; DR

I punti storia sono stime dello sforzo per la squadra nel suo insieme per spostare una storia da "iniziato" alla "definizione di fatto". Se le storie non coinvolgono più set di abilità o coinvolgono più persone, probabilmente hai un'attività piuttosto che una storia.

I punti storia non sono stime uomo-ora

I punti storia sono una misura dello sforzo relativo:

  If FOO is a baseline 2-point story
 And BAR is roughly twice as much work
Then BAR is a 3-point or 5-point story.

In Scrum, in genere si vede il Product Backlog stimato in punti storia, sebbene l'opinione sia spesso divisa sul fatto che le singole attività debbano essere stimate sullo Sprint Backlog. Quando si valutano le attività di Sprint Backlog, si possono certamente utilizzare le ore ideali piuttosto che i punti della trama, ma anche così le stime sono generalmente per il tempo di orologio a muro piuttosto che per le ore di lavoro.

I team di mischia usano caselle temporali auto-organizzate

Le stime uomo-ora sono solitamente un "odore del progetto" che una squadra non è completamente auto-organizzante. Un team Scrum efficace è agile proprio perché consente ai team di spostare le risorse da un'attività all'altra secondo necessità, all'interno di ogni sprint.

Se il team utilizza la programmazione delle coppie, o se una storia richiede che più membri del team sciamano su compiti specifici, allora il team dovrebbe considerare queste cose sia nelle loro stime di story-point sia nella loro Sprint Planning. Durante lo Sprint Planning, il team Scrum rimuove ogni storia dal Product Backlog, lo stima e quindi cerca di determinare se la storia si adatta allo sprint corrente.

Lo sforzo di squadra richiesto per raggiungere la "definizione di fatto" tende ad essere uno strumento più accurato per questo tipo di valutazione rispetto alla misurazione delle ore di lavoro. Tuttavia, il team deve utilizzare le metriche che portano al maggior successo per il progetto.

In generale, la chiave è lasciare che gli esecutori delle attività (ad esempio il team di sviluppo) eseguano la stima. Le stime uomo-ora tendono ad essere uno strumento di budgeting imposto dal processo di stima del team dall'esterno, piuttosto che fornire una tecnica di stima efficace per un processo time-boxed. Scrum si basa sul time-boxing, non sulla fallacia di utilizzo del 100% , quindi è probabilmente meglio evitare tecniche progettate per misurare l'utilizzo fin dall'inizio.

Ogni team e ogni progetto sono diversi, quindi il tuo chilometraggio potrebbe sicuramente variare.

Come già affermato nell'altra risposta, le storie sono generalmente stimate in dimensioni relative. Quindi non dovrebbe fare alcuna differenza.

Forse il fatto che pensi di aver bisogno di accoppiare storie specifiche dimostra che hanno un diverso livello di complessità rispetto agli altri e dovrebbero prendere in considerazione un maggiore sforzo nella loro stima.

La tua squadra non sembra convinta del valore della programmazione della coppia, come dici nei commenti. Dovresti pensare a come lo cambieresti. Considera di fare una prova esclusivamente usando la programmazione di coppia e una senza. Certo, non sarà decisivo, ma dovrebbe aiutare il tuo team a capire meglio.

Trovo che TDD aiuti davvero a facilitare la programmazione delle coppie. Il metodo di fornire un test per primo aiuta le coppie a decidere facilmente il loro obiettivo.

Ho trovato che la programmazione non in coppia (con TDD) era una falsa economia. Abbiamo avuto una velocità maggiore fino a quando un accumulo di bug nascosti ci ha portato ad abbattere e non fornire nulla a causa della necessità di correggere i bug.

Quando eseguiamo l'accoppiamento programmato, la nostra velocità è stata del 15% più lenta, ma alla fine di ogni rilascio abbiamo completamente eliminato una classe di bug. Era più prevedibile.

Fare una programmazione di coppie con TDD richiede disciplina. E sappiamo tutti che essere disciplinati è difficile e la tua squadra potrebbe non volerlo ma poi devi convincerli.

Per dare seguito a questo ....

Ho incontrato un consulente di mischia la settimana scorsa e ho fatto questa stessa domanda su di lui - la sua risposta è stata che non dovrebbe cambiare il modo in cui stimate i punti della storia. Se accoppi la programmazione su una storia, l'aspettativa è che stai facendo un livello di programmazione delle coppie su molti / tutti i racconti, quindi qualsiasi sforzo di over / under nella manodopera dovrebbe uniformarsi nel tempo e non dovrebbe influenzare la velocità.