Fattori decisivi nella programmazione delle coppie

Nel mio ultimo lavoro abbiamo fatto un sacco di programmazione per coppie. Abbiamo scoperto che non era un buon metodo per insegnare / imparare. Quando abbiamo provato ad usarlo per insegnare spesso che la coppia sarebbe rimasta indietro, uno sarebbe frustrato.

La migliore performance era solitamente di 2 persone con un livello di abilità simile con punti di forza, approcci e idee visivamente diversi. Le persone svilupperebbero un senso per gli altri punti di forza e debolezza e di conseguenza sarebbero un complemento efficace.

Abbiamo anche trovato che l'accoppiamento non è molto efficace per semplici correzioni di bug, funzionalità. Aree in cui il lavoro è stato semplice e diretto.

Quindi di nuovo è solo la mia esperienza in un team di sviluppo.

Ho trovato che la programmazione di coppie è molto utile per l'apprendimento / l'insegnamento. Ma non mettere un guru con un principiante, il principiante sarà sopraffatto e il guru infastidito. Dovresti avere una persona che conosce un po 'più dell'altro, o due persone che conoscono cose diverse. In quel caso la programmazione della coppia è un modo molto efficiente per trasferire il set di abilità.

È IMO meno utile quando due programmatori hanno lavorato così tanto insieme da risolvere un problema esattamente nello stesso modo se lo facevano separatamente. Quindi stai sprecando il tempo di una persona.

Eh, dal momento che la mia esperienza sull'argomento è puramente teorica e non ho alcuna esperienza diretta di metodi di sviluppo agili, continuerò a buttare i miei pensieri al mulino. Credo che il miglior risultato della programmazione di coppia sarebbe in tali situazioni in cui i due programmatori hanno una leggera differenza nelle loro esperienze e livelli di abilità e hanno lavorato in aree leggermente diverse. Lo "scrittore" dovrebbe avere meno esperienza del "lettore" per utilizzare il lavoro di squadra nel modo migliore. La ragione è che lo "scrittore" deve imparare e diventare molto più fiducioso con il suo codice e il "lettore" deve condividere la sua esperienza a beneficio della squadra e del progetto. In nessun caso dovrebbero sentirsi diseguali; Immagino che se il "lettore" si sente meno esperto e un po 'perso, allora i suoi sforzi non saranno sfruttati al massimo del loro potenziale. La commutazione attiva dei ruoli, sia la capacità di dare e di acquisire un feedback costruttivo è la chiave; è inutile cercare di accoppiare persone che non riescono ad andare d'accordo.

Non dovresti guardare la programmazione delle coppie in quale lingua si conosce meglio dell'altra, credo che se vuoi che un programma sia fatto in C ++, scegli 2 persone che sono brave in questo, o uno studente veloce, lo stesso vale a qualsiasi altra lingua / tecnologia.

Prova a guardare ad altre risorse che i due potrebbero avere, dovrebbero avere approcci sempre diversi, se combattono sulle idee è una buona cosa perché da 2 buone idee si potrebbe trovare una grande, a meno che non diventi brutta.

Anche una coppia dovrebbe sempre essere di persone con competenze simili altrimenti si farà tutto il lavoro e l'altra cercherà di recuperare, nel peggiore dei casi ci vorranno due o più volte, come se la persona migliore fosse fare tutto da solo, poiché spiegherà sempre ciò che fa.

Questo deriva dalla mia esperienza all'università, dato che lavoriamo sempre in team, lavorando con persone con competenze simili, per me è sempre stato più gratificante.

C'è un libro chiamato Pair programming illuminated (ISBN 9780201745764) che descrive diversi aspetti della programmazione della coppia, tra l'altro mettendo insieme persone con esperienze diverse. Uno dei capitoli è denominato "Il mio partner è un perdente totale" e altri problemi di ego eccessivo .