Gestión ágil de proyectos en una Estrategia SOA

por

¿Puede la gestión ágil de proyectos ayudar en una estrategia SOA?. En esta entrada vamos a analizar este asunto, en mi opinión uno de los grandes olvidados cuando nos acercamos a una estrategia TIC basada en SOA.

 

INTRODUCCIÓN

Que la gestión del proyecto es un aspecto clave para su éxito resulta tan obvio como decir que el agua moja. Su correcta planificación, en tiempo y en recursos tanto humanos como técnicos, así como un buen seguimiento del proyecto, la gestión de riesgos, etc, son vitales para que nuestro proyecto alcance los objetivos marcados.

 

Lo que no encuentro tan obvio, o al menos no encuentro mucho debate sobre ello, es de qué manera la gestión de proyectos debe adaptarse a una estrategia de Orientación a Servicios. Aunque no todo es adaptarse: también es aprovechar las ventajas que aporta.

 

 

EL CONTEXTO

 

Empezaremos situando con claridad el contexto: estamos implantando una estrategia de Orientación a Servicios en nuestra organización y tras un piloto exitoso (no exento de dificultades), tenemos un Catálogo de Servicios inicial, una Normativa de Gobierno SOA publicada, una Oficina de Gobernanza liderando la estrategia, y una Oficina de Interoperabilidad responsable del desarrollo y mantenimiento del Catálogo de Servicios, y del despliegue y monitorización de la infraestructura.

 

Estamos por tanto a las puertas de extender la estrategia al resto del ecosistema de información. Ojo que vienen curvas.

 

Ya hemos hablado varias veces sobre los pilares de una estrategia SOA: Gobernanza, Bajo Acoplamiento, Eventos vs petición/respuesta (es decir, mensajería asíncrona vs mensajería síncrona), Contratos de Servicios (el Catálogo de Servicios), Infraestructura (dimensionamiento, configuración y monitorización), y el resto de los principios SOA reconocidos en la industria (Autonomía de los Servicios, Composición de Servicios, Reutilización de Servicios, Abstracción de los Servicios y Descubrimiento de los Servicios).

 

Desplegar una estrategia SOA en una organización supone algo parecido a encarar un proyecto de proyectos. En realidad esto es un concepto familiar en la gestión de las TIC desde hace décadas, porque toda organización que tenga un grado de madurez adecuado en esta área clave para sus objetivos, debe manejar periódicamente un Plan de Proyectos.

 

Pero el proyecto de proyectos que es la adopción de una estrategia SOA implica algo más. Porque esos proyectos requieren de una coordinación y una gestión jerarquizada bajo la oficina de Gobernanza que lidera la estrategia. En una estrategia SOA, es muy raro encontrar un proyecto que solo afecte a un sistema, a un equipo, a una empresa proveedora y a un responsable de proyecto. Lo habitual es que se vean implicados al menos dos, y con bastante frecuencia, más de dos.

 

Una estrategia SOA implica cambiar algunos patrones muy consolidados en las prácticas de muchos equipos y empresas, y esto no es ni inmediato ni fácil. Muchos de los proyectos no serán evolutivos desde un punto de vista funcional, sino de reingeniería SOA, es decir: adaptar los sistemas actuales con sus funcionalidades actuales a la nueva estrategia.

 

En paralelo, la organización está también desarrollando líneas de actuación en materia de comunicaciones, servidores, formación, mejora de procesos, atención a incidencias, soporte a usuarios, etc, etc.

 

Normalmente existe algún estamento superior al que se debe informar del estado de los proyectos, especialmente los proyectos clave, o del retorno de alguna inversión, o del resultado de alguna gestión que afecta a determinados sistemas o equipos.

 

