¿Cómo aplicar Agile y Scrum en proyectos de infraestructura?

Proyecto de actualización en el CPD - Cortesía de Pixabay

Los proyectos de infraestructura son aquellos que se producen en las áreas de sistemas y de arquitectura, suelen ser cosas como:

• Actualizaciones de hardware o de software
• Instalación de la infraestructura necesaria para que una aplicación de producto se pueda desarrollar y/o ejecutar
• Instalación masiva de BBDDs distribuidas
• Cambios de plataformas de correo
• Migraciones masivas de BBDDs por cambio de versión del SGBD

A diferencia de los proyectos de producto, en los que siempre se construye algo "nuevo", los proyectos de infraestructura no siempre implican algo nuevo, pueden tener requisitos bien definidos y dependencias conocidas, lo que ocurre es que la incertidumbre emerge en forma de problemas imprevisibles. Por tanto la complejidad de los proyectos de infraestructura puede ser de menor grado, pero cosas como los problemas y otras restricciones, como que algunas de sus tareas solo se puedan realizar dentro de ventanas permitidas (fines de semana o fuera de horas de oficina) por ejemplo, hacen que Agile y Scrum puedan aportar grandes beneficios. También aquí la creatividad de las personas es esencial para la resolución de problemas, así como para encontrar maneras de hacer el trabajo de la forma más eficiente posible.

En este tipo de proyectos hay que averiguar qué ofrece valor, habitualmente suele tratarse del ahorro de costes o del coste de la demora para habilitar la construcción de funcionalidades de producto que si tienen valor de negocio. En un proyecto de migración a la nube por ejemplo, puede medirse el ahorro de costes asociado con el espacio de disco y la utilización de la CPU, y en un proyecto de infraestructura para un producto puede medirse el coste que representa el retraso en la puesta en marcha de una determinada funcionalidad.

La ejecución de Scrum se hace de la misma manera que en un proyecto de producto, la clave siempre está en los puntos de feedback y de integración que ocurre a final de cada uno de los sprints. Por ejemplo, si te tratara de un cambio de la plataforma de correo, se puede empezar por un grupo reducido de usuarios, los que estén a favor del cambio, se migran y se toma feedback, se hacen los ajustes correspondientes y se migra el siguiente grupo. Lo mismo para las BBDD, se empieza por una, se comprueba, se toma feedback y a por la siguiente.

Nunca es buena idea cambiar todo a la vez, cuando puede haber imprevistos es mejor empezar de forma acotada y expandir paso a paso, a través de sprints y priorizando por criticidad, ahorro de costes, coste de la demora, valor... una migración de servidores, por ejemplo, se podría afrontar incrementalmente incorporando en cada sprint nuevos servidores para dar servicio a los productos de más valor en función de los segmentos de cliente que más importen.