¿Cuál es el estado de la técnica??

Las metodologías ágiles hoy en día ganan popularidad y se han convertido en una corriente principal del desarrollo de software debido a su capacidad para generar una alta satisfacción del cliente.. La consultoría de estimación y métricas recibe cada vez más "asignaciones ágiles" y se supone que deben brindar valiosos consejos para entornos de proyectos ágiles. Pero las metodologías Agile difieren de las metodologías Waterfall tradicionales, especialmente en la forma en que se realizan las estimaciones y la recopilación de métricas.. Una encuesta a través de la literatura e Internet para estos temas dará una idea de las diferencias y ampliará nuestro conocimiento y puede fortalecer nuestras habilidades.. Se encontraron nuevos enfoques sobre cómo se pueden aplicar las técnicas e instrumentos existentes en entornos Agile. El resultado de esta encuesta engloba tres artículos. Este primer artículo muestra el estado del arte de las métricas en el desarrollo ágil de software.

Métricas de software en general

La métrica de software o la medición de software es un concepto de la industria del software.. Se puede describir de la siguiente manera: aplicar valores a las propiedades de productos o procesos de acuerdo con principios definidos para llevar a cabo análisis estadísticos o comparativos en nombre de un propósito previamente definido.

Software Metrics generalmente admite tres áreas de interés.

• Planificación, pronóstico
• Supervisión & controlar
• Mejora del rendimiento, evaluación comparativa

Hay muchas métricas de software en uso para diferentes situaciones. Putnam y Myers señalan maravillosamente de qué se trata todo esto con el ‘5 Métricas centrales‘ para el desarrollo de software: uno desarrolla un producto de aceptable calidad con cierto esfuerzo en cierto hora. La relación entre el producto, calidad, esfuerzo y tiempo, está determinada por la productividad, que por lo tanto también debe medirse. Echamos un vistazo más de cerca a estas métricas principales.

Producto(Talla)
Mide propiedades cuantitativas, que determina el tamaño del producto. Para hacer antes o después.
Ejemplos: LOC, Puntos de función, número de casos de uso, número de características, Historias de usuarios.

Calidad
El producto tiene que poseer alguna cualidad., generalmente determinado por medio de 'número de defectos por período en el tiempo', el tiempo medio para desertar (MTTD) y la 'densidad de defectos' (número de defectos por KLOC).

Esfuerzo
Medido en meses-persona dedicados exclusivamente a su proyecto.

Duración
Este es el tiempo de respuesta sin interrupción entre la fecha de inicio y la fecha de finalización del proyecto (por ejemplo. en meses).

Productividad
Esta es una propiedad del proceso., es decir. el proceso de desarrollo de software en la organización. Se enfatiza que esta no es la productividad de una o más personas que se ocupan de la realización! La productividad determina la relación entre el producto (Talla), esfuerzo y tiempo en la llamada Ecuación del Software en su forma básica:

Productivity = product size (with a known Quality) / (effort * time)
(refer to the book for explanation)

Estas métricas centrales respaldan lo mencionado anteriormente (principal) áreas de interés de la siguiente manera.
Planificación y predicción: productividad y tamaño del producto (en una calidad deseada) determinar indirectamente el costo, tiempo de entrega y esfuerzo.
Monitorear y controlar: todo tipo de medidas se utilizan como parte del producto, porcentaje de esfuerzo gastado por producto entregado en comparación con el tamaño total del producto en un momento determinado, número de errores encontrados durante el desarrollo en comparación con el número esperado de errores. Este tipo de mediciones caracteriza el desempeño del equipo del proyecto.
Mejora, evaluación comparativa: al construir un historial con información clave de proyectos terminados propios, se puede determinar un punto de referencia con el cual se pueden comparar proyectos futuros. También se puede comparar el rendimiento propio con el rendimiento de otras empresas. (evaluación comparativa). Con esta segunda comparación se podrá determinar si la organización se desempeña en línea con el mercado..

Métricas en proyectos ágiles

