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.

Siempre enarbolando la bandera del Testing

Llevo muchos años dedicados al Delivery y desde los principios, inclusive antes de saltar a la palestra se ha enarbolado la bandera del Test como un factor decisorio. Muchas son las acciones y experimentos que he visto o se han realizado que al final no han tenido éxito, o inclusive he visto en primera persona como el test es la parte del ciclo de vida tedioso, aburrido y que se realizará si se tiene tiempo, y sino pues contemos con la buena suerte de la diosa fortuna, y confiemos en la buena disciplina de los desarrolladores.

La buena noticia, es que hemos evolucionado mucho, tanto en forma de pensar como ejecutar, así como las herramientas que nos permitan asegurar que los resultados que estamos produciendo cumplan lo esperado por nuestros clientes, lo esperado por los requerimientos. Sabemos cuanta variedad de tipos de procesos de pruebas existen… recientemente comentaba mi experiencia en un gran proyecto donde teníamos mas de 20 tipología de entornos enmarcados dentro del ciclo de vida del desarrollo y me decían para que tenías tantos… Adentrémonos dentro de la amalgama de tipología de procesos de test, tenemos por ejemplo: Acceptance testing, Ad hoc testing, Black box testing, Code coverage, Compatibility testing, Conformance testing, Load testing, Localization testing, Mobile Device Testing, Sanity testing, Smoke testing, Stress testing, GUI software testing, Fuzz testing, Unit testing, White box testing, Boundary testing, Integration testing, Installation testing, Exploratory testing, All-pairs testing, Scenario testing, Soak testing, QuickCheck, Software performance testing, Regression testing, System testing, Model-based testing, Static testing, Usability testing, Game testing, Session-based testing, Hallway testing, System integration testing, Boundary Value Analysis, Pseudolocalization, Recovery testing, Software verification, Playtest, Keyword-driven testing, Monkey test, Manual testing, Combinadic, Build Verification Test, realmente es una buena lista, casi podría decir sin equivocarme que en el mundo de la consultoría utilizamos, aquellos que preocupados por la calidad del software, una ínfima parte de la lista. En ocasiones no se comprende ni por el usuario final, ni por los propios consultores, el coste que tiene garantizar lo que estamos desarrollando, se suele escuchar en alguna ocasión, pero si sois profesionales, porque me tiene que costar tanto desarrollar y probarlo…

Sin duda bajo mi concepción, están cambiando mucho las cosas y ello es positivo, se comprende más lo que hacemos en los proyectos, el usuario final no es un ente que desconoce lo que implica el ciclo de vida, se crean nuevos métodos más ágiles de desarrollo, con la única finalidad de acercar lo que entendemos a un producto que no se ciña únicamente por completar con éxito un plan de trabajo, sino a generar un producto que realmente sea desde el primer momento que sale la luz de valor añadido para el cliente. Todos aquellos que vivimos en el mundo del software ya sea trabajando en el o como usuarios, sabemos que los errores no son gratuitos, se requiere tener un equipo bien dimensionado para atender las quejas del usuario, trasladar las quejas a los equipos de mantenimiento, planificar y aplicarlos con cuidad en el código desarrollado, si este código no cumple con los criterios de la orientación a las pruebas, puede ser cada vez más costoso corregir las incidencias.

