In che modo le metodologie agili, e le relative pratiche, possono essere d‘aiuto in un progetto Offshore dove lo sviluppo viene delocalizzato in nazioni in cui il costo è minore? Analizziamo aspetti fondamentali del problema per poi individuare le pratiche migliori da seguire.
Introduzione
In questo articolo vedremo se e come le metodologie agili, e le relative pratiche, possono essere d‘aiuto in un progetto Offshore dove lo sviluppo viene delocalizzato in nazioni in cui il costo è minore.
Nel prossimo articolo parleremo di alcune pratiche agili (e lesson-learned!) che possono essere utili in processi Offshore.
Prima di addentrarci nel cuore dell‘articolo, vorrei ricapitolare quanto affrontato ad oggi nella sezione Metodologie di MokaByte.
Metodologie predittive & agili, Best Practices
Una metodologia di sviluppo è un insieme integrato di metodi che specifica chi deve fare cosa e quando/come farlo, stabilendo quindi un insieme di ruoli (il chi), di attività (il cosa) ed un ciclo di vita che scandisce le differenti fasi.
Nei precedenti articoli, abbiamo introdotto alcune tra le principali metodologie di sviluppo software.
In [MOKAMET_1] abbiamo evidenziato come, in una metodologia predittiva (waterfall, RUP, …), dapprima si studino bene i requisiti del prodotto per poi stimare e pianificare le attività e le risorse necessarie per pianificare la sua realizzazione.
In [MOKAMET_2] abbiamo visto invece come, con un approccio adattivo, il prodotto sia realizzato in maniera incrementale come successione di versioni che convergano progressivamente sulla versione finale del prodotto consentendo opportuni aggiustamenti nel corso dello sviluppo.
La gestione di processi di sviluppo, senza un adeguato supporto metodologico, portano a costi e rischi elevati di gestione soprattutto se applicati a progetti su larga scala.
Inutile dire che, in pratica, non esiste un processo/metodologia migliore a priori, ognuno presenta punti di forza e debolezza e quindi meglio si adatta ad un contesto piuttosto che ad un altro secondo dell‘ambiente e della tipologia del progetto.
Indipendentemente da quale metodologia adottare (la “scelta” in tal senso esula dallo scopo di questo articolo) è possibile utilizzare delle Best Practices in modo integrato e trasversale alle metodologia stessa.
Nei precedenti articoli abbiamo presentato alcune importanti pratiche (vedere [PAM] e [XP12P]) per lo sviluppo del software.
Nello specifico abbiamo esaminato: Test Driven Development (vedere [MOKA_TDD]), Continuous Integration (vedere [MOKA_CI_1] e [MOKA_CI_2]) , Refactoring (vedere [MOKA_REFAC]), Coding Standards (vedere [MOKA_QS_1]), Collective Code Ownership e Pair Programming (vedere [MOKAMET_2]).
Offshore
Con il termine Offshore si intende la delocalizzazione di un processo di sviluppo in nazioni maggiormente vantaggiose in termini economici (cosiddette nazioni “cost effective”).
Il processo di esternalizzazione del processo di sviluppo prende il nome di Business Process Outsourcing (BPO). Tale termine fu coniato intorno ai metà anni 90 ed è diventato molto popolare negli ultimi anni grazie anche all‘esplosione dell‘Internet Business.
I principali vantaggi dell‘Offshore sono (vedere [OFSH]):
- Cost savings: riduzioni di costi (salari, tasse, benefits, parco macchine, …)
- State-of-the-art technology: generalmente le aziende Offshore investono per essere competitive sulle nuove tecnologie Software e Hardware
- Scalability: possibilità di scalabilità di risorse in tempi brevi
- Price stability: stabilità del costo del progetto
- New business partners: l‘Offshore porta ad avere nuovi business partners
- More time to focus on core business activities: delocalizzando le attività di sviluppo si ha più tempo per concentrarsi sul proprio core business
Ci sono tipologie diverse di progetti Offshore; principalmente possiamo suddividerli in due categorie:
- Fixed-price projects: progetti a prezzo fisso dove progetto si riferisce ad una offerta “chiavi in mano”; definiti gli obiettivi del progetto il team Offshore deve consegnare lavoro al cliente. Per il cliente il processo di sviluppo è una black-box
- Collaborative projects: progetti collaborativi nei quali il team Offshore collabora alla realizzazione del progetto insieme al team Onsite. Il team Onsite è responsabile della raccolte delle specifiche del lavoro (use cases / story cards, UpFront Design, test cases, … ). Questi tipi di progetti possono richiedere lo sviluppo solo dal lato Offhsore o da entrambi le parti (co-sourced) con relativa necessità di condivisone del codice. In tale contesto la comunicazione tra il team “locale” (OnSite) e “delocalizzato” (Offshore) è molto importante.
Offshore: conseguenze
La prima cosa da tenere in considerazione nel caso di un progetto Offshore è che il principio base delle metodologie agili della prossimità fisica (face-to-face) viene meno.
Infatti la dislocazione fisica delle persone coinvolte nel progetto rende problematico l‘attuazione delle fondamentali pratiche agili come gli stand-up meeting e la condivisone del medesimo workspace che implicano il “face-to-face”.
Un processo di OffShore rende più problematica la comunicazione a causa di:
- dislocazione geografica
- fuso orario
- lingua
- differenza di cultura
- qualità tecnologica della connettività
Offshore: possono le pratiche agili essere d‘aiuto?
Veniamo ora al nocciolo dell‘articolo.
Viste le “difficoltà ” che la delocalizzazione del processo porta con sà©, la domanda fondamentale diventa quindi come e se le pratiche delle metodologie agili possono essere d‘aiuto ad un processo di sviluppo Offshore.
In effetti in tali condizioni di progetto le metodologie tradizionali (quelle predittive / “plan-driven”) sembrano più opportune.
La sempre crescente adozione di processi in Offshore e l‘adozione di Metodologie Agili al caso di team distribuiti in un contesto internazionale (sviluppo Offshore) ha portato le stesse metodologie agili ad “adattarsi” (Agile Offshore Software Development – vedere [VM_AOSD]) o nel caso dello stesso XP con il Distributed Extreme Programming (vedere [DXP]).
L‘articolo “principe” (a mio avviso) che spiega come adattare la metodologia agile e le sue dirette principali pratiche è quello Martin Fowler (vedere [MF_OFSH).In tale articolo Martin Fowler descrive la sua esperienza con la sua azienda americana ThoughtWorks rispetto alla sede di Bangalore, in India.
Partendo dalle pratiche che piu‘ sono messe “in crisi” dalla distanza intrinseca nell‘Offshore, descrive una serie di accorgimenti e di lesson learned che permettono di applicare una metodologia agile anche in ambito distribuito.
Parte delle pratiche e lesson learned proposte saranno descritte nel prossimo articolo dedica-to alle pratiche di sviluppo software per progetti Offshore.
AOSD
AOSD è l‘acronimo di Agile Offshore Software Development.
E‘ basata sulle Best pratices di XP (Continuous Integration, , Testing, Short Iterations, …) ,RUP (notazione UML) e sull‘Open Source (Emma, JUnit, …); il tutto applicato al contesto dei progetti Offshore (vedere [VM_AOSD]).
Vincent Massol, direttore tecnico dell‘azienda Pivolis (vedere [PIVOLIS]) specializzata nella gestione di progetti Offshore adottando l‘AOSD, spiega una serie di pratiche e lesson learned per “adattare” al meglio la metodologia “agile” anche in contesto Offshore.
Parte delle pratiche e lesson learned proposte saranno descritte nel prossimo articolo dedi-cato alle pratiche di sviluppo software per progetti Offshore.
Distributed Extreme Programming – DXP
Il Distributed eXtreme Programming (DXP) è l‘XP adattato per la gestione di progetti Off-shore.
Il focus della metodologia DXP è indirizzare la gestione delle pratiche che richiedono la vi-cinanza fisica e che quindi devono essere adattate ad un contesto di progetto Offshore.
Lo sforzo è quindi indirizzato sulle pratiche come Pair Programming, On-Site Customer, Planning Game, Continuous Integration per cercare di adattarle ad un contesto distribuito di progetto instaurando una modalità di comunicazione e sui tool di comunicazione che devono essere efficienti e collaborativi!
Tali tool, usati con disciplina, permettono di lenire la lontananza fisica e “virtualizzare” la vicinanza fisica delle persone
DXP introduce inoltre un nuovo “valore” nel processo: la pazienza!
La pazienza e la tolleranza: pazienza per i problemi tecnologici (scarsa qualità delle connessioni, problemi di rete, telefonate rumorose) e tolleranza per le differenze culturali.
Conclusioni
La sempre crescente adozione di processi in Offshore e l‘adozione di Metodologie Agili al caso di team distribuiti in un contesto internazionale (sviluppo Offshore) porta le stesse metodologie agili ad adattarsi.
L‘Offshore introduce benefici in termini di riduzione costi e di aumento di opportunità .
L‘Offshore introduce però anche dei costi e rischi extra rispetto rispetto ad una gestione Onsite. La più grande conseguenza è la comunicazione dovuta alla distanza, il fuso orario, la cultura e la lingua.
In questo primo articolo si è parlato di come le metodologie agili (come AOSD e DXP) possono adattarsi anche a contesti Offshore.
Nei prossimi articoli ci addentreremo più in dettaglio presentando una serie di pratiche e lesson learned utili per i progetti Offshore.
Riferimenti
[MOKAMET_1]
S. Rossini, “Processi e metodologie di sviluppo(I)” MokaByte 83 Marzo 2004
https://www.mokabyte.it/2004/03/metod-1.htm
[MOKAMET_2]
S. Rossini, “Processi e metodologie di sviluppo(II)” MokaByte 85 Maggio 2004
https://www.mokabyte.it/2004/05/metod-2.htm
[MOKA_TDD]
S. Rossini, “Pratiche di sviluppo del software (I): Test Driven Development”, MokaByte 86 Giugno 2004
https://www.mokabyte.it/2004/06/softwaredev-1.htm
[MOKA_CI_1]
S. Rossini, A. D‘Angeli, “Pratiche di sviluppo del software (II): Continuous Integration: la teoria” MokaByte 87 Luglio Agosto 2004
https://www.mokabyte.it/2004/06/softwaredev-1.htm
[MOKA_CI_2]
S. Rossini, A. D‘Angeli “Pratiche di sviluppo del software (III) Continuous Integration: la pratica” MokaByte 88 Settembre 2004
https://www.mokabyte.it/2004/09/softwaredev-3.htm
[MOKA_REFAC]
S. Rossini, “Pratiche di sviluppo del software (IV): Il Refactoring”, MokaByte 86 – Ottobre 2004
https://www.mokabyte.it/2004/10/softwaredev-4.htm
[MOKA_SPIKE]
S. Rossini, “Pratiche di sviluppo del software (V): Spike Solution” MokaByte 93 – Febbraio 2005
https://www.mokabyte.it/2005/02/software_dev-5.htm
[MOKA_CC]
S. Rossini, M. Piraccini, “Pratiche di sviluppo del software (VI): Code Coverage” MokaByte 99 Settembre 2005
https://www.mokabyte.it/2005/09/softwaredev-6.htm
[MOKA_QS_1]
S. Rossini, “Qualità del software: auditing del codice” MokaByte 90-Novembre 2004
https://www.mokabyte.it/2004/11/auditing.htm
[MOKA_QS_2]
S. Rossini, “Qualità del software(II): i Test” MokaByte 91 Dicembre 2004
https://www.mokabyte.it/2004/12/test.htm
[OFSH]
http://www.offshoringtimes.com/
[MF_OFSH]
Martin Fowler, “Using an Agile Software Process with Offshore Development”
http://www.martinfowler.com/articles/agileOffshore.html
[VM_AOSD]
Vincent Massol, “AOSD: Agile Offshore”
http://www.pivolis.com/pdf/AOSD20041217.ppt
[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
[PIVOLIS]
http://www.pivolis.com
[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”