Es la infraestructura, estúpido

Cuando se trata de implantar un sistema de integración contínua a posteriori, esto es, cuando un proyecto hace tiempo que está en marcha, es seguro que va a haber problemas.

Los proyectos adquieren vida propia, y evolucionan a su manera si no existe un control sobre ellos, casi siempre, hacia el desastre el día de la entrega. Nota para navegantes: los parches y soluciones ad hoc sólo empeorarán la situación.

Es por ello que los mecanismos de control se deben implantar desde el primer día, dentro del análisis (si no estás haciendo análisis, tu problema es más grave). Una jefatura de proyecto que realice sus tareas (gestión y control) es el primer paso. Una plataforma de integración contínua donde se vigilen los aspectos básicos de higiene y buenas maneras en el código puede ser el segundo paso.

Medir la salud de un proyecto

Hoy he encontrado una revista muy interesante que publica IBM, The Rational Edge, sobre gestión de proyectos, análisis, diseño y buenas prácticas.

He estado mirando una serie de artículos sobre cómo medir la salud de un proyecto, y éste es un resumen:

• Establecer sólo la meta a conseguir es un error. Se debe establecer un margen de error porque la realidad es cambiante. A través de las iteraciones los valores esperados deben ir aproximándose a la meta. A medida que esto ducede, el riesgo va decreciendo.
• La definición de tareas detallada inicial es un error, porque se basa en especulaciones. Lo que hay que hacer es medir en cada fase ciertas cosas.
• En la fase de elaboración (análisis y diseño) se identifican los riesgos que afectan al proyecto según su importancia. Se debe realizar un seguimiento de estos riesgos para validar que van disminuyendo conforme va progresando el proyecto. El proyecto va progresando a medida que se van solucionando problemas en cada iteración. También hay que tener en cuenta el trabajo que se rehace, porque muestra problemas en decisiones anteriores, y debe haber más trabajo rehecho al principio del proyecto y menos al final.
• Otros elementos a tener en cuenta son las funcionalidades que se descubren sobre la marcha, las pruebas y la estabilidad en la construcción. Si no se realizan las pruebas se da por terminado un trabajo que no lo está, y que luego será trabajo para rehacer. Las pruebas deben ser unitarias y funcionales, y se debe realizar un seguimiento de cobertura. El sistema debe construirse sin problemas la mayoría de los días, y se debe investigar qué ha pasado los días que no se ha construido correctamente (integración continua).
• Realizar una retrospectiva sobre qué se hizo bien y qué mal, separándolo del quién. Realizar una guía de recomendaciones.

---

Referencias
Measuring project health: Part I. Bittner, K. The Rational Edge, Enero 2007, págs. 24 – 32.
Measuring project health: Part II. Bittner, K. The Rational Edge, Marzo 2007, págs. 24 – 31.
Measuring project health: Part III. Bittner, K. The Rational Edge, Mayo 2007, págs. 38 – 44.