La recolección, interpretación y medición de los procesos tiene que tener un criterio simple y además tiene que ser de utilidad, esto último quiere decir que si una organización se toma el trabajo de recolectar, interpretar y medir los procesos, entonces seguramente es porque piensa hacer algo con el resultado de ello, o no?
Hay veces que los datos que recolectamos no son de utilidad en la actualidad, aunque la organización tendría que tener claro como las piensa utilizar en el futuro y esto tendría que ser claro y detallado.
Con esto, podemos explicar entonces que todo lo que recolectemos, interpretemos y midamos sin tener una utilidad, implica un riesgo para la organización. Aquí podemos deducir entonces, que las métricas que las organizaciones tienen que tener para sus procesos (por ejemplo el proceso de desarrollo de software) son aquellas que les sean de utilidad para tomar decisiones y nada mas que aquellas que vaya a utilizar en la actualidad o que ya tenga la expectativa de utilización en el futuro cercano y con un grade de detalle muy avanzado.
En las organizaciones -por lo general- a la pregunta del objetivo que tiene la misma para el año o para los próximos 5 años, muchas veces la única respuesta que se escucha es 'ganar dinero'. Y si, todos sabemos que la rentabilidad es muy importante. Ahora siendo los que llevamos adelante los proyectos de software en la organización, podemos tener problemas en los proyectos por distintas razones.
- Mala estimación
- Cambios de Requerimientos
- Retrasos en el calendario
- Etc.
Luego de un tiempo de llevar adelante los proyectos de la misma manera (enfocados en el tiempo y coste), nos hemos dado cuenta en mi grupo de trabajo que estábamos llevando adelante los proyectos con un único objetivo, y este era el mas importante para el grupo de Diseñadores/Desarrolladores ya que nosotros solo nos enfocabamos en ello, y eso era TIEMPO y COSTE.
Cuando entendimos eso (nos llevo mas de dos años entenderlo) comenzamos a seguir los proyectos de una manera diferente.
Hasta este momento, hacíamos los proyectos con TDD y corríamos los proyectos en nuestra herramienta de Integración Contínua (Hudson), generando los informes de Test (Unitarios, Componentes, Integración), CheckStyle, PMD, Cobertura, cada noche, todos los días de la semana. La herramienta de Integración Contínua generaba además de los informes, el envío de mails a los participantes del proyecto si los mismos no pasaban la compilación y test.
Entonces, porque decimos que solo nos interesaba el TIEMPO y COSTE en nuestros proyectos? Simplemente porque nadie tenía ningún nivel de servicio que cumplir, ni se guardaba ninguna métrica sobre el checkeo de código o sobre la cobertura de los mismos.
Luego, despúes de razonar un tiempo sobre este punto, logramos llegar a derivar en un conjunto de SLA's con los que nos sentimos cómodos en el seguimiento de los proyectos, generando una calidad muy alta en los mismos.
- Cantidad de errores detectados por las herramientas de inspección automática, como PMD, Checkstyles, Macker.
- Cobertura de código por los test (Unitarios, Componentes e Integración): en los entornos que desarrollamos (JEE), asociado al proceso de integración continua, se mide el porcentaje de código cubierto por las pruebas unitarias, de componentes y de integración.
Con Scrum, también agregamos a nuestras métricas, la velocidad del equipo y el factor de foco en los diferentes Sprints de los diferentes proyectos y los imprevistos e impedimentos sucedidos.
Y como cierre, podemos nombrar algunas métricas que se pueden tener en general en las organizaciones, y que solo deberían llevarse si se piensa hacer algo con ellas (nosotros no las tenemos, por ahora).
- Cantidad de defectos, desagrupados por etapa del proyecto y tipo de entregable (defecto en software, en especificación funcional, en especificación técnica, o en el proceso mismo).
- Tiempo promedio de solución de un defecto.
- Sobreesfuerzo generado por defectos, es decir, el esfuerzo necesario para corregir los defectos, desagregado por actividad.
- Cantidad de cambios a los requerimientos, también desagrupados por etapa del proyecto y cantidad de cambios aceptados y rechazados.
- Velocidad de avance del equipo, medida por la cantidad de historias del usuario o de requerimientos implementados por unidad de tiempo y como avance ganado, definido como tiempo insumido / (tiempo insumido + tiempo estimado para completar ).
- Milestones cumplidos en tiempo, demorados y demora promedio.
- Cantidad de cambios al plan del proyecto, y el motivo de los mismos (cambios a los requerimientos, cambios a la dotación del equipo de trabajo, errores en la estimación).
- Desvío de la estimación original, por componente y actividad, para lo cual el sistema de registración de horas está alineado con la forma de estimar: se imputan horas con el mismo concepto y granularidad con que se estima el proyecto.
Como resumen, tenemos que recordar el concepto que ha originado la nota, que es el esfuerzo de recolectar una métrica sirve si ésta puede servir de base para una toma de decisión. Y por cierto, el objetivo de estas métricas (o de cualquier otras) no es cumplir con CMMI, signifique esto lo que signifique, sino dar información útil, que sirva para tomar decisiones, sobre la performance del proceso y el estado del proyecto.
