Grandes consultoras visionaron hace ya unos años la importancia para mejorar su competitividad hacer uso de desarrollos Offshore, desarrollos descentralizados que permitan hacer uso de costes de desarrollo más económicos y a mayor escala que un enfoque estrictamente Onshore. Pero quizás agudizado por estos momentos de crisis que fuerzan a las compañías a ser más eficaces, más eficientes, han impulsado este movimiento a un enfoque con prácticas Agile que podrían a priori pensarse que son más efectiva para enfoques mas pequeños, de corta duración y centralizados. La mayoría de las organizaciones optan por un modelo waterfall tradicional para el enfoque de desarrollos Off-shore. Estas definen tareas dimensionadas en grandes planes de trabajo y con modelos organizativos tradicionales, naturalmente estas aproximaciones chocan directamente con aproximaciones Agile, las cuales definen aproximaciones increméntales de valor añadido. Una aproximación que hemos comentado en alguna ocasión en este blog es hacer uso de modelos híbridos tal como se ilustra en el siguiente gráfico, se define una baseline donde definiremos los parámetros del proyecto, los estándares de desarrollo, la arquitectura técnica a utilizar en cada una de las iteraciones que después se irán aplicando en el modelo Offshore. En la primera iteración (Spring 1) el equipo Onshore trabaja directamente con el usuario de negocio definiendo los requerimientos funcionales, cuando estos están suficientemente detallados estos son entrados en el back-log de la funcionalidad a implementar. El back-log no es más que un inventario de las capacidades que deberán ser diseñadas, desarrolladas y testadas y aceptadas por el negocio una vez se de la luz verde de su finalización. Así el equipo Offshore toma el inventario, lo evalúa y determina la complejidad y el esfuerzo a realizar, basado en esta estimación dimensiona el equipo adecuado para su desarrollo, pero justo cuando el desarrollo empieza, es cuando los problemas empiezan, ya que las metodologías utilizadas dentro del equipo Offshore son habitualmente metodologías tradicionales con sobrecostes posiblemente innecesarios en una aproximación Agile. Veamos algunos ejemplos. El primer escenario, donde se plantea de forma iterativa, el equipo Offshore decide incrementar el coste de la iteración en un factor de 1/4 debido a que no está incluido en ningún momento las pruebas de concepto, los prototipos, las demos o las revisiones de código, significa ello que los desarrollos Agile no contemplan estas tareas, es lo que se preguntan los equipos Offshore. Existen diversos métodos híbridos para dar respuesta a esta pregunta. Otro ejemplo es cuando el equipo Offshore rechaza al inicio del desarrollo de la iteración por no estar perfectamente documentado el alcance de la misma. Nuevamente técnicas híbridas se pueden aplicar, pero cuanto de riesgo suponen estas aproximaciones…? Se debe tener los ojos bien abiertos, porque podrían estas aproximaciones generar más riesgo en el proyecto. Entonces la pregunta que nos formulamos debería ser, es posible desarrollos globales utilizando modelos Agile? Y como siempre utilizaré las respuesta del consultor, depende… Agile por definición es iterativo, necesita un alto grado de comunicación en el proceso de desarrollo, versus a un modelo más tradicional. Los modelos GDM (Global Delivery Model) están basados en la premisa del desarrollo 24 horas aprovechando las diferencias horarias. Existen diversos factores que determinan el grado de éxito de uso de aproximaciones Agiles en modelos GDM, un primer factor aunque parezca etéreo es el factor cultural, sin duda un modelo Agile implica un mayor «stress» por parte del cliente y el equipo distribuido debe estar preparado para trabajar en estas condiciones de cambios continuos. El segundo factor es el talento de cada persona del equipo, así pues nos deberemos hacer estas preguntas: Cuanto contenido complejo puedes anticiparte? Si no podemos anticiparnos con propuestas, soluciones, estas decisiones recaerán son el equipo Offshore y dado su grado de conocimiento es posible que no den con una solución a tiempo en el corto espacio que implica una iteración, por tanto puede hacer fracasar el proyecto Agile, la siguiente pregunta muy relacionada con la anterior es disponemos de los arquitectos y diseñadores necesarios, si no disponemos de estas figuras es posible que los equipos no puedan avanzar con la suficiente agilidad. La siguiente pregunta que nos debemos formular es, nuestra organización o modelo de GDN es suficientemente flexible para hacer uso de un modelo Agile, ya que debemos tener presente lo que supone un modelo Agile de una continua presión por disponer de releases cada cierto corto espacio de tiempo definido en una iteración.
Sin duda el matrimonio Agile y GDM puede ser un matrimonio de éxito donde podamos mejorar e incrementar la eficiencia, pero debemos no ser ingenuos en su uso pues tiene muchos factores de riesgo que deberemos abordar con modelos, experiencias, herramientas adecuadas. Un gran reto que nos iremos viendo envueltos en los próximos años como hemos ya venido trabajando en desarrollos Onshore/Agile.
También recuerdo más recientemente como alguien de relevancia comentaba en una audiencia que exceptuando en raras ocasiones los proyectos SOA había tenido éxito y se conseguían los objetivos que habían impulsado su ejecución. ¿Es SOA por tanto una desilusión?, cabe preguntarse, ¿porque es un fracaso?, quizás la pregunta nos lleve a reflexionar que tal vez hemos menospreciado el factor de otras cuestiones subyacentes que requerían primero una respuesta antes de plantearse un modelo SOA, preguntas quizás de ámbito técnico que se partía de que todo estaría resuelto con simplemente publicitar un conjunto de servicios, preguntas tal vez como cual es el mejor ESB? o preguntarse por WS-* vs REST y otras muchas más que seguro se os estarán ocurriendo, quizás implique que debamos primero rediseñar nuestras aplicaciones para poder dar servicio SOA. SOA debe estar dentro de un proyecto mucho más grande sino seguramente será un fracaso. SOA debe estar dentro de una estrategia a largo plazo y no como un factor complementario y puntual, debe ser un producto de años, bien orquestado y alinear quizás muchas estrategias. Analicemos que factores pueden impulsar una estrategia de esta magnitud, cada uno seguramente tendrá sus propias motivaciones, pero si analizamos algunos escenarios podremos ver que posiblemente tengamos, como muy bien dice Hanu Kommalapati esta tipología: