Pair Programming or not Pair Programming? Questo è il problema
Pair Programming, team programming (Mob Programming, Ensemble o Posse Programming) o in generale tutte le forme di programmazione in gruppo, nei team di sviluppo software sono ancora oggi un argomento di dibattito e di discussione.
Come Scrum Master, da alcuni anni seguo team molto diversi tra loro che sviluppano soluzioni software differenti. Diverse le società, diversi i contesti, diversi i team e per ognuno la domanda se ha senso fare Pair Programming è spesso presente, senza una risposta definitiva.
Con questo articolo vorrei parlare di ciò che ho colto dall’esperienza sul Pair Programming: ho svolto qualche esperimento vestendo i panni dello sviluppatore, ma, soprattutto, come Scrum Master ho avuto l’opportunità di osservare dall’esterno cosa succede quando due o più persone scrivono codice insieme.
Che cosa significa l’espressione “Pair Programming”?
Il pair programming affonda le proprie radici nell’eXtreme Programming, una metodologia di sviluppo software “mirata a migliorare la qualità del codice e la responsività al cambiamento dei requisiti del cliente“.
La metodologia del Pair Programming prevede la presenza di due persone su uno stesso terminale. In generale si identificano due ruoli: il “driver” (conducente) ha il compito di scrivere il codice, mentre il “navigator” (navigatore o osservatore) ha il compito di supervisionare e correggere il codice man mano che viene scritto.
Durante l’attività, i ruoli possono essere scambiati a intervalli regolari così che il navigator diventi driver e viceversa.
Pair Programming: gli aspetti più interessanti
In genere, la prima volta che ci si avvicina a questa tecnica si ha l’impressione di “perdere tempo”. L’intuito e l’istinto ci portano a pensare che la “velocity” si dimezza: lo stesso lavoro fatto “in pairing” potrebbe essere svolto da due persone contemporaneamente, raddoppiando la velocità.
Su questo punto occorre però fare attenzione: l’istinto e l’intuito spesso ci possono ingannare; per una reale valutazione occorre procedere con un’analisi più profonda in modo da comprenderne i reali pregi e difetti (soprattutto nel medio/lungo periodo). I risultati di questa analisi possono essere sorprendenti e inattesi.
Vi sono diversi aspetti della programmazione in gruppo (due o più persone) che hanno catturato la mia attenzione. Di seguito vorrei provare a fare un elenco dei punti che ritengo più interessanti: per ognuno di essi si potrebbe forse dedicare un articolo a parte, ma per il momento vorrei accontentarmi di descrivere a grandi linee queste meccaniche “nascoste”.
Esposizione di idee e concetti
Quando elaboriamo un concetto o un’idea e dobbiamo esporla a un nostro interlocutore, introduciamo dentro di noi dei meccanismi di revisione aggiuntivi; questo non avviene quando non dobbiamo “rendere conto” a nessuno di ciò che diciamo. Se pensiamo a qualcosa, ma non dobbiamo dirlo a nessuno, il pensiero non viene sottoposto a un certo livello di critica o a delle severe revisioni.
Lo definirei come una sorta di “effetto spotlight” ristretto e valido solo nel contesto della collaborazione lavorativa.
Le idee o i concetti che non ci convincono fino in fondo vengono in un qualche modo elaborati, verificati e infine respinti da noi stessi. È come se la sola presenza di un’altra persona ci stimoli a estrarre il meglio di noi, come se ci forzasse di validare ulteriormente ciò che abbiamo elaborato.
Non saprei dire se è perché temiamo il giudizio altrui o meno, ma quello che si sperimenta è un accrescimento del valore delle idee che il singolo elabora e condivide: solo le idee migliori, revisionate nelle proprie interiorità, vengono condivise.
La coppia o il gruppo quindi beneficia solo delle idee migliori dei singoli.
Chiarezza di idee e concetti
Penso sia capitato un po’ a chiunque: avere un’idea non del tutto chiara e provare a esporla a una persona che ci sta di fronte. Tramite la semplice esposizione il nostro pensare si schiarisce e comprendiamo meglio le idee e i concetti che in un primo momento sembravano confusi.
Questo meccanismo di chiarezza e di auto correzione avviene tramite la semplice esposizione di ciò che abbiamo pensato. È un po’ come se il solo fatto di essere ascoltati, di ascoltare chiaramente la nostra voce che esprime i concetti, di essere costretti a formulare delle frasi con chiarezza, ci metta in una condizione privilegiata di rielaborazione del nostro pensiero.
Questo aspetto aiuta le persone a chiarire concetti e li allena a formulare pensieri sempre più strutturati e logici.
Parallelismo
Ho colto questa caratteristica solo quando ho osservato dall’esterno delle persone coinvolte nella programmazione di gruppo.
Quando due programmatori collaborano, le attività non seguono un percorso lineare bensì quello di persone coinvolte. È abbastanza frequente che nascano delle micro-attività che possono essere immediatamente parallelizzate. Un tipico esempio è la ricerca di un’informazione chiave nel Web: mentre una persona va avanti con il lavoro, l’altra si attiva nella ricerca. Anche nei casi in cui l’informazione risulti bloccante per il prosieguo del lavoro, le persone si attivano contemporaneamente nella ricerca e spesso il risultato arriva molto prima che non eseguendo la ricerca da soli. Inoltre, la ricerca non è quasi mai lineare: durante la ricerca di un’informazione si avanzano ipotesi, discussioni, idee, ecc; tutte cose che aiutano le persone a identificare una soluzione migliore.
Di queste operazioni, mentre lavoriamo insieme ve ne sono molte. Forse se ne ha poca coscienza perché quando siamo coinvolti vediamo solo il nostro operato, ma vi assicuro che dall’esterno questo meccanismo è molto più visibile e salta all’occhio facilmente.
Condivisione delle conoscenze tecnologiche e di dominio
La collaborazione permette alle persone di apprendere. Molto semplicemente, quando le persone coinvolte nel Pair Programming condividono la propria conoscenza (sia essa tecnologica o di dominio dell’applicazione), indirettamente stanno aiutando le persone attorno ad apprendere. Se un’idea o una proposta non è chiara sarà naturale chiederne spiegazione e così facendo la conoscenza passa da una persona all’altra.
Da un certo punto di vista è un ottimo modo per formarsi: si ha un insegnante dedicato, si può interagire direttamente, ci si concentra solo su un argomento ben definito e limitato, la conversazione avviene nel linguaggio adatto a chi sta ascoltando, l’esposizione e la profondità degli argomenti sono calibrati perfettamente sulla base delle necessità di quel momento.
Modalità di pensiero
“Chi va con lo zoppo impara a zoppicare“. Questa frase ha chiaramente un’accezione negativa. Vorrei invece provare a darle un significato positivo: cosa avviene quando siamo spesso a contatto con una persona con cui di sovente lavoriamo insieme? Quello che accade, un po’ inconsciamente, senza che ce ne accorgiamo, è che iniziamo a comprendere come questa persona ragiona, che metodologie usa, che chiarezza di pensiero ha e come si muove di fronte a un determinato problema.
Non solo comprendiamo queste cose, ma in un qualche modo le facciamo nostre: in modo inconsapevole le “rubiamo” il “modus operandi” e la “forma mentis”.
A livello di pensiero impariamo a ragionare e a pensare come la persona che ci sta di fronte.
È singolare come questo avvenga in modo più deciso quando siamo a contatto con persone di cui abbiamo una grande stima; avviene molto meno se invece non condividiamo molto delle persone con cui operiamo.
In modo forse non consapevole, dentro di noi assorbiamo quello che stimiamo e rigettiamo quello che consideriamo non interessante.
In un qualche modo, cresciamo e ci miglioriamo senza che ce ne rendiamo conto.
Problem solving
“Vi è mai capitato di avere un bug urgente da risolvere e dover chiamare diversi colleghi per aiutarvi?” “Avete mai meditato sulle dinamiche di quanto succede?” “Perché la risoluzione di un problema in una situazione urgente viene spesso affrontata da più persone?”
Quello che dall’esterno si osserva è che le persone comprendono immediatamente l’obiettivo comune, mettono a disposizione le proprie conoscenze, le proprie energie, si attivano per contribuire attivamente al processo, fanno ipotesi, validano le proposte degli altri, provano a fare analisi e a proporre soluzioni di diagnostica o di verifica.
Di solito succede che il problema si risolve in breve tempo e con l’aiuto di tutti.
In una situazione di stress emerge il miglior modo di lavorare e… funziona!
Perdita di autonomia personale
Se da un lato il Pair Programming aiuta la collaborazione tra le persone, da un altro punto di vista mi è parso che limiti la crescita dell’autonomia personale.
Nel mondo del lavoro è essenziale sviluppare delle capacità di autonomia e di auto-organizzazione. Queste facoltà si sviluppano meglio quando siamo soli di fronte a un problema e non riceviamo aiuti da nessuno. In tali situazioni siamo costretti a far emergere tutte le nostre qualità nel tentativo di risolvere la situazione.
Anche se sgradevoli, queste situazioni ci aiutano e ci permettono di rafforzare le nostra figura professionale.
Le interazioni: una questione anche di carattere
È fondamentale che le persone coinvolte nella collaborazione siano di mente aperta e che sentano la ricerca della verità come un obiettivo comune da raggiungere.
Se ci si dispone in tal modo, senza pregiudizi o posizioni di parte, si innesca un dialogo costruttivo che porta a considerare e validare solo le idee migliori. È un processo virtuoso che permette alle persone di scegliere tra le diverse soluzioni possibili quella che presenta più vantaggi o meno svantaggi.
Su questo aspetto occorre fare molta attenzione: la collaborazione con uno o più “compagni di viaggio” potrebbe far emergere delle criticità. Se ad esempio vi sono persone molto introverse o di incompatibilità caratteriali, ci si potrebbe trovare di fronte a situazioni di disagio personale. In tal caso, è importante che i gruppi e le coppie si formino con il benestare degli interessati in modo tale da creare fin da subito un ambiente sereno e amichevole in cui le persone coinvolte possano essere propense a condividere ciò che pensano senza impedimenti di sorta.
Questo aspetto è un punto abilitante: se vi è una buona armonia tra le persone che collaborano, tutti i punti precedenti trovano compimento e si genera un valore eccezionale. Al contrario, se il rapporto tra le persone diventa difficile o peggio litigioso, nessuno dei punti sopra descritti si innesca, vanificando lo sforzo.
Pair Programming: qualche contesto e un metodo di valutazione
Il Pair Programming (o anche la programmazione in gruppo) può essere applicata con costanza all’interno di un’azienda fino a diventare la normale pratica di lavoro in qualunque situazione.
Per chi invece ha ancora molti dubbi o anche solo una semplice curiosità, vorrei lasciare un ultimo consiglio: considerate il Pair Programming (o in generale la programmazione a gruppi) come un’opportunità da valutare sul campo. È più rapido e semplice fare una prova reale e valutare i relativi vantaggi e svantaggi piuttosto che continuare a ragionare sulla carta.
Se volete fare una prova, vi suggerisco alcune situazioni tipiche in cui il Pair Programming sembra adattarsi bene per risolvere determinati problemi.
Single point of failure e bus-factor
È ad esempio un ottimo modo per condividere le informazioni e quindi risolvere i tipici problemi di “single point of failure” che si possono verificare nei team in cui una persona detiene una conoscenza chiave. Riducendo il “bus-factor” si abbassa il rischio di trovarsi in situazioni di necessità senza le dovute competenze.
Affiancamento
Anche l’affiancamento in ingresso e/o in uscita da parte di un collega è un’ottima occasione per sperimentare il Pair Programming: la condivisione della conoscenza avviene in modo ottimale se ci si affianca a qualcuno per un certo periodo (ad esempio i canonici due/tre mesi).
Code Review
La Code Review è un’altra situazione in cui si può ricorrere al Pair Programming: sia perché il codice viene scritto direttamente dalla coppia (o dal gruppo) determinando una review “by-default”; sia scegliendo di fare pairing/mob per mostrare quanto fatto fino a quel momento.
Pair Programming: applicazione e metro di misura
Selezionate delle persone che volontariamente vorrebbero cimentarsi nel Pair Programming; selezionate un paniere di situazioni utili allo scopo (ad esempio quelle citate poco sopra o comunque attività non critiche); decidete un intervallo temporale e definite delle logiche di rotazione tra le persone.
Alla fine dell’esperimento basterà raccogliere il parere delle persone coinvolte: chi ha lavorato in tal modo è la persona migliore per fornirvi un responso.
Conclusioni
Le realtà in cui viviamo sono estremamente diverse perché diversi sono gli ambiti tecnologici, diversi i prodotti e diverse le persone. Per applicare il Pair Programming, o in generale la programmazione in gruppo, non esiste una regola valida per tutti e per tutti i casi: data la situazione e conoscendo bene lo strumento, ognuno deve trovare la propria strada per creare un buon ambiente lavorativo, efficace ed efficiente.
Magari, aiutati da uno Scrum Master!