Dai post e feedback precedenti (qui e qui) se la convenienza anche in termini di tempi di sviluppo del pair programming per problemi complessi e per la qualità del codice, per problemi semplici due sviluppatori spaiati sembrano andare più veloci.
Ho notato che quando sono observer mentre il driver è alla tastiera ed il problema è semplice in effetti tendo a distrarmi non essendo necessaria la mia attenzione. Lo switch tra observer e driver mi obbliga a stare attento ma non basta.
Pensandoci bene tuttavia...
...se il problema è semplice vuol dire che c'è spazio per fare di più e/o meglio:
- fare palestra - se si stà scrivendo codice nuovo per un problema semplice è un'ottima occasione per osare di più nel disegno, fare esperienza, cercando di applicare miglioramenti che in condizioni normali sarebbero troppo rischiosi
- migliorare il codice - se si stà rimuovento un bug o implementando una evoluzione troppo semplice è un'ottima occasione per aggiungere valore al codice facendo refactoring
- finire in fretta - se si stà rimuovento un bug o implementando una evoluzione troppo semplice ma l'assenza di test e la qualità del codice impedisce qualsiasi iniziativa di refactoring (si sta lavorando su un prodotto che è a fine corsa) è un'ottima occasione per finire in fretta e togliersi la rottura di scatole andando molto più veloci alla tastiera con la tranquillità di avere l'observer che ci fa da rete di sicurezza.
Non è naturale accellerare di più quando la strada è semplice? Forse il motivo per cui non accade è che prima bisogna aver sviluppato una buona fiducia reciproca col pair e col pair programming in genere. La capacità di beneficiare del pair programming anche per problemi semplici probabilmente è una qualità dei dev XP più esperti.
Aggiornamento del 3-Giu-2006
Ecco alcuni accorgimenti che mi hanno aiutato a tenere alta la velocità quando lo sviluppo era semplice ma lungo:
- Prima di iniziare stendere col proprio pair una scaletta delle cose da implementare (che indica i punti di intervento sul codice e gli scopi che l'intervento vuole assolvere proprio a livello di codice) che sia chiara e condivisa da entrambi. come fosse una mappa del viaggio che poi potrà essere seguita ed eseguita celermente punto dopo punto.
- Lavorare a tempo finito:
- indicare un orario realistico per il completamento del lavoro/task (puntando all'eccellenza ma senza farsi catturare dalle sirene della perfezione)
- scrivere i vantaggi e/o i benefici a cui il completamento del lavoro/task aspira;
- a lavoro/task finito individuare un'altra attività gratificante da svolgere (come finire di lavorare ad un ora decente, occuparsi di un task particolarmente piacevole o interessante, fare una pausa piacevole e rilassante)
- In caso di stanchezza e perdita di lucidità chiamare un break e fare due passi fuori dall'ufficio, meglio se all'aperto per poi riprendere a piena velocità.
Aggiornamento del 25-Lug-2006
<<
If things seem under control, you’re just not going fast enough.
>>
Autore: Mario Andretti
Fonte: http://pierg.wordpress.com/2006/06/27/56/
Tags : Team Work | Agile | Pratiche |