Algunos consejos sobre la implantación de métricas software (2/2)

Este post se divide en dos partes. Ahora estás en la segunda. Te dejo el enlace a las dos partes:

Si en el anterior post hablábamos sobre empezar con pocas métricas y que estas ayuden al negocio, en este segundo post de la serie comentar alguna recomendación más: Mide en periodos cortos, frecuentemente, de manera automatizada y define niveles de abstracción.

Mide en periodos cortos, frecuentemente y de manera automatizada

No es lo mismo medir cada día que cada mes o cada año. Si mido cada mes me daré cuenta antes de los problemas que si mido cada año. Si los periodos de medición son muy grandes puede que medir sólo me sirva para confirmar problemas software que ya es tarde para resolver.

Medir frecuentemente me hace ser predictivo en vez de reactivo. Pero claro, medir muy frecuentemente puede tener un inconveniente… que lleve y consuma mucho tiempo (en tomar las medidas, hacer informes, reuniones, etc.) y que esto me reste productividad. Cómo resolver esto, automatizando al máximo la toma de métricas y la elaboración de informes. Si quiero medir de manera frecuente no puedo perder semanas en hacer un informe de medición, ya no tendría sentido.

Hoy en día hay numerosas herramientas para obtener métricas software, muchas de ellas de código abierto. Pero recuerda una cosa más, una herramienta de medición genera cientos de métricas en muy poco tiempo. Y el exceso de información al que te puede llevar puede ser tan problemático como su ausencia. Las herramientas pueden ser una “ametralladora” disparando métricas. Por ello, recuerda lo que hablamos en el anterior post: selecciona primero un conjunto de métricas en función de tus objetivos de negocio, empieza con pocas métricas y luego automatiza. Que la herramienta venga siempre después de la ingeniería.

Y define niveles de abstracción.

Nos hemos encontrado con muchas organizaciones que han externalizado a fábricas software su desarrollo, que reciben muchas entregas y que disponen de un pequeño equipo de control de calidad software. Y para poder controlar grandes cantidades de software externalizado, automatizan la medición y generan cientos de métricas, pero sin embargo en la organización no saben exactamente cómo va globalmente la calidad del software que han externalizado.

Por ello, es necesario tener métricas a diferentes niveles de abstracción. Las métricas que interesan a un programador, no son las mismas que interesan a un jefe de proyecto, a un director de desarrollo o las que necesito para saber si me está siendo rentable haber externalizado el desarrollo software.

Es muy recomendable decidir qué mostrar, cuándo y a quién. Evitar perderse en los detalles.

0 comentarios en “Algunos consejos sobre la implantación de métricas software (2/2)”

  1. Creo que otro aspecto a tener en cuenta es la manera de fijar los umbrales de estas métricas. Debe ser la organización la que debe decidir los umbrales de sus métricas, basándose en su experiencia y en sus objetivos de negocio, ya que lo que para una organización puede ser un valor de una métrica «bueno» para otra, puede no serlo tanto.
    También me parece acertada la idea de al principio, poner unos umbrales asequibles, fáciles de alcanzar por los desarrolladores y poco a poco ir haciendolos mucho más estrictos. Creo que de esta manera, se podría motivar a los desarrolladores.
    Un saludo.

  2. Pingback: Algunos consejos sobre la implantación de métricas software (1/2) - Javier Garzás, sobre calidad software y otros temas relacionados

Deja un comentario

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

Share This
Ir arriba