Pair Programming / Collaboration in una piccola azienda

Alcuni mesi dopo aver sollevato questa domanda, devo dire che sono soddisfatto dei nostri risultati. Ma non è esattamente quello che ho accettato all'inizio. Tieni presente che si tratta di un team ristretto, quindi questa soluzione non si adatta a tutti.

Ho trovato che è meglio lasciare che ognuno faccia il proprio lavoro. E nel tempo abbiamo sviluppato una fiducia reciproca in cui, se ci imbattiamo in un problema, chiamiamo gli altri in nostro aiuto. Non credo che qualcuno voglia lavorare con qualcuno che veglia sulle loro spalle. Di tanto in tanto mi siedo dietro qualcuno e qualche volta li aiuto attraverso un problema senza essere sollecitato. A volte non ho nulla da aggiungere e forse li infastidisco un po '. Ma capiscono che io non sono lì per arparli. Sono principalmente lì per fare una pausa da quello che sto facendo e presentare un po 'di collaborazione.

Ciò che ho scoperto è che le persone GIUSTE nel tempo (in una piccola squadra) prendono e si sincronizzano con quelle che gli altri stanno facendo. Non è necessario gestire o comunicare a qualcuno ciò che stanno facendo sempre male.

Di tanto in tanto, siediti con qualcuno e affronta un problema, dove sei un esperto o qualcuno che sta imparando, o entrambi. Spiega perché potresti o non farei qualcosa in un modo piuttosto che in un altro. Le buone idee prendono di solito, mentre altre rimangono indietro. E alla fine della giornata hai un gruppo di persone produttivo e coeso che potrebbe lavorare su cose diverse ma condividere uno scopo comune.

Poiché è già stato discusso in altre risposte perché la programmazione della coppia non è una soluzione per te , I discuterà ciò che abbiamo attualmente sperimentato e siamo soddisfatti dei risultati.

Secondo me, ciò che puoi fare per aumentare la collaborazione è avere due persone insieme per ogni progetto. Ognuno di loro lavora su una parte diversa del progetto, ma poiché queste parti devono essere integrate i due sviluppatori devono collaborare. Ciò richiede anche che i due programmatori discutano l'architettura (layering e interfacce) del progetto e quindi decidano di assumere ruoli diversi.

E, se questo approccio, limita il numero di progetti che la tua azienda può gestire contemporaneamente, puoi assegnare a questa coppia collaborante due progetti contemporaneamente.

Recentemente abbiamo sperimentato questo approccio, avendo uno di loro sviluppato modelli + integrazione con apis e l'altro programmatore che gestisce views e controller . Abbiamo trovato i seguenti vantaggi di questa impostazione:

1. La struttura del codice risulta in un modo molto migliore rispetto al caso in cui uno solo lavori su tutti gli aspetti del progetto.
2. Non dobbiamo ricordare loro di commettere codice nel repository ecc.
3. Devono sforzarsi di testare il codice degli altri, invece di affidarsi esclusivamente al nostro QA dedicato.

A mio parere, la programmazione di coppie non è la soluzione al problema che si pone.

Ci sono due ruoli distinti nella programmazione di una coppia. observer è lì per rivedere e feedback sul codice scritto dal driver . Se stai cercando di trasmettere idee per migliorare le decisioni che i tuoi programmatori junior stanno facendo, mi chiedo quanto sia efficace la possibilità di trovare la loro capacità di rivedere criticamente il codice che stai scrivendo quando stai eseguendo il ruolo del driver.

Senza questa dinamica il vantaggio della programmazione della coppia è perso.

Come programmatore senior ti suggerirei di prendere in considerazione un programma più strong di formazione e sviluppo dei dipendenti con il tuo capo. I tuoi programmatori junior dovrebbero avere una struttura per migliorare le loro capacità. In genere è possibile utilizzare metodi come illuminazioni, scrivere un documento di standard di codifica, suddividere attività autonome dal proprio lavoro e assicurare che siano in atto processi di revisione del codice adeguati.

TL; DR : Non penso che la programmazione di coppie funzioni per te. Invece dovresti cercare di far preoccupare le persone sulla qualità a lungo termine del loro codice e far sì che voglia trovi le risposte. Questo deve essere fatto in modo informale.

Informazioni su cultura e qualità

Ritengo che questo problema non riguardi la metodologia di programmazione, ma piuttosto la cultura . Nella mia esperienza, la cultura è possibile da dirigere, ma raramente raccontandone le persone. Cioè, provare a forzare un certo flusso di lavoro su persone che non si sono evolute in modo naturale o che è troppo lontano dalla pratica esistente è destinato ad avere conseguenze negative.

In altre parole, non vuoi sembrare il seme che viene in giro ronzando le ultime parole d'ordine, anche quando alla fine sei tu. La maggior parte dei programmatori che conosco potrebbero taggarti mentalmente come rumore di sottofondo. Non essere un'ape aziendale