Puede que esté pensando que un gobierno TIC efectivo siempre ha sido responsable de coordinar y supervisar todo el Plan de Proyectos de una organización, lo cual es cierto. Pero tradicionalmente han sido proyectos aislados, que afectan a un solo sistema y equipo de desarrollo de software (además de otras áreas transversales relativas a infraestructuras, comunicaciones, etc), y habitualmente han sido acometidos de manera independiente, elevando informes de seguimiento a los responsables del Plan de Proyectos, que permitían gestionar riesgos y tomar decisiones acerca de dicho plan.

 

En una estrategia SOA en cambio, la interoperabilidad cobra más protagonismo, y la gestión de proyectos debe tener en cuenta otras cuestiones que no son tan familiares ni tan inmediatas desde un punto de vista tradicional.

 

Bien, situado el contexto, continuemos.

 

EL PROBLEMA

 

Cuando existe un Catálogo de Servicios disponible para su reutilización por el resto de sistemas, empiezan a convivir proyectos y equipos que, de entrada, van a distinta velocidad. Si la organización mantiene el enfoque tradicional de gestión de proyectos, basado en el modelo en cascada (planificación, análisis, diseño, codificación, testing, despliegue), vamos a encontrarnos enseguida con proyectos de varios meses de duración, que encontrarán difícil encaje con la disponibilidad real de los servicios del Catálogo. Además esas metodologías tradicionales tienen inconvenientes bien conocidos: dificultad de adaptarse a los cambios y alta probabilidad de obtener respuestas a necesidades obsoletas por el paso del tiempo.

 

Este desfase de velocidades que aludíamos sucede porque la Oficina de Interoperabilidad (OI) es un equipo especializado y dedicado a mantener el Catálogo de Servicios. Y este catálogo es la “navaja suiza” de la organización, donde todos los sistemas deberán mirar para reutilizar los servicios existentes para sus requisitos, y para incorporar con la OI nuevos servicios de interés para la organización. Por lo tanto cuando se identifique la necesidad de evolucionar un servicio existente o de crear uno nuevo, éste va a estar disponible en días o pocas semanas como mucho (naturalmente, asumiendo que la OI está correctamente dimensionada). El nuevo servicio o la nueva versión del servicio estará disponible muchísimo antes de que el proyecto que lo necesita haya llegado a la fase de construcción.

 

En un ecosistema de información complejo, con el tiempo esta dinámica dará lugar a importantes conflictos de versiones, implantaciones, fases de testing, pilotajes, y en definitiva veremos una creciente ineficacia de la OI, un crecimiento ralentizado del Catálogo de Servicios (con frecuentes y largos bloqueos), un lastre en la extensión de la estrategia (que empezará a ver como determinados proyectos concluyen fuera de su alcance), y muy probablemente, una merma en la calidad de los resultados que se vayan obteniendo.

 

En definitiva, nuestros jefes no verán todos esos beneficios que prometía una estrategia SOA, y llegarán a plantearse retirar su confianza, disminuir la inversión, el compromiso y la implicación, presionar para obtener resultados, etc, etc. Todo encaminado hacia el desastre y la vuelta atrás.

 

Pero, que no cunda el pánico. Hay solución.

 

 

LA SOLUCIÓN

 

Para evitar esto, afortunadamente, tenemos hoy día las metodologías de gestión ágil de proyectos. Y en mi opinión, son los compañeros de viaje perfectos para la extensión de una estrategia de Orientación a Servicios. Me atrevería a incluirlas como ingrediente necesario en la estrategia SOA.

 

Aunque existen varias de estas metodologías, la más conocida y extendida es SCRUM. Considero que sería un acierto incluir dentro de la estrategia de interoperabilidad orientada a servicios la adopción de esta metodología en la gestión de los proyectos, al menos a partir de la etapa de extensión de la estrategia, para así tener la mayor flexibilidad y capacidad para adaptar los sistemas a la evolución del Catálogo de Servicios. Como hemos visto en el apartado anterior, la fase de extensión de una estrategia SOA es, por su propia naturaleza, una fase ágil, con una muy alta capacidad de generar releases rápidas en periodos de tiempo cortos. Por lo tanto, la aplicación de metodologías de gestión ágil de proyectos es especialmente apropiada.

 

