<< [OT] 2006 Odissea nel call center Telecom Italia | Home | Annotazioni sul Pair Programming >>

Quando collaborare è viaggiare al Quadrato

In questi giorni ho lavorato ad alcuni task in pair e ho anche visto due colleghi lavorare in pair.  Quando dico lavorare in pair intendo in due contemporaneamente alla stessa scrivania sul problema  e anche in due da remoto in momenti diversi sullo stesso problema.

L'efficienza è quello che mi ha sorpreso, è che il lavoro in pair non ha solo dimezzato i tempi, in questi casi particolari gli ha ridotti ... al Quadrato. In un caso ha migliorato la qualità finale del task, nell'altro ha reso possibile il task nel tempo disponibile. Ecco un esempio dei task:

  • semplificata l'implementazione di una nuova funzionalità ad una applicazione esistente tramite refactoring applicando il pattern MVC ad un WinForm e relativi user control (il problema è stato nella esperienza del MVC relativa al Web invece che alle app Windows)
  • trovato l'ottimo tra un insieme di possibili soluzioni (il problema è stato verificare che l'ordinamento non era totale e trovare un criterio corretto&efficace)
  • individute le classi del sistema da cui iniziare a scrivere unit test con il miglior rapporto costi/benefici (il problema è stato far funzionare 2 tool utili a raccogliere indicazioni significative)

A mio avviso c'è stato un notevole risparmio di tempo perché

  • nessun membro del team possedeva da solo la "mappa" completa che portava all'obiettivo mentre i pair che hanno collaborato avevano le parti di quella mappa che una volta unite hanno indicato la strada
  • la via più breve che portava all'obiettivo era troppo complicata/rischisa ma è diventata percorribile combinando le capacità dei 2 peer

Il lavoro in pair ha funzionato per la buona preparazione dei pair (conoscenza, esperienza, capacità), obiettivi comuni e condivisi e l'esortazione al gioco di squadra con un risultato (EEE) decisamente vantaggioso.

Qual'è la vostra esperienza/opinione del lavoro in pair?

Update 16-Feb-2006:

In sintesi dalle esperienza raccolte nei feedback ricevuti ad ora appare che:

  • E' indispensabile che entrambi i pair siano disposti, direi interessati, a lavorare in pair e dialogare e a mettere in discussione le proprie convinzioni sul lavoro in corso
  • Il pair ha il vantaggio di condividere la conoscenza
  • Il lavoro in pair è più efficace quando la coppia è composta da pari ossia non c'è un rapporto docente-studente, in questo caso c'è un affiancamento che è meglio non confonde con fare pair
  • Le persone che fanno pair è preferibile che abbiano conoscenze/esperienze sufficientemente comuni per potersi capire velocemente e sufficientemente diverse per beneficiare della una molteplicità di opinioni
  • Per fare pair è utile disporre nel team della capacità di valorizzare le opinioni diverse e risolvere i conflitti in modo costruttivo
  • Per problemi complessi lavorare in pair è sicuramente vantaggioso per la qualità del software prodotto e senza allungare i tempi (le giornate uomo di lavoro)
  • Per problemi più semplici o per i quali non ci sono dubbi significativi, l'utilità di fare pair è dubbia

Update 17-Feb-2006:

Sintesi degli altri feedback ricevuti:

  • Fare pair è una tecnica efficace per aumentare notevolmente la qualità del codice prodotto
  • E' una pratica che piace, diverte  e gratifica
  • Un rapporto paritario tra i pair (esprimersi, essere ascoltati, scegliere ed agire) è un elemento sentito come molto importante sia per il buon funzionamento del pairing sia per il risultato prodotto
  • Non c'è accordo se i pair debbano scambiarsi alla tastiera in base al tempo (ogni x min.) o in base alle attività (es. cambio pair tra testing e coding)

Update 23-Feb-2006:

Altri feedback ricevuti:

  • La coppia si disciplina meglio rispetto al singolo dal punto di vista del tracking ,della naming convention e del test coverage
  • Il lavoro risulta più lento rispetto a 2 developers spaiati
