Dopo aver affrontato alcune buone pratiche atte a migliorare il lavoro di team distribuiti nel numero precedente, in questo articolo continueremo la presentazione di tali best practices e di importanti lesson learned utili per la gestione dei processi offshore
Nel precedente articolo pubblicato nella sezione Metodologie di Mokabyte si è visto come la sempre crescente adozione di processi in Offshore e l‘adozione di Metodologie Agili al caso di team distribuiti in un contesto internazionale porta le stesse metodologie agili ad “adattarsi” come nel caso di AOSD e DXP (vedere [MOKA_OFSH_1]).
In questo articolo continueremo la presentazione, iniziata in [MOKA_OFSH_2], di alcune pratiche e lesson learned utili per la gestione dei processi Offshore
7 – Nearshore Pilot
Questa pratica, laddove strutturalmente possibile, prevede un pilot del processo di delocaliz-zazione in Nearshore prima di remotizzare il tutto in Offshore.
Con il termine Nearshore si indica il processo di remotizzazione dello sviluppo in città lontane o all‘interno della stessa nazione (es: Milano/Bologna) o in nazioni limitrofe (es: USA/Messico).
La prossimità geografica allevia i trade-off dell‘Offshore: non c‘è il problema del fuso orario, si parla la stessa lingua e agevola l‘attuazione del pattern Ambassadors (i viaggi sono meno costosi!).
In sintesi, il Pilot Nearshore permette una maggiore facilità di startup, setup e tuning del processo di quanto si avrebbe partendo direttamente in Offshore.
8 – Tutorial + FAQ = documentazione on demand!
Quando si esternalizza un processo Offshore in una nazione cost-effective, bisogna tenere conto della traduzione della documentazione.
Questo passo (teoricamente) ovvio, consiste “semplicemente” nel tradurre la documentazione necessaria per permettere al team Offshore di documentarsi sul progetto che dovrà prendere in carico.
In realtà (!) il tutto dipende dalla qualità della documentazione del progetto; nel caso in cui sia scarsa e/o insufficiente e/o datata o … mancante (sigh!), la prima attività da fare (e da non trascurare) è la razionalizzazione della documentazione in italiano per poi procedere alla relativa traduzione.
La documentazione così tradotta permetterà lo startup del team Offshore.
Per aiutare/agevolare a prendere confidenza con il software del progetto è, a mio avviso, utile prevedere a corredo della documentazione una demo e/o un tutorial pratico.
Un tutorial/demo aiuterà lo sviluppatore a prendere dimestichezza del software e a fare pratica per lo sviluppo/configurazione dell‘applicazione.
A questo punto il team Offshore ha a disposizione sia la documentazione basilare che esempi pratici di sviluppo.
L‘eventuale “gap di know how” tra i due livelli di documentazione può essere sanato in modo collaborativo e incrementale mediante la creazione sul WIKI di un‘apposita sezione di FAQ (Frequently Asked Questions).
Ogni domanda da parte di un membro del team Offshore deve essere censita sul WIKI ed avere una corrispondente risposta da parte del team OnSite.
Se applicata in modo rigoroso e continuativo (che non è proprio banale) tale pratica porta in modo naturale e incrementale ad un aggiornamento sistematico della documentazione e “ritagliata” ad hoc per le esigenze del team Offshore.
I “nemici” di tale pratica sono l‘uso non disciplinato dei tool come instant messaging e telefono dove l‘informazione, una volta “consumata” e non pubblicata sul WIKI, viene “persa!
Sicuramente aiuta in tal sesnso a essere un po‘ “coercitivi” non rispondendo alle domande di potenziale importanza via telefono e/o instant messaging ma solo nella sezione FAQ del WIKI.
9 – MOCK Environment
Quando uno sviluppo viene dato in Offshore è importante prevedere la connettività da parte dell‘applicazione software remotizzata verso i data store OnSite (DBMS, ambienti Legacy, Sicurezza, …).
Questo richiede l‘accesso da parte del team Offshore ai data store OnSite mediante VPN, cioè una linea di comunicazione “dedicata virtuale”.
Una Virtual Private Network (VPN) è una rete privata che utilizza un mezzo di trasmissione pubblico e condiviso come può essere per esempio internet. I messaggi della VPN transitano sulla rete pubblica opportunamente cifrati e mediante protocolli “sicuri” come IP security, SSL, PPTP …
È fondamentale tenere conto delle possibili indisponibilità di rete e/o delle eventuali carenze di qualità della connessione.
Bisogna fare in modo che questi inconvenienti non inficino pesantemente il lavoro dell‘Offshore.
Di seguito si riportano alcune possibili pratiche che operano proprio in questa direzione.
- Local DB
Per applicazioni che necessitano di accedere a DB per dati di dominio/configurazione (ad esempio con JDBC) è bene installare in loco al team OffShore un proprio DB. Sarà compito del team OnSite fornire le opportune DDL di definizione ed i relativi script SQL di popolamento. Questo permette al team OffShore di lavorare in modo indipendente dall‘ambiente OnSite.
- Host Mock
L‘Integration Layer deve essere “cortocircuitabile” (loopback locale) simulando un accesso ad Host e restituendo i dati di test opportunamente configurati.
In questo modo è possibile sviluppare le parti applicative che necessitano di accedere all‘Host; anche in questo caso è importante che tale operazione avvenga mediante configurazione e non in modo programmatico.
- Security Mock
In taluni casi di potrebbe avere la necessità di un Security Mock, cioè di una “sicurezza finta” che permetta l‘esecuzione dell‘applicazione con apposite utenze di test senza che sia obbligatorio collegarsi alla sicurezza “reale” OnSite. Anche in questo caso la configurazione deve avvenire a livello di configurazione e non di codice.
10 – Gestione di ambienti duplicati
Consentire l‘accesso alle risorse OnSite in modo sicuro e ordinato a postazioni remote non è banale: richiede tempo e organizzazione.
Se oltre alla complessità tecnologica, aggiungiamo anche i tempi organizzativi/burocratici, ecco che può capitare che venga presa la decisione di avviare i lavori in modo “tattico” mentre nel frattempo si predispone l‘ambiente “strategico”.
Una possibile modalità “tattica” prevede la creazione di un ambiente “analogo” a quello OnSite presso la sede Offshore.
Questo ambiente è quindi dedicato al team Offshore e avrà ad esempio un proprio sistema di Software Configuration Management (SCM) e di bug tracking.
In questa configurazione tattica si introducono trade-off al processo di delocalizzazione da gestire con attenzione.
Innanzitutto si introducono overhead di processo per le operazioni di “travasamento” dai sistemi OnSite ai sistemi OffShore e viceversa: dall‘Onsite all‘Offshore in fase di avvio lavori e dall‘Offshre all‘OnSite in fase di chiusura lavori.
Ad esempio, ad ogni consegna del software da parte del team Offshore, la fase di integrazione del codice OnSite richiede il travasamento delle informazioni dai repository OffShore a quelli OnSite. Per ogni file modificato si devono eseguire le operazioni di:
- check-out del codice dal sistema SCM OffShore
- check-out del codice dal sistema SCM OnSite
- aggiornamento del file
- check-in del file aggiornato sul sistema SCM OnSite
Operazioni analoghe dovranno essere fatte anche per il sistema di Bug-tracking e per la documentazione.
Si evince come con un approccio tattico risulta maggiormente oneroso ogni eventuale riciclo del software.
Una pratica che può aiutare a ridurre al minimo il rischio di disallinemento codice e/o documentazione e/o bug tracking consiste nell‘ “azzerare” i repository OffShore ad ogni rilascio (avvenuto con successo!) di una milestone e prevedere un aggiornamento degli stessi prima della milestone successiva.
Di fatto si attua un approccio “Master/Slave”: il team Onsite è Master di ogni startup di Milestone(s) e ha l‘onere di fornire in input il codice, documentazione, segnalazione bug aggiornati per il team Offshore.
Slave: il team Offshore, ad ogni nuova Milestone non deve fare affidamento del codice/documentazione sui propri repository locali, ma deve lavorare sulla situazione aggiornata data dal team OnSite.
Questa pratica, se da un lato introduce un ulteriore overhead di processo, dall‘altro assicura che l‘OffShore parta dall‘ultima situazione aggiornata dal Team Onsite riducendo possibili rischi di disallineamento di codice e/o documentazione.
Questa pratica è applicabile quando la tipologia del progetto prevede solo lo sviluppo da parte del solo Team Offshore e non da entrambi i lati.
Conclusioni
Nel prossimo articolo concluderemo la rassegna di pratiche e lesson learned utili per la gestione dei processi Offshore.
Riferimenti bibliografici
[MOKA_OFSH_1]
S. Rossini, “Offshore. Parte I: le metodologie agili e i progetti offshore”, Mokabyte 108, Giugno 2006
[MOKA_OFSH_2]
S. Rossini, “Offshore. Parte II: best practices per la gestione di progetti offshore (1)”, Mokabyte 109, Luglio/Agosto 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 (Forrester), “Offshore Outsourcing And Agile Development”
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti gruppi bancari, pubblica sanità, pubblica amministrazione e software house.
Attualmente ricopre il ruolo di Sofware Factory Manager, Lean Change Agent ed Enterprise Architect presso Capgemini.
Esperto in ambito di sanità pubblica come Project/Program Manager per la governance dei progetti IT strategici di Cartella Clinica Elettronica (CCE) e Fascicolo Sanitario Elettronico (FSE).
Esperto in ambito bancario dove ha ricoperto per una decina d'anni il ruolo di Project Manager e Leader Software Architect (BPM, IWBank e BPS) occupandosi della pianificazione e gestione del progetto, del coordinamento del gruppo di sviluppo software sia InHouse che Nearshore/Offshore. Esperto nella conduzione di progetti secondo metodologia di Project Management PMBok e metodologia agile Scrum.
Si occupa di Java dal 1999 arrivando da precedenti esperienze in C e C++ in ambito Telco (Alcatel & Siemens). Ha pubblicato più di un centinaio di articoli su argomenti di IT Governance, Project Management, architetture enterprise e problematiche di Integrazione e SOA. È coautore dei libri "Manuale pratico di Java" (2001) e "La programmazione della piattaforma J2EE" (2005) editi da Hops/Tecniche Nuove. Certificazioni IT Governance: COBIT V.4.1 Foundation Certificate; certificazioni IT Service Management: ITIL V.3 Foundation Examination; certificazioni Project Management: CSM - Scrum Master, CSPO - Scrum Product Owner, PMI: 35 contact hours.
Profilo linkedin: http://www.linkedin.com/pub/stefano-rossini/30/977/242