En SCRUM hay dos roles que son fundamentales:

Product Owner, que suele ser quien expone los requerimientos (normalmente alguien de la organización).

SCRUM Master o facilitador, encargado de «despejar el camino» al equipo técnico resolviendo los bloqueos, las dependencias con terceros, resolviendo dudas, etc.

 

Junto a estos roles, existen unos conceptos especialmente importantes en mi opinión:

Product Backlog, que es la lista de los requisitos que se van a resolver en el proyecto. Estos requisitos se irán repartiendo en las distintas iteraciones, normalmente priorizando los que supongan mayor beneficio con el menor esfuerzo, y teniendo en cuenta la velocidad del equipo (una medida revisable de la capacidad de tareas que puede realizar en una iteración).

Sprint, que es cada una de las iteraciones en las que se ataca un subconjunto del Product Backlog (llamado Sprint Backlog), y que obtiene como resultado una release, que se muestra al Product Owner en una demostración, y está lista para subir a producción. Las iteraciones suelen ser cortas, entre 2 y 4 semanas, aunque no es raro encontrar referencias a sprints de 2 y hasta 3 meses (que a mí me parece excesivo).

 

Hay muchas cosas en SCRUM que me gustan, pero aquí no se trata de contar en detalle la metodología SCRUM ni mi análisis particular. Las sesiones diarias de sincronización del Sprint y la Retrospectiva me parecen un acierto que demuestra lo mucho que SCRUM se acerca a la realidad de los proyectos, y por supuesto aquí también lo consideramos. Pero insisto, volvamos al foco del post: gestión ágil de proyectos en una estrategia SOA.

 

 

GESTIÓN ÁGIL DE PROYECTOS EN UNA ESTRATEGIA SOA CON SCRUM.

 

Y ¿cómo encaja SCRUM en una estrategia SOA? Pues en mi opinión, estupendamente. Pero eso sí, teniendo muy presente que estamos ante un “proyecto de proyectos”, por lo que aquí cabe plantearse un «SCRUM de SCRUMs”.

 

Si suena complejo es porque es complejo. Pero ¿quién dijo miedo?.

 

Y teniendo en cuenta la complejidad inherente a una estrategia SOA, no estamos añadiendo más complejidad. Estamos añadiendo técnicas que nos van a simplificar y aliviar la coordinación de los proyectos a ejecutar durante la extensión de la estrategia.

 

Veamos cómo.

 

El Plan de Proyectos que surge en la extensión de una estrategia SOA mezclará requisitos funcionales con requisitos de reingeniería SOA. Lo más habitual es que todos los proyectos incluyan ambos tipos de requisitos, y podría ocurrir que algunos proyectos consten exclusivamente con requisitos de reingeniería SOA.

 

El primer aspecto clave para usar SCRUM en nuestro escenario es obvio: todos los Product Owner y todos los SCRUM Master deben ser perfectamente conscientes y conocedores de la estrategia, la normativa y el Catálogo de Servicios.

 

El segundo lleva el sentido inverso: la Oficina de Gobernanza y la OI deben tener en cuenta a la hora de diseñar los procedimientos y las políticas las peculiaridades de SCRUM en la gestión de los proyectos. No tiene sentido diseñar procedimientos largos, complejos o muy burocráticos, cuando la filosofía misma de los proyectos es la agilidad y la rapidez en obtener resultados.

 

En tercer lugar, será necesario que un Product Owner de la Oficina de Gobernanza coordine los Product Backlog de los proyectos y al resto de Product Owners. El responsable de la OI sería el Product Owner del Catálogo de Servicios. Este equipo adoptaría el mismo enfoque que el resto de los equipos para facilitar la sincronización de las releases.

 

Las metodologias agiles encajan en la Estrategia SOA mediante una piramide jerarquica de proyectos SCRUM coordinados desde la Gobernanza SOA

 

