Quali sono i possibili svantaggi della programmazione delle coppie? [chiuso]


22

La programmazione delle coppie è abbastanza famosa oggi.

Ha diversi vantaggi come:

  1. Programmi con meno bug.
  2. I costi di manutenzione post-produzione sono molto inferiori.
  3. Le pratiche consolidate vengono messe in discussione con conseguente comparsa di nuove idee.
  4. I programmatori imparano gli uni dagli altri.
  5. I programmatori sviluppano competenze trasversali.

Ma quali sono gli svantaggi della programmazione in coppia?


1
Il "parallelo" nel titolo della domanda è un refuso?
5gon12eder,

14
Intendi altro che il fatto che ci vogliono due persone per produrre lo stesso (forse meno) output?
Robert Harvey,

4
@ ThorbjørnRavnAndersen Probabilmente è meno.
Robert Harvey,

4
@ ThorbjørnRavnAndersen Qualcosa non va nella tua matematica. Fondamentalmente, quello che stai dicendo è che sei costantemente in revisione peer / code. È difficile immaginare come sia più economico in termini di tempo.
Robert Harvey,

5
Ciò può essere realizzato abbastanza prontamente senza la distrazione di un accordo di programmazione della coppia in piena regola. Lavora con i tuoi colleghi sviluppatori di software in questa funzione in base alle necessità.
Robert Harvey,

Risposte:


28

Sebbene la programmazione delle coppie abbia guadagnato una notevole reputazione, ha anche diverse insidie.

Alcuni di questi sono i seguenti:

  1. Nella programmazione in coppia non è possibile sedersi e autovalutare il proprio codice.
  2. Una coppia potrebbe smettere di essere attivamente impegnata.
  3. Il driver deve "programmare ad alta voce". La programmazione silenziosa riduce il vantaggio.
  4. Costa più ore-uomo per produrre le stesse funzionalità. È necessario mantenere un equilibrio tra qualità del codice e aumento dei costi di codifica.
  5. Un fenomeno "guarda il maestro" può sorgere quando un programmatore esperto e un principiante si accoppiano. Il membro inesperto può diventare l'osservatore mentre il membro con esperienza completa la maggior parte della codifica.
  6. Quando due utenti esperti si accoppiano, può sorgere un fenomeno di "ego dello sviluppatore", con ogni membro che cerca di spingere le proprie idee.

4
2 e 5 possono essere contrastati con l'accoppiamento Ping-Pong (cambio ruoli tra driver e navigatore molto rapidamente in fase di blocco con il ciclo TDD: Alice scrive test falliti, Bob scrive codice per effettuare test, refactors Alice, Bob scrive test falliti, Alice scrive il codice per superare il test, i refactor Bob, Alice scrive il test fallito ...). In questo modo, guidatore e navigatore cambiano ruolo ogni due minuti al massimo (più come decine di secondi) e ogni membro ottiene compiti altrettanto grandi e importanti.
Jörg W Mittag,

5
4 sembra ovvio, ma non ne sono sicuro. La cattura di bug e il feedback anticipato, ad esempio, possono (o meno) compensare effettivamente le raddoppiate ore degli sviluppatori.
Jörg W Mittag,

4
@ JörgWMittag (re: accoppiamento Ping-Pong) suona come una ricetta per una giornata di lavoro molto stressante: / Spero di non dover mai programmare in un posto dove applicano questa o qualsiasi altra metodologia di programmazione a coppie rigide.
Andres F.

4
La programmazione del ping-pong richiede che le due parti siano essenzialmente intercambiabili. Ho un collega in cui l'unica combinazione di programmazione di coppie sensate è fargli pensare e io scrivere (e meditare). Lo aiuta a rimanere concentrato e a capire cosa sta succedendo.
Thorbjørn Ravn Andersen,

3
Potresti anche menzionare che un bel po 'di tempo è sprecato a discutere di dettagli insignificanti mentre nelle revisioni del codice puoi concentrarti solo su aspetti importanti.
Giorgio,

24

