Métricas de software en Metodologías ágiles

Question

Las metodologías ágiles prevalecen en estos días, pero parece que no encuentro mucha documentación sobre qué métricas son más útiles y por qué. He encontrado muchas más cosas que dicen que algunas métricas tradicionales como LOC y código de cobertura de pruebas no son apropiadas, dejando dos preguntas principales:

1. ¿Por qué esas dos (y otras) métricas son inapropiadas?
2. ¿Qué métricas son mejores para Agile y por qué?

Incluso con un proceso ágil, ¿no le gustaría saber cuánta cobertura de código tiene con las pruebas de su unidad? ¿O simplemente es que esta métrica (y otras) simplemente no son como útiles como otras métricas como la complejidad y la velocidad ciclomática?

Answer 1

ágil es una cosa orientado a los negocios, ágil se trata maximizar el valor para el cliente y reducir al mínimo los residuospara proporcionar el retorno de la inversión más óptima.Esto es lo que debería medirse. Y para hacerlo, utilizo el sistema que Mary Poppendieck recommends. Este sistema se basa en tres medidas integrales que deben ser tomados como un paquete:

1. Tiempo de ciclo
   • Desde el concepto del producto para el primer lanzamiento o
   • De solicitud de función a la característica de implementación o
   • De detección de errores a la resolución
2. Realización de caso de negocio (sin esto, todo lo demás es irrelevante)
   • P & L o
   • ROI o
   • Objetivo de la inversión
3. satisfacción del cliente
   • por ejemplo Net Promoter Score

Claro, a nivel de equipo se puede realizar un seguimiento de cosas como la cobertura de las pruebas, la complejidad ciclomática, la conformidad con los estándares de codificación, etc., pero de alta calidad no es un fin en sí mismo, es sólo una media. No me malinterpreten, no digo que la alta calidad no importe, la alta calidad es obligatoria para lograr un ritmo sostenible (e incluimos "ningún aumento de la deuda técnica" en nuestra Definición de Listo) pero aún así, el objetivo es para entregar valor al cliente de una manera rápida y rentable.

Answer 2

1.1) LOC son fáciles de responder

• Son muy dependientes del idioma que usa! La misma característica puede tener una gran diferencia cuando se escribe en JAVA o en Ruby, por ejemplo

• ¡Un software no bien escrito puede tener más líneas que una buena!

1,2) Cobertura de código

• mi humilde opinión se debe utilizar métrica, aunque no es perfecto, debe darle un buen entendimiento de donde el código necesita más pruebas.

• Solo un punto que debe tener en cuenta aquí es que también depende del idioma. ¡Puede haber algunas situaciones en las que tenga una clase o método que realmente no necesita probar! Por ejemplo, una clase con solo getters y setters.

2) A partir de (1) que acaba de mencionar métricas de código, pero a juzgar por su pregunta acerca de la velocidad, que está interesado en métricas en todo el proceso de creación, por lo que sería enumerar algunas:

• Velocidad: la clásica y, si se usa bien, puede mejorar bastante bien el rendimiento de un equipo ágil, ya que sabrá lo que su equipo realmente puede hacer en un tiempo fijo.

• Burn y quemar cartas: se le puede dar una buena idea sobre cómo el equipo está llevando a cabo durante la interacción (Sprint)

Hay algunos artículos sobre InfoQ sobre esto. Here y here.

Answer 3

Independientemente de la metodología, hay algunas métricas básicas que pueden y deben usarse.
Según S. Kahn, los más importantes son los siguientes tres:

• tamaño del producto
• número de defectos que se encuentran en fase final de pruebas
• y el número de defectos encontrados en el campo.

Si esos son todo lo que la pista, hay por lo menos cinco formas en que pueden ser utilizados:

• calcular la tasa de defecto del producto (A)
• tasa de defectos prueba de calcular (B)
• determinar un objetivo deseable para A y supervisar el rendimiento
• determinar un objetivo deseable para B y supervisar el rendimiento
• evaluar la correlación entre A y B
• si no se encuentra una correlación, forma métrica de la efectividad de prueba (B/A * 100%)

Aunque no necesariamente divertido de leer, Metrics and Models of Software Quality Engineering proporciona una excelente visión general de ingeniería de software y métricas en profundidad.

Answer 4

En cuanto a la pregunta 1, no veo ninguna razón para que esas métricas sean malas en un proceso Ágil.

