La invasión de las métricas mutantes

El escéptico Abel Muiño, Manuel Recena y otros más de la lista de Ecosistemas Software son unos “adictos” a Sonar, de modo que no me ha quedado más remedio que evaluarlo. Con una conexión más o menos decente a Internet seguro que se instala bien y rápido, las instrucciones son muy sencillas. El problema que he tenido es que cuando la conexión a Internet falla, la cosa se complica porque hay muchos jar que descargar… Pero bueno, el proceso es bastate robusto. Requiere de una base de datos: yo he elegido MySQL, pero pueden ser otras.

Para el que no lo sepa, Sonar es una herramienta que sirve para recolectar métricas de muy diversa índole y mostrarlas juntas. Por ejemplo, recopila los tests (maven’s surefire), la cobertura de los mismos (Cobertura), análisis estático (PMD), acomodación a reglas de estilo (checkstyle), etc. Además, elabora históricos, con lo que podemos ver la evolución y todo… Se puede jugar con él durante horas para ver todas las métricas, hipervinculadas con el código, con los tests, etc. Muy chulo.

Examinar un “dashboard” de Sonar es, sin embargo, un tanto agobiante. Mucha información. En mi opinión: demasiada. Ya lo hemos discutido varias veces en la lista de “agile-spain” y en “foro-agiles”, pero mi postura sigue siendo la misma: mejor pocas métricas pero que ayuden que muchas pero que despisten. El objetivo fundamental de un equipo de desarrollo es, desde un punto de vista agilista, claro, entregar valor al cliente al final de cada iteración y de manera sostenible en forma de software que funciona. Y esto es relativamente fácil de medir: cuánto incremento de valor hay en cada iteración. Lo ideal sería medirlo en euros, pero quizás algo complicado… mejor en puntos de historias de usuario.

De todos modos, Sonar es una herramienta que, convenientemente afinada, puede ser de gran, gran ayuda para los perfiles responsables de mejorar la calidad interna de los proyectos. Con Sonar se pueden preparar sesiones de revisión de código muy productivas. En cualquier caso, ésta es una discusión muy rica.

Tagged:
  • Abel Muiño

    No creo que seamos adictos, es que (al menos a mi) me resulta divertido ver cómo la comunidad ágil se revoluciona ante la palabra "métrica"… y normalmente la reacción no está justificada. Tan solo es un miedo a que tal vez las métricas podrían perjudicar al equipo… pero es igualmente probable que no lo hagan o que le ayuden (por ejemplo, si crees que usar unas convenciones de código ayudan al equipo, necesitarás algo que te diga si se están aplicando o no… si la respuesta es no entonces habrá que investigar el porqué hablando con los miembros del equipo).

    Es como suponer (y perdón por la metáfora imperfecta) que la visión periférica es mala, porque te puede descubrir nuevos caminos en lugar de seguir en linea recta, sin contar con que también te permite evitar ser aplastado por un camión en cualquier cruce.

    Por otra parte, están las necesidades de los clientes. La confianza es un pilar básico en la mentalidad ágil, pero la reducción del riesgo es un pilar básico de la empresa. Esperar que un cliente se fie a ciegas de la empresa (ágil o no) no es realista.

    Lo que nunca he defendido es que Sonar (o las métricas que captura) sean las más adecuadas o la única opción para mejorar la calidad o evaluar un desarrollo. De hecho, Sonar es "el topping" del ecosistema de desarrollo, algo que miras cuando todo lo demás funciona. Este post en el blog de Sonar creo que resume esta idea bastante bien.

    Otra faceta interesante de Sonar (que yo intento explotar) es que es muy atractivo para los puestos de gestión (al borde del mundo técnico). Con un poco de criterio es fácil construir un buen informe en el que se defienda el uso de otras prácticas para mejorar la calidad del software (desde CI a TDD a formación para el equipo).

    Para terminar, sólo reiterar de forma nada constructiva mi opinión de que "software que funciona" es sólo la primera mitad del camino. Ese software debe ser mantenible y no atar al cliente a un único proveedor.

  • Jose Manuel Beas

    ¿Otro tema interesante que podríamos sacar en el Agile Open?