Offshore

IV parte: best practices per la gestione di progetti offshore (3)di

Nei precedenti articoli si è visto come la sempre crescente adozione di processi in offshore con team distribuiti in un contesto internazionale porta metodologie agili ad "adattarsi". In questo articolo concluderemo la presentazione di alcune pratiche e 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 [MOKA_OFSH_1].

In questo articolo finiremo la presentazione, iniziata in [MOKA_OFSH_2] e [MOKA_OFSH_3], di alcune pratiche e lesson learned utili per la gestione dei processi offshore.

11 - Gestione del team: no Micromanagement!

In un progetto (soprattutto Offshore) non è buona pratica che il capo progetto "locale" gestisca direttamente le risorse Offshore (Micromanagement).

Il capo progetto non deve coordinare e/o entrare nel merito delle singole attività  delle singole risorse Offshore. Ã? bene che la struttura organizzativa preveda che il Project Manager Onsite sia aiutato da un Offshore Team Leader per il coordinamento degli sviluppatori.

L‘Offshore Team Leader diventa di fatto il "proxy" dell‘Onsite Project Leader e gestisce le risorse Offshore in loco aiutando a capire/rilevare/comunicare/gestire eventuali problematiche di progetto (ritardi, incomprensioni, errori, ...).



Figura 1 - Gestione del team

Ã? importante cercare di creare dei medesimi ruoli sia Onsite che Offshore che oltre ad aumentare il grado di comunicazione inter e intra-team, migliora la gestione del progetto e la condivisione del know-how.
Un anti-pattern in tal senso è ad esempio avere solo un "Guru" da un lato; questo rende difficoltosa la crescita del team dell‘altro lato!
La creazione di figure analoghe aiuta a creare un ambiente di lavoro collaborativo e ad evitare atteggiamenti di superiorità  da parte dell‘uno o dell‘altro lato.


Figura 2 - Creazione dei medesimi ruoli da ambo i lati

12 - Regular Short Status Meetings & Short Iterations

Le metodologie agili promuovono regolari meeting brevi per l‘intero team di sviluppo (stand-up meeting in XP, scrums in Scrum, ...).
Questo è importantissimo anche in un progetto Offshore nel quale bisogna tenere conto però anche della lontananza e del fuso orario.
Bisogna che il meeting avvenga ad un orario che tenga conto delle rispettive esigenze di lavoro.
Ã? altrettanto importante anche suddividere il progetto in iterazioni brevi.
Avere milestone ravvicinate (e quindi rilasci ravvicinati) permette di avere dei controlli frequenti e rilevare e gestire quanto prima eventuali errori e/o incomprensioni o modifiche da apportare: prevenire è meglio che curare!
Personalmente reputo una buona pratica che l‘Offshore Team Leader allinei l‘Onsite Project Manager con una mail di report quotidiana per permettergli di avere aggiornamenti regolari e sistematici.


Figura 3 - Iterazioni del progetto

13 - WE! (Not US and THEM)

La parte remota dal gruppo non deve essere vista come una parte "staccata" che sviluppa e basta.
Pensare in termini di un unico gruppo aiuta la collaborazione, il knowledge sharing e quindi la produttività  stessa del team.
In un progetto Offshore capiteranno sicuramente momenti in cui si dovrà  capire se un certa incomprensione è dovuta al gruppo di lavoro Onsite o Offshore. In tali circostanze è più importante pensare alle ragioni che hanno portato ad un incomprensione piuttosto che concentrarsi sulle sole conseguenze.
"Investigare" è giusto, ma non per trovare un "colpevole" ma per capire le ragioni dell‘incomprensione e capire come si possa migliorare il processo affinchà© la cosa non si ripeta.
Se ci si concentra in tale direzione mantenendo sempre sotto osservazione/tuning il processo non si potrà  fare altro che ... migliorare!

14 - Procedura di accettazione

Il vero scopo dell‘Offshore è il raggiungimento di significative riduzioni di costi pur garantendo un adeguato livello qualitativo.
Per potere garantire un adeguato livello qualitativo è importante avere dei chiari criteri di accettazione e di "misurazione" del software sviluppato.
Ã? bene specificare in ogni processo (e soprattutto in ambito Offshore) una procedura di accettazione del deliverable del prodotto software prima di consegnarlo al cliente.
Ad esempio, la procedura che applico al progetto a cui sto lavorando prevede il controllo della documentazione e del codice. Per il controllo del codice vengono applicati i criteri di Q&A a livello di audit code, code coverage e test.


