Pair programming durante lo smart working: alcuni consigli
La situazione al momento è quantomeno particolare. I contatti umani veri e propri sono drasticamente ridotti e lo smart working è assodato ormai per tutti.
Questo porta inevitabilmente delle conseguenze, e a tal proposito credo sia interessante fare una valutazione sul pair programming non solo come pratica di sviluppo, ma anche come occasione di “incontro” per vivere meglio la situazione attuale.
Dato che i momenti di condivisione che consentiva l’ufficio sono andati sostanzialmente perduti, il fatto di lavorare su un task con un compagno di team può essere un buon modo per affrontare le eventuali difficoltà con maggiore energia, e, nondimeno, soddisfare quel bisogno di comunicare che in qualche misura ci caratterizza tutti.
Pair programming? Sì
Questa tecnica quindi potrebbe rivelarsi lo strumento vincente per affrontare meglio Story più o meno ostiche e allo stesso tempo consentire ai membri di un team di avere un po’ di quel contatto diretto che lavorando da casa e singolarmente non si potrebbe avere. E qui arriviamo al punto: non è l’home working ad essere spiacevole, quanto il doverlo fare quotidianamente che implica una “perdita” dal punto di vista umano.
Tutto ciò, grazie al pair programming, si può limitare.
Per i più coraggiosi esiste una modalità di questa tecnica diciamo estrema, ovvero il mob programming [1] di Woody Zuill (tra gli speaker dei recenti Italian Agile Days 2020). A tal proposito ricordo che durante la prossima iterazione delle gilde aziendali ce ne sarà una proprio su questo argomento.
Elenco ora alcune considerazioni che spero possano risultare utili relativamente al pair programming:
- Cambiare frequentemente i ruoli di “driver” e “navigator” è decisamente utile per tenere alto il livello di concentrazione e coinvolgimento di entrambe le parti.
- Se una delle due parti non è in condizione di dare un contributo efficace (per qualsiasi motivo) meglio comunicarlo e agire di conseguenza (se non è il caso di fare pair programming in un dato momento non c’è problema, “va benissimo così”).
- Potrebbe risultare più stancante fare pair programming che non lavorare singolarmente (anche solo per il grado di interazione che viene richiesto), quindi fare delle pause può essere d’aiuto.
- Durante uno Sprint è consigliabile ruotare le coppie in modo che ciascun membro del team lavori con persone diverse.
- Non tutte le coppie funzionano bene alla stessa maniera. In tal caso è consigliabile cercare di comunicare bene e non fermarsi al primo tentativo andato “quasi bene”.
- Può creare dipendenza.
Conclusioni
Consiglio di dare un’occhiata alla guida di questa pratica sul sito di Martin Fowler [2].
Alcune note:
- Fare pair programming senza essere davanti allo stesso computer è diverso da quello che prevede la pratica vera e propria, ma a grandi linee valgono le stesse regole.
- Nella mia esperienza ho praticato questa tecnica quasi esclusivamente da remoto.