Quanto è comune la programmazione di coppia sul posto di lavoro?

16

Sono sempre stato incuriosito dalla programmazione in coppia, ma in 12 anni di sviluppo non ho mai lavorato in un posto dove hanno utilizzato questa pratica, quindi sono sempre stato scettico su come la gente la vede.

Mi chiedo se ciò sia dovuto al denaro / al tempo (il capo dai capelli appuntiti che individua due persone su un computer che lavora sullo stesso codice !!!! come osano!) O per altri motivi?

development-process pair-programming

— OZZ
fonte

8

Penso che il PHB possa essere corretto in questa situazione. Due persone (e quindi due stipendi) per un prodotto sono fondamentalmente una pessima decisione economica. Non ci sono molti casi in cui la programmazione abbinata è più produttiva di quella individuale, almeno non "a tempo pieno" - quindi non è fatta molto al di fuori del tutoraggio di nuovi membri dello staff o di lavorare insieme su un problema specifico.

— TZHX,

3

Molto difficile convincere il capo dai capelli a punta che questo ha valore.

— Walter,

3

Per il nuovo codice penso che la programmazione delle coppie abbia un grande valore. La prima iterazione può richiedere la stessa quantità di tempo, ma IME impiega molto meno tempo per il debug. E quando due persone conoscono lo stesso codice, il debug diventa più facile, perché possono guardare in modo indipendente insieme. "Dato abbastanza bulbi oculari, ogni insetto è trasparente."

— Michael K,

1

@Michael, non sempre, ma a volte penso che l'associazione sul codice legacy possa essere utile. Può abbattere i silos e / o ridurre i costi di refactoring. Detto questo, sono completamente d'accordo w / you.

— DevSolo,

5

@TZHX: "Due persone per un output sono affari scadenti". Questo è un argomento gravemente difettoso e lo sai (come pagare i programmatori per riga di codice). La programmazione delle coppie è un argomento complesso e non dovrebbe essere ignorata così facilmente.

— Martin Wickman,

20

Ho avuto lo stesso concerto per 15 anni e di recente (negli ultimi 12-18 mesi) abbiamo iniziato ad adottare le tecniche Agile. Laddove viene utilizzata la programmazione delle coppie, la storia / funzionalità dei risultati è stata implementata in tempo con meno difetti. Tuttavia, non penso che sia stato impiegato abbastanza spesso.

Prima della nostra adozione Agile, un altro sviluppatore e io abbiamo condiviso di tanto in tanto la tastiera nel corso degli anni (forse una volta ogni 3-4 mesi). Il nostro team di gestione è sembrato riluttante, ma è stato sempre soddisfatto del nostro accoppiamento informale poiché in genere ha realizzato alcuni dei seguenti:

silos ridotti nella squadra (grande vittoria quando la squadra è 6-8 sviluppatori)
codice prodotto con meno difetti
ogni sviluppatore in genere ha acquisito abilità da esso

Direi che la gestione è riluttante, ma se puoi fare piccoli passi e dimostrare che la funzionalità è migliore in seguito (risparmio sui costi) e / o ogni (o uno) sviluppatore ha acquisito alcune abilità (pagandolo in avanti), puoi raccogliere vapore se la trovi una pratica adatta a te o alla tua squadra.

— DevSolo
fonte

grande intuizione DevSolo, grazie per la condivisione. Immagino che probabilmente hai una squadra abbastanza stabile (basso turnover del personale?)

— ozz

Prego. Il nostro fatturato è stato piuttosto basso ... 4 di noi hanno condiviso lo stesso ufficio da oltre 15 anni con 4 trasferimenti (in 4 edifici e 2 stati)!

— DevSolo,

Ironia della sorte, il tuo pseudonimo è "DevSolo";) nb le mie esperienze concordano con le tue

— ChrisAnnODell,

11

La mia ipotesi è che probabilmente ci sarebbero molte resistenze da parte degli sviluppatori. Ricordi di essere stato costretto a lavorare con persone che forse non erano le persone più motivate al mondo durante il college o addirittura il liceo? Quelle persone esistono ancora. A meno che tu non abbia una squadra composta da tutte le persone di "alto livello", questo tipo di installazione causerà un po 'di animosità nel gruppo.

— PEMDAS
fonte

Pemdas molto vero!

— ozz,

2

+1, purtroppo. Il lavoro di squadra è un'abilità che devi sviluppare e, se non vuoi, non puoi. Forse è quello che dovrebbero fare i manager dei programmatori: trovare la struttura del team che promuove la massima produttività con le persone che hanno.

— Michael K,

4

Questa professione richiede di tenere sotto controllo l'ego. Non è sempre facile, ma i premi saranno estremamente utili.

— DevSolo,

@DevSole ... cosa c'entra esattamente con la mia risposta?

— Pemdas,

@Perndas, stavo assumendo, forse in modo errato, che la resistenza sarebbe dovuta all'ego. Almeno quando l'ho visto, sembra essere questo il motivo. Ho visto solo 2 sviluppatori (che ricordo) in realtà resistere a questo. L'ego non poteva adattarsi nella stanza, l'altro aveva problemi con la fiducia.

— DevSolo,

9

Non l'ho fatto ufficialmente, ma ogni volta che sono bloccato, chiamerò uno sviluppatore e lavoreremo entrambi su una soluzione insieme. È un ottimo modo per far rimbalzare le idee, lasciare che una persona pensi mentre l'altra attua, quindi non perdere il filo del pensiero perché lo stai scrivendo.

Vorrei che fosse fatto di più.

— CaffGeek
fonte

4

