Mejora continúa de la calidad

En el post anterior Medir y controlar, hemos visto que las métricas cuantitativas tales como el número de líneas de código (LOC) o la medida de la complejidad cyclomatica (CC) están:

  • Fácilmente disponibles – todas las herramientas de análisis de código las proponen;
  • Exactas – estas medidas no varían (casi nunca) según las herramientas;
  • Fácilmente comprensibles para los ejecutivos.

¿Esto es decir que las medidas cualitativas estarían difíciles, inexactas y poco útiles? De hecho, todo depende de lo que quieres hacer, pues del caso de utilización. Hoy, veremos un caso ideal: la mejora continúa de la calidad (Continuous Improvement).

Elija 12 o 15 métricas consideradas como críticas y para las cuales tu o tu equipo de proyecto apunta al cero defectos. Cada noche (o a finales de cada semana), el código de la aplicación está analizado y las violaciones para estas métricas críticas estan identificadas. Cada mañana (o a principios de cada semana), el equipo de proyecto analiza los defectos recientemente introducidos y decide su remediaciones. Si la herramienta de análisis es conectada con la herramienta de desarrollo, estas remediaciones aparecerán en el ‘task list’ de cada desarrollador. Aquí se encuentra un ejemplo de tal proceso : Effective Code Review with Sonar.

¿Cuáles son las ventajas de un proceso de mejora continúa de la calidad?

  • Coste de corrección de los defectos el más bajo, porque lo más temprano posible en el ciclo de desarrollo. Sooner is cheaper.
  • Mejora continúa de las competencias: el equipo de proyecto se familiariza con las buenas prácticas más importantes.
  • Deuda técnica controlada: las derivas de mantenibilidad son contenidas.

Sin embargo, con el fin de limitar la carga adicional de trabajo (análisis del código fuente, comprobación de los resultados, reparto de las correcciones á efectuar), es recomendable disponer de unas herramientas adecuadas:

  • Un servidor de gestión de versiones que permita compartir el código fuente entre los desarrolladores y alimentar la herramienta de análisis de código.
  • Si es posible, una herramienta de gestión de pruebas para validar cada versión (build).
  • Una herramienta de integración que se encarga de automatizar las tareas de compilación (build), de análisis de código y de prueba.

Idealmente, estas herramientas deben comunicar entre ellas, con el fin de:

  • Subir (upload) en la herramienta de análisis de código los resultados de las pruebas e identificar, por ejemplo, los componentes más peligrosos para la aplicación: componentes con una Complejidad Cyclomatica (CC) elevada o muy elevada e insuficientemente probados. Porque son complejos, estos componentes presentan un riesgo elevado de introducir un defecto en caso de evolución, y entonces deben ser sometidos a pruebas prioritariamente.
  • Bajar (download) en la herramienta de desarrollo la lista de las correcciones a efectuar, para cada desarrollador.

Se trata de un proceso completo de Integración continua, que supone herramientas completamente integradas pero también un nivel correcto de madurez de los equipos de desarrollo. La integración es importante con el fin de automatizar lo mejor posible las diferentes fases del proceso y limitar la carga adicional de trabajo y facilitar la aceptación de este nuevo modo de trabajo.

También recomendaría empezar con un número limitado de métricas, con el fin de no sumergir los programadores con buenas prácticas á tolerancia cero. Será posible extender el blanco más tarde, cuando los desarrolladores habrán subido esta primera marcha y plenamente adherido a esta nueva organización. Por esa razon, es importante disponer de herramientas completamente integradas.

 

Esta entrada está también disponible en Lire cet article en français.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *