Sviluppo software e principi agili con team distribuiti

Team distribuiti e dispersi

Lo sviluppo software con tecniche agili attribuisce un valore fondamentale alla comunicazione diretta (face-to-face), tuttavia la nostra esperienza quotidiana in Intré è con situazioni in cui non è sempre possibile avere tutte le persone coinvolte in un progetto in una stessa stanza.

Normalmente i nostri team:

• lavorano presso le sedi dei clienti, e solitamente gli incontri di persona con Product Owner e Scrum Master sono solo periodici;
• includono persone che sono di base in sedi Intré diverse (Monza o Seriate).

Inoltre capita che nostri sviluppatori collaborino con sviluppatori del cliente (o come team affiancati, o nello stesso team).

La combinazione di questi fattori genera una serie di casistiche che non sono esattamente in linea con l’idea di un gruppo di lavoro coeso e a strettissimo contatto, ed una serie di problematiche che però possono essere riconosciute e gestite in diversi modi.

Un team è:

• distribuito quando composto da un numero ristretto di gruppi di persone che lavorano in sedi diverse ed eventualmente con separazione di competenze, pur condividendo gli stessi obiettivi lavorativi;
• disperso invece quando è composto da un insieme di persone in cui potenzialmente ognuno lavora in una diversa posizione.

Un team disperso, anche se piccolo, richiede grandi sforzi per ottenere un coordinamento efficace (ed in questi giorni ce ne stiamo rendendo tutti conto). E’ importante che il team abbia modo di consolidare una propria identità ed intimità. Il successo di un progetto dipende dalla capacità dei colleghi di affrontare le limitazioni e le barriere comunicative enfatizzando l’importanza di interazioni efficaci. Questo è esattamente quello che i principi agili promuovono.

Comunicazione in team distribuiti

Ovviamente anche la comunicazione con il cliente, oltre che fra colleghi, è di fondamentale importanza. E’ importante evitare che si crei una distanza fra i desideri, le aspettative e le percezioni che il cliente ha del lavoro del team di sviluppo. Proprio per questo motivo occorre dotarsi di un canale di comunicazione sempre aperto, e che vi siano occasioni di allineamento con la giusta frequenza. In questi momenti di confronto, il team potrà capire se sta lavorando in maniera efficace (ed efficiente) ed eventualmente intraprendere azioni correttive.

Non esiste una ricetta valida per tutti

Tuttavia non esiste una ricetta o un metodo che possa essere usata da qualsiasi team indistintamente per risolvere tutti i problemi. Ogni caso deve essere analizzato, compreso, ed avrà bisogno di adottare soluzioni specifiche con il contributo di tutte le figure professionali coinvolte.

Allo stesso modo, non può esistere una tecnologia che possa risolvere automaticamente tutti i problemi derivanti dalla non co-locazione integrale di un team, se le persone già non lavorano naturalmente come un team. La cultura aziendale, i valori comuni e le convinzioni di ogni singolo elemento del team influenzano la possibilità di creare rapporti di fiducia, buona collaborazione, e una visione comune degli obiettivi. Una delle barriere più significative è rappresentata proprio dalla difficoltà di avere riscontri tempestivi per colpa dei rallentamenti introdotti dalla distanza fra i partecipanti.

Caratteristiche di un team

L’obiettivo di team distribuiti o meno deve essere di raggiungere insieme gli obiettivi che i singoli, da soli, non potrebbero raggiungere. Gli individui devono quindi essere in primis consapevoli di essere un team e devono:

• condividere un’identità di team, sentirsi tutti parte della stessa squadra;
• condividere una visione comune, senza ambiguità su quali siano gli obiettivi da raggiungere e i risultati attesi;
• riconoscere le responsabilità condivise, ed ognuno deve prendersi l’impegno di contribuire al successo degli sforzi del team;
• rispettare le regole di convivenza e lavoro nel team;
• apprezzare i valori condivisi, che danno la direzione al team stesso.

