Industrialización del Software: Manual del paracaidista

Y en estas que de repente eres afortunado al caer cual paracaidista en un proyecto que va como el rosario de la aurora. Así que tienes que ponerte a industrializar el desarrollo del software, que es la forma «fina» de decir que tienes que empezar a poner orden.
 
Partimos de una situación en la que el proyecto es un caos, con lo que no podemos abordar todos los frentes a la vez, o corremos el riesgo de no conseguir reconducir ninguno. Para que el proyecto sea un caos y te llamen para reconducirlo es que probablemente ya tengan cosas entregadas o estén muy cerca de tener que entregar.
 
¿Por donde empezar?
 
Si hacemos caso a lo que propugnaba Bertran Meyer en su libro sobre Construcción de Software Orientado a Objetos, existen dos factores de calidad, los internos y los externos. 
 
Simplificando un poco, los factores de calidad externos son todos aquellos que ve el cliente y los internos son todos esos «palabros» que nos inventamos los técnicos, que si la modularidad, que si el polimorfismo, etc. 
 
Al final como el propio Meyer dice, lo importante son los factores de calidad externos, los internos son un medio para conseguirlos. Es decir, que lo que tenemos que conseguir es que el cliente esté contento, porque se han cumplido los requisitos, los plazos, los costes, etc. Un cliente normalmente no va a fijarse en que la complejidad ciclomática es mayor que 10.
 
¿Que es lo primero a asegurar?
 
Lo primero a mi modo de entender es asegurarse que se cumple el plan de pruebas y sino lo hay elaborarlo y luego cumplirlo. Es decir asegurar que cuando el cliente de a grabar la aplicación graba correctamente. Sin esto creo que lo demás da más o menos igual.
 
Pero mi cliente no quiere mojarse
 
A veces resulta que, sobre todo cuando un proyecto va mal, las personas involucradas en vez de tener una actitud constructiva para sacar el proyecto adelante, pasan a un modo de supervivencia en el que lo que hacen es actuar para que la culpa no sea suya, ya que vislumbran que el proyecto no va a salir bien. ¿Que hacer en esos casos?
 
Yo lo que propongo es que independientemente de que el cliente no quiera validar los planes de pruebas los elabores, aunque sea para uso interno y se los hagas llegar al cliente, con el mensaje de «estas son las pruebas que vamos a realizar» y ejecutar estas pruebas nos llevan tantas horas. 
 
De esta forma, independientemente del cliente, empiezas a darle la vuelta a la situación. Empiezas a controlar el caos y les haces ver que si quieren que en cada traspaso se prueben más cosas eso va a suponer más tiempo, es decir más coste.
 
Técnicamente no es complejo, unos documentos de texto con una descripción de que es lo que hay que probar y un espacio para indicar si la prueba a ido bien o no es suficiente para empezar. Luego ya te podrás meter en herramientas que te ayuden a mecanizar el proceso.
 
Si os habéis visto en una de esta no dudéis en compartir vuestras experiencias.