Los métodos ágiles tienen el mismo punto de partida que el método en cascada, a saber: uno desarrolla un producto de aceptable calidad con cierto esfuerzo en cierto hora.

El enfoque y los procesos pueden diferir, pero en principio es otro camino que lleva al mismo destino. No es de extrañar que en un entorno ágil las métricas de software tengan su lugar. sin embargo, hay algunas diferencias notables en el enfoque de cascada. En primer lugar, cabe señalar que los métodos ágiles tienen sus mayores éxitos en proyectos pequeños y medianos para aplicaciones comerciales.

El enfoque de las métricas ágiles está en línea con este tamaño limitado y se enfoca principalmente en el equipo, la iteración actual, el lanzamiento actual. Menos en el proyecto y puede que no sea en absoluto en un programa completo de proyectos. En breve, el foco está dirigido internamente. Es importante notar esto porque en este punto ágil difiere claramente del enfoque en cascada. Una segunda diferencia llamativa entre las métricas ágiles y las métricas en cascada es la diferencia en las unidades de medida utilizadas. Métricas ágiles para el producto(Talla) y la productividad se expresan en unidades subjetivas (puntos de historia y puntos de historia por iteración o velocidad) que se aplican solo a este proyecto y a este equipo. Esto hace que la comparación entre equipos, proyectos y organizaciones imposibles. Las métricas de cascada se expresan especialmente en unidades estandarizadas con fines de evaluación comparativa.

La siguiente matriz muestra las métricas centrales de Putnam y Myers en ambos entornos.

Métrica principal	Ágil	Cascada
Producto(Talla)	características, cuentos	FP, PPC, UCP
Calidad	defectos/iteración, defectos, MTTD	defectos/liberación, defectos, MTTD
Esfuerzo	puntos de la historia *)	persona meses
Hora	duración (meses)	duración (meses)
Productividad	velocidad (puntos/iteración de la historia) **)	horas/FP ****)

*)	Los puntos de la historia son subjetivos y solo se aplican a este proyecto y este equipo.
**)	La velocidad es subjetiva y solo se aplica a este proyecto y este equipo., evaluación comparativa no es posible.
***)	FP y CFP son objetivos y son estándares internacionales para expresar el tamaño funcional.
****)	Horas/FP es utilizado por varias estimaciones & herramientas de métricas para fines de evaluación comparativa.

 

Un recorrido en la Web por el uso de métricas en la comunidad Agile da como resultado un panorama variado. Algunos consultores proponen métricas que "permanecen cerca de la manifiesto ". En esta categoría, los objetivos emergen como una "percepción de la confianza del patrocinador"., ‘ comprensión de la satisfacción del cliente’ y ‘motivación del equipo’. La perspectiva desde la cual los “agilistas’ mira las métricas, está bien ilustrado por la presentación en Métricas ágiles por Mike Griffith. Aparte de los 'agilistas' hay consultores que se enfocan en las métricas tradicionales, aunque estas métricas usan conceptos y unidades propios de Agile como características, iteraciones, puntos de la historia y la velocidad.

Un documento notable en este contexto., el reciente tesis de hanna kulas. Este documento señala por qué Agile es tan especial y cómo se pueden incorporar ciertas métricas de productos en proyectos ágiles.. Adicionalmente qué se medirá y qué beneficios se podrán establecer. La aplicación de estas métricas de productos puede conducir a un aumento en la satisfacción del cliente como resultado de una mayor calidad del producto y menores costos de desarrollo, lo que a su vez es el resultado de una mejor comprensión del proceso de desarrollo de software..

Notable y característico de ágil es la ausencia de métricas para evaluación comparativa o cualquier otra forma de comparación externa. Las unidades de medida utilizadas para el producto. (Talla) y la productividad son subjetivos y se aplican exclusivamente al proyecto y al equipo en cuestión. Desde la perspectiva de un gerente de adquisición o patrocinador, no hay posibilidad de comparar equipos de desarrollo o contratistas de licitación en cuanto a productividad.. Entonces, el proceso de selección de un contratista por motivos racionales (productividad) es virtualmente imposible.

