Volví a pensar en el post anterior sobre las medidas del esfuerzo de proyecto, y la estimación de los costes de desarrollo y de QA antes del inicio del proyecto, cuando encontré un anuncio en un foro donde se habla de medición de la Calidad de software, para una conferencia sobre el mismo tema.

Ya sabes, uno de esos eventos en los que diferentes expertos hacen una presentación sobre temas tales como ‘¿qué métricas para evaluar los proyectos’ o mesas redondas para hablar de ‘métodos para la estimación de los costes de desarrollo y de mantenimiento’.

El autor de este anuncio pidió a los miembros del foro qué temas de debate les gustaría que se trataran en esta conferencia, y esa pregunta ha desencadenado una serie de respuestas y reacciones que voy a resumir brevemente:

• Basta, stop, alto, ya, deje las presentaciones y los ‘papers’ en « ¿Cómo medir la productividad en el mantenimiento de software? », « Medidas efectivas de riesgo » o « Uso de Function Points en la industria aeroespacial ».
• Hace ya más de 35 años que usamos métricas y sin embargo los departamentos de TI continúan ignorando las medidas de Calidad de software y el número de proyectos que fallan o se retrasan es siempre mayor.

Y esos comentarios: « la industria de la medición de la Calidad de software se encuentra en un estado lamentable » y « podemos aprender de la comunidad Agile que ha integrado estas medidas en sus prácticas ».

Estoy totalmente de acuerdo con esta afirmación, y me recordó una presentación por Olivier Gaudin, co-fundador y CEO de SonarSource, que encontrarás aquí : Webinar: Take Continuous Inspection to Your Enterprise with Sonar 3.0.

Un extracto de esta presentación: la diapositiva que me parece la más importante a nivel de visión de nuestro mercado de Calidad de software, y que coincide completamente con los comentarios anteriores:

Nota: a izquierda se encuentra el estado actual del mercado y a derecha, lo que debería ser.

Análisis de código, análisis de la calidad de la aplicación, medición de la calidad del software, de la calidad del código … Hay diversos nombres casi tantos como herramientas, gracias a la fértil imaginación de los departamentos de marketing. Pero todas estas herramientas hacen lo mismo: análisis de código para identificar violaciónes de buenas prácticas de programación y agregar diferentes métricas en indicadores que se presentan en un dashboard.

Hace 5 años, habia menos herramientas en el mercado, por lo general se limitaban al análisis de dos o tres tecnologías, eran difíciles de poner en práctica y su uso era restringido a los equipos de Calidad. Ellos trataron de implementar procesos de auditoría de aplicaciones, pero estos esfuerzos fueron a menudo infructuosos sin un empujo fuerte de los directores de TI para generalizar estos procesos en los proyectos, sino también, por la desconfianza de los desarrolladores a ser controlados.

Hoy en día, me encuentro a menudo con responsables de Calidad, algunos de los cuales yo conozco como clientes anteriores, y les veo contandome, con una mirada muy molesta, que la herramienta de análisis de código que ellos compraron a precios altos no se utiliza, pero que los equipos de proyectos han implementado un proceso de Integración Continua basada en herramientas Open Source como Sonar y Jenkins.

Primera lección importante: la calidad de las aplicaciones proviene de los desarrolladores. Controlar los desarrolladores y medir la calidad de su producción tiene pocas posibilidades de éxito si ellos no están completamente convencidos del valor de este proceso. Claro, es más fácil controlar el código proporcionado por una empresa de servicios, pero da resultados solamente si el proveedor implanta en sus propios equipos un proceso de Integración Continua. O bien, puedes prepararte para cambiar de proveedor, lo que no es tan fácil cuando el es el único con el conocimiento de tu código, conocimiento que perdiste cuando se decidió externalizar tus aplicaciones.

