Madrid, un día de finales de agosto, de mucho calor, algo normal. En una empresa que desarrolla software, como tantas otras, algo normal. En una reunión de comité de crisis, porque le habían externalizado parte de un desarrollo software y están perdiendo el control, algo, por desgracia, demasiadas veces normal.
Están a punto de que el cliente les cancele el contrato y pase el desarrollo a otra empresa.
Multitud de carencias, ausencias y errores en la gestión del proyecto. Pero quiero detenerme concretamente en uno: la calidad del software.
– ¿Puedes decirme la calidad del código? ¿alguna métrica? ¿quizás la complejidad ciclomática del proyecto?
– Si, creo que en algún sitio estaba.
– Si no tenéis claro dónde está… es que no revisáis mucho la calidad del desarrollo ¿no?.
– Espera, aquí está, hay fichero con métricas.
– Los valores de las métricas de calidad software están disparados, eso explica que en los últimos meses el proyecto no avance. Se ha disparado el tiempo que se tarda en añadir una nueva funcionalidad. Pero ¿por qué? ¿por qué no controlasteis desde un primer momento la calidad del software?
Y aquí, en esta, y en otras empresas, aparece un catálogo típico de escusas que intentan justificar el porqué algo tan crítico, un cáncer para los proyectos, como es la mala calidad del software… nadie le presta atención.
1 – “Al comenzar el proyecto, yo no sabía los umbrales que deberían tener las métricas, por eso no pusimos un valor objetivo”
Hay una diferencia entre matemáticas y la estadística. Las matemáticas son exactitas. La estadística se mueve en rangos, con porcentajes de error. El cálculo de una métrica es una operación matemática. La gestión de muchas métricas es estadística.
Es razonable, hasta cierto punto, que no sepas si el porcentaje de código repetido tiene que ser exactamente 4.9% o 9,2%. Es lógico, hasta cierto punto, que no sepas si la complejidad ciclomática media de tu proyecto tiene que ser 12 o 22.
Y es lógico que no lo sepas… porque estás tratando a las métricas como matemáticas, y no estadísticamente. Usa rangos y errores: “siempre por debajo de 200” (es razonable que 200 es mucho, mucho, mucho), “15 con un más menos 2% de error”
Es como si por no saber tu peso ideal… jamás te peses. Aunque no sepas tu peso ideal, si ves que te acercas a 120 Kilos… algo deberías hacer. No sé si debes pesar idealmente 84 o 60k pero no debes permitir, por no pesarte, llegar a 120k.
2 – “Preferimos ver como avanza el proyecto y ahí poner objetivos”
Si, en paralelo al paso anterior, pensaste lo de “arranquemos a ver como avanza el proyecto y ya vemos los valores de las métricas” seguramente tu proyecto ya estará lejos de lo que debiera ser razonable en calidad software, a partir de ahora sólo podrás trabajar para no estar peor… en vez de para seguir bien. Volver a estar en forma ya es un trabajo demasiado duro para ti.
3 – “Es que hay veces, en la práctica, que hay que saltarse alguna métrica”
Es discutible, pero aun si fuese cierto… esa excepción no justifica la regla de no poner umbrales a ninguna métrica.
Si no pones ningún objetivo, tendrás toda la calidad software disparada. Pon objetivos de calidad, y si algún trozo del código no puede cumplirlos estudia ese caso de manera aislada y, si es necesario, pon ahí una excepción… pero no una excepción al todo.
4 – “Es que hay muchas métricas, reglas, etc., y no me voy a poder poner a mirar todo”.
Pues no mires todo, mira lo que de verdad duele. Pon prioridad.
Ya te decía que, por ejemplo, hay dos métricas básicas para hacerte una idea de la calidad de un software (y del dinero que puedes estar tirando) o que la complejidad ciclomática es la métrica esencial para evaluar el diseño software.
Por eso, cualquiera de ellas están en toda herramienta de calidad software existente. Empieza por ahí. Al menos, empieza por ahí.
En calidad software dame números y no buenas intenciones. 4 excusas típicas para no hacerlo