Ho avuto esperienza come sviluppatore o team di comando in diversi progetti che sono stati esternalizzati e in tutti i casi ho visto risultati meno che stellari. La maggior parte di questi progetti ha adottato una filosofia a cascata, con grandi incontri di kickoff, fasi di raccolta dei requisiti di mesi, numerose conferenze telefoniche e innumerevoli e-mail. Una cosa che mi ha sempre frustrato è l'assenza di un accesso anticipato al codice. I contratti sono configurati in modo tale che il team offshore è responsabile del soddisfacimento dei requisiti funzionali, che è ciò di cui i dirigenti sono interessati. Ciò significa, tuttavia, che le decisioni relative all'architettura, i dettagli di implementazione, l'utilizzo dei pattern e le cose che riguardano gli altri sviluppatori sono così profondamente radicati al momento della consegna del prodotto che non siamo in grado di offrire feedback o richiedere modifiche reali.
Qualcuno qui ha gestito un progetto offshore che non ha riscontrato questi problemi? Nello specifico, mi chiedo se ci sia un modo per strutturare i contratti per costringere i team offshore a lavorare in cicli più brevi e ri-factor o re-design basati sul feedback degli sviluppatori on-shore. Non ho avuto troppa esperienza con metodologie agili (sono d'accordo con i principi generali, ma lavoro in un negozio conservatore che ha le sue metodologie radicate), ma mi chiedo se queste potrebbero in qualche modo essere adattate per aiutare a gestire lo sviluppo offshore. Nel complesso, sto cercando di minimizzare le sorprese e gli incubi di manutenzione che inevitabilmente si presentano quando un team di sviluppo viene lasciato a lavorare in isolamento per mesi alla volta.