Coppia la rotazione in una squadra per una programmazione efficace delle coppie

Question

Coppia la rotazione in una squadra per una programmazione efficace delle coppie

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

1

Seguiamo la programmazione delle coppie nella nostra azienda e affrontiamo sempre il tema della rotazione equilibrata ed efficace delle coppie all'interno degli sviluppatori sulle storie.

Seguiamo una metrica semplice in cui il nome di ogni sviluppatore è mappato con ogni altro sviluppatore e contrassegniamo la rispettiva intersezione ogni volta che due sviluppatori si accoppiano.

Questo non sta funzionando bene, non possiamo tenere traccia di quanto tempo una coppia ha trascorso l'abbinamento e le persone dimenticano di aggiornare le metriche molte volte. Monitorare la rotazione delle coppie è utile perché vogliamo che la conoscenza del progetto sia condivisa tra il team e non solo una coppia. Di solito, quindi, ciò che accade è che chiunque si accoppia continua ad abbinare fino a quando l'intera storia non è completata (dato che hanno un contesto migliore), e nessun altro sa di ciò che viene fatto e ampli; se la storia o un bug di regressione / produzione ritorna, la stessa coppia deve prenderlo (lasciando quello che stanno facendo attualmente), che è ciò che crea un collo di bottiglia.

Esistono metriche conosciute che possono essere utilizzate per tracciare le rotazioni della coppia.

agile pair-programming extreme-programming

posta Vivek 02.04.2014 - 19:45

fonte

3 risposte

Leggi altre domande sui tag agile pair-programming extreme-programming

Qual è il modo idiomatico per mantenere i dati in questa semplice applicazione basata sui dati? Esegui test dell'interfaccia utente codificati su diversi progetti

score 1 · Answer 1

Perché senti la necessità di monitorare la quantità di tempo che gli sviluppatori hanno abbinato l'uno con l'altro? È perché vuoi rimuovere i colli di bottiglia che hai menzionato o vuoi condividere conoscenze nel team, o perché il codice che stai rilasciando alla produzione è bacato?

Suggerirei di tenere traccia delle cose che sono importanti per voi e lasciare alla squadra il compito di seguire il modo migliore per raggiungerle.

Ad esempio, traccia ogni volta che una storia deve essere assegnata a una coppia specifica e prova a portare quel numero a zero nel tempo.

score 1 · Answer 2

Non sono sicuro che tu voglia farlo. Il tuo motivo per l'abbinamento è molto buono: condividere le conoscenze nel team, assicurandoti che più persone siano esposte a diverse parti del codice in modo da avere più persone in grado di lavorare in aree. Tuttavia, l'intera idea delle coppie di timeboxing, specialmente nel mezzo di un particolare oggetto di lavoro (una storia, un bug, qualunque cosa) non sembra una buona idea.

Spezzare una coppia nel mezzo di una storia interrompe il flusso. Hai due persone che si sono incontrate e stanno lavorando efficacemente per risolvere un problema. Nel bel mezzo di loro trovare una soluzione, implementarla e provarla, li strappi e provi a creare una nuova coppia. Questa nuova coppia deve svilupparsi come una squadra, andare sulla stessa pagina e poi continuare con il lavoro: il risultato netto è un'interruzione della produttività e della qualità.

Mi piace l'idea di creare nuove coppie, ma solo quando ha senso. Vorrei sostenere coppie che lavorano insieme per uno sprint. Per diffondere meglio le coppie, tieni traccia di chi ha fatto coppia e cerca di far lavorare insieme nuove persone. Certo, se ci sono persone che non lavorano bene insieme, potresti voler evitare quell'associazione in futuro.

Le tue preoccupazioni riguardo alla necessità di interrompere il lavoro se c'è una regressione, un bug o la storia torna indietro non ha senso per me. Questo approccio di "abbandonare tutto per risolvere un problema" non è agile. A meno che il problema non sia un problema di tipo showstopping, dovrebbe essere inserito nel backlog e priorizzato e corretto quando appropriato. Se è urgente e deve essere immediatamente affrontato, non è necessario che la stessa coppia lavori su di esso. Assegnalo a una coppia che ha qualcuno che ha conoscenza di quella parte del codice. Questo ti lascia con una persona che comprende la funzionalità insieme al design e all'implementazione e qualcuno che ora può apprenderlo mentre implementa la correzione.

score 0 · Answer 3

Assegna un'ancora di coppia che sarà sull'attività dall'inizio alla fine. Una stima dell'attività non dovrebbe essere più lunga di 2/3 giorni.

Cambia coppia ogni mezza giornata. La descrizione di Tommaso del flusso di rottura sarebbe corretta se non fosse rimasta nessuna ancora.

Se desideri un feedback visivo, tieni una tabella di abbinamento sulla lavagna e consenti all'ancora di aggiornare con chi ha abbinato.

Attenzione, non tutti sono felici di cambiarlo spesso, alcune persone preferiscono vedere una funzionalità dall'inizio alla fine spesso con la stessa persona. Penso che questo crei silo di conoscenza e richieda lunghi processi di revisione del codice.