Secondo me, la domanda principale che dovresti porci è "sono soddisfatto della qualità e del valore commerciale del codice che la mia organizzazione emette?" e se la risposta è negativa , dovresti chiedere "come posso girarlo?".

In definitiva, la qualità e il valore sono definizioni umane solo tu o qualcun altro nella tua organizzazione puoi (e dovresti) pensare.

Associa programmazione e microgestione

Quindi, a rischio di sembrare un po 'avanti e duro, mi sembra che leggere la programmazione della coppia ti abbia effettivamente fatto pensare a qualche forma di microgestione , o viceversa. MM è una ricetta infallibile per alienare la maggior parte delle persone.

In difesa della programmazione di coppie: la programmazione di coppia non riguarda un ragazzo che guarda oltre la spalla di un altro ragazzo. Che è tanto semplice quanto la gestione. In PP si tratta di usare due menti per pensare a due livelli contemporaneamente - una persona si occupa dei problemi di alto livello , big picture mentre l'altro si occupa di dadi e bulloni necessari per produrre codice funzionante. E a mio modesto parere, funziona raramente se i due partecipanti non sono in grado di cambiare posizione. Dovrebbero essere abbastanza esperti per avere un simile arsenale professionale di concetti e un vocabolario professionale condiviso (non siamo mentalmente legati - ancora , muhahaha).

Per la tua situazione, direi che tu sei un piccolo team e tu sei l'unico con esperienza reale (questo è quello che mi piace per il tuo post), la programmazione in coppia o la revisione della maggior parte del codice il tempo non avrebbe funzionato. Hai solo 24 ore al giorno. Invece, alcune soluzioni che potresti prendere in considerazione:

• Incoraggiali a partecipare a SO con il tag della lingua appropriato o a pubblicare alcuni frammenti di codice per la revisione su Code Review SE. Inizia un piccolo contest informale su chi può ottenere il maggior numero di punti Rep per settimana

  SO può fare miracoli per gli sviluppatori principianti poiché fornisce un feedback costante e segue il battito cardiaco della comunità.

• Dai un'occhiata ad alcuni dei codici che hanno registrato e contestali informalmente con alcune domande riguardanti la sua evoluzione a lungo termine. Molti programmatori principianti non sono semplicemente abituati a pensare di rendere il loro codice leggibile e mantenibile. Una volta che hai capito questi problemi, cercheranno più informazioni da soli, da te o da altre fonti.

Non penso che la programmazione in coppia sia qualcosa che ti possa aiutare nel tuo ambiente. Non è che non aiuterebbe gli sviluppatori meno esperti a fare esperienza - c'è anche una domanda dei programmatori sulla programmazione delle coppie con ingegneri di vari livelli di abilità . Anche se ci sono benefici come la condivisione delle conoscenze e meno errori, la programmazione delle coppie richiede un maggiore investimento nel tempo. Con un team di tre sviluppatori e solo quattro persone con background / esperienze di sviluppo, mantenere una routine di programmazione di coppia sembra essere difficile.

Penso che un'alternativa migliore nella tua situazione siano le revisioni del codice, specialmente se le adotti in modo appropriato. Una revisione del codice può consistere in qualsiasi cosa da parte di una persona che guarda oltre un piccolo pezzetto di codice e fornisce feedback a più persone (anche all'intero team) in una stanza per un'ora o due per esaminare la progettazione e l'implementazione di un intero componente. Questi possono essere variati in base al lavoro svolto, in particolare sulla base delle conoscenze, delle esperienze e delle esigenze della squadra. È ancora possibile ottenere l'aspetto della condivisione della conoscenza facendo partecipare più persone alla revisione allo scopo di trovare problemi, fornire suggerimenti e acquisire conoscenze leggendo i risultati della revisione per incorporare i commenti nel proprio lavoro, prima che vengano revisionati . Ciò ha anche il vantaggio di consentire agli altri sviluppatori di lavorare individualmente fino a quando non considerano il loro lavoro da svolgere, ma offre comunque uno spazio per raggiungere gli obiettivi desiderati mentre utilizzano le conoscenze e le competenze dell'intero team.

My question is whether anyone has ever been in a similar situation, and what worked for them.

Dato che stai invitando l'esperienza, ecco cosa ho fatto. Ho scelto l'approccio a basso rischio e ho chiesto a qualcuno di decenni più giovane di me di passare un po 'di tempo a lavorare insieme. Non abbiamo etichettato l'attività. Nessuno, tranne me, sapeva che stavamo provando una nuova tecnica.

Non so esattamente quali dettagli mettere in relazione, ma il processo ha funzionato molto bene. Voleva essere mentorato, il che era qualcosa che non avevo in anticipo. Quindi ha aperto la comunicazione in entrambe le direzioni in modo molto positivo.

As a matter of fact, I (as the most advanced developer) ask for the others' opinion/help more than they do mine, because I value the input of an outside eye.

Sembra che potresti inquadrare questo come progressione logica di ciò che stai facendo attualmente.