Tags :   |  |  |

Print | posted @ lunedì 13 febbraio 2006 23:11

Comments on this entry:

Gravatar # re: Quando collaborare è viaggiare al Quadrato
by Michele Bernardi at 14/02/2006 02:30
L'efficenza di un lavoro in pair secondo me é strettamente legata alla difficoltà del processo da affrontare... Tanto più il processo é complesso tanto più 2 persone riescono, confrontandosi e condividendo le proprie idee, non solo a realizzare un prodotto migliore, ma effettivamente anche in meno tempo/uomo...
MERAVIGLIE del pair programming... Però nelle parti "normali" continua a sembrarmi uno spreco i risorse...
Gravatar # re: Quando collaborare è viaggiare al Quadrato
by Marco Sigot at 14/02/2006 11:06
Concordo con Michele, esiste una formula tra l'utilizzo di risorse e il risultato ottenuto in funzione della complessità del processo (o progetto) .. questa funzione demarca la soglia oltre la quale è conveniente il lavoro "in pair" .. non per nulla le riunioni sono il tipico esempio di lavoro "in pair", se sono organizzate bene, sono il fondamento delle strategie aziendali .

Gravatar # re: Quando collaborare è viaggiare al Quadrato
by Igor Damiani at 14/02/2006 11:25
mi capita spesso di lavorare in coppia, ma non per quanto riguarda lo sviluppo di applicazioni.
Io credo che sia una cosa davvero efficiente. Io credo che il vero requisito sia che le 2 persone debbano avere conoscenze complementari, e che insieme formino la torta del 100% che bisogna coprire per concludere il lavoro/progetto. Esempio: [sviluppatore puro + analista] oppure [sviluppatore SQL Server + esperto dell'applicativo che si sta creando]. Oltre a capacità&preparazione, credo che conti molto anche un certo feeling personale, perchè se regna il buonumore, il lavoro è anche più bello, divertente e produttivo.
Gravatar # re: Quando collaborare è viaggiare al Quadrato
by Davide Senatore at 16/02/2006 12:49
Ciao Luca, ti posso riportare la mia esperienza sul pair programming. E' dai tempi delle scuole superiori (quindi MOLTO tempo fa) che, senza saperlo, impiego il pair programming con un collega e devo dire che le cose che sono uscite durante le sessioni in coppia, non sarebbero mai state possibili da raggiungere per una persona sola. Sembra quasi che la somma delle conoscenze, esperienze, motivazioni e perchè no emozioni dia un risultato ben superiore alla semplice somma algebrica delle competenze di ogni singola persona. Questo vale anche in ambiti al di fuori della programmazione, infatti mi sono trovato nella stessa situazione quando lavoravo con 3D studio MAX... la fantasia e le soluzioni portate da ciascun elemento si fondono per ottenere un risultato decisamente superiore rispetto a quello ottenibile singolarmente. L'unica condizione necessaria per il pair programming, a mio avviso, è ce non vi sia mai tra i due partecipanti all'esperienza un rapporto docente-studente, quanto piuttosto un rapporto tra pari, altrimenti il più "debole" potrebbe venire "schiacciato" e potrebbe non far emergere le buone idee che solitamente vengono partorite dalle menti "fresche".
Gravatar # re: Quando collaborare è viaggiare al Quadrato
by Francesco Quaratino at 16/02/2006 14:02
la mia esperienza di "piar programming" è stata fino ad oggi talvolta fallimentare e altre volte proficua. Da tali esperienze ho dedotto che le variabili in gioco sono davvero tante. Primo fra tutti la "disponibilità" a lavorare in pair, ovvero a dialogare e - soprattutto - a mettere in discussione le proprie convinzioni in tempo reale (vedi lo "spirito di condivisione della conoscenza" citato da Tammacco nel suo post). E' una forma mentis che in alcune persone è un vero e proprio tabù. Condivido l'opinione di Bernardi e Sigot, i quali mettono in primo piano il fattore "complessità". Condivido meno l'opinione di Damiani, perchè -sempre in base alla mia piccola esperienza- le conoscenze complementari finiscono per diventare spunto di divulgazione di tali conoscenze, in altre parole, invece di lavorare si finisce per insegnare/imparare (che non è poi tanto male...) con conseguente perdita di tempo.
Gravatar # re: Quando collaborare è viaggiare al Quadrato
by M.rkino at 16/02/2006 14:45
ciao Luca, ti porto la mia possitiva esperienza. Qualche hanno fa su una procedura java mi sono ritrovato a lavorare in pair con un mio collega. Il risultato è stato ottimo... l'eperienza non fù voluta ma casuale, al termine della procedura il collega mi disse "vedi ci siamo ritrovati a fare quello che chiamano 'pair programming' ...". Non ho poi avuto molte altre occasioni per ri-provare ma la mia esperienza mi ha portato a dire che lavorare in tale modalità ha aumentato l'effeficienza e la produttività.... meno distrazioni - tipiche di un programmatore solo con a disposizione la rete - e un doppio controllo sul codice scritto.
Gravatar # re: Quando collaborare è viaggiare al Quadrato
by Stefano Grevi at 16/02/2006 16:12
Provo a riportare il mio unico caso di pair programming, l'ultima attività fatta prima di salutare il cliente :
quello di un progetto critico a cui ho
lavorato e che è andato bene, progetto in cui abbiamo applicato alcuni
dettami dell'XP.

Non citerò alcuni dettagli per motivi di 'privacy', ma devo dire che
alla fine abbiamo chiuso il progetto 'senza avere l'acqua alla gola' e
gli obiettivi sono stati raggiunti. In un mese e mezzo non è affatto
male.


Progetto con :

-Tempi per l'analisi e decidere l'architettura : 1 mese circa (sforati)
- Tempi per stilare il codice : 1 mese e mezzo scarsi
- Una risorsa da istruire in ASP.NET e C#
- Unit testing su tutti i membri pubblici delle classi facenti parte della business logic (e non)
- Documentazione (con NDoc). Commentare ogni membro pubblico.
- Interfacciamento con un motore di 'calcolo' esterno ancora in corso di sviluppo durante il progetto


Cosa è stato fatto :


- Pair programming : una persona preparata (ma neanche tanto...io :-D ) in ASP.NET e C# che affianca
quella da istruire (che conosce meglio le regole di business)
- Meeting minimali : confronti costanti e frequenti, ma molto brevi su ogni dubbio o problematica sia architetturale che implementativa
- Refactoring : prima stesura 'ingenua' della funzionalità in modo che 'funzioni', poi refactoring continuo fino a fine progetto
- Unit testing.

Il costo del pair programming è stato, penso, valutato come
ammortizzato interamente in quanto alla fine del progetto la persona da
istruire ha acquisito le conoscenze necessarie, il prodotto finale ha un numero molto
basso di bachi (= meno tempo dedicato al debug) ed il team non ha
risentito della mia dipartita :-)

L'analisi è stata superata di gran lunga dopo la prima settimana :-)))
Le feature indicate nell'analisi iniziale alla fine erano meno di quelle realizzate e meno articolate. La stima tempi era stata fatta sull'analisi iniziale.

Problemi nel lavoro in coppia, attriti interni nel team, discrepanze nelle esperienze e nei caratteri sono emersi e sono stati risolti; in questo caso è compito del Team Leader rivedere chi lavora con chi e far capire ai più esperti che non è col segreto di Pulcinella che avranno dei vantaggi.

Alla fine del progetto mi sono guardato intorno ed ho scoperto di
essermi divertito, anche se abbiamo lavorato parecchio.


Gravatar # re: Quando collaborare è viaggiare al Quadrato
by Fabio Carucci at 19/02/2006 20:25
Ciao Luca carissimo,

sull'onda del ricordo delle nostre sessioni all'Agile Day 2004 ti posso dire che, facendo gli scongiuri, tra breve proverò a mettere on line un blog in cui racconterò un piccolo gruppo di developers che fanno pair programming su un progetto. Appena sono pronto posterò il link.

-Fabio

Comments have been closed on this topic.