A continuación, se resumen las métricas "ágiles" que se han encontrado en la Web.; su propósito y cómo se miden. Tenga en cuenta que la mayoría de las métricas admiten "supervisión & control'. Obviamente, con respecto a esta área de interés, el entorno ágil no varía mucho del entorno de cascada tradicional..

Métricas 'ágiles', resultados de una encuesta en la Web

Las siguientes tablas muestran las métricas recomendadas por varios "consultores ágiles" en muchos casos según su propia práctica. Las métricas se agrupan en torno a las áreas de interés mencionadas anteriormente en este documento.

Métricas para Planificación, pronóstico

Métrico	Propósito	Cómo medir
número de características	1. Información sobre el tamaño del producto. (y todo el lanzamiento). 2. Cuando el estado se aplica a las funciones: conocimiento en progreso.	El producto comprende características que a su vez comprenden historias.. Las funciones se agrupan como 'cosas por hacer', 'en curso', y 'aceptado'.
número de historias planeadas por iteración/lanzamiento	1. Información sobre el tamaño del producto. (y todo el lanzamiento). 2. Cuándo se aplica el estado a las historias: conocimiento en progreso.	El trabajo se describe en historias., que se cuantifican en puntos de historia. Las historias se agrupan como 'cosas por hacer', 'en curso', y 'aceptado'.
número de historias aceptadas por iteración/lanzamiento	Para realizar un seguimiento del progreso de la iteración/lanzamiento	Registro formal de relatos aceptados.
Velocidad del equipo	Consulte Monitoreo & Control
LOC	Indica la cantidad de trabajo completado (Progreso), cálculo de otras métricas, es decir. densidad de defectos.	De acuerdo con las reglas acordadas, qué LOC contar.

Métricas para Supervisión & Control (progreso y rendimiento)

