Elastic Pair Programming
Un modo alternativo di fare pair programming
Elastic Pair Programming
Qualche tempo fa ho trascorso una bella serata insieme ad Adrian Bolboacă, provando per la prima volta in pubblico una tecnica di pair programming osservata e sperimentata nelle aziende in cui ho lavorato.
In questo post vi racconto le caratteristiche di questo approccio.
Il pair programming tradizionale
Il pair programming è una pratica cardine di eXtreme Programming (XP), e non mi dilungherò nella sua spiegazione. Trovate una descrizione esaustiva sulla vecchia e cara C2 Wiki.
Ci sono vari modi di fare pair programming; nel suo ultimo libro, “Practical Remote Pair Programming”, Adrian illustra molto bene alcuni degli approcci più utilizzati.
Normalmente la pratica del pair programming è piuttosto disciplinata; i ruoli sono ben definiti, ci sono regole e tempi da rispettare.
La disciplina è uno dei punti di forza della tecnica, soprattutto all’inizio del viaggio verso l’XP.
Attraverso questa pratica, si innesca una continua collaborazione con i colleghi, rinforzando la capacità del singolo di comprendere ed elaborare i concetti di dominio.
Dopo anni di pratica, un team stabile raggiunge una elevata padronanza del proprio dominio applicativo, delle tecnologie e delle tecniche adottate dal team.
A quel punto, il pair programming “classico” finisce spesso per andare stretto, ed è in queste occasioni che è possibile allentare un po’ le regole e passare ad una modalità di lavoro più elastica.
Elastic pair programming
Il nome “elastic pair programming” è arrivato un po’ a sorpresa; prima di confrontarmi con Adi non avevo mai pensato a questo approccio come a qualcosa di definito, a cui dare un nome.
Nonostante questo, direi che la definizione rappresenta bene la caratteristica principale dell’approccio, ovvero l’elasticità di regole e ruoli.
A dire il vero di regole ce n’è solo una: ci si scambiano idee (e tastiera) in continuazione.
Ho trovato questo modo di lavorare molto utile in diverse situazioni.
La più classica è quella in cui alla tastiera ci sono due persone che si conoscono da tempo, entrambe professionisti con esperienza.
Non necessariamente si è esperti dello stesso dominio o delle stesse tecniche, anzi, spesso ho trovato interessante favorire il confronto tra punti di vista differenti.
L’idea è quella che, di fronte ad un problema ostico o peculiare, uno sviluppatore esperto chiami in causa un suo pari per condividere ed eventualmente confutare l’ipotesi di soluzione, e giungere magari ad una soluzione migliore o inaspettata per entrambi.
Ho usato questa tecnica spesso in modalità “on-demand”, chiamando in causa colleghi che normalmente non fanno pair programming con me o in team in cui la pratica non era consuetudine.
La pratica risulta interessante anche per “sbloccare” colleghi scettici rispetto alla pratica del pair programming.
Mi è capitato infatti di essere accolto in un team di soli senior, tutti molto ferrati sul dominio applicativo, in cui ognuno sviluppava in maniera abbastanza indipendente dagli altri.
Io avevo bisogno di imparare in fretta, così ho cercato di introdurre la pratica del pair programming nel team per favorire le occasioni di condivisione; nonostante i colleghi fossero disponibili, era abbastanza evidente per me la loro insofferenza verso le regole imposte dalla pratica.
A quel punto, quando ho capito che l’esperimento pair programming sarebbe inesorabilmente fallito, ho cercato approcci e soluzioni per non perdere le opportunità di confronto, tanto utili per me (ma a tendere per l’intero team).
In questa situazione abbiamo quindi rilassato le regole, concedendoci di prendere la tastiera in qualsiasi momento per intervenire.
I test, le implementazioni e le soluzioni hanno iniziato quindi ad emergere con più facilità, e così le discussioni in merito ai dettagli del linguaggio, ai pattern, o ai differenti approcci che ognuno di noi, per la sua esperienza, ha accumulato durante gli anni.
In questa situazione sono riuscito ad ottenere comunque i benefici della condivisione di conoscenza, molto importanti per me, rinunciando al “side-effect” (che comunque continuo ad apprezzare) della disciplina e della cadenza che da il pair programming tradizionale.
Un’altra situazione che ricordo bene è quella che avveniva quando mi confrontavo con i miei colleghi nelle gilde.
Le gilde sono uno strumento molto potente che l’azienda ci metteva a disposizione per imparare, crescere e migliorare le nostre capacità.
Nelle gilde, dei “team” creati ad-hoc lavorano ad un progetto proposto e scelto da loro, con il fine di esplorare nuove tecnologie o approcci.
In situazioni come queste, molto rilassate ed aperte al confronto, abbiamo trovato beneficio nel lavorare in usando questo stile elastico di pair programming, ed è stato poi abbastanza naturale per noi evolvere fino a quello che oggi è normalmente indicato come ensemble (Mob) programming.
Trappole
Questa tecnica ha una sola regola, ma bisogna fare attenzione: è proprio quando ci sono poche regole che è più facile sbagliare.
Questo approccio può diventare facilmente un sistema proprio per non fare pair programming; non avendo “obblighi”, è facile cadere nell’anti-pattern in cui il driver scrive codice e lavora da solo, mentre il navigator pensa ad altro…
In questa situazione è meglio piuttosto tornare a lavorare ognun per sé, e riflettere magari a livello di team su cosa impedisce questo genere di collaborazione e quali alternative abbiamo per continuare a mantenere alto il flusso di informazioni tra le persone.
Anche in assetto da elastic pair programming si stabiliscono dei working agreement, tra cui ad esempio tenere alla larga smartphone e distrazioni.
In alcune occasioni ho lavorato in pair con un secondo computer oltre a quello principale, un po’ come viene concesso anche in ensemble programming. Il computer secondario è di supporto: il navigator lo può usare ad esempio per cercare qualcosa in rete mentre il driver rimane focalizzato sul codice, non certo per farsi gli affari suoi. Il fine rimane sempre quello di scrivere codice e risolvere problemi insieme.
Un’altra raccomandazione è quella di non utilizzare questa tecnica senza avere esperienza di pair programming tradizionale, o fra due persone entrambe poco ferrate su tecnica e/o dominio. In questo caso si rischia facilmente di perdere la bussola e naufragare.
Come recitava un famoso spot pubblicitario di qualche anno fa, elastic pair programming è per molti, ma non per tutti 🙂
Il trucco che utilizzo io per decidere se è il caso di usare questo approccio è farmi una semplice domanda: “Sapresti risolvere da solo questo problema?”. Se la risposta è qualcosa tipo “Sì, ma sono curioso di sapere come lo risolverebbe -inserisci qui il nome-”, ci sono i presupposti per una buona sessione di elastic pair programming.
Elastic pair programming da remoto
L’esperienza con Adi mi ha fatto capire che questo stile può funzionare anche da remoto.
Anzi, la continua ricerca di consenso e lo scambio di ruoli mantiene alta l’attenzione delle persone, impedendo che la distanza fisica abbassi il confronto e lo scambio di idee.
Da qualche anno ho smesso di fare il programmatore a tempo pieno, anche se non di rado svolgo il mio lavoro di coach e trainer in team di sviluppo software.
Nelle esperienze che ho maturato nell’ultimo anno e mezzo di lavoro remoto forzato ho potuto osservare l’efficacia di questo stile, anche se spesso le persone erano inconsapevoli di fare questo genere di pair programming 🙂
Conclusioni
Non credo di aver inventato nulla di nuovo con questa tecnica, forse solo di aver dato un nome ad una pratica che molti programmatori già adottano da tempo.
Spero che questa consapevolezza aggiunga una opzione in più nella vostra cassetta degli attrezzi 😉