Ho provato diverse volte a programmare in coppia, anche all'interno di un'organizzazione che (brevemente) ha considerato la possibilità di implementarla come un processo obbligatorio per tutti gli ingegneri (puoi immaginare quanto bene sia stata elaborata l'idea). Personalmente, l'ho odiato.

Le ragioni che elencherò di seguito sono solo le mie esperienze soggettive e non posso "misurare" il loro impatto in termini concreti. Ma qui sono tutti uguali:

1 - Avere un 'navigatore' e un 'driver' aiuta solo se il primo è vocale e il secondo ascolterà.

Abbiamo incontrato tutti gli sviluppatori che sono testardi, zelanti per qualche preoccupazione teorica o patologicamente incapaci - psicologicamente - di "buttare via" il vecchio lavoro quando qualcuno suggerisce un problema. E tutti conosciamo individui troppo timidi o diffidenti per sollevare dubbi o suggerire casi angolari.

Quando questi tipi di sviluppatori sono accoppiati, il navigatore assume rapidamente un ruolo passivo e ciò che si ottiene è la programmazione esclusiva con una revisione automatica del codice. Questo è uno spreco di risorse monumentale.

2 - L'associazione impedisce la creatività.

Contrariamente a quanto si pensava in precedenza sul valore del "brainstorming di gruppo", il consenso in questi giorni è che il lavoro di conoscenza creativa richiede indipendenza e autonomia . Quando lavori da solo, puoi rapidamente hackerare insieme un'idea folle per vedere se è effettivamente fattibile. Puoi assemblare senza parole alcuni strani prototipi e, se fallisci, non importa, perché nessuno lo sa .

Confrontalo con l'accoppiamento: quando voglio provare qualche nuovo concetto, devo convincere il mio partner, parlare attraverso l'implementazione, passo dopo passo, e spero che non mi giudichino se fallisce. Questo tipo di ambiente è tossico per la creazione di nuove idee.

3 - Design con il minimo comune denominatore.

Quando una coppia non è in grado di sviluppare nuove idee, come sopra, o quando gli individui non riescono a concordare alcuni principi fondamentali su come dovrebbe essere progettata una caratteristica, ciò che ne risulta è un disegno confuso che tenta di scendere a compromessi e non soddisfa nessuno.

Se abbini uno sviluppatore che costruisce astrazioni di programmazione funzionali meravigliose, eloquenti, verso il cielo con un maniaco delle prestazioni veloce e sporco, il codice che produrranno insieme in genere non sarà né terribilmente elegante né particolarmente veloce.

4 - Mancanza di autonomia e trasparenza violenta.

Trasparenza violenta è una frase che ho preso da una polemica moderatamente famosa (e piuttosto controversa) contro la metodologia Scrum. Descrive il modo in cui alcune organizzazioni infantilizzano gli sviluppatori e li trattano con il sospetto normalmente riservato ai lavoratori non professionisti.

Qualunque cosa tu pensi del "danno" di rendere il lavoro degli sviluppatori completamente trasparente (e potresti non essere d'accordo sul fatto che in realtà è un danno), molte persone apprezzano la loro autonomia e la loro capacità di lavorare da soli, fidati di fare la cosa giusta. È un bisogno psicologico importante e costringere gli sviluppatori ad accoppiarsi (come ho visto accadere in almeno un negozio) lascerà i dipendenti sgomenti, sconvolti e alienati.

5 - Alcuni sviluppatori semplicemente non giocano bene in coppia.

Alcune persone non si comportano o non possono comportarsi in modo appropriato in un ambiente accoppiato. Possono avere una cattiva igiene, cattive abitudini lavorative, una personalità abrasiva, un modo "forte" e "intenso", o tutta una serie di altri attributi che li rendono ottimi singoli lavoratori, ma poveri programmatori di coppie.

Puoi risolverlo? Non proprio. Cambiare il comportamento personale è difficile. Un negozio di programmazione per coppie deve essere molto attento alle assunzioni e investire molto tempo nel vedere come funziona qualcuno e se sarà in grado di lavorare bene con i propri colleghi. Discriminare di più la personalità, tuttavia, significa che l'assunzione richiederà più tempo a meno che non allenti i tuoi standard di abilità e competenza.


3
Mentre mi piace la frase "trasparenza violenta", è stata la mia esperienza che la metodologia preferita (mischia / agile o qualcosa di più tradizionale) non ha alcuna relazione con il fatto che gli sviluppatori siano trattati come professionisti o meno. Le organizzazioni disfunzionali tratteranno i professionisti come i bambini se (fingono di) seguire Scrum o CMMI.
David

1
"Confrontalo con l'accoppiamento: quando voglio provare qualche nuovo concetto, devo convincere il mio partner, parlare attraverso l'implementazione, passo dopo passo, e spero che non mi giudichino se fallisce. Quel tipo dell'ambiente è tossico per la creazione di nuove idee. ": Non si tratta solo di giudizio, ma di velocità. Non vuoi essere distratto quando hai un'idea, vuoi scrivere il più possibile finché sei nel flusso. Associare la programmazione ti impedisce attivamente di farlo.
Giorgio,

1
Dopo aver scritto tutte le tue idee, puoi metterle in ordine, forse il giorno successivo e, successivamente, lasciare che un collega faccia una revisione approfondita, ad esempio su uno strumento come la scheda di revisione, in modo che abbiano tutto il tempo per guardare le tue idee finite e pensaci senza pressione del tempo. La programmazione della coppia impedisce anche questo perché cerca di combinare la codifica e la revisione del codice in un'unica attività.
Giorgio,

2
@Jimmy: se avessi scritto cinque risposte anziché una risposta con cinque punti, otterrai cinque voti da me.
Giorgio,

Assolutamente d'accordo sul fatto che la sperimentazione richiede un lavoro silenzioso e veloce, l'esatto contrario di ciò che richiede l'abbinamento. Forse l'associazione funziona bene per gli sviluppatori che eseguono la manutenzione o aggiungono funzionalità discrete a un sistema aziendale esistente di grandi dimensioni. Ma sono certo che non serve affatto al lavoro che richiede scoperta, nuove tecnologie, ingegnosità o modi creativi di lavorare con vincoli difficili.
Jimmy Breck-McKye il

12

Dipende dalla tua situazione o prospettiva.

La programmazione delle coppie fa bene all'organizzazione. Ma fa bene all'individuo?

Dopotutto è un metodo di riduzione dei costi (feedback anticipato) e produttività; Non riguarda te ma il progetto, il prodotto, l'azienda ($$).

Sebbene tu possa avere benefici personali, non sono la ragione o la fine di alcuna metodologia di sviluppo. La programmazione di coppie (a tempo pieno), ad esempio, ti impedisce anche di rallentare, navigare ecc., Devi giustificare le tue pause al tuo partner.

Il tuo partner (rotante) sarà la migliore telecamera di sorveglianza: l'intensità del lavoro aumenta.

Oppure, distribuendo la conoscenza l'individuo diventa meno rischioso per l'azienda (ad es. Non può lasciare l'azienda con conoscenze essenziali) e ha meno "chip di contrattazione".

Sono sicuro che trovi più punti leggendo articoli affermativi in ​​modo più critico dalla TUA situazione / punto di vista reale nell'azienda piuttosto che dal punto di vista del tuo manager.

Quasi tutte le metodologie sono scritte dal punto di vista del gestore.


A meno che tu non sia il proprietario dell'azienda, ti viene dato denaro per generare codice. Il codice migliore che puoi produrre è il migliore per il tuo datore di lavoro - pensare in un modo di avere patatine di contrattazione contro il tuo datore di lavoro è a mio avviso non capire ciò che ti rende prezioso in primo luogo. Credo che la PP sia così intensa che non puoi farlo tutto il giorno, ma ha bisogno automaticamente di riposo.
Thorbjørn Ravn Andersen,

7
Dato che alcune persone sono costrette a guadagnarsi da vivere "per essere preziose per un datore di lavoro", devono anche calcolare con l'interesse personale e non solo con gli interessi dei loro datori di lavoro in mente come i minion.
Un ospite

1
@ ThorbjørnRavnAndersen non stiamo vivendo in un mondo ideale, dove tutti pagano le tasse e tutti vengono compensati in base al merito.
Den

1
@ ThorbjørnRavnAndersen Il codice migliore è il migliore per il mio datore di lavoro? Vorrei vivere un mondo così, nel mio mondo ciò che conta è produrre funzionalità il più rapidamente possibile, in cui la qualità del codice è semplicemente un valore intermedio che non dovrebbe richiedere più tempo del necessario. I bug sono ok, di solito non sono gravi e facilmente risolvibili.
Alex

@Alex "di solito non grave" - Desidero quel mondo: D
Gusdor

5
  1. All'improvviso ora devi dire a qualcuno quando vuoi andare in bagno o prendere un caffè. Almeno non è necessario chiedere il permesso.

  2. Devi far fronte alle norme igieniche dell'altra persona.


4

Oltre ad altre risposte:

  1. Molte aziende con cui ho lavorato hanno programmato i loro programmatori con laptop (basati sul sito dei clienti - più facili da tenere al sicuro se portati a casa dopo il lavoro, essendo in grado di fare il lavoro dispari da casa su VPN in un pizzico, ecc.) Molti anni fa ho già avuto problemi a vedere sullo schermo del laptop di un'altra persona (il "guidatore") dal punto di vista della spalla navigando - l'età non migliorerà questo (e alcuni schermi diventano difficili da leggere al di fuori dell'angolo di visione ideale in ogni caso).

    Pertanto, i programmatori di coppie avranno bisogno di schermi sufficientemente grandi, che aumenteranno il costo dell'hardware e limiteranno l'adattabilità alla posizione. Potrebbe non essere un problema per alcuni, in altri casi sarà un problema.

  2. Ho anche scoperto che le differenze nelle preferenze di igiene personale (incluso il fumo, il mangiare e il bere), così come gli scontri di personalità, ostacolano la produttività. È abbastanza facile dire a due programmatori di "succhiarlo e andare d'accordo", spesso ciò si tradurrà in persone che tengono piuttosto la bocca chiusa e si sabotano silenziosamente attraverso azioni passive-aggressive per sfogare i loro risentimenti reciproci.
  3. Rumore. Io, per esempio, mi piace un ambiente di lavoro tranquillo. Non riesco a immaginare le chiacchiere costanti da alcuni gruppi di programmatori di coppie (poiché è necessario parlare per la comunicazione). Anche la musica vocale sulle mie cuffie tende a interferire con la mia concentrazione (strumentali insipidi per l'ascolto in ufficio ...). Immagino che ciò possa essere mitigato allontanandomi dall'onnipresente ufficio open space verso uffici dedicati a 2 persone, ma ciò comporterà un ulteriore aumento dei costi.

Aneddoti per il tuo divertimento:

  • Un precedente datore di lavoro una volta aveva ottenuto un appaltatore da un altro paese (tutti per rimanere anonimi per proteggere i colpevoli). Il datore di lavoro ha fornito alloggio ma non trasporto. Dato che il contraente ha vissuto lungo la mia strada per il lavoro, mi sono offerto volontario per prenderlo e lasciarlo di nuovo. Diciamo che la sua igiene personale non era allo stesso livello di quella a cui sono abituato, e ha anche fumato pesantemente ("il più forte!") Mentre io no. Durante il nostro viaggio di 15 minuti in ufficio, ho tenuto i finestrini abbassati, anche in inverno, il che non ha impedito alla mia auto di odorare come una stanza per fumatori stantia dopo il periodo di tre mesi del collega (no, non ha fumato in macchina , ma lo ha fatto mentre mi aspettava).
  • Inoltre non abbiamo programmato la coppia, ma ci siamo seduti uno accanto all'altro a un tavolo da conferenza (per un po '). Dopo circa un mese, c'era un bel anello marrone sul finto legno del tavolo attorno alla posizione della mano del mouse del collega. A quel punto ho una scrivania aperta proprio accanto all'area open space del call center, che ho preferito (con l'aiuto delle mie cuffie).
  • Poi c'è l'onnipresente bevanda da ufficio: il caffè. Anche se lo bevo, posso andare d'accordo senza e non bere più spesso di quanto possano fare altri colleghi. I respiri a distanza ravvicinata possono essere piuttosto spiacevoli, simili all'odore vuoto della tazza dimenticata. Chiamiamo la fragranza "afosa" ...

3

Penso che la programmazione delle coppie fallisca per motivi sociali e pratici. Fondamentalmente stai chiedendo a una persona di lavorare sotto costante sorveglianza e l'altra a non fare altro che creare buchi.

Ciò che inevitabilmente accade dopo un po 'è che la coppia si è divisa per "controllare le e-mail" o "si continua a controllare male su quel problema live" ecc.

Invece di migliorare l'output del codice, il volume viene ridotto. Sia per motivi pratici 'Ho bisogno di andare a pranzo / incontro per sincronizzarmi con te' che social 'Ill solo aspettare che Bob finisca quello che sta facendo prima di chiedere di accoppiarlo di nuovo, non voglio essere visto come un fastidio'

Per quanto riguarda i vantaggi vantati, ci sono molte pratiche comuni che li raggiungono in modi più semplici ed efficaci


2

Dire a due sviluppatori senior di fare una "programmazione dolorosa" se sono sicuri che si possa fare il lavoro è il più grande svantaggio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.