Nell’ultimo anno e mezzo di lavoro ho avuto l’occasione di lavorare in pair programming per gran parte della mia settimana lavorativa. In cosa consiste questa modalità di lavoro? Partiamo dalla definizione che ne dà Wikipedia:
tecnica di sviluppo del software nella quale due programmatori lavorano insieme a una postazione di lavoro
Nella mia esperienza la postazione di lavoro è un concetto superato. Io e molti miei colleghi lavoriamo da remoto, sparsi in diverse città d’Italia o – talvolta – d’Europa o del mondo.
In un’ottica di remote first questo non rappresenta in alcun modo uno svantaggio in termini di produttività e qualità del lavoro. Per il pair programming può anzi risultare un vantaggio: tolto il carico emotivo del dover lavorare fisicamente fianco a fianco con un’altra persona, se ne possono apprezzare meglio i benefici.
Non nascondo che questi non mi sono stati immediatamente evidenti: ho dovuto superare una fase di rodaggio in cui è stato, se non proprio la frustrazione, quanto meno il disagio a farla da padrone.
Il pair programming serve a tutti?
Per la natura del mio lavoro, front-end developer, non era raro che fossi l’unica a occuparmi di una parte o fase di un progetto, nelle aziende in cui ho lavorato in passato. Pensavo di non poter intervenire in altre fasi o di non aver bisogno di essere a conoscenza di alcune dinamiche o scelte architetturali, né tantomeno che altre figure professionali avessero la stessa esigenza nei confronti del mio lavoro e delle mie scelte.
Lavorare in ideato ha completamente ribaltato questa concezione, e una delle cose che ha contribuito maggiormente nel farmi cambiare visione è stato proprio il pair programming. Ho imparato che ragionando insieme si riesce a sviscerare meglio il problema, facendo emergere questioni che da soli probabilmente non avremmo notato oppure arrivando più in fretta a conclusioni che da soli avremmo impiegato più tempo a raggiungere.
Come facciamo pair programming da remoto?
Le esigenze tecniche sono unicamente una buona connessione e uno strumento per condividere il proprio schermo. Nel pair programming uno dei due sviluppatori si prende carico di scrivere il codice, l’altro è attivamente partecipe nel decidere come e cosa scrivere e cerca di mantenere una visione più ad ampio raggio rispetto al task che si sta svolgendo. Questi due ruoli vengono indicati con dei nomi mutuati dal rally: il primo è il driver, il secondo è il navigator. È una buona pratica scambiarsi spesso tali ruoli per far sì che ci sia un approccio sempre “fresco” al problema.
Il primo impatto, non molto positivo
Come è stato l’avvicinarsi e lo sperimentare questa pratica, per me totalmente nuova? Come accennavo, la prima fase non mi ha vista particolarmente entusiasta.
Ciascuno di noi può essere più o meno propenso a lavorare in coppia, per motivi caratteriali, abitudine, insicurezza o – al contrario – eccessiva sicurezza.
Si potrebbe ritenere uno spreco di tempo ed energia l’assegnare due persone ad uno stesso compito, poiché uno solo dei due produce materialmente codice si tende a pensare che l’altro sia un mero spettatore e che abbia un ruolo passivo. Questo accade soprattutto quando la coppia di driver e navigator è composta da professionisti con diverso grado di competenza ed esperienza e a fare da driver è quello più esperto. Viceversa, se la scrittura del codice viene affidata al programmatore meno esperto, questi potrebbe sentirsi sotto osservazione e provare ansia da prestazione o altre sensazioni tutt’altro che positive.
Questo, non lo nego, è stato quello che ho pensato anche io nelle primissime sessioni di pair programming.
I vantaggi, provati sulla mia pelle
Fortunatamente è bastato pochissimo per farmi ricredere: mi sono accorta che stavo opponendo resistenza ignorando il fatto che i benefici del pair programming superavano di gran lunga il disagio del dover affrontare questa modalità così nuova e per certi versi così “intensa” a livello emotivo.
Proverò ad elencare alcuni dei vantaggi che ho trovato, per grandi linee:
- condivisione della conoscenza all’interno del team: la composizione delle coppie di sviluppatori che fanno pair cambia continuamente, le informazioni si spostano agevolmente di testa in testa e in breve tempo tutto il team è aggiornato e acquisisce una buona conoscenza di dominio, molto più velocemente che se ci si affidasse ai soli riti (standup, iteration meeting ecc.) in cui l’intero team si confronta;
- maggiore qualità del codice: scrivere essendo “osservati” da qualcun altro ci obbliga a domandarci se quello che stiamo facendo è chiaro per entrambi; discutendo si giunge alla produzione di codice più leggibile e più stabile;
- minore spreco di tempo: l’essere focalizzati in due su un obiettivo porta a lavorare con maggiore velocità e più concentrazione, è più difficile che ci si ritrovi impantanati in situazioni che sembrano irrisolvibili perché si analizzano i problemi insieme. Può anche succedere che il collega con cui facciamo pair si sia già imbattuto nello stesso problema e si giunga prima a una soluzione.
Un ottimo strumento per i remote worker
Ovviamente il pair programming non è la panacea per tutti i mali, è uno strumento e come tale va utilizzato quando è utile farlo.
Ci sono circostanze in cui non è consigliabile o rappresenta un’effettiva perdita di tempo, ad esempio in presenza di task molto semplici o di competenze talmente diverse che non porterebbero “contaminazione” né crescita di una parte o dell’altra.
Va tenuto conto delle caratteristiche individuali di ciascuno e del fatto che per alcuni il dover programmare in pair potrebbe rappresentare solo uno stress.
Per la mia esperienza è uno strumento utile in particolare per i remote worker: aiuta a recuperare un po’ quel senso di condivisione e confronto che verrebbe a mancare se si lavorasse tutto il giorno in solitaria. In più aiuta molto ad avere consapevolezza dei diversi modi di pensare, ad arrivare a una conclusione e ad affrontare un problema, favorendo un indubbio arricchimento.
Mi piace apprezzare ogni volta il senso di sinergia che fare pair programming mi lascia: insieme si lavora per raggiungere un obiettivo comune. L’importante è fare pratica e capire anche quando è il caso di lasciar perdere.
È un po’ come andare in tandem: se si pedala insieme si va spediti ma bisogna essere ben coordinati e cercare di andare allo stesso ritmo. Sperimentando si capisce anche che ci sono tratti abbastanza brevi da poter essere affrontati a piedi in solitaria, situazioni in cui ci sentiamo nelle gambe uno sprint da velocisti e situazioni in cui ci lasceremmo solo trascinare da chi pedala, rallentandolo.
Il pair programming è quindi un mezzo col quale raggiungere una meta, a noi scegliere se e quando sia il mezzo migliore.
Flowing nasce il 19.02.2019 dalla fusione di ideato e extrategy, ecco perché in questo post trovi uno di questi brand! Scopri di più sul nostro speciale percorso di co-creazione di Flowing.