Métrico	Propósito	Cómo medir
Burn-down de iteración	Rendimiento por iteración, ¿Estamos en el buen camino??’.	Esfuerzo restante (en horas) para la iteración actual (esfuerzo gastado/planificado expresa desempeño).
Velocidad del equipo por iteración	Para aprender la Velocidad histórica para cierto Equipo. No se puede utilizar para comparar diferentes equipos..	Número de puntos de historia realizados por iteración dentro de esta versión. Velocity es específico del proyecto y del equipo.
Liberar Burn-down	Para realizar un seguimiento del progreso de un lanzamiento de una iteración a otra, "¿estamos encaminados para todo el lanzamiento?".	Número de puntos de la historia 'por hacer' después de completar una iteración dentro del lanzamiento (la extrapolación con cierta velocidad muestra la fecha de finalización).
Liberar quemado	Cuánto 'producto' se puede entregar dentro del marco de tiempo dado.	Número de puntos de historia realizados después de completar una iteración sobre el número total de puntos de historia (de la liberación). En una línea de tiempo, muestra el progreso de la "finalización del alcance"..
Número de casos de prueba por iteración	Para conocer la cantidad de trabajo de prueba por iteración. Para seguir el progreso de las pruebas.	Número de casos de prueba por iteración registrados como "sostenidos", 'fallido' y 'hacer'.
Tiempo del ciclo (capacidad del equipo)	Determinar los cuellos de botella del proceso.; la disciplina con menor capacidad es el cuello de botella.	Número de historias que se pueden manejar por disciplina dentro de una iteración (es decir. análisis- Codificación de diseño de interfaz de usuario - prueba de unidad- prueba del sistema).
Ley de Little: 'los tiempos de ciclo son proporcionales a la longitud de la cola'.	Información sobre la duración; podemos predecir el tiempo de finalización en función de la longitud de la cola.	Trabajo en progreso (# cuentos) dividido por la capacidad del paso del proceso.

Métricas para Mejora (calidad del producto y mejora del proceso)

Métrico	Propósito	Cómo medir
Número acumulado de defectos	Para realizar un seguimiento de la eficacia de las pruebas.	Registro de cada defecto en el sistema de gestión de defectos.
Número de sesiones de prueba	Para realizar un seguimiento del esfuerzo de prueba y compararlo con el número acumulado de defectos.	Extracción de datos del repositorio de defectos.
Densidad de defectos	Para determinar la calidad del software en términos de "ausencia de defectos".	El número acumulado de defectos dividido por 1000LOC (BLOQUEAR).
Distribución de defectos por origen	Decidir dónde asignar los recursos de garantía de calidad.	Registrando el origen de los defectos en el repositorio de defectos y extrayendo los datos por medio de una herramienta automatizada.
Distribución de defectos por tipo	Para saber qué tipo de defectos son los más comunes y ayudar a evitarlos en el futuro.	Registrando el tipo de defectos en el repositorio de defectos y extrayendo los datos por medio de una herramienta automatizada.
Tiempo de ciclo de defectos	Insight en el tiempo para resolver un defecto (velocidad de resolución de defectos). Cuanto más rápida sea la resolución, se producirá la codificación menor 'en la parte superior'.	Fecha de apertura del defecto menos la fecha de resolución (generalmente la fecha de cierre en el repositorio de defectos).

Nota: también hay 'métricas'’ encontró que la medida 'percepción de la confianza del cliente ‘ y ‘ información sobre la satisfacción del cliente. Sin embargo, para estas métricas, la comunidad ágil no logra que sea plausible por qué estos aspectos se aplican específicamente a ágil y, por lo tanto, no están incluidos.. Refiriéndose a mi propia experiencia de más de 30 años estos aspectos se miden en todo tipo de entornos de proyecto. Más o menos lo mismo se aplica al uso del Método del Valor Ganado.

Conclusiones

Este recorrido por la Web y por las publicaciones lleva a las siguientes conclusiones.

1. Las métricas utilizadas dentro de los métodos ágiles y las unidades utilizadas (puntos de la historia, velocidad) no están estandarizados. Esto hace que la evaluación comparativa sea problemática., si no imposible.
2. Cuando los puntos de la historia realizados se expresan como LOC, se puede establecer una correspondencia con unidades de tamaño funcional estandarizadas. (FPn); incluso la productividad de una organización o la productividad del equipo puede determinarse.
3. Los métodos ágiles podrían beneficiarse de la incorporación de métricas de productos como consecuencia de un aumento en la satisfacción del cliente como resultado de una mayor calidad del producto y menores costos de desarrollo a través de una mejor comprensión del proceso de desarrollo de software..
4. Dentro de la comunidad Agile se desarrollan muchas métricas, que esencialmente son las mismas que las métricas dentro del método de cascada, aunque utilizan unidades y conceptos ágiles propios.
5. Los métodos ágiles no reconocen el "tamaño funcional". El 'tamaño' de un lanzamiento se expresa como número de características o historias. La medición de los "puntos de la historia" no produce una (funcional) Talla, sino más bien una cantidad de esfuerzo requerido.

Enlaces a algunos de los sitios web.

• grandes visibles – Métricas y diagnósticos ágiles
• Marco ágil escalado – Métrica
  Este sitio web de Dean Leffingwell toma una posición especial. Scaled Agile Framework es una filosofía y una metodología que enmarcan el desarrollo ágil en una estrategia empresarial 'esbelta'. Algunas de las métricas de "Arte" mencionadas en el diagrama se incluyen en las tablas anteriores.
• Instituto de Ingeniería de Software – Siete categorías de métricas ágiles
• Respuestas principales – Gestión de proyectos de calidad

 

 

Sobre el Autor

John Kammelar es consultor de métricas en metrieken.nl, que ayuda a las organizaciones a obtener información y control sobre los costos y el tiempo para el desarrollo y la administración de software. Cuantifican la funcionalidad con Function Point Analysis. Con base en este análisis se puede hacer una estimación realista del tiempo y los costos. Este blog es parte de una serie de tres artículos como resultado de una extensa encuesta. Esta primera parte muestra el estado del arte de las métricas en el desarrollo ágil de software. Todos los artículos se pueden descargar desde el metrieken.nl sitio web.

Una publicación de blog representa la opinión personal del autor.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.