Associa programmazione / collaborazione in una piccola azienda

Lavoro in una piccola società di sviluppo come sviluppatore principale. Abbiamo altri due sviluppatori, oltre al mio capo che è uno sviluppatore, ma in realtà non fa più gran parte della programmazione reale.

Il problema che sto cercando di superare è sfaccettato. Abbiamo tutti la tendenza a lavorare sui nostri progetti senza molta collaborazione tra di noi. È un dato di fatto, io (come lo sviluppatore più avanzato) chiedo l'opinione / aiuto degli altri più di quanto facciano i miei, perché apprezzo l'input di un occhio esterno.

Voglio aumentare la nostra collaborazione e l'ho espressa a loro. In gran parte perché mi piacerebbe mostrare loro alcune cose su come diventare sviluppatori migliori e seguire le migliori pratiche. Ma dati i tipi di personalità dei nostri altri sviluppatori, penso che siano più a loro agio nel lavorare da soli.

Ho letto della programmazione in coppia e ho letto (in alcuni forum) che non funziona bene quando uno sviluppatore è più avanzato degli altri (cosa che sono). Eppure, ritengo indispensabile iniziare a collaborare in modo che il nostro lavoro non sia così disparato.

La mia domanda è se qualcuno si è mai trovato in una situazione simile e cosa ha funzionato per loro?

Mi rendo conto che questa non è una situazione adatta a tutti, ma sono disposto a dare una possibilità a più approcci.

Lavoriamo tutti in un'area comune, gli sviluppatori non hanno uffici / cabine individuali.

Dato che è già stato discusso in altre risposte sul perché la programmazione delle coppie non è una soluzione per te , parlerò di ciò che abbiamo attualmente sperimentato e siamo soddisfatti dei risultati.

