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.
- Distributed Continuous Integration
- Use cases + Acceptance Test
- Bug-fixing first
- WIKI
- Multiple Communication Modes
- Ambassadors
- Nearshore pilot
- Tutorial + FAQ = documentazione on demand!
- MOCK Environment
- Gestione di ambienti duplicati
- Gestione del team: no Micromanagement!
- Regular Short Status Meetings & Short Iterations
- WE! (Not US and THEM)
- Procedura di accettazione
- 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”
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