Quando funziona la programmazione della coppia? Quando evitarlo?

Ricerca redatta da Laurie Williams indica che la programmazione della coppia funziona meglio nei team industriali quando

• Le coppie lavorano su specifiche, progettazioni e complesse attività di programmazione - gli esperimenti indicano che non viene mostrato alcun miglioramento della qualità quando si lavora su semplici compiti in una coppia, ma potrebbero esserci miglioramenti di velocità. Si noti inoltre che la "programmazione" della coppia spesso include attività diverse dalla scrittura del codice.
• Ogni individuo in un accoppiamento ha lo stesso livello di esperienza - mentre la programmazione delle coppie è ottima per l'allenamento, le coppie sono più coinvolte quando si trovano sullo stesso livello.
• I ruoli ruotano regolarmente - la rotazione regolare aiuta a mantenere attivo il copilota mentre gli individui tendono a contribuire maggiormente quando guidano o sentono che stanno per guidare.
• Le coppie ruotano regolarmente - i team hanno espresso conforto nel conoscere le diverse parti del sistema che stanno costruendo. La rotazione delle coppie aiuta con il trasferimento delle conoscenze che riduce alcuni rischi nel progetto. In un contesto accademico vengono spesso assegnate coppie, tuttavia nel settore sono generalmente auto-assegnate spesso durante lo stand-up. In entrambi i casi, la coppia è più efficace quando entrambe le persone sono disposte a partecipare a partecipanti che vedono il valore dell'attività di accoppiamento.

Nella mia esperienza personale ho scoperto che il mio team di XP spende in media circa il 60% della nostra coppia di sviluppatori. Il resto del tempo è dedicato allo sviluppo individuale. Non è raro abbinarlo per creare un progetto iniziale, lavorare da solo sul design per qualche ora, quindi tornare insieme per finire parti difficili o difficili del codice.

Ho anche scoperto che la programmazione della coppia è più efficace in blocchi da 1,5 a 2,5 ore. Qualcosa di molto meno tende a richiedere troppo overhead per l'installazione mentre molto di più e le coppie tendono a diventare irritabili e stanchi. Irritabile e stanco significa che non stai comunicando bene e potresti lasciare che i difetti entrino nel sistema.

La programmazione accoppiata ha funzionato per me in pochissime situazioni.

Dove la programmazione delle coppie fallisce per me

The short story is that pair programming doesn’t work for me as the main way of developing software. I can pair program for a day, or maybe a week, especially if we’re focused on a particular problem. But after that? I’m done. Toast. I don’t want to see anyone, talk to anyone, and I need at least a couple of days in a cave until I’m fit for human company again.

It’s a sad story, but the funny thing is that I’m so much happier now with how it ended. I’m happily employed on a contract where I work from home or from a coffee shop, and I’ve made new friends and explored more of San Francisco than I ever thought possible. I have a bicycle and a laptop, and as long as I meet my deadlines and check in code regularly, my time is my own.

I’ll list the big problems I have with pair programming up front and give you the detail and anecdotes later.

1. Split focus.
2. No experimentation.
3. No high notes.
4. No pride in ownership.
5. No escape...

...I asked my co-workers if they saw what I saw, if I was missing something, anything -- I didn’t see how this could work, how people could keep doing this. They said I was doing fine, that it just took time to settle in and adjust. That it was hard for everyone at first.

Eventually, I retreated into myself. Between the blinding headaches, the insomnia, and the pounding, unmet need to write code, I stopped responding to input. I could stare at a screen and not see anything. Someone could talk to me unexpectedly and I wouldn’t hear them. I was fulfilling the rote requirements of my job, but I wasn’t there. I’d used up everything I had just showing up for the day. I started checking my iPhone when my other partner was typing.

Finally -- just shy of three months later, and for the first time ever -- I was fired for not being a team fit when pair programming.

Not Alone

I wrote this not just to understand it, but also to be able to talk about it. There’s been a presumption that pair programming works for most people and is much easier and faster than programming solo would be. This may or may not be the case, but as a long term practice, pair programming doesn’t work for me. There are many other people that pair programming doesn’t work for either. We matter too...

Il mio team ha fatto la programmazione delle coppie sin dal suo inizio, molto tempo prima che lavorassi lì, come parte di un negozio per lo più di "programmazione estrema". La programmazione della coppia è lo stato predefinito ; le persone vanno davvero singleton solo se c'è un numero dispari, o occasionalmente per le indagini, specialmente quelle che implicheranno problemi con attrezzature ostili e cercheranno di farlo funzionare.

"Junior / senior" non è l'unico modo per andare. "Intermediate / junior" è utile; aiuta il ragazzo di livello intermedio a sintetizzare le conoscenze che ha ottenuto costringendolo a comunicarlo a qualcun altro. "Intermedio / Intermedio" sfida due persone che lavorano insieme per condividere le proprie conoscenze, comunicare e lavorare come parte di un team. E anche se hai due ragazzi molto più anziani, è probabile che abbiano diverse aree di competenza e possano approcciare approcci diversi. Gli aspetti di condivisione della conoscenza non finiscono quando qualcuno è vagamente "in piena velocità" su un progetto. Piuttosto, la programmazione della coppia è l'epitome di un'organizzazione apprendimento . Nuove tecniche e best practice si diffondono rapidamente.

