Offshore

III parte: best practices per la gestione di progetti offshore (2)di

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"

Condividi

Pubblicato nel numero
110 settembre 2006
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…
Articoli nella stessa serie
  • Offshore
    I parte: le metodologie agili e i progetti offshore
  • Offshore
    II parte: Best practices per la gestione di progetti offshore (1)
  • Offshore
    IV parte: best practices per la gestione di progetti offshore (3)
Ti potrebbe interessare anche