Pues primera conclusión: los desarrolladores son los principales usuarios de una herramienta de análisis de código y esta debe ser integrada en una cadena de softwares, desde la herramienta de desarrollo hasta un repositorio de gestión de la configuración. Si los consultores de Calidad quieren quedarse solo en el mando de una herramienta de análisis de código para comprobar el trabajo de los desarrolladores, sus esfuerzos serán en vano y se encontrarán aislados. Su papel es de empujar las herramientas y procesos de calidad dentro de los equipos.

Esto nos lleva a la segunda pregunta importante: ¿por qué el trabajo de los equipos de Calidad es ignorado por los departamentos de TI? Porque la gran mayoría de los consultores de Calidad no sabe cómo vender el valor de la información que pueden entregar a los departamentos de TI y a los usuarios.

Los consultores de Calidad son muy a menudo más interesados en la propia métrica que en su uso y su valor. Eso lo estoy experimentando constantemente, cada vez que hablo de LOC – la métrica Lines Of Code – en un foro: inmediatamente, unos expertos me dicen que el uso de este indicador es una ‘malpractice’ y sólo los Puntos de Función permiten medir el tamaño de una aplicación. Y luego tengo que demostrar tesoros de diplomacia y largas explicaciones para justificar el uso de este indicador: no para medir el tamaño funcional de la aplicación, sólo para medir el número de líneas de código.

Cuando conoces a alguien por primera vez, ¿qué es lo primero que se nota? Su tamaño. ¿Es pequeño, mediano o grande? Lo mismo sucede con una aplicación, primero voy a ver su tamaño. Luego puedo usar medidas de peso funcional para verificar si esta persona, perdón esta aplicación, tiene sobrepeso o no.

Pero los consultores de Calidad prefieren perderse en querellas de expertos sobre la utilidad o no de una medida en lugar de pensar en el uso que se puede hacer de esta métrica y su valor para los equipos de proyecto, los stakeholders y los responsables de TI. ¿Cuántos ‘papers’ para explicar las diversas y complejas variantes de calculo de puntos de función en tal aplicación o tal tipo de programación? ¿Cómo los CIOs pueden ser capaces de entender estos cálculos y usarlos para los negocios?

Conozco Directores de CPD que tienen constantemente en su mesa una pantalla con todas las alertas para todas las aplicaciones instaladas en la infraestructura de que son responsables. Si una aplicación crítica – por ejemplo, de pagos bancarios – encuentra un problema – por ejemplo, en los archivos con los datos de pago – esta aparecerá en rojo en la pantalla, lo que le permite reaccionar de inmediato, incluso antes que los usuarios tengan conocimiento del problema.

¿Cuantos CIOs, responsable de sistemas aplicativos, responsables de un conjunto de aplicaciones tienen un panel de control en su pantalla?

Yo no conozco a ninguno. ¿Por qué? Porque la mayoría de las herramientas son complicadas de usar, con métricas complejas de entender, y sobre todo, no se puede personalizar el dashboard de acuerdo a los deseos del usuario (excepto Sonar). Por eso se necesita un consultor de Calidad para interpretar estos indicadores y proporcionar una información valiosa para los directores.

Hoy hay más herramientas que en el pasado, pero veo muy pocas que:

1. Pueden integrarse eficientemente en la cadena de producción de software desde el puesto de trabajo del desarrollador.
2. Pueden mejorar la eficiencia de los desarrolladores para producir código de calidad sin ningún coste / carga de trabajo adicional.
3. Tienen una interfaz bastante sencilla y personalizable, que permite que diferentes usuarios tengan su propio panel de control con los indicadores que consideren pertinentes para su trabajo.

Yo sigo viendo proveedores de software explicar las complejas técnicas que llevan a cabo sus herramientas para detectar más defectos y enumerar la larga lista de métricas que sólo tienen sus productos, pero que sólo sirven para un arquitecto J2EE o un consultor de Calidad. Y el mercado sigue siendo, como señala Olivier Gaudin, un mercado pequeño de herramientas con precios altos.

Y consultores de Calidad siguen preguntándose por qué no les llaman cuando tantos proyectos se retrasan o fracasan.