La programmazione di coppie aiuta anche a mantenere la qualità del codice (meno difetti) e la sanità mentale del codice (non fa solo ciò che intende, ma fa ciò che dovrebbe ... idealmente senza scendere in una buca del coniglio di più settimane facendo la cosa sbagliata, o due cose giuste diverse che entreranno in conflitto selvaggiamente). Aiuta i programmatori a mantenere la loro attenzione: qui nel cuore della Silicon Valley, sede della settimana lavorativa di 80 ore, possiamo lavorare solo per 40 ore settimanali perché stiamo facendo un'intensa programmazione per otto ore al giorno, cambiando le cose via l'uno con l'altro. (Inoltre, se avessi lavorato più a lungo sulla programmazione di coppie, probabilmente avresti smesso di funzionare o almeno bruciato. Questo è ottimo per l'equilibrio tra lavoro e vita privata, e aiuta anche la tua organizzazione quando è importante avere tempi di risposta rapidi (inversione di bassa latenza, in particolare).

Non è tutto, completamente, 100% pesche e crema; Trovo che la programmazione di coppie sia occasionalmente un ostacolo alla mia applicazione di processi cerebrali intuitivi che sono utili su alcuni problemi. Più di recente, in un compito di perdita di memoria, ho trascorso un po 'di tempo sia con che senza coppie; senza uno, mi sentivo più libero di gironzolare e provare esperimenti senza sapere esattamente come spiegare ciò che stavo facendo in ogni momento. Ci sono anche alcuni vantaggi nel lavorare singleton, essere in grado di andare su una tangente e fare alcuni refactoring selvaggi (valutati nella metodologia XP) per un capriccio.

Ma tutto sommato, i vantaggi superano di gran lunga i costi e l'accoppiamento ha funzionato in modo spettacolare per noi: dalla fase di avvio all'acquisizione da parte di una società più grande e alla nostra successiva integrazione. (A proposito, la programmazione di coppie ci ha aiutato a mantenere una continuità culturale attraverso l'espansione e nonostante un piccolo giro d'affari).

(Sviluppiamo un'appliance software in Perl, ~ $ 4,000 - $ 40,000 prezzo di listino.)

Non ho mai lavorato in una configurazione di "Pair Programming" eppure posso affermare di aver fatto parte delle tre circostanze che hai elencato. Lo scenario che hai menzionato sembra più una "programmazione regolare" con fasi di aiuto / formazione lanciate. Non abbiamo fatto tutto questo prima che venisse messa in pratica la "coppia di programmazione"? La programmazione di coppie, presumibilmente, richiederebbe un approccio più impegnato in cui il processo di condivisione all'interno di una squadra non si interrompe nel momento in cui affronta il compito o il problema immediato. Ma questo è ciò che "penso" non quello che "so".

Personalmente per la programmazione delle coppie Mi piacerebbe lavorare in un team in cui ho la possibilità di imparare e condividere le mie conoscenze. Una squadra squilibrata in cui tutti quelli con cui lavori sono in vantaggio di molti chilometri, o in un modo al di sotto della media possono diventare piuttosto poco interessanti abbastanza rapidamente. Inoltre, avrei paura di lavorare con persone che sono impostate nel loro credo e difficili da convincere.

Negli ultimi mesi abbiamo sperimentato la programmazione Pair nel nostro team. Mi sembra piuttosto utile quando si sta lavorando su qualcosa di nuovo (nuova tecnologia, nuova funzionalità, ecc.) In quanto è possibile far rimbalzare rapidamente le idee con un'altra persona del team e farle convalidare / invalidare. Inoltre, una peer review affiancata aiuta a tenere lontani i bug.

Un altro compagno di squadra ha provato a usare la programmazione pair con un test per fare ATDD ed erano abbastanza contenti dei risultati (secondo i suoi calcoli un aumento del costo di sviluppo del 20% ha portato ad una diminuzione di circa il 50% nel tempo di test)

Buona notte

molte volte abbiamo discusso delle pratiche di Extreme Programming e della programmazione di coppie . Tornando indietro nel tempo, siamo in grado di capire che la programmazione è un'attività solitaria perché i programmatori avevano bisogno di concentrazione e isolamento. I programmatori di quel periodo si trovavano nella zona , uno stato mentale in cui potevano concentrarsi efficacemente sul codice e prendere decisioni piacevoli e creative.

La programmazione accoppiata sembra essere anche rischiosa se si presuppone che un programmatore si interrompa a vicenda. D'altra parte, è più difficile interrompere due programmatori che lavorano insieme. Nella programmazione Solo, ad esempio, sarà più facile essere interrotti, quindi è quasi impossibile per un programmatore solista rimanere nella "zona".

La qualità del codice è un'altra quando la linea morta è dietro l'angolo. Le persone saranno sempre di fretta, siano programmatori di coppia o programmatori solisti: non applicheranno alcune best practice e si dimenticheranno dei test unitari.

Vorrei attenermi alla programmazione delle coppie. Perché quando si tratta di rischi, quando un programmatore se ne va, avrai sempre un altro ragazzo per documentare il processo e insegnare a tutti gli altri come funziona.

Lavorare su qualsiasi cosa di complessità non banale tende ad essere un buon candidato per la programmazione di coppie in modo che più persone capiscano il codice piuttosto che un solo sviluppatore che conosce una parte della base di codice. Un altro caso è dove qualcuno vuole trasferire alcune abilità. Un esempio potrebbe essere quello di avere qualcuno che è veramente bravo in coppia di test unitari con qualcuno che non ha familiarità con il concetto e quindi aiuta ad avere un'abitudine iniziale su qualcosa.

Per quanto riguarda la posizione in cui evitare la programmazione delle coppie, le attività di lavoro grunt sono semplici dove sarebbe meglio suddividere il lavoro in due gruppi e lasciare che ogni sviluppatore faccia parte del lavoro separatamente per portare a termine il lavoro. Alcune attività possono richiedere solo un bel po 'di digitazione, ma non sono così grandi che vale la pena dedicare qualche ora a cercare di trovare un modo migliore di farlo come si potrebbe fare se ogni sviluppatore adotta un approccio a forza bruta per alcuni ore.