Solidi ma agili con il pair programming

Il pair programming è la pratica diffusa in diverse metodologie di sviluppo agile che richiede a due programmatori di lavorare seduti uno accanto all’altro su una stessa macchina. Uno fa quello che l’altro non sta facendo. Uno scrive un test? L’altro pensa a come soddisfarlo. Uno scrive codice di una classe? L’altro cerca informazioni strategiche sul web. Sembra un spreco, ma non lo è. Il pair programming aiuta e, perché no, rende tutti più sereni, anche i manager! Vediamo come.

Nel mondo agile tipicamente la persona che scrive è chiamata driver mentre l’altra navigator. A me piace chiamarli rispettivamente tattico e strategico. Trovo che questi termini descrivano meglio il senso del ruolo proprio di ogni elemento della coppia: la strategia è il coordinamento di certe azioni mirando ad un obiettivo più o meno lontano, tattica è l’insieme di mezzi concreti utilizzato per raggiungere il singolo obiettivo intermedio. Quindi: il programmatore tattico scrive il codice, decide come renderlo elegante, leggibile, efficiente e decide, inoltre, come impiegare gli idiomi tipici del linguaggio per risolvere problemi tattici già incontrati; il programmatore strategico invece assiste questo processo pensando un passo più avanti, a come la classe che si sta scrivendo insieme si dovrà interfacciare alle altre preesistemti e alle altre da scrivere ancora, a quali classi si dovranno ancora scrivere, a quali test automatici saranno utili e, fondamentale, a quali design pattern sarà bene impiegare per risolvere problemi strategici già incontrati.

La critica che più frequentemente proviene da chi non ha mai provato questa tecnica davvero appieno – perché chi invece l’ha attuata con sincera dedizione non la critica mai! – è quella dettata dalla pura intuitività: due persone, lavorando contemporaneamente allo stesso compito, non risolvono la metà dei problemi nello stesso tempo? No, vediamo perché.

Se mi permettete di vedere per un momento la coppia di programmatori come un unico essere programmante, il punto fondamentale del pair programming può essere espresso non tanto nel tentativo di raddoppiare i picchi di intelligenza del programmatore che lavora da solo, quanto nel dimezzarne i picchi di idiozia. Con tutto il dovuto rispetto per tutti i programmatori nel mondo, a chi non è mai capitato di incappare in vicoli ciechi per ore, impegnati in tecnicismi di sterile produttività, in perversi gold-plating alla ricerca del Graal della perfezione del codice che non avrebbero mai più avuto riconoscimento in termini sia di gloria sia di denaro? Oppure più semplicemente a chi non è mai capitato di non vedere una soluzione a portata di mano per semplice distrazione o stanchezza? Programmare in coppia riduce il rischio che queste situazioni si ripropongano se non estremamente di rado.

Questa solidità si ripercuote in un miglioramento della qualità del codice scritto, sia a livello locale sia a livello globale, di architettura. Tale miglioramento a sua volta abbassa il tempo speso nel debugging, recuperando molto – se non la totalità – del tempo perso per l’assegnamento di due persone allo stesso task. La pratica del test-driven programming – di cui parleremo – entra in forte risonanza con la pratica del pair programming portando i team XP molto vicini all’ideale abolizione del debugging.

Abolire il debugging significa produrre di più. Non dimentichiamolo mai: fare debugging non è mai produttivo. Il debugging è sempre solo un costo.

Poco sopra ho scritto che il tempo recuperato con l’incremento di qualità della scrittura del codice non è detto che compensi completamente il rallentamento dovuto alla duplicazione dell’assegnazione sviluppatori-task. Alla resa dei conti ci interessa solo sapere se una pratica ci permetta di risparmiare tempo in assoluto e in pratica e non solo in teoria o in presenza di fortunate condizioni coincidenti. Perché allora insistiamo nell’adottare una tecnica che forse, pur se poco, qualcosa ci fa perdere in termini di tempo? La risposta è semplice: per ottenere predittibilità .