A mio avviso, ciò che puoi fare per aumentare la collaborazione è riunire due persone su ciascun 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 (stratificazione 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 contemporaneamente a questa coppia collaborante due progetti.

Di recente abbiamo sperimentato questo approccio, avendo uno di loro ha sviluppato modelli + integrazione con API e l'altro programmatore che gestisce viste e controller . Abbiamo trovato i seguenti vantaggi di questa impostazione:

1. La struttura del codice risulta in un modo molto migliore che se solo uno sta lavorando su tutti gli aspetti del progetto.
2. Non dobbiamo ricordare loro di impegnare il codice nel repository, ecc.
3. Devono impegnarsi a testare il codice a vicenda, invece di affidarsi esclusivamente al nostro QA dedicato per questo.

Secondo me, la programmazione delle coppie non è la soluzione al problema che sollevi.

Esistono due ruoli distinti in una programmazione di coppia. L' osservatore è lì per rivedere e fornire feedback sul codice scritto dal conducente . Se stai cercando di comunicare idee per migliorare le decisioni che prendono i tuoi programmatori junior, metto in dubbio l'efficacia della loro capacità di rivedere criticamente il codice che stai scrivendo quando svolgi il ruolo di autista.

Senza questa dinamica si perde il vantaggio della programmazione di coppia.

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

TL; DR : Non credo che la programmazione in coppia funzionerebbe per te. Invece dovresti cercare di preoccupare le persone della qualità a lungo termine del loro codice e far loro desiderare di trovare risposte. Questo deve essere fatto in modo informale.

A proposito di cultura e qualità

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

In altre parole, non vuoi assomigliare al seme che viene in giro a ronzare le ultime parole d'ordine, anche quando alla fine lo sei. La maggior parte dei programmatori che conosco ti taggerebbe mentalmente come rumore di fondo. Non essere un'ape corporativa.

A mio avviso, la domanda principale che dovresti porti è "Sono soddisfatto della qualità e del valore commerciale del codice che la mia organizzazione mette?" e se la risposta è negativa, dovresti chiedere "come faccio a invertire questa tendenza?".

In definitiva, qualità e valore sono definizioni umane a cui solo tu o qualcun altro della vostra organizzazione potete (e dovreste) pensare.

Accoppia programmazione e microgestione

Quindi, a rischio di sembrare un po 'avanti e aspro, mi sembra che leggere sulla programmazione di coppia in realtà ti abbia fatto pensare a qualche forma di microgestione o viceversa. MM è una ricetta sicura per alienare la maggior parte delle persone.

In difesa della programmazione in coppia: la programmazione in coppia non riguarda il fatto che un ragazzo si guardi alle spalle. Questo è micro quanto la gestione. PP riguarda l'uso di due menti per pensare a due livelli contemporaneamente: una persona si occupa di problemi di alto livello e di grande immagine , mentre l'altra si prende cura dei dadi necessari per produrre codice funzionante. E a mio modesto parere, raramente funziona bene se i due partecipanti non sono in grado di cambiare posto. Dovrebbero essere abbastanza simili per avere un simile arsenale professionale di concetti e un vocabolario professionale condiviso (non siamo collegati alla mente - eppure , muhahaha).

Per la tua situazione, direi che dal momento che sei una piccola squadra e sei l'unico con esperienza reale (è quello che mi sembra il tuo post), programmare in coppia o rivedere la maggior parte del codice la maggior parte delle volte non funziona. Hai solo 24 ore al giorno. Invece, alcune soluzioni che potresti prendere in considerazione:

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

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

• Dai un'occhiata ad alcuni dei codici che controllano e sfidali in modo informale con alcune domande relative alla sua evoluzione a lungo termine. La maggior parte dei programmatori principianti non è semplicemente abituata a pensare a rendere il proprio codice leggibile e mantenibile. Una volta che hai questi problemi in testa, cercheranno ulteriori informazioni da soli, da te o da altre fonti.

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

Penso che un'alternativa migliore alla tua situazione sia la revisione del codice, soprattutto se li adatti in modo appropriato. Una revisione del codice può consistere in qualsiasi cosa, da una persona che osserva un po 'di codice e fornisce feedback a più persone (anche l'intero team) in una stanza per un'ora o due per esaminare l'intero progetto e l'implementazione di un componente. Questi possono essere variati in base al lavoro svolto, soprattutto in base alle conoscenze, alle esperienze e alle esigenze del team. È ancora possibile ottenere l'aspetto della condivisione delle conoscenze facendo partecipare più persone alla revisione allo scopo di trovare problemi, fornire suggerimenti e acquisire conoscenza leggendo gli output della recensione per incorporare i commenti nel proprio lavoro, prima di averla rivista .

La mia domanda è se qualcuno si è mai trovato in una situazione simile e cosa ha funzionato per loro.

Dato che stai invitando l'esperienza, ecco cosa ho fatto. Ho scelto l'approccio a basso rischio e ho chiesto a qualcuno decenni più giovane di me di trascorrere del tempo lavorando 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 un mentore, che era qualcosa di cui non avevo idea in anticipo. Quindi ha aperto la comunicazione in entrambe le direzioni in modo molto positivo.

È un dato di fatto, io (come lo sviluppatore più avanzato) chiedo l'opinione / aiuto degli altri più di quanto facciano i miei, perché apprezzo l'input di un occhio esterno.

Sembra che potresti inquadrarlo come una progressione logica di ciò che stai attualmente facendo.

Alcuni mesi dopo aver sollevato questa domanda, devo dire che sono contento dei nostri risultati. Ma non è esattamente quello che ho accettato all'inizio. Tieni presente che questa è una piccola squadra, quindi questa soluzione non si adatta a tutti.

Ho scoperto che è meglio lasciare che ognuno faccia il proprio lavoro. E nel tempo abbiamo sviluppato una fiducia reciproca in cui, se incontriamo un problema, chiamiamo gli altri in nostro aiuto. Non penso che qualcuno voglia lavorare con qualcuno che lo guardi alle spalle. Di tanto in tanto mi siedo dietro qualcuno e talvolta li aiuto attraverso un problema senza essere sollecitato. A volte non ho nulla da aggiungere e forse li infastidisco un po '. Ma capiscono che non sono lì per arpiarli. Sono principalmente lì per prendermi una pausa da quello che sto facendo e introdurre un po 'di collaborazione.

Quello che ho scoperto è che le persone GIUSTE nel tempo (in una piccola squadra) raccolgono e si sincronizzano con quello che fanno gli altri. Non è necessario gestire micro o dire a qualcuno che cosa fanno di sbagliato in ogni momento.

Di tanto in tanto, siediti con qualcuno e risolvi un problema, sia che tu sia un esperto o qualcuno che impari, o entrambi. Spiega perché dovresti o non faresti qualcosa in un modo invece che in un altro. Le buone idee prendono di solito, mentre altre rimangono indietro. E alla fine della giornata hai un gruppo produttivo e coeso di persone che potrebbero lavorare su cose diverse ma condividere uno scopo comune.