DZone articolo Inizio del 2011: I Hate Programmazione coppia (e il tuo codice e voi)

"Sei programmazione in coppia ? "il nostro direttore ha chiesto nel suo tono snarky, durante l'utilizzo esagerato di aria doppie virgolette per enfatizzare il suo scetticismo. Poi se ne andò senza aspettare una risposta ...

Questo è solo un esempio dei numerosi casi che ho sperimentato nel corso degli anni da parte degli scettici di programmazione in coppia.

Questo non è un concetto particolarmente nuovo, e in passato sia hardware e sviluppatori software ha lavorato in coppia su una base di routine. Tuttavia, con la recente popolarità (e di notorietà) dello sviluppo del software agile, il dibattito di programmazione coppia continua a infuriare.

Perché questa pratica ad evocare una risposta emotiva da parte di persone?

Fatica accoppiamento

Accoppiamento stanchezza sembra essere uno degli argomenti più comuni contro il pair programming. Infatti, una conversazione che ho avuto recentemente è stato con una persona che accoppiati per oltre 6 ore di fila e poi mai di nuovo appaiati. Il suo volto scrunched quando si parla di esso, tanto che penso si sentiva dolore reale anche pensarci.Mi informai sul perché non ha pause, o utilizzare il pomodoro tecnica ma non era disposto a divulgare i dettagli.

Nota: è importante lavorare ad un ritmo sostenibile e di prendere piccole ma frequenti pause. Questo vale anche per programmazione in coppia!

Singoli punti di guasto

Una delle mie citazioni preferite da un datore di lavoro è passato "Non siamo una organizzazione a thread singolo".Ragazzo era lui sbagliato, abbiamo avuto singoli punti di guasto ovunque! Purtroppo programmazione in coppia è stata vista con disprezzo tale che non è sopravvissuto modalità pilota. Presso altre strutture che ho visto due persone e condividere le conoscenze in modo tale che la sola osservazione dell'organizzazione threaded effettivamente tenuta d'acqua. La gente potrebbe eseguire il codice con successo invece di chiamare un ingegnere del software, mentre lui è in vacanza a Disney World con la sua famiglia. (Storia vera)

Nota: è importante avere una conoscenza condivisa del codice di base, altrimenti la vostra organizzazione non può recuperare quando i membri chiave del team lasciare (e saranno).

È troppo costoso per avere 2 persone in 1 computer

Un altro argomento contro il pair programming è che è troppo costoso avere due sviluppatori di lavorare insieme nello stesso momento. Ho visto dirigenti fare il caso che la programmazione coppia è raddoppiato il loro costo per operare ingegneria del software, e poi prontamente uccidendo l'iniziativa. Tuttavia sembra che il costo di portare gente nuova a regime è spesso trascurato in questa equazione.

Nota: Quando si tenta di realizzare l'analisi costi / benefici di pair programming, invece il tempo di un neo assunto prende per arrivare fino a velocità sul suo contro proprio quando l'accoppiamento con un membro del team già esistente.

Per aiutare a visualizzare questo argomento sto facendo, immaginate un paio di programmazione scivolo r.

Slider paio di programmazione: 
0% []-------------[] 100%

A sinistra allo 0%, i membri del team non hanno assolutamente idea di che cosa l'altro sta lavorando all'interno della base di codice.

Sulla destra al 100%, i membri del team enfaticamente odiano l'un l'altro.

Nessuno dei due estremi promuove la crescita del team, in modo da con la maggior parte delle pratiche è necessario sforzarsi di trovare il giusto equilibrio per la tua squadra e organizzazione.

Sì, sì ... dammi esempi reali

Un anno fa il nostro team di sviluppo praticato pair programming almeno 4 o più ore della nostra giornata lavorativa di 8 ore. Immaginate il cursore paring pari o superiore al 50% ogni giorno. Questo è stato soprattutto perché avevamo già membri del team con una grande quantità di conoscenze dominio transizione off e nuovi membri del team in transizione E prima di chiedere, sì, abbiamo fatto del nostro meglio per lo schermo del nuovi membri del team durante il processo di intervista. Gli intervistati erano tenuti a coppia con i membri esistenti per avere un'idea di quello che un giorno medio sarebbe come prima firma.

E 'ormai un anno dopo, e siamo attualmente l'abbinamento a circa il 25% per 3 giorni a settimana, e 45% per 2 giorni alla settimana. Abbiamo rivisitato come coppia ad ogni iterazione retrospettiva (2 settimane). Questo è importante perché abbiamo bisogno di parlare apertamente di come stiamo lavorando insieme come una squadra e regolare le cose, se necessario.

Abbiamo imparato molto l'uno dell'altro e come lavoriamo nel corso dell'ultimo anno.

Ho scoperto che quando si connette al dispositivo di scorrimento e coppia per un minor numero di ore che si tende a comunicare con l'altro meno. Il ronzio camera squadra è ridotta in modo significativo in questi tempi, ed è più difficile mantenere un impulso della squadra nel suo complesso.

Ho scoperto che con dispositivo di orientamento orari accoppiamento come un artefatto del nostro stand ogni giorno aiuta a mantenerci onesti. Ora anche la domanda "Che cosa vorreste coppia oggi?", In quanto in tempi diversi membri del team vogliono iscriversi per lo stesso compito.

Sono abbastanza certo che continueremo a imparare nel corso dell'anno prossimo.

Così, in breve, prima di dichiarare il vostro odio eterno per la programmazione di coppia, prova a dargli un altro colpo con alcuni controlli ben pensato ed equilibri. Semplicemente potrebbe sorprendervi.

Corso Java - Corsi Java - Corsi programmazione Java

 Corso programmazione Android - Certificazione Android