Figura 4 - Esempio di criteri di accettazione

A livello di audit code (code e naming convention) non devono essere presenti errori a livello ERROR o WARNING nel software prodotto.
A livello di Code Coverage la percentuale di copertura dei test (a livello di classe, metodo, statement e blocchi) non deve essere inferiore all‘80%. A livello di test deve essere presente quantomeno un test per ogni bug dichiarato risolto e devono essere presenti (e documentati) i test relativi agli Acceptance Test concordati in precedenza. La procedura di accettazione deve essere rigorosa e soprattutto: ripetibilie. Per questo è bene cercare di formalizzare i passi che compongono tale procedura (es: report sul WIKI, documento Word, tabella Excel, ...).

Nel progetto Offshore che sto gestendo usiamo un report in formato Excel che elenca i controlli da effettuare (compilazione, deploy, esiti dei test, code coverage, audit code, rispetto delle linee guida architetturali, presenza e completezza della documentazione, ...) in modo da normare la procedura di accettazione del prodotto Offshore prima di rilasciarlo al cliente.



Figura 5: Esempio di documento di accettazione

15 - Fuso orario: Extends working day

Gestire il fuso orario non è banale.

Ad esempio, con un fuso orario di 4 ore e mezza (es: Italia-India), quando il team italiano inizia al lavorare il team indiano è già  a metà  giornata lavorativa (e magari in pausa pranzo).
In modo pragmatico (quasi "cinico") bisogna cercare di suddividere la giornata dedicando la prima parte a seguire / collaborare con il team Offshore, la seconda parte per gestire le attività  Onsite e per fornire gli elementi utili per il team Offshore per il giorno successivo.
Se si gestisce bene il fuso orario cercando di dare continuità  al lavoro, la giornata produttiva passa virtualmente da otto a dodici ore!
Facile a dirsi ma, vi assicuro, non proprio banale da attuarsi...



Figura 6 - Fuso orario

Conclusioni

Sicuramente la gestione di un progetto Offshore richiede elevate competenze di project management per creare e gestire processi adatti agli scopi prefissati: sono infatti diversi i fattori che possono rallentare od ostacolare il corretto sviluppo del progetto, inficiando i benefici economici e di scalabilità  legati allo sviluppo offshore.
L‘Offshore introduce dei costi e rischi extra rispetto a una gestione di progetti Onsite.
La possibilità  di miscommunication e/o misunderstanding in un processo Offshore è maggiore (distanza, fusio orario, cultura, lingua) e bisogna attuare con rigore (ancora più rigore di quello che si farebbe in un progetto Onsite) le pratiche precedentemente spiegate per minimizzare tali rischi.
Bisogna essere dei buoni mediatori per sopperire e mitigare le eventuali difficoltà  di lingua e di cultura; insomma, bisogna avere la giusta attitudine ed una buona dose di flessibilità .
Ã? importante tenere ben presente le necessità  di avere una buona comunicazione anche da un punto di vista tecnologico prevedendo un buona connettività  (connessione VPN, linea telefonica, ...) e utilizzando gli opportuni tool.
In questi articoli si è parlato di alcune importanti pratiche e lesson learned utili per la gestione dei processi Offshore prendendo spunto da quanto descritto in letteratura da Martin Fowler, Vincent Massol e dalla mia personale esperienza.

Negli articoli "Best practices per la gestione di progetti offshore" sono state presentate 15 pratiche e lesson learned. In particolare, su MB 109 (luglio/agosto 2006) sono stati affrontati i punti 1-6, su MB 110 (settembre 2006) i punti 7-10, mentre sul presente numero MB 111 di ottobre 2006 sono appena stati affrontati i punti 11-15.

  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

Riferimenti

[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

[MOKA_OFSH_3] S. Rossini, "Offshore. Parte III: best practices per la gestione di progetti offshore (2)", Mokabyte 110, Settembre 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://www.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
111 ottobre 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
    III parte: best practices per la gestione di progetti offshore (2)
Ti potrebbe interessare anche