AlfonsoStuardi.com

Il Pair Programming (PP) è una attività dell’eXtreme Programming (XP) nella quale due programmatori lavorano congiuntamente, come una singola mente e spesso fisicamente sulla stessa macchina, per lo sviluppo di task. Il PP applicato a task complessi porta sicuramente innumerevoli benefici:

• Miglioramento della qualità: Una coppia di programmatori che lavora sulla stessa story card tende a completare il lavoro con un numero minore di difetti;
• Miglioramento della produttività: risulta più difficile che una coppia subisca rallentamenti o addirittura blocchi nell’affrontare un problema. Inoltre, la presenza di un collega tende a minimizzare i tempi dedicati a “distrazioni” quali la lettura delle email o la navigazione web. Infine, i problemi tendono ad essere risolti con una progettazione più chiara ed un numero minore di righe di codice;
• Eliminazione dei “compartimenti stagni”: una corretta rotazione delle coppie permette a tutto il team di conoscere i vari aspetti dell’applicazione ed il dominio di business;
• Trasferimento della conoscenza: la rotazione delle coppie consente ai singoli programmatori di acquisire nuove skill. Il livello dei collaboratori e dell’intero team tende a crescere durante lo sviluppo del progetto, migliorando anche il morale.
• Auto-selezione: il team tende automaticamente ad eliminare coloro i quali presentano prestazioni non in linea con il resto della squadra.

Dal lato del team leader o degli sviluppatori, quindi, il PP potrebbe rappresentare il classico “silver bullet”, migliorando decisamente lo sviluppo di tutta una serie di task.

La prospettiva di business, tuttavia, è in qualche modo differente. Un project manager, nel presentare una soluzione di sviluppo basata sul PP agli stakeholder, deve argomentarne la scelta, evidenziando un incremento del ROI.

Return on Investment.

L’argomentazione basata sull’incremento della produttività dei singoli è, purtroppo, irrilevante quando si parla di ritorno dell’investimento.  Sicuramente gli stakeholder mirano ad aumentare la produttività, ma solo se quest’ultima, ceteris paribus, porta ad un incremento del ROI.

Per spiegare meglio il concetto, poniamoci in un caso estremo. Prendiamo in considerazione un piccolo progetto per il quale possono essere seguite due distinte strade:

1. PP con due sviluppatori senior; stima di 2 mesi/uomo per concludere il progetto; costo totale 20k euro.
2. Cento stagisti (magari in tirocinio universitario) organizzati in 20 team da 5 elementi, impegnati nel trovare una soluzione almeno equivalente a quella in grado di essere sviluppata dai 2 sviluppatori senior; stima di 100 mesi/uomo per concludere il progetto (50 volte l’effort del caso 1, ma senza alcun costo) + un mese/uomo di project management e mezzo mese/uomo per l’overhead introdotto dalla scelta della soluzione migliore tra quelle sviluppate dai vari team; costo totale 15k euro.

Nel caso in cui siano identici rischi e ricavi, quale sarebbe la soluzione più economica? Come premesso, si tratta di una estremizzazione, ma evidenzia un meccanismo simile al rasoio di Occam, applicato al business.

Ovviamente, produttività totale, qualità del codice di una singola riga presa casualmente e qualità della progettazione di un singolo tirocinante non saranno neppure paragonabili ai due senior del caso 1. Tuttavia, non importa. Dalla prospettiva del management, è importante soltanto che un team di tirocinanti abbia prodotto una soluzione funzionante, consentendo all’azienda di risparmiare 5k euro e migliorando quindi il ROI del progetto. Anche a dispetto della disastrosa produttività individuale del caso 2. Economicamente parlando, quindi, esiste uno scenario che è migliore dell’altro, anche se non è quello “ideale”.

Two is the magic number?

A differenza di una nota pubblicità, dove si era convinti che 3 fosse il numero magico, nel nostro contesto il 2 non lo è… eccetto quando lo è!

In economia esistono tutta una serie di concetti relativi alla massimizzazione delle produzione mediante l’utilizzo di risorse limitate: ogni problema, tenuto conto delle risorse e dei vincoli, ha la sua unica soluzione, consistente nel numero di risorse da assegnare.

In una prospettiva più concreta, prendiamo in considerazione un singolo task in un progetto. Il task avrà il suo numero ottimale di sviluppatori ad esso dedicati in funzione anche del team di sviluppo. Per un gruppo di tirocinanti potrebbe essere 17.2; per un gruppo di guru 1.2; per un team di senior 3.4. Ogni specifico task ed ogni specifico team hanno le loro caratteristiche e queste caratteristiche sono uniche. Solo in casi molto rari il numero ottimale di sviluppatori da assegnare sarà uguale a 2. Il punto è questo: sostenere che una coppia di sviluppatori sia un’assegnazione ideale e tanto assurdo quanto asserire che gruppi formati da 1, 3 o 4 persone rappresentino assegnazioni ottimali.

Per questo motivo, nella prospettiva del management, l’utilizzo del PP è accetabile solo quando ottimale rispetto ad altre soluzioni. Team leader esperti comprendono implicitamente che alcuni task possono essere affrontati decisamente meglio collettivamente; non esitano quindi ad utilizzare il PP o gruppi ancora più numerosi, se lo ritengono opportuno. Quello che è decisamente da evitare è il fatto di considerare 2 come un numero magico, la panacea di tutti i mali, da utilizzare in qualsiasi situazione senza considerare il contesto.

Per questo motivo, lasciamo da parte questo numero arbitrario e basiamoci sull’esperienza, l’intuizione, la strategia di business, le metriche utilizzate e una forte comprensione dei punti di forza e dei limiti dei nostri collaboratori nel decidere SE e QUANDO utilizzare il PP.