Un altro strumento da utilizzare, se non si ha familiarità, si chiama "Rubber Ducking". Fondamentalmente, metti un oggetto sulla tua scrivania come un'anatra di gomma (il tuo usa davvero un giocattolo Yoda) e spiegagli il problema. vedi c2.com/cgi/wiki?RubberDucking

— DevSolo

Uso invece la persona seduta accanto a me ... non possiamo mettere roba sui nostri banchi.

— CaffGeek

Sul serio?

— Michael K,

@Michael ... non hai idea delle regole che abbiamo qui. Eppure, le poche cose buone superano tutte quelle cattive ... a malapena.

— CaffGeek,

È triste ascoltare quei programmatori irragionevoli che si applicano ai programmatori (è piuttosto stupido, non credi? Devono fare uno sforzo in più per renderci felici di bilanciarlo)

— Zekta Chan,

9

Non mi interessa:

1 - Mi piace ascoltare la mia musica durante la programmazione. Non tutti vogliono sentire Slayer esplodere nelle orecchie.

2 - Sono stato educato pensando di guardare le spalle delle persone molto scortese e di sentirmi molto a disagio quando le persone lo fanno.

3 - Penso molto velocemente e quando sono su un filo di soluzione, quando sto iniziando a trovare una risposta, essere interrotto è l'ultima cosa di cui ho bisogno.

4 - Non posso fare pause occasionali per esaminare forum e newsgroup. Alcuni potrebbero ritenerlo inappropriato comunque, ma lo trovo molto importante per il mio continuo miglioramento. Di tanto in tanto mi distraggo troppo, ma in generale il vantaggio della mia maggiore conoscenza supera qualsiasi colpo alla mia produttività.

Suppongo che potrebbe essere diverso su altri team, ma le poche volte in cui sono davvero sconcertato da qualcosa e DEVONO aiutare sono quasi sempre quello che alla fine trova la soluzione comunque. Sono davvero bravo in quello che faccio ma penso che potrebbero essercene altri in corso ... non sono sicuro, in ogni caso trovo che sto meglio solo risolvendo i problemi difficili e in generale meglio facendo da solo. Potrebbe sembrare arrogante, ma ciò non lo rende falso.

Ho considerato che potrebbe effettivamente aiutare gli altri a raccogliere alcune delle mie tecniche ma, tenendo conto del n. 3, difficilmente sarebbero in grado di porre domande senza interrompere il mio pensiero.

Detto questo, di tanto in tanto l'ho provato. A volte ha vantaggi minori, ma di certo non riesco a vederlo come una cosa coerente. Il sistema del lupo solitario funziona per me e sembra funzionare per la squadra.

— Edward Strange
fonte

2

@Noah, basato esclusivamente sul n. 2, non sono sicuro di capire il concetto di programmazione a coppie. L'idea non è quella di guardare oltre una spalla. L'idea, come l'ho praticata, è quella di condividere il PC per lavorare in tandem. Non è programmazione master / slave, è programmazione peer. Forse il secondo è un termine migliore per questo ...

— DevSolo

Questo è perfettamente valido. Alcune persone vogliono solo essere lasciate sole per capirlo da sole.

— MattC

E anche +1 per la cosa delle cuffie. Faccio esplodere metal e / o trance tutto il giorno e mi arrabbio molto quando le persone mi parlano di cose. Non possono aspettare fino alla fine della mia canzone preferita? : D

— MattC

2

@Noah: leggendo la tua lista, sembra che ti stiano perdendo i punti più fini della programmazione delle coppie. Non sto dicendo che è per tutti, e sicuramente ci vuole tempo e fatica per passare dalla modalità cowboy alla modalità condivisione. Proprio come ci vuole tempo per imparare a fare correttamente TDD (o qualsiasi altra pratica agile per quella materia).

— Martin Wickman,

1

continua ...: Con "senior" significa che potresti non essere effettivamente quello che fa il codice, ma aiutare uno sviluppatore più giovane a dare un suggerimento. Inoltre, non sono il più grande fan dell'idea della programmazione in coppia, ma vedo che probabilmente è principalmente fuori dalla mia zona di comfort. A molti sviluppatori piace lavorare da soli sulla propria stazione, ma devo ammettere che probabilmente avrei imparato di più e avrei trovato soluzioni migliori di come stavo lavorando insieme a un altro sviluppatore. Quindi è davvero una questione di comfort personale rispetto a lavorare in modo più efficace.

— Anne Schuessler,

5

La programmazione in coppia è un ottimo modo per iniziare o fare qualcosa di non banale e difficile. Più compiti di routine e semplici vengono eseguiti meglio da soli.

Ho partecipato a una serie di sessioni di programmazione in coppia, sia in startup / garage che in grandi aziende. Accadde invariabilmente solo quando veniva accolto qualcosa di nuovo e di difficile, vale a dire due volte all'anno, per alcune settimane. Quanto spesso succede nella tua azienda?

— 9000
fonte

meno spesso di quanto vorrei, questo è certo.

— ozz,

5

Non l'abbiamo mai chiamato così, ma nel passato, è così che abbiamo sempre attaccato nuovi problemi. Ci accoppiamo per iniziare una soluzione, ma di solito scoppiamo per finire / pulire individualmente i dettagli. Non più così tanto. Sembra diventare sempre più raro.

— Brian Knoblauch
fonte

3

Non molto comune In tutti i negozi in cui sono stato negli ultimi 10 anni, l'ho visto una volta. Nel negozio più lento e meno efficiente. Sembra creare un ambiente rumoroso e stressante. Una persona finisce per guidare e parlare costantemente impedendo all'altra di pensare affatto.

Riunisci il team per le revisioni del codice in gruppi o in coppie e offri agli sviluppatori il loro spazio. A lungo andare sarà meglio che inseguire l'ultima moda di Agile.

— Servio
fonte