Purtroppo nessuno può instillare queste caratteristiche in un team: deve essere il team stesso a maturarle nel tempo. Con la possibilità di essere co-locati, almeno per brevi periodi ed all’inizio di un progetto, è sicuramente più facile che ciò accada. In assenza di questa possibilità sicuramente ci vorrà più tempo. Sarà quindi necessario provvedere con altre occasioni, che (non a caso) prendono il nome di team building.

Supporto al team

Ma come può un team rendersi conto della propria maturità, oltre che tecnica (che forse è la parte più facile), rispetto alle caratteristiche appena introdotte? Innanzitutto è essenziale che ci siano delle riflessioni collettive periodiche (le retrospettive, di cui parleremo in seguito). A volte però è necessario il coinvolgimento di figure che abbiano la possibilità di una visione più astratta del contesto. Non saranno sicuramente coinvolte nella vita quotidiana del team e del progetto, ma magari non nei dettagli specifici dello sviluppo, seppur competenti, in modo da avere una percezione della situazione con meno rumore.

Malgrado alcune metodologie agili affermino di essere evolute al punto di non richiedere più un “project manager”, ci sono delle responsabilità che, soprattutto nel caso di team distribuiti, possono essere cruciali e devono comunque essere assegnate:

• gestire gli aspetti legati alle politiche dell’organizzazione, assicurando al team tutto il sostegno di cui ha bisogno;
• supportare gli aspetti personali dei membri del team, che siano individuali o legati alle relazioni con gli altri membri del team;
• prevenire e tenere sotto controllo eventuali situazioni critiche;
• essere responsabile di alcuni aspetti legati al budget, anche raccogliendo dal team e fornendo al Product Owner informazioni preziose;
• selezionare gli sviluppatori più adatti al team, sia in base alle competenze necessarie per massimizzare le potenzialità del team, sia in base al carattere ed alla compatibilità fra le persone.

Retrospettive

Un momento in cui può essere necessaria la figura di un facilitatore è quello della retrospettiva, il momento in cui il team analizza cosa sta succedendo e cerca di migliorare. E’ importante che il facilitatore non sia (né sia percepito) come un giudice, quanto piuttosto come un investigatore che aiuta il team ad instaurare un confronto costruttivo. Non è necessario che il facilitatore abbia un ruolo attivo nella cerimonia, quanto piuttosto che la organizzi, ne scandisca i momenti e aiuti a distillarne i risultati in una maniera che sia davvero utile al team.

Strumenti per il facilitatore

Un altro aspetto su cui il facilitatore può agire è quello della scelta di uno strumento adeguato allo svolgimento da remoto della retrospettiva. Ogni team ha delle preferenze sul formato (che a volte è meglio scuotere, per evitare abitudini e noia), così come ogni facilitatore. Si utilizzano fogli di calcolo condiviso, con colonne dedicate agli argomenti e celle in cui scrivere i suggerimenti delle persone, oppure c’è chi condivide un documento su cui disegnare insieme (tipo post-it). Ancora, c’è chi preferisce fare una chiacchierata informale e poi condividere degli appunti.

Affrontare una retrospettiva

Il nocciolo di ogni retrospettiva è costituito da tre domande.

• Cosa ha funzionato bene, e merita di essere ricordato e fatto ancora?
• Quali azioni avremmo dovuto fare in maniera diversa?
• Che cosa non abbiamo capito?

Tutti i membri di un team devono contribuire con il proprio punto di vista. La timidezza, o la difficoltà ad esprimersi in una lingua diversa dalla propria, sono ostacoli evidenti anche quando le persone coinvolte in una retrospettiva sono nella stessa stanza. Quando ci si confronta a distanza è importante tenere in considerazione anche altri aspetti.

La capacità di attenzione durante un incontro virtuale è drasticamente ridotta. Ci sono molte distrazioni che non sono percepite da tutti, e comunque è molto difficile restare concentrati in call per più di un’ora. E’ importante che le sessioni di retrospettiva (ma non solo, effettivamente) siano pianificate accuratamente e limitate nel tempo (time-boxed).