Una de las características de SCRUM es la reunión diaria de sincronización del Sprint. En esta sesión rápida, que se recomienda que se haga de pie precisamente para agilizarla, se establecen los objetivos más inmediatos (del día) para el equipo, y se ponen encima de la mesa los bloqueos, dudas o dependencias que el SCRUM Master debe despejar. Pues bien, sería deseable que en una Estrategia SOA se celebrara una sesión diaria que reuniera a todos los SCRUM Master implicados en los proyectos, para que desde la Oficina de Gobernanza se agilizara la resolución de los problemas y bloqueos elevados por los distintos equipos.

 

Otra de las características más eficaces de SCRUM es la celebración de sesiones de Retrospectiva al final de cada Sprint. Estas reuniones tienen como objetivo revisar cómo ha funcionado el Sprint, qué cosas hay que potenciar, mejorar, cambiar o corregir, para todos los roles del equipo. Y efectivamente, lo siguiente que planteo es tener también una sesión de Retrospectiva a nivel de Oficina de Gobernanza con los Product Owner y SCRUM Master de los proyectos.

 

Dependiendo de las dimensiones de la organización y la variedad de proyectos concurrentes, habrá que dimensionar de forma razonable la duración de los Sprints. Quizás menos de un mes puede ser demasiado estresante, demasiadas reuniones, y más de un mes de duración para cada Sprint puede ser demasiado, favoreciendo un avance demasiado pausado.

 

En una Estrategia SOA las metodologias agiles encajan especialmente bien con el mantenimiento del Catalogo de Servicios, bajo una Gobernanza que coordina los distintos sprints

 

¿Me he vuelto loco? ¿84 reuniones al mes? eso sin contar reuniones de seguimiento, comités, etc, etc. Calma.

 

Pensemos un poco:

– Un sprint más corto no reduciría el número de reuniones, al contrario: habría más reuniones de retrospectiva, porque las sesiones diarias de sincronización seguirían siendo las mismas.

– Un sprint más largo no reduciría las sesiones de sincronización diarias, pero sí las reuniones de retrospectiva. Sin embargo, éstas perderían efectividad, serían más densas y requerirían más esfuerzo para obtener medidas de mejora realmente eficientes. E insisto: reduciríamos las reuniones globales mínimamente.

– El peso de esta cantidad de reuniones aparentemente exagerada lo llevan las sesiones diarias de sincronización de cada proyecto, donde como hemos comentado anteriormente el SCRUM Master se reúne con su equipo para trazar las tareas del día, y poner sobre la mesa los obstáculos que debe despejar el facilitador. Pero estas reuniones, siguiendo la filosofía SCRUM, son de todo menos tradicionales: se celebran de pie, no deben durar más de 15 minutos, y son uno de los principales motores de la metodología ágil. Y si una técnica te da agilidad, pues a por ella ¿no?.

– Donde precisamente habría que plantearse si tiene sentido reunirse es en todas esas reuniones tradicionales que se celebran en los proyectos, esas tareas altamente improductivas, donde unos cuantos profesionales bastante cualificados para hacer avanzar los proyectos se sientan durante unas horas para acabar concluyendo que tienen que hacer otra reunión, que hay que replanificar, que hay que preguntar aquí o allá, o que hay que enviar un correo recordando algo, etc, etc… unas reuniones donde la mayoría de los asistentes o no abren la boca, o solo les afecta lo que se dice en 10 minutos a lo sumo… unas reuniones a las que le sigue la redacción y revisión de un acta… ¿cuántas horas de trabajo se van en estas reuniones? ¿no es ese balance de horas altamente improductivas el que habría que atajar?.

 

Sí. Rotundamente sí.

 

 

EL ÚLTIMO OBSTÁCULO Y SU SOLUCIÓN.

 

