Negli ultimi mesi, sto lavorando con un’azienda che predilige l’uso della metodologia “Pair Programming“, chenon mi era mai capitato di utilizzare in modo costante. Certo, è successo a tutti di sedersi con un collega per discutere di un problema o guardare insieme un pezzo di codice alla ricerca di eventuali migliorie, ma farne una metodologia di lavoro è di sicuro tutt’altra cosa.

Innanzitutto, spieghiamo in cosa consiste questa metodologia, prendendo in prestito la definizione di Wikipedia: “è una tecnica agile di sviluppo del software nella quale due programmatori lavorano insieme a una postazione di lavoro. Uno dei due, indicato come “conducente” (“driver”) scrive il codice; l’altro, detto “osservatore” (“observer”) o “navigatore” (“navigator”), svolge un ruolo di supervisione e di revisione simultanea del codice. Il conducente ha l’obiettivo principale di portare a termine una soluzione funzionante del problema in considerazione, mentre al navigatore è lasciato il compito di segnalare errori del conducente o proporre strategie alternative di soluzione. I due programmatori cambiano spesso ruolo.” (https://it.wikipedia.org/wiki/Pair_programming).

Questa è solo una definizione di Pair Programming, ma la varietà di stili con cui è possibile metterla in atto è molteplice. Vediamo insieme qualche esempio.

Ping Pong Pairing

Questo stile fa al caso vostro quando utilizzate TDD come metodo di sviluppo. Avremo quindi i seguenti passaggi:

1. Ping: Sviluppatore A scrive un Unit Test che ha come esito Rosso (fallito)
2. Pong: Sviluppatore B scrive una prima implementazione in modo da rendere il test verde (passato)
3. A questo punto sarà lo sviluppatore B a scrivere il prossimo Ping (test rosso)
4. Dopo ogni Pong si fa una sessione di refactoring del codice in modo da utilizzare l’approccio Red – Green – Refactor (Scrivi test che fallisce, rendi il test verde con una prima implementazione, rifattorizzi il codice scritto)

Strong Style Pairing

Questo stile viene utilizzato specialmente quando bisogna introdurre un nuovo membro in un team o progetto. L’idea alla base è che un progetto di chi osserva venga implementato da chi scrive il codice. In questo stile, l’Observer è la persona con più esperienza e conoscenza di ciò che si andrà ad implementare, mentre il Driver è il novizio che, durante la fase di implementazione, probabilmente non capirà completamente quello che scriverà. Dopo l’implementazione, bisognerà dedicare uno spazio alle eventuali domande del Driver su quanto implementato. Questo stile è amato particolarmente da quei manager che prediligono un inserimento di un nuovo membro basato sul “fare” e non sull’osservare passivamente.

Per una corretta sessione di pair programming, non basta scegliere il giusto stile da utilizzare: ci sono altri aspetti da tener presente, in modo da non rendere l’esperienza frustrante.

Gestione del tempo

Non siamo delle macchine, lavorare otto ore consecutive insieme ad un’altra persona che ci osserva o anche da osservare non è facile: meglio utilizzare dei piccoli slot di tempo in cui concentrarsi su specifici aspetti dell’implementazione, che porteranno alla chiusura del task assegnato. Una delle tecniche consigliate è quella del “Pomodoro”, che si divide in cinque fasi:

1. Scegliere il task su cui lavorare
2. Settare un timer su un intervallo di tempo (di solito 25 minuti)
3. In questo intervallo, provare a lavorare senza interruzioni sul task scelto
4. Dopo il primo intervallo, fare una breve pausa (5-10 minuti)
5. Dopo 4 o 5 intervalli concedersi una pausa più lunga (15-30 minuti) in modo da ricaricare completamente le batterie evitando qualsiasi attività connessa al lavoro.

Rotazione del pair

La rotazione del pair prevede che, dopo un certo tempo (stabilito di comune accordo), uno dei due componenti del pair abbandoni il task che si sta affrontando, lasciando il posto ad una persona completamente nuova. Questo dovrebbe favorire lo sharing delle conoscenze all’interno del team ed evitare il concentrarsi delle conoscenze su singoli individui. Un altro motivo per cui è vantaggioso ruotare i pair è sicuramente quello logistico: uno dei due componenti potrebbe essere assente per malattia, o ferie. La rotazione porta vantaggi e svantaggi, sta ad ognuno capire il modo migliore per farlo.

Pianificazione della giornata

Lavorare in coppia richiede che le due persone si organizzino in modo da avere gli stessi slot di tempo liberi per dedicarsi allo sviluppo. Concordare gli orari per evitare impedimenti tipo meetings, permessi per faccende personali ecc. aumenta la produttività del pair ed evita la situazione spiacevole in cui uno dei due rimane fermo ad aspettare la disponibilità dell’altro.

Come tutte le metodologie di lavoro, anche questa ha i suoi vantaggi e svantaggi. Io vorrei spiegarvi cosa vi ho trovato di buono e cosa, invece, non mi ha convinto.

Vantaggi

Condivisione delle conoscenze: lavorare a stretto contatto con un’altra persona ha sicuramente il vantaggio di poter, in ogni caso, imparare qualcosa di nuovo. Osservare un diverso modo di pensare, di approcciare un problema e come risolverlo, aiuta sicuramente a crescere professionalmente.

Rapido inserimento in un nuovo team: di solito, quando si entra in un nuovo team, c’è sempre il primo periodo di adattamento per imparare la metodologia di lavoro, come svolgere dei task semplici per iniziare a conoscere i vari progetti su cui lavorare. Poter lavorare a stretto contatto con una persona che invece ha già esperienza su tutto quello che riguarda il lavoro che si andrà ad affrontare, permette comunque un inserimento “morbido” ma sicuramente più rapido ed efficace, sia che si faccia da Driver che da Observer. L’alternarsi delle due cose permette, anzi, in un caso di osservare i vari “segreti” utili per velocizzare il processo in cui si diventa produttivi, nell’altro può velocizzare l’individuazione di punti deboli su cui lavorare per aumentare la propria produttività.

Team Building: quale migliore occasione per conoscere i tuoi compagni di team se non lavorare a stretto contatto? Il pair programming non significa concentrarsi esclusivamente sul codice otto ore al giorno senza scambiarsi una parola. Anzi, secondo la mia esperienza, l’alternarsi di sessioni di coding e piccole pause caffè aumenta la produttività e la concentrazione.

Codice migliore: quattro occhi sono meglio di due. La matematica non è un’opinione, due persone che guardano lo stesso pezzo di codice hanno sicuramente meno possibilità di sbagliare. Si discute sulle scelte architetturali, su eventuali librerie da utilizzare e quali pattern scegliere. Il confronto è sempre una cosa buona e produce cose migliori.

Svantaggi

Effetto Traino: una delle cose peggiori che può succedere durante un pair, è che l’Observer sia poco coinvolto. Questo può capitare specialmente se il pair viene fatto da remoto: la lontananza fisica può portare a quel fenomeno per il quale l’Observer si fa un po’ i fatti suoi, lasciando il Driver da solo a risolvere il problema, e sminuendo l’utilità di questa metodologia di lavoro, producendo uno spreco di risorse economiche ed umane.

Pair Errato: c’è poco da fare, ad alcune persone piace particolarmente lavorare da soli, magari ascoltando musica, altri invece possono non essere a proprio agio mentre vengono osservati a scrivere codice. Qualsiasi sia il motivo, secondo me non è conveniente forzare un pair. Magari potrebbe essere utile far ruotare i pair del team fino a trovare quelli che funzionano. Questo è un altro aspetto controverso: alcuni sono dell’opinione che ruotare i pair ad intervalli regolari porti esclusivamente benefici, magari per alcuni dei motivi che spiegavo sopra (come la condivisione delle conoscenze). Secondo la mia esperienza, non è sempre giusto: fa bene ogni tanto magari ogni due o tre iterazioni cambiare partner, in modo da arricchire la propria esperienza, ma se si è trovato un buon compagno di lavoro che aumenta la vostra produttività e non fa risultare pesante la giornata di lavoro, è giusto continuare a lavorarci assieme.

Pair esclusivamente remoto: uno dei vantaggi di questa metodologia è sicuramente il poter interagire con un’altra persona stando a stretto contatto. Per me, il metodo migliore è quello in cui si utilizza un solo terminale e il pair seduto alla stessa scrivania lavora e discute del task di cui si sta occupando scambiando spesso i ruoli di Driver e Observer. Lavorare sempre da remoto con un’altra persona, che magari non si è mai conosciuto personalmente, può rendere questa metodologia a volte pesante. Non è naturalmente la regola, tutti questi discorsi sono sicuramente soggettivi e magari ci sono persone che invece preferiscono di gran lunga lavorare esclusivamente da remoto. Ma, secondo me, la parte di interazione sociale è molto importante per far funzionare questa tecnica di lavorazione.

Conclusioni

Come già detto, tutto questo è molto soggettivo. Quello che posso dire è che, come ogni cosa, anche l’utilizzo di questa metodologia aumenta sicuramente il proprio bagaglio di esperienze. Entrando nello specifico, mi è capitato molto spesso di essere in pair con un collega veramente molto bravo sul TDD (Test Driven Development): osservare il suo modo di lavorare e ricevere correzioni sul mio lavoro, mi ha aiutato notevolmente ad imparare ad utilizzare correttamente ed efficientemente questa metodologia di sviluppo.

Anche il livello di esperienza dei due attori coinvolti è molto importante nel pair programming: lavorare con un altro Senior può essere sicuramente divertente e ti permette di crescere, ma d’altro canto lavorare con uno sviluppatore dal profilo Junior aiuta a far crescere il team, trasferendo conoscenze ad una persona con meno esperienza di te.

Spero di aver alimentato la vostra curiosità sull’argomento e magari la voglia di provare il pair programming nei vostri cicli produttivi.

Al prossimo articolo!