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.