La verità è che un processo industriale sano ottiene pochi vantaggi dalla possibilità di essere rapidissimo se non può integrarsi con stime attendibili – seppur non necessariamente esatte. Il debugging è un’attività che, oltre a non essere produttiva, è completamente imprevedibile. Pertanto, ammesso e non concesso che il pair programming comporti un effettivo rallentamento dello sviluppo, possiamo tranquillamente stabilire che il costo di un rallentamento sufficientemente piccolo può essere accettato se in cambio si ottiene la possibilità di ridurre l’impatto del debugging nella pianificazione e quindi di fare dei piani di precisione maggiore.

Concludendo, il pair programming è una pratica che offre un intero ventaglio di vantaggi nell’attuazione di una metodologia agile per lo sviluppo software. Tra questi abbiamo visto che troviamo anche la possibilità di migliorare il planning dei nostri progetti con buona pace di manager, sviluppatori e clienti.

A presto con il prossimo articolo! Ciao!

April 25 2008 02:00 am | Base and Le pratiche XP

8 Responses to “Solidi ma agili con il pair programming”

  1. Pair programming rocks! | Sviluppo Agile on 03 Aug 2008 at 13:10 #

    [...] Il dominio da trattare e, di conseguenza, da descrivere avrebbe potuto essere un vero problema considerato anche che io e Marc non avevamo mai lavorato insieme prima d’ora. Fortunatamente la condivisione dei valori agili e la conoscenza delle relative pratiche ha fatto sì che esistesse una via per stabilire una rapida comunicazione fin dalle prime ore insieme: il pair programming. [...]

  2. Luisa Mortola on 24 Sep 2008 at 15:42 #

    Questo programmare in coppia mi piace moltissimo. Mi ricorda la “coppia creativa” ovvero artdirector & copywriter delle classiche agenzie pubblicitarie. Oggi va scomparendo, soprattutto nelle webagency.

  3. Jacopo Romei on 26 Oct 2008 at 22:44 #

    Sì Luisa, effettivamente ci sono un sacco di analogie tra la coppia di programmatori e quella di cui ci scrivi. Sicuramente la dialettica che si instaura è simile, sebbene nella coppia art-copy le funzioni dei due non siano interscambiabili mentre nel pair programming scambiarsi è persino doveroso!

  4. SviluppoAgile.it - Solidi ma agili con il pair programming - Francesco (cphp) Trucchia on 10 Jan 2009 at 14:40 #

    [...] e professionali a cura del mio amico nonchè coach XP Jacopo Romei. Il primo della serie è un articolo sul Pair Programming, davvero molto interessante, che ci fa compredere la potenza di questa metodologia a volte così [...]

  5. L'Extreme Programming e il valore della comunicazione | Sviluppo Agile on 02 Apr 2009 at 09:26 #

    [...] team XP condividono informazione spesso, volentieri e su più livelli. Utilizzano il pair programming, per trasferire rapidamente conoscenza da uno sviluppatore all’altro; spazi di lavoro [...]

  6. Dafne on 05 May 2009 at 12:41 #

    sono completamente d’accordo sul pair programming… io e Luca progettiamo allo stesso modo… essendo noi complementari è molto più produttivo per noi progettare e discutere le soluzioni insieme. :)

  7. User experience agile con il pair programming, anzi pair design! | Sviluppo Agile on 23 Nov 2009 at 17:29 #

    [...] In questo post – scoperto via Alberto – si espongono i vantaggi dello UX design – la progettazione della user experience – condotto in coppia. Noto interessanti analogie con uno dei miei primi post… [...]

  8. Pair Programming- MAS Consulting BLOG on 30 May 2012 at 10:16 #

    [...] http://www.sviluppoagile.it/solidi-agili-con-pair-programming [...]

Trackback URI | Comments RSS

Leave a Reply