mregazzi.info

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”.

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.

“Ciao Team, ecco il backlog che abbiamo prodotto nella sessione di User Story Mapping che abbiamo fatto ieri pomeriggio. Sono circa un centinaio di user story ed abbiamo circa un’ora per assegnare ad ognuna una stima in user story point. Se finiamo qualche minuto prima, sappiate che ho portato delle sfogliatelle che sforna un’ottima pasticceria qui vicino.”

Quando un Product Owner esordisce in questo modo, ci possono essere due reazioni: o il team fa la rivoluzione, rifiutandosi di stimare 100 storie in un’ora…

“Un’ora per 100 storie ? Ma se al refinement di due ore facciamo fatica a stimarne 3…”

Oppure il team ha già partecipato ad una sessione di MARE (Massive Affinity Rough Estimation, le parole sono mischiate ad hoc per ottenere un acronimo simpatico) per cui hanno già tutti l’acquolina in bocca pregustando le sfogliatelle.

Ho facilitato questo tipo di sessione tante volte, con differenti team a diverso livello di maturità e seniority, in ambiti di business diversi. La velocità media che abbiamo registrato è proprio circa 100 storie all’ora, ovvero in un’ora un team Scrum riesce mediamente ad assegnare una stima grezza ad un centinaio di storie di cui ha vagamente sentito parlare, ipotizzare una propria velocity e mangiare circa 12 sfogliatelle (no, non è un team da 12, è che sempre mediamente ci sono almeno 2 o 3 persone che se ne mangiano due).

Uno dei principi segreti di Agile è “viaggiare leggeri” e questo vale per tutto: per il design come per le stime. Se siamo all’inizio di un progetto (se lavoriamo per progetti), oppure stiamo ideando nuove feature o ancora stiamo creando l’MVP della prossima killer app, abbiamo imparato che se vogliamo andare veloci dobbiamo avere poco bagaglio. Non stimeremo quindi nel dettaglio le 100 storie, ma ne faremo una stima grezza e, soprattutto, di tipo relativo e basato sulla affinità tra storia e storia. non voglio dilungarmi sulla teoria, voglio darvi subito la ricetta. Non delle sfogliatelle, ma della sessione MARE con un team che non vi ha mai partecipato.

Scrivete tutte le storie su foglietti di carta in formato pari ad un quarto di A4. Devono essere leggibili e devono essere molto mobili, quindi i Post-It non vanno bene. Nel caso voleste comunque usare i Post-It, fate pure ma abbiate cura di attaccarli prima della sessione su fogli pari ad un quarto di A4. Per i più affezionati ai tool, una stampa/unione ricavata da un export dal vostro software preferito è il massimo che vi concedo. Assicuratevi di avere una stanza capiente e con una grande superficie a disposizione: può essere un tavolo da riunioni di almeno 4 metri quadri oppure lo stesso pavimento, se libero.

Predisponete un angolo in cui il PO possa accomodarsi ed accettare richieste di chiarimento. Invitate quindi tutto il team e ricordate a tutti che non si sta facendo una stima dettagliata né tanto meno si sta ragionando sull’effort. Spiegate che si stanno solo mettendo in ordine le storie, dalle più semplici e veloci alle più complesse ed incerte. Se si riescono ad ordinare per gruppi, è più facile, se questi gruppi sono quattro o cinque ancora meglio.

Cominciamo con una ventina di storie, leggendole a voce alta una ad una e posizionandole secondo l’ordine che il team pensa opportuno. Si saranno formate quattro o cinque colonne sopra le quali attaccheremo indicheremo una taglia (XS, S, M ecc.). Finite le prime venti, chiedete immediatamente al team di provare ad andare avanti da soli e piano piano portate storie sul tavolo mentre il team le ordina. Quelle meno chiare saranno prese da un qualunque membro del team che chiederà chiarimenti al PO, senza interrompere il flusso del team. Tenete pronto qualche foglietto bianco per eventuali correzioni o splitting.

Quando tutte le storie sono incolonnate, potrete assegnare dei range ad ogni colonna. Ad esempio 1-2 per le XS, 3-5 per le S, 5-8 per le M, 8-13 per le L e 13-20 per le XL. Riportate quel valore su ogni singola storie e passate alla fase successiva: tra le storie prioritarie il team quale si sente di poter portare a termine in circa… uno sprint ? Scelte le storie, avrete anche una prima velocity presunta sommando i valore di stima delle singole storie. In realtà ne avrete due, una buona per il best case ed una per il worst case. Adesso siete pronti ad affrontare una sessione di Release Planning ma prima… mangiatevi le sfogliatelle.