Es un matrimonio posible Agile y desarrollo Offshore?

apr-09-paradoxbigGrandes 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áficoimage, 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.

¿Qué ocurre con SOA…?, da paso a Cloud Computing…

Aun recuerdo una presentación hace ya algún tiempo donde se explicaba como SOA supondría para las empresas la fórmula para la reducción de costes incrementar la agilidad de las compañías y potenciar de forma fácil los incrementos de su valor añadido a gran escala. Unusual Spiral NGC 4921Tambié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:

· SOA-R, soluciones orientadas a obtener beneficios, ejemplos ampliamente conocidos Microsoft Live, Google, Amazon, etc. Soluciones estrechamente alineadas al negocio de las compañías, por lo tanto hay un fuerte apoyo del negocio, bien definido, bien acotado, implementando los estándares del mercado. Básicamente diría fuerte implicación de la organización, puesto que su éxito depende en parte la medida de subsistencia de la propia compañía que emprende el proceso.

· SOA-B, permitir el negocio, con esta segunda estrategia se pretende eliminar el desacoplamiento de los sistemas de las organizaciones. Las compañías no son estáticas, continuamente se desarrollan sistemas útiles para determinadas áreas pero que también podría ser vitales o de valor añadido para otras y que debido a la complejidad de su organización hace que sea complicado el flujo de información, es aquí donde soluciones SOA-B pueden ser acicate para llevar a cabo la resolución de estos problemas. Por tanto los motivantes son más orientados a la alineación del negocio, naturalmente se necesita la esponsorización del proyecto puesto que puede afectar a muchas áreas, la implicación del departamento de IT, y va a requerir un proceso extensivo en el tiempo ya que podemos toparnos con multitud de sistemas, tecnologías e inclusive soluciones parciales que deberemos ir abordando en una estrategia a largo plazo.

Por tanto ¿esta SOA muerto…? que ocurre con Cloud Computing, ya recogíamos en este blog varios enfoques de lo que representa Azure, escuchábamos en el PDC a Muglia etiquetar a Azure como la quinta generación de computación, empezando por las aplicaciones monolíticas, aplicaciones cliente/servidor, aplicaciones web y SOA. Porque Microsoft argumente que Cloud es un paso más, por la imposibilidad de SOA de escalar adecuadamente y con ello conseguir los objetivos que abanderaban su ejecución. Con la plataforma de servicios Azure construidos sobre los principios de SOA pretende superar las limitaciones iníciales, ¿cómo…? rediseñando desde el principio la plataforma y no “re aprovechando la existente” esta aproximación es la que lo hace diferente. Según Joe Mckendrick SOA no es una plataforma es una colección finita de tecnologías, una metodología una filosofía si cabe que permiten ofrecer servicios disponibles en cualquier momento en cualquier sitio y consumidos por cualquier usuario, aunque esa es solo la teoría… Según David Chappell comparar SOA vs Cloud Computing es como comparar peras con manzanas, aunque puedan tener puntos en común resuelven problemas diferentes, SOA proporciona servicios web desde aplicaciones u otros programas mientras que Cloud proporciona servicios de software a usuarios finales y ejecutando código, SOA expone servicios a otras aplicaciones, ejemplo tengo un sistema SAP que expone servicios a otras aplicaciones. En Cloud se habla de Software como Servicio, se está hablando no solo de dar servicio a otras aplicaciones sino que también al usuario final. Por supuesto otra diferencia es la plataforma, cuando pensamos en Windows Azure pensamos en plataformas para desplegar servicios desde la Cloud, pero también para ejecutar código en la Cloud esta es una realidad totalmente diferente de la aproximación SOA. Me quedo con la frase de Chappell: They overlap in some areas but they are fundamentally different.

Seguiremos hablando largo y tendido en este blog.