El proceso de test podríamos estratificarlo en los siguientes niveles:


  • Unit test, bajo mi punto de vista sería el test mínimo que cubre la funcionalidad del componente desarrollado o módulo. En una programación orientada a objetos la mínima unidad sería a nivel de clase, donde definiremos los métodos de test para cada método de la clase. Afortunadamente los que trabajamos en el mundo Microsoft contamos con la valiosas aportaciones que nos proporciona el Visual Studio 2008 para añudarnos a cometer este objetivo básico. Deberemos incluir los ciclos de pruebas unitarias dentro de procesos periódicos que alerte al programador de que lo desarrollado no está alterando el comportamiento de otras partes del código. Existen muchas escuelas que nos enseñan cuando debemos generar estas pruebas, unos abogaran por primero establecer la codificación de las pruebas unitarias antes del desarrollo del código, en otros blogs abordaremos con más detalle cada disciplina, aunque existe blogs escrito por vosotros con un nivel de detalle excelente que nos puede ayudar a comprender la mecánica de cómo hacerlo.
  • El siguiente nivel que nos viene a todos a la cabeza sin duda son las pruebas integradas, como desarrollamos aplicaciones por fortuna en un solo módulo o clase, aunque de todo he podido ver en mis años dentro del delibery, los componentes que cada desarrollador codifica interactúan unos con otros mediante interfases y las garantías de que esta iteraciones funcionen correctamente son el objetivo de las pruebas integradas, pruebas con componentes comunes, pruebas con elementos de arquitectura, son ejemplos que estarían dentro de las pruebas integradas. Bajo mi punto de vista continuamos aun dentro del ámbito y entorno de la responsabilidad de los desarrolladores y estos deben responsabilizarse de la implementación de estas pruebas.
  • El siguiente nivel, que ya tendréis en mente, son las pruebas de sistema, el producto que estamos desarrollando se enmarca dentro de los requerimientos definidos que por un proceso de diseño descendente hemos descompuesto en elementos individuales que hemos ido probando de forma individualiza y sumando elementos y probando sus interfases, toca pues probar que el sistema cubre los requerimientos definidos, muchas veces estas pruebas caen en el contexto del equipo de pruebas de sistema, un equipo con la visión de conjunto de todos el sistema y con los requerimientos como arma arrojadiza contra lo desarrollado, mi visión es que aquí para poder establecer ciclos de desarrollos cortos también deberíamos abordar procesos automatizados de pruebas, será entonces muy importante que modelos de aplicación hayamos seleccionado, modelos que nos permitan orientar nuestro sistema a las pruebas.
  • Por último ya tendréis en menta que el siguiente nivel son las pruebas de sistema integradas, en el casi 90% de las aplicaciones que desarrollemos estas deberán de convivir con otras aplicaciones o sistemas, estas pruebas deberán garantizar que lo que desarrollamos se integran perfectamente con otros sistemas que pueden estar desarrollándose en paralelo, con lo que tendremos que lidiar con la dificultad que ello implica, o con sistemas que ya están instalados y que pueden estar sufriendo procesos evolutivos y deberemos gestionar nuestros ciclos de versiones de nuestro producto con los ciclos de versiones de la evolución de otros sistemas. La generación de estas pruebas puede caer fuera del ámbito del desarrollador, ya que es necesario conocer cómo funcionan otros sistemas, pero sin duda bajo mi punto de vista para que estas puedan realizarse con la periodicidad necesaria, deberemos poder automatizar al máximo mediante simuladores, conjunto de datos, etc.

Todos estos niveles junto con todas las pruebas citadas que en sucesivos post podemos debatir si ello es de interés actual, serían imposibles de abordar y esta es mi opinión sin dos condicionantes, herramientas que te ayuden en el proceso de generación de las pruebas, en el proceso de ejecución de las pruebas y en el proceso y esto es muy importante en el proceso de análisis de los resultados e historificación del proceso de mejora que nos permitan tener una visión de la salud de nuestro sistema y su mejora o degradación, para mi es fundamental el esfuerzo realizado por Microsoft con la plataforma de desarrollo Visual Studio Team System y estoy seguro que seguirá aportándonos nuevas capacidades en el futuro con las siguientes versiones del mismo, así como de tener claro la metodología para incorporar de forma adecuada las pruebas en el ciclo de desarrollo de las aplicaciones, sin ello, podemos tener toda la batería de herramientas como un factor interesante a la hora de desarrollar nuestras sesiones de evangelización, nuestras propuestas, pero no en nuestros procesos de delivery.

Corolario final, enarbolemos la bandera de las pruebas como algo realista desde el principio del desarrollo, desde el diseño de la arquitectura de aplicación y tengamos presente todos los aspectos que nuestro sistemas tiene y cuál es su entorno porque podemos generar un producto de calidad que podría ser metástasis cuando lo ponemos en el bosque de sistemas del cliente.

Gracias por leer mi blog que no tiene más finalidad que exponer mi punto de vista sobre como yo percibo la realidad del software enfundado en el mono del entorno de Microsoft.

Agradecer la oportunidad

Permitirme publicar un breve post, con la única finalidad de agradecer a Rodrigo Corral González la oportunidad de publicar alguno de mis blogs también en la comunidad Geeks, el cual quiero centrar exclusivamente al ciclo de vida del desarrollo con tecnologías Microsoft, reservando este espacio para continuar teniendo la oportunidad de expresarme comodamente sobre todos los temas que me motivan y de alguna manera afectan a mi vida profesional. Geeks, es una comunidad de Bloggers, de una excelencia muy alta, y de un valor añadido para sus lectores muy importante, yo me considero lector asiduo de lo que allí se escribe, y pensar en que me dan la oportunidad de escribir y publicar algunos de mis blogs, me llena de ilusión, orgullo y supone un nuevo desafío en este campo.