Pair Programming e tempi di sviluppo

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:

  1. 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.
  2. 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)
  3. 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 :   |  |  |

Print | posted @ Thursday, February 23, 2006 3:05 PM

Comments on this entry:

Gravatar # re: Pair Programming e tempi di sviluppo
by Antonio Ganci at 2/23/2006 4:32 PM

Per la mia esperienza la resistenza maggiore l'ho trovata nei colleghi più che nei dirigenti. Per me ha un grande valore e a volte non riesco quasi farni a meno; capisco comunque anche le opinioni contrarie anche se spesso sono frutto di pregiudizio più che di reale esperienza.
Gravatar # re: Pair Programming e tempi di sviluppo
by PierG at 7/25/2006 11:45 AM

Ma voi evidentemente siete fortunati: avete dei manager illuminati.

Non tutti sono nella vostra condizione privilegiata.

PierG
Comments have been closed on this topic.