LOC le proporciona una medida relativa del tamaño. Si bien puede no ser siempre útil comparar números entre proyectos, puede proporcionarle una tasa de crecimiento dentro del proyecto. Si puede obtenerlo, la cantidad de líneas modificadas dentro de un sprint también puede ser útil para rastrear una tasa o refactorizar.

La cobertura de código (de líneas de código) le da una idea general de si su equipo cumple o no con una barra mínima de pruebas automatizadas dentro de un proyecto.

En cuanto a la pregunta 2, mantenga los elementos anteriores y aquí están unos cuantos más:

• LOC frente al recuento de prueba. Si puede, mantenga relaciones separadas para la unidad, la integración y las pruebas del sistema.
• Número promedio de criterios de aceptación versus escenarios de prueba (o pruebas) para cada historia. Puede ayudar a proporcionar una mejor idea de si su prueba contra la intención de la historia o no.
• Número de defectos descubiertos
• Cantidad de trabajo descubierto (esto a menudo es capturado por el software de seguimiento Agile) que no formaba parte de las estimaciones originales. Te ayudará a juzgar si estás haciendo una planificación "suficiente".
• Constancias de seguimiento, o la falta de ella, de sprint sprint para sprint
• Aunque probablemente no sea popular y probablemente sea potencialmente peligroso, las estimaciones de seguimiento funcionarán para cada desarrollador. Si bien se supone que los equipos deben organizarse e impulsarse por sí mismos, no todos los equipos son capaces de lidiar con los problemas humanos.

Answer 5

sólo para añadir

Por qué LOC y Cobertura Código de Pruebas son menos que ideales:

ágil hace hincapié en el resultado, no de salida (ver manifiesto ágil). Estos dos simplemente rastrean la salida. Además, no miden correctamente la refactorización, que es un aspecto vital de los procesos ágiles.

Otra medida a considerar sería la ejecución de funciones probadas. No puedo describir mejor que esto: http://xprogramming.com/articles/jatrtsmetric/

Answer 6

Voy a responder a esta pregunta muy antigua ...

COL y Cobertura de la prueba son, en mi opinión, buenas métricas, pero tienen una gran problema: si los presionas, puedes hacer que crezcan rápidamente, pero el resultado será terryifing: toneladas de código sin sentido, o en la cobertura de prueba, puedes invocar todo tu código en un bloque try-catch y no escribir uno solo assert ... O aún peor, solo escriba uno por "cumplimiento", pero sin ningún tipo de orientación comercial o sentido de código ...

Por lo tanto, este tipo de métricas son muy buenas si ayudan al equipo a honestamente evaluar su resultado , pero son una herramienta malvada si forman parte de algunas reglas de "cumplimiento", ya que su uso de esa manera causa más daño (código muerto, malas pruebas) que lo que originalmente quería lograr.

Entonces, con cada métrica, piense cómo podría engañarla si se viera forzado a alcanzar un cierto valor, y piense en las consecuencias ... Esto no es un problema de cobertura de prueba o LOC, muchas otras métricas pueden tener resultado similar, incluso complejidad ciclomática ...Si divide su código de manera incorrecta, puede reducir la complejidad ciclomática, ¡pero eso no significa que obtenga un código mejor o más legible!

Por lo tanto, este tipo de métricas son bastante buenos para ver lo que está sucediendo dentro de un equipo, pero cualquier medida que tome debe basarse en objetivos concretos, no en la métrica sí ... Por ejemplo: la cobertura

prueba es bajo: implementa dojos de codificación una vez al mes para ayudar a entrenar a las personas a escribir códigos verificables, descubrir qué código tiene la peor cobertura de prueba e intentar implementar una arquitectura mejor/más comprobable que ayude/motive a los desarrolladores a escribir pruebas, etc.

Como puede ver, nunca le dice al equipo que alcance cierto valor de cobertura de prueba, solo usa la métrica para ver dónde puede mejorar y luego busque medidas que beneficien a su proceso, después de un tiempo esperaría que la cobertura de prueba aumentara, ¡pero no está presionando a la gente para que lo haga! Está evaluando cambios para ver si las medidas están ayudando. Si después de un tiempo descubre que la cobertura de prueba no ha cambiado con sus medidas, entonces es hora de buscar otras ideas, y así sucesivamente ...