Desarrollo Global de Software

Publicado en

Autor

El desarrollo global de software, conocido también como desarrollo y entrega global, no es un concepto nuevo. El primer libro bajo este título fue publicado en 1998 [1]. La definición simple de lo que es el Desarrollo Global de Software habla de desarrollo entre varios equipos en localidades distribuidas geográficamente. Los equipos pueden ser de la misma organización o pertenecer a distintas organizaciones. La distribución geográfica puede variar desde distintos edificios de la misma ciudad hasta diferentes continentes.

La motivación inicial de este tipo de desarrollo fue abaratarlos costos de mano de obra. La India fue el primer país en la mira y lo supo aprovechar muy bien. Pero hoy en día esta práctica se ha popularizado entre múltiples actores y también puede tener otro tipo de motivaciones, como por ejemplo:

  • Desarrollo de sistemas complejos, que requieren de equipos con distintas especializaciones.
  • Desarrollo 24 hrs, que aproveche diferencias de horarios.
  • Estar más cerca del cliente o del mercado.

Retos

El desarrollo global de software es una fuente de nuevos retos para la Ingeniería de Software. Algunos de los más importantes son los siguientes [2]:

Procesos. Los modelos de procesos que tenemos disponibles están diseñados para una sola organización y, a lo más incluyen a los subcontratados, pero no tenemos procesos para organizar la colaboración y coordinación entre varias organizaciones para un proyecto común. Hoy en día esta falta significa, según algunas fuentes, la disminución de productividad hasta en 50%.

Comunicación. Si de por sí la comunicación es difícil dentro de un solo equipo y con un solo cliente, este problema se multiplica en caso de equipos distribuidos geográficamente. La comunicación incompleta da lugar a malos entendidos, omisiones, errores y, en consecuencia, re-trabajo.

Cuestiones culturales. Las barreras del idioma, las diferencias en formas de pensar y expresarse, así como diferentes costumbres y formas de trabajar pueden afectar a las relaciones entre equipos, disminuir confianza, y por lo tanto, ser causante de retrasos.

Coordinación del trabajo. Distribuir las tareas entre varios sitios y zonas horarias es mucho más complejo que hacerlo para un proyecto de un solo sitio. En efecto, el costo de la coordinación es mayor y los resultados en vez de ser más rápidos se obtienen con retraso.

Visibilidad y control. En proyectos tradicionales en un solo sitio, es viable transmitir de forma oportuna a todos los participantes el conocimiento sobre la estructura del proyecto, roles y sus responsabilidades, asignación de las actividades de desarrollo, así como el estatus global del avance del proyecto. Sin embargo, transmitirlo oportunamente a distintos sitios geográficamente distribuidos puede ser difícil, especialmente cuando se colabora con otras empresas o con equipos en distintas zonas horarias.

Métricas del proyecto. La recolección de datos para mediciones establecidas para un proyecto de desarrollo global de software puede no ser tan fácil. Las diferencias en procesos o infraestructuras heterogéneas pueden ser causantes de datos poco coherentes y, en consecuencia, harán difícil la evaluación cuantitativa del éxito del proyecto.

Cuestiones políticas. Tanto dentro de las organizaciones, que, por ejemplo, temen perder trabajo o resienten la competencia de sitios remotos, como en países o regiones, se pueden dar situaciones que conduzcan a agendas ocultas u objetivos contradictorios.

Protección de propiedad intelectual. Es una preocupación muy latente en desarrollo global especialmente en los países donde las leyes de propiedad intelectual son más laxas.

Infraestructuras y herramientas de desarrollo. Al tener equipos distribuidos y multiempresa es común que la infraestructura y herramientas varíen. Quienes provienen de organizaciones más maduras cuentan frecuentemente con herramientas robustas y propietarias, mientras que los equipos más pequeños están utilizando las herramientas ligeras, con frecuencia de código abierto. Esto puede ser un causante adicional de incompatibilidades de ambientes de desarrollo y problemas de integración.

Factores de éxito

Según Global Software Development Handbook [3] los factores críticos de éxito de este tipo de proyectos son los siguientes:

  • Reducir ambigüedades de procesos organizacionales, de administración, de requerimientos y diseño. Cualquier ambigüedad puede llevar a diferentes entendimientos, estos a conflictos y re-trabajo.
  • Maximizar la estabilidad, sobre todo de requerimientos y de arquitectura. Según estudios, una solicitud de cambio a requerimientos en un proyecto distribuido requiere 2.4 veces más de tiempo que en uno de un solo sitio.
  • Entender dependencias, tanto técnicas como temporales, es crucial. De esto depende la posibilidad de buena distribución del trabajo y la definición adecuada de actividades de coordinación en su volumen, frecuencia y tipo.
  • Facilitar la coordinación. Existen múltiples maneras de lograr la coordinación entre equipos. La más común es a través de comunicación, aunque también se puede lograr vía procesos, administración del proyecto o la arquitectura.
  • Balancear flexibilidad y rigidez en procesos. Los procesos tienen que ser lo suficiente flexibles para incorporar diferentes prácticas y experiencias de los equipos y dejarles cierto margen de libertad, pero lo suficientemente rígidos para asegurar que ciertos aspectos del proyecto estén perfectamente definidos, como por ejemplo: instrucciones comprendidas, arquitecturas respetadas, requerimientos cubiertos, administración de configuración definida y aplicada, procedimientos para integración y pruebas adecuados, etc.

Para aterrizar estas ideas al territorio mexicano quiero agregar algo. Seguramente ya tenemos en México empresas que están involucradas en el desarrollo de software global. Sabemos poco de sus experiencias. Por otro lado, tenemos desde hace años el movimiento de creación de clusters, pero cuando los visito y pregunto por proyectos en los que participan varias empresas, la respuesta es que “todavía no, pero ya pronto”.

Conozco los primeros intentos de este tipo de esfuerzos y los estoy observando con el objetivo de tener elementos para generar un modelo de procesos, que permita organizar las empresas pares para que colaboren en proyectos complejos. Digamos un MoProSoft Colaborativo. A los que tienen experiencia en este tipo de proyectos los invito a colaborar.

Referencias:
[1] D. W. Karolak. Global Software Development: Managing Virtual Teams and Environments. IEEE Computer Society, 1998.
[2] K. Fryer, M. Gothe. “Global software development and delivery: Trends and challenges”. http://bit.ly/sg30r2
[3] R. Sangwan, M. Bass, N. Mullick, D.J. Paulish & J. Kazmeier. Global Software Development Handbook. Auerbach Publications, 2007.

Bio

La Dra. Hanna Oktaba es profesora de la UNAM, miembro del IPRC, y directora técnica del proyecto COMPETISOFT.
hanna.oktaba@ciencias.unam.mx