L‘adozione sempre crescente delle Metodologie Agili da parte di team dislocati in contesti internazionali differenziati (Offshore) porta le stesse metodologie agili ad “adattarsi” come nel caso di AOSD e DXP. In questo articolo verranno presentate alcune pratiche e lessons learned utili per la gestione dei processi offshore.
Nel precedente articolo si è visto come la sempre crescente adozione delle Metodologie Agili nel caso di team distribuiti in un contesto internazionale (Offshore) porta le stesse metodologie agili ad “adattarsi” come nel caso di AOSD e DXP (vedere [MOKA_OFSH_1]).
Si è visto come un processo di OffShore rende più problematica la comunicazione per i seguenti motivi:
- dislocazione geografica
- fuso orario
- lingua
- differenza di cultura
- qualità tecnologica della comunicazione
In questo articolo verranno presentate alcune pratiche e lessons learned utili per la gestione dei processi Offshore.
Tali pratiche/lesson learned sono scaturite dalla mia esperienza (attualmente ricopro il ruolo di capo di un progetto di sviluppo Software in Offshore per un‘importante Banca italiana) incrociate con la letteratura di riferimento, in particolar modo quella di Martin Fowler e Vincent Massol.
Martin Fowler, Chief Scientist dell‘azienda americana ThoughtWorks descrive in [MF_OFSH] la sua esperienza di Offshore con la sede di Bangalore in India.
Vincent Massol è direttore tecnico dell‘azienda Pivolis specializzata nella gestione di progetti Offshore adottando l‘Agile Offshore Software Development (vedere [VM_AOSD]).
Le pratiche e le “lessons learned” che verranno descritte durante questa serie di articoli sono:
1 Distributed Continuous Integration
2 Use cases + Acceptance Test
3 Bug-fixing first
4 WIKI
5 Multiple Communication Modes
6 Ambassadors
7 Nearshore pilot
8 Tutorial + FAQ = documentazione on demand!
9 MOCK Environment
10 Gestione di ambienti duplicati
11 Gestione del team: no Micromanagement!
12 Regular Short Status Meetings & Short Iterations
13 WE! (Not US and THEM)
14 Procedura di accettazione
15 Fuso orario: Extends working day
1 – Distributed Continuous Integration
La Continuous Integration (CI) è una pratica XP che pone l‘accento sul fatto di avere un processo di build e di test completamente automatico che permetta ad un team di modificare, compilare e testare un progetto più volte al giorno.
Il principale beneficio della Continuous Integration è quello di facilitare lo sviluppo incrementale del software agevolando le operazioni d‘integrazione tra i moduli software che man mano concorrono a costituire il prodotto finale.
Con un processo di Continuous Integration la maggior parte dei bug di un sistema si manifesta il giorno stesso in cui si integrano i moduli interessati riducendo drasticamente i tempi di problem determination e problem solving.
La pratica di Continuous Integration può essere di fondamentale aiuto anche in ambito di processi Offshore: Distributed Continuous Intengration (DCI).
Build regolari infatti permettono di avere la possibilità di avere feedback continui e aggiornati dello sviluppo Offshore. Tale monitoring permette di controllare e seguire il progresso del progetto ed anticipare eventuali errori e/o incomprensioni.
Per la DCI è importante avere una buona connettività al fine di evitare lunghe attese di processi di build.
E‘ buona pratica in generale che il build server risieda presso il gruppo di sviluppatori più cospicuo che, generalmente, è quello Offshore.
In progetti collaborativi dove si necessita di sviluppo massivo di software da entrambi i lati è possibile prendere in considerazione il fatto di mettere il code repository in cluster.
2 – Use cases + Acceptance Test
In un progetto Offshore oltre a fare “viaggiare” i requisiti, è importante definire dei test di accettazione (Acceptance Test).
Tali test aiutano a capire meglio il requisito e/o il Design da implementare, diminuendo la possibilità di fraintendimento/incomprensione (rispetto al solo requisito) oltre che a rappresentare un “obiettivo concreto” per lo sviluppatore Offshore.
Gli Acceptance test agevolano inoltre l‘utilizzo del Test Driven Development (TDD): la pratica di sviluppo software incentrata sui test.
Seguendo la pratica TDD, lo sviluppo tradizionale viene “stravolto”: in TDD si sviluppa in primo luogo il codice di test della funzionalità d‘interesse, poi il codice applicativo che tale funzione implementa.
Tale pratica permette quindi di:
- chiarire meglio il requisito
- dare allo sviluppatore Offshore un concreto obiettivo da raggiungere
- attuare il TDD presso il team Offshore (RTDD: Remote Test Driven Development)
3 – Bug-fixing first
Nel caso di attività di sviluppo OffShore riguardanti sia sviluppi evolutivi (nuove features) che correttivi (bug-fixing) è molto utile seguire la pratica di iniziare prima con il bug-fixing.
Un‘attività di bug-fixing richiede più code-reading che sviluppo di nuovo codice ed è ottima per prendere familiarità con il software e con il processo metodologico.
Anche nell‘attività di bug fixing trovo fondamentale utilizzare un procedimento TDD.
Prima di correggere un‘anomalia si devono predisporre uno o più casi di test (test di unità con ad esempio JUnit) che mettano in rilievo l‘anomalia da correggere.
Lo scopo è ottenere un test automatico e ripetibile (che fallisce) prima di procedere all‘effettiva correzione dell‘anomalia.
L‘anomalia sarà giudicata evasa solo nel caso in cui il test, precedentemente sviluppato, venga eseguito con successo.
Il TDD porta allo sviluppo naturale e incrementalmente di una suite di test che permette da un lato la verifica del codice in sviluppo, dall‘altro fornisce la possibilità di verificare la non regressione a fronte di interventi software.
4 – WIKI
L‘utilizzo del WIKI è fondamentale per contenere le informazioni di pubblica utilità del progetto da condividere con il team Offshore.
Cos‘è un WIKI?
La parola WIKI è una forma contratta di “wiki wiki” (“weekie weekie”) derivante dal gergo hawaiano e sinonimo di “veloce”, “rapido”, anche se a volte WIKI viene interpretato come acronimo di “What I Know Is”.
Un wiki è un repository Web (collaborativo!) di documenti ipertestuali che permette ad ogni utilizzatore di aggiungere contenuti (come in un forum per intenderci) ma anche di modifi-care i contenuti esistenti inseriti da altri utilizzatori.
perché il WIKI?
Il WIKI è:
- semplice da installare
- facile da usare
- collaborativo (!)
- utilizzabile via browser
Sul WIKI si deve pubblicare la documentazione di progetto e tutte le informazioni utili per lo svolgimento del progetto (FAQ, HOW-TO, Best Practices, Lesson Learned, tips and tricks, ? ).
E‘ importante che il WIKI sia ben strutturato, di facile consultazione ed è bene prevedere una persona con il ruolo di “giardiniere del WIKI”.
Un WIKI non ben strutturato e di difficile consultazione pregiudica gran parte dei suoi be-nefici.
Un esempio di prodotto open-source WIKI è XWIKI (vedere http://www.xwiki.com/xwiki/bin/view/Doc/WebHome).
5 – Multiple Communication Modes
In un processo di OffShore è importantissimo imbastire un efficace modalità di comunicazione e prevedere più “canali” di comunicazione.
Fondamentale è avere un Wiki, un tool di instant messaging e … una buona connettività !
Per esempio un tool di instant messaging è ottimo per fare domande e risposte in modo veloce oltre che per sapere se una persona è o meno alla propria postazione.
Se le informazioni di cui si necessita sono tante, piuttosto che un cospicuo numero di messaggi è meglio fare una bella e sana telefonata (senza dimenticarsi di aggiornare il WIKI (!) con le informazioni che potrebbero essere di pubblica utilità ).
Il telefono deve essere utilizzabile senza problemi e senza che il costo gravi sulle persone del progetto.
Il tool auspicabile per l‘Offshoring è il tool di voice over IP dove in un “colpo solo” è possible sia telefonare (Internet phone) che scambiarsi messaggi (instant messaging).
Questo è utilissimo quando ad esempio ci sono problemi di comprensione: se qualcosa non si capisce per voce, ? lo si scrive!
Ogni canale di comunicazione deve essere usato con un preciso scopo al fine di garantire la massima condivisione delle informazioni.
Ad esempio, bisogna evitare che informazioni utili vengano condivise solo da una parte del team (es: mediante telefono e/o messaging) piuttosto che metterle sul WIKI (dove rimangono! e sono a disposizione di tutti!)
Per i meeting di “stato avanzamento lavori” ritengo preferibile una Video Conference, in questo modo oltre a parlarsi, ci si “vede”.
Ambassadors
Niente è meglio di un qualsiasi tool di comunicazione che una bella ? visita!
La pratica ambassador prevede uno scambio reciproco di “ambasciatori” da ambo le parti.
Gli ambasciatori possono essere gli stessi capo progetti, oppure architetti e/o sviluppatori a secondo del contesto e della ragione dell‘”ambasciata”.
Questo permette di conoscersi meglio, capire il reciproco contesto e modo di lavoro e indi-viduare possibili miglioramenti di processo e/o di comunicazione.
Conclusioni
Nel prossimo articolo continueremo la rassegna di pratiche e lesson learned utili per la gestione dei processi Offshore.
Riferimenti
[MOKA_OFSH_1]
S. Rossini, “Offshore. I parte: Le metodologie agili & i progetti offshore”, MokaByte 108, Giugno 2006
[MOKAMET_1]
S. Rossini, “Processi e metodologie di sviluppo(I)” MokaByte 83, Marzo 2004
[MOKAMET_2]
S. Rossini, “Processi e metodologie di sviluppo(II)”, MokaByte 85, Maggio 2004
[MOKA_TDD]
S. Rossini, “Pratiche di sviluppo del software (I): Test Driven Development”, MokaByte 86, Giugno 2004
[MOKA_CI_1]
S. Rossini – A. D‘Angeli, “Pratiche di sviluppo del software (II): Continuous Integration: la teoria”, MokaByte 87, Luglio-Agosto 2004
[MOKA_CI_2]
S. Rossini – A. D‘Angeli: “Pratiche di sviluppo del software (III): Continuous Integration: la pratica”, MokaByte 88, Settembre 2004
[MOKA_REFAC]
S. Rossini, “Pratiche di sviluppo del software (IV): Il Refactoring”, MokaByte 86, Ottobre 2004
[MOKA_SPIKE]
S. Rossini, “Pratiche di sviluppo del software (V): Spike Solution”, MokaByte 93, Febbraio 2005
[MOKA_CC]
S. Rossini – M. Piraccini, “Pratiche di sviluppo del software (VI): Code Coverage”, MokaByte 99, Settembre 2005
[MOKA_QS_1]
S. Rossini, “Qualità del software: auditing del codice”, MokaByte 90,-Novembre 2004
[MOKA_QS_2]
S. Rossini, “Qualità del software(II): i test”, MokaByte 91, Dicembre 2004
[OFSH]
http://www.offshoringtimes.com/
[MARTIN_FOWLER]
http://www.martinfowler.com
[MF_OFSH]
M. Fowler, “Using an Agile Software Process with Offshore Development”
http://www.martinfowler.com/articles/agileOffshore.html
[THOUGHTWORKS]
http://www.thoughtworks.com
[VM_AOSD]
Vincent Massol, “AOSD: Agile Offshore”
http://www.pivolis.com/pdf/AOSD20041217.ppt
[PIVOLIS]
http://www.pivolis.com
[PAM]
Scott W. Ambler, “The Practices of Agile Modeling (AM)”
http://www.agilemodeling.com/practices.htm
[XP_12P]
http://www.xpexchange.net/english/intro/practices.html
[AM]
http://www.agilemodeling.com/
[AGMAN]
Manifesto for Agile Software Development
http://agilemanifesto.org
[MFNM]
Martin Fowler, “The New Methodology”
http://www.martinfowler.com/articles/newMethodology.html
[DXP]
http://www.kircher-schwanninger.de/michael/publications/xp2001.pdf
[DPFO]
D. Cronin, “Designing products for offshore development”
http://www.cooper.com/content/insights/newsletters/2004_issue02/Offshore_Development.asp
[FCSO]
Fog creek Software, Offshoring
http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=2160&ixReplies=17
[FOOAD]
S. Moore, L. Barnett, “Offshore Outsourcing And Agile Development”, Forrester