Non è possibile capire se tutte le persone siano effettivamente concentrate sulla conversazione o annoiate. Soprattutto nella fase finale, è difficile comprendere che tutti siano davvero consapevoli degli impegni che il team si sta assumendo. C’è il forte rischio che il team si prenda degli impegni su cui però non tutti sono veramente consapevoli e concordi.

Impatti sullo sviluppo software per team distribuiti

A prescindere dalle impostazioni generali e dalle cerimonie di un team, l’impatto della distanza è notevole anche su altre pratiche più operative. Di seguito riporteremo solo alcuni esempi.

Pair programming

Il pair programming è una tecnica che genera una continua revisione del codice, e che potenzia la circolazione della conoscenza all’interno di un team. Ovviamente per due programmatori seduti fianco a fianco è molto semplice condurre sessione pair in maniera efficace, assicurandosi che entrambi siano pienamente concentrati. Lavorando a distanza, molti fattori possono disturbare l’attività: latenza nella comunicazione, impossibilità di accedere alle stesse risorse, eccetera. I membri del team dovranno quindi fare uno sforzo extra per trovare la giusta modalità di condivisione del codice su cui lavorare insieme. Inoltre, il pair programming a distanza potrebbe essere complicato dalla mancata conoscenza diretta (o confidenza) fra le persone. E’ quindi importante che vi sia un equilibrio fra il tempo di sviluppo individuale ed in coppia, in modo che non si creino blocchi ed inibizioni.

Refactoring

Il refactoring, ovvero la pulizia e riscrittura di parti di codice in maniera più chiara ed efficiente, senza alterarne le funzionalità, è una pratica fondamentale anche per i piccoli team. Per i team distribuiti e di grandi dimensioni, diventa ancora più importante per evitare che il software accumuli una quantità non gestibile di “disordine” e debito tecnico. E’ tuttavia fondamentale che vi sia una consapevolezza condivisa quando una parte di codice viene rifattorizzata. Per fare un esempio, il Product Owner deve conoscerne il valore, i rischi, ed il costo.

Condivisione della conoscenza

Più in generale, la condivisione della conoscenza richiede degli accorgimenti aggiuntivi. Se in un ambiente fisico condiviso è possibile reperire informazioni agevolmente rivolgendosi direttamente ai propri colleghi, nel momento in cui chi detiene la conoscenza non è facilmente raggiungibile si possono creare situazioni complesse. Non solo la generazione di una documentazione di valore (aggiornata, comprensibile e senza sprechi) rientra fra le necessità di un progetto –sia relativamente al software, che alle pratiche e ai processi del team– , ma anche la capacità del team di trasmettere in maniera corretta e competente i riferimenti a ciò che è stato documentato diventa fondamentale. Il rischio di una comunicazione e condivisione non efficace è di avere un effetto “telefono senza fili” in cui non solo non si riesce a trovare l’informazione che serve, ma addirittura ne viene fornita una errata. Anche in questo caso la scelta di una tecnologia adeguata (wiki, condivisione di file, …) è necessaria ma non sufficiente, e la verifica costante del corretto utilizzo delle risorse è una responsabilità condivisa del team.

Conclusioni

E’ ovviamente impossibile dare una trattazione esaustiva dell’argomento in un singolo post, ma speriamo di aver dato esempi efficaci degli aspetti del lavoro cooperativo che sono influenzati dalla distanza fra individui o parti costitutive di un team.

Nell’ottica di un’interpretazione agile di queste problematiche, la cosa più saggia è probabilmente recuperare l’ispirazione dal Manifesto per lo Sviluppo Agile del Software, valorizzando in primis:

Gli individui e le interazioni più che i processi e gli strumenti

e la capacità di un team di

Rispondere al cambiamento più che seguire un piano