Signos vitales de un proyecto software

Estoy leyendo el libro «The ThoughtWorks Anthology» dentro de la colección «The Pragmatic Programmer». Son ensayos sobre tecnologías y metodologías software de autores conocidos en el mundo de la ingeniería software (Martin Fowler, por ejemplo). Aunque algunos ensayos son duros de tragar, otros me han parecido muy interesantes de cara a la gestión de proyectos software, en especial el capítulo 8, que lleva como título «Project Vital Signs» de Stelios Pantazopoulos. Comienza diciendo : «En el campo de la medicina, un doctor o enfermera puede entra en la habitación de un enfermo, mirar la gráfica del paciente y hacerse una idea rápida y general del estado y signos vitales de dicho paciente. Con esa información a mano, el médico puede formarse rápidamente una idea sobre el estado de salid del paciente y decidir si es necesario tomar alguna acción correctiva. ¿No sería genial que existieran gráficas de ese estilo para un proyecto de desarrollo software, de tal forma que, de un vistazo nos permitieran hacernos una idea rápida de los signos vitales del mismo?» Eso es precisamente lo que el capítulo desarrolla a partir de ahí. Nos propone 5 gráficas a modo de «information radiators». Es un término acuñado por Alistair Cockburn (justo cuando estaba visitando una oficina de ThoughtWorks, la empresa de M. Fowler para la que trabajan el resto de autores del libro) para nombrar aquellas gráficas que, puestas en grande para que sean visibles por cualquier miembro del equipo, informen de los signos vitales del mismo. A partir de esos signos vitales podremos deducir el estado del proyecto. Esas gráficas se pueden dibujar sobre pizarras dentro de la sala de desarrollo o construir a través de post-its y enormes cartulinas como fondo; el estado de las graicas será actualizado por todos los miembros del proyecto (algunas sólo por ciertos roles y otras por otros). Un ejemplo para aclarar todo ésto: la gráfica «Scope burn-up»:

Es una gráfica donde vemos mucha información, muchos signos vitales del proyecto. En concreto, por cada iteración vemos:
* El número de historias de usuario sin desarrollar
* El número de historias desarrolladas pero que no han pasado aún los test de calidad
* El número de historias desarrolladas que ya han pasado los test de calidad
* La fecha en la que se pretende completar el desarrollo de todas las historias de usuario
* La fecha en la que se pretende tener validadas por control de calidad todas las historias de usuario
* Deadline
Como he dicho, la gráfica muestra los puntos anteriores por cada iteración, y además, la pendiente de cada curva (amarilla, roja, verde), nos da una idea rápida de si vamos bien o mal (si llegaremos a las fechas planificadas a tiempo o no).

Aparte del «scope burn-up chart» hay otras cuatro gráficas distintas que permiten tomar otras medidas de signos vitales (calidad de los entregables, control presupuestario, estado actual de implementación y percepción del estado del proyecto por los miembros del equipo). Lo dicho, un capítulo muy interesante y práctico para todo aquel que quiera desarrollar y gestionar proyectos software y no se conforme con los artefactos clásicos… dentro de un libro muy recomendable.