A todo lo dicho sobre cómo integrar SCRUM como metodología de gestión ágil de proyectos en la adopción de una Estrategia SOA, añadiría otro ingrediente más, relacionado con la agilidad en la gestión de las TIC, y con la capacidad de una organización para poner en operación sus soluciones y servicios. En mi experiencia, me he encontrado con importantes retrasos y conflictos en esta etapa final, a pesar de todo el trabajo realizado para tener una release lista para su despliegue y puesta en producción.

 

Me estoy refiriendo a DevOps.

 

DEVOPS Y LA ESTRATEGIA SOA

 

¿Y qué es DevOps? Puede que haya oído el término últimamente pero apuesto a que nunca se ha detenido nadie a explicarle lo que es (si me equivoco, entonces me alegro de no haber apostado nada concreto). Sin desviar el foco del post, y para poder situarlo en el contexto que nos interesa, vamos a tratar de fijar el concepto.

 

DevOps nace de la fusión de “Development” y “Operations”. En realidad el término no hace justicia a la amplitud y variedad de equipos y perfiles que abarca. Es frecuente encontrar en la definición de DevOps a tres disciplinas relacionadas y participantes activas en el diseño, desarrollo, testing, y puesta en producción de los sistemas de información: Desarrollo, Calidad (QA) y Operaciones.

 

Lo que DevOps persigue es extender la bondades de las metodologías ágiles hasta las etapas posteriores al visto bueno del usuario a las pruebas finales. Tradicionalmente los equipos de desarrollo han tenido su meta en ese hito: las pruebas de usuario. Pero, para la organización, en ese punto no es donde acaba todo, sino donde empieza. Y habitualmente nos encontramos en la práctica de los proyectos con desfases y problemas importantes en la coordinación del empaquetado, versionado, despliegue, y soporte.

 

Como hemos dicho, DevOps está muy relacionado con las metodologías Ágiles, y es especialmente necesario y eficiente en escenarios donde se persiguen releases frecuentes, con poca carga funcional, que aportan valor rápidamente a la organización (justo lo que ocurre con SCRUM). La automatización de las pruebas, y por extensión, de la generación del paquete correspondiente a desplegar, libre de errores, así como la implicación de los perfiles de Operaciones en el ciclo de vida de desarrollo, son dos de las más destacadas características de DevOps, y permiten alinear mucho mejor la puesta en producción y soporte a la operación posterior al desarrollo puro del proyecto, y en definitiva, mejorar sustancialmente la calidad del resultado de todo este trabajo.

 

En una estrategia SOA, donde buscamos que la extensión de la estrategia se produzca con el menor número de bloqueos posible, hemos planteado la incorporación de metodologías ágiles para la gestión ágil de proyectos, permitiendo de esta forma liberar paquetes de mejoras bien coordinados con la evolución y extensión del Catálogo de Servicios.

 

En este contexto, DevOps es la guinda al pastel: reduce drásticamente los problemas “post-producción”, mejorando la capacidad de atención a incidencias y soporte al usuario, la calidad de las implantaciones, el tiempo necesario para instalar las nuevas versiones, etc, etc.

 

Y, finalmente, un detalle adicional y colateral a todo esto, que no quiero dejar de subrayar como importantísimo para el éxito de cualquier proyecto (ya sea la implantación de una estrategia SOA, como cualquier otro proyecto), y que está en el ADN de la filosofía subyacente a las metodologías ágiles. Los profesionales que participamos en los proyectos, dedicamos muchas horas, energía, esfuerzo e ilusión, a lo que hacemos. Comprobar que nuestro trabajo llega en óptimas condiciones, en tiempo y forma, al usuario final o al ciudadano, es un elemento enormemente motivador. En cambio, ver que el esfuerzo se pierde por el camino, es un elemento enormemente desmotivador.

 

Y no es ningún secreto que equipos motivados son equipos más productivos y eficaces.

 


Si te ha gustado este artículo, compártelo en tus redes sociales. Si te interesa o quieres añadir o matizar algo, o simplemente opinar sobre el contenido, no dudes en dejar un comentario aquí abajo.

¡Y gracias por tu tiempo!

Te puede interesar

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This