Basta parlare di “Pair Programming”

Sono un agile coach. Mi piace quasi tutto del mio lavoro. Ma se avessi una bacchetta magica una cosa la cambierei: non vorrei più sentire parlare di pair programming o, meglio, non vorrei più sentirne parlare da chi non ha mai lavorato con un team che ha adottato il pair programming come pratica da applicare sistematicamente.

Con un minimo di riscrittura, potrei twittare questo desiderio e finirla qui, ma nei miei sogni più egocentrici c’è almeno uno scettico che legge questo articolo e si fa venire qualche dubbio, per cui cerco di argomentare le mie ragioni. Che poi fossero solo i manager ad essere allergici al pair programming, potrei capire ma, purtroppo, mi capita con una inattesa frequenza di trovare oppositori anche tra gli sviluppatori e non di rado anche tra gli scrum master.

Per prima cosa chiariamo cosa è “pair programming”, inteso come pratica di extreme programming. Non devo nemmeno tribolare troppo, la definizione presa da wiki.c2.com è chiara ed esaustiva:

An Extreme Programming Practice in which two engineers participate in one development effort at one workstation. Each member performs the action the other is not currently doing

Da questa definizione si capisce come non si stia parlando di “affiancamento” a scopo didattico e, soprattutto, che le due persone impegnate stanno lavorando in maniera sinergica, fanno esattamente la stessa cosa “uno per volta”.

No alt text provided for this image

Pare che da alcune misurazioni risulti infatti che le performance di un pair sia inferiore almeno del 15% (e non del 50%) rispetto a due sviluppatori che lavorano in parallelo. Ma sono misurazioni di laboratorio, in ambiente ideale. Sul campo ho notato risultati molto differenti e questo perché quando misuriamo in un contesto ideale, prima di tutto sincronizziamo gli orologi e cerchiamo di lavorare senza disturbi, ovvero ci poniamo in un condizione che in genere non si verifica. Quando un pair lavora accade qualcosa di straordinario. Gli orologi si sincronizzano da soli, il livello di focus è altissimo e si mantiene per periodi molto lunghi, lo stato di flow è tangibile: mi è capitato di arrivare a dover ricordare a sviluppatori così concentrati che potevano usufruire della toilette. So che mi ringraziano per questo, ma io ringrazio loro ancora di più perché queste persone mi hanno fatto vedere quali livelli di energia si possono raggiungere. Fa molto new age, ma parliamo team che sviluppavano sistemi complessi con una difettosità nulla, in tempi incredibili e allo stesso tempo perfezionavano continuamente il modo in cui lavoravano, ad esempio realizzando tool per il testing automatico in modo da applicare un processo di tipo A-TDD (considerando l’epoca a cui mi riferisco, direi che era un risultato strepitoso).

Quando parlo di “tempi incredibili” non posso non fare un esempio: ci accorgemmo che il sistema avrebbe potuto avere un problema di memoria nel caso di elaborazioni di grandi flussi di Corporate Banking (CBI), per cui passammo ad un tecnologia differente (da DOM a SAX Parser per i nostalgici). Dall’inizio del passaggio al deploy in produzione questa cosa ci portò via ben tre giorni. Tempo dopo mi sono trovato, in altro ruolo ed in un’altra azienda, a chiedere ad un team la stessa modifica, per gli stessi motivi, su un sistema analogo di trattamento flussi CBI. Quel team mi ha dato una stima dell’attività che mi ha fatto trasalire: 434 giorni uomo. Quella modifica non è stata fatta, lasciando il cliente insoddisfatto (non faccio nomi ma parliamo di entità importanti dove il committente finale ha un fatturato a 12 cifre).

Ripeto i numeri: 6 (sei) giorni uomo (3 x 2), contro 434 (quattrocentotrentaquattro) giorni uomo. Siamo 1 a 72. Certo è un caso limite, circoscritto, ma è utile per provare a darsi una risposta alla domanda: quali fattori aiutano un team a raggiungere determinati livelli di performance ? Per quello che ho osservato, i team che performano meglio hanno caratteristiche comuni:

  • Adottano in varie salse le pratiche di extreme programming tra le quali, su tutte, team co-locati, sviluppo in coppia, proprietà collettiva del codice, design semplice, integrazione continua, cliente sul posto, sviluppo guidato dai test, settimana da 40 ore. L’ordine non è casuale.
  • Continuamente e collaborativamente mettono in discussione il proprio modo di lavorare.
  • Lavorano insieme da almeno 12 – 18 mesi.
  • La presenza femminile è compresa tra il 30% ed il 40%.
  • Il numero di bug è prossimo allo zero.
  • Se trovano un pezzo di cartaccia in terra lo raccolgono e lo buttano nel cestino.

Di solito non osservo team che vanno 70 volte “meglio” di altri: a spanne i team migliori hanno una produttività circa 4 volte superiore.

Il pair programming sistematico è uno degli ingredienti fondamentali: quando si lavora con uno che consideriamo al nostro livello è un continuo crescere, tenersi su di morale, abbassare la soglia del fastidio quando si vedono i problemi, disintegrare i patti sociali che spingono molti team a rinunciare ad essere dei grandi team per paura di perdere “spazio privato”, senza capire che è proprio quella rinuncia che li porterà ad erodere sempre più quello spazio prezioso.

La prossima volta che mi incontrate, non ditemi “Non possiamo permetterci di fare pair programming”. Potreste dovervi sorbire di nuovo questo “pippozzo” sul perché due è meglio di uno.