Si tuvieses datos para predecir cuál será el número ganador del gordo de Navidad, ¿seguirías escogiendo un número por lo bonito o feo que parece ser? En tus proyectos tienes datos para predecir y decidir cómo actuar en base a datos empíricos, huye de la intuición. Todavía hoy en día se escuchan frases como “Eso de Scrum… ¿no te parece un invento de hippies?”. Estos comentarios suelen venir de personas acostumbradas a trabajar según los métodos tradicionales de construcción de software, a crear enormes documentos de especificaciones y planificaciones basadas en la intuición, acostumbradas a ver cómo esas planificaciones fracasan, a intentar equiparar la construcción de software con la construcción de un coche o de un edificio. En un entorno caracterizado por una alta incertidumbre y cambios constantes e impredecibles, se debe utilizar un método empírico que, a través de entregas constantes, nos permita obtener la información y el conocimiento necesario para tomar decisiones. Ese conocimiento surge de la comparación entre una hipótesis y el resultado real obtenido tras la entrega.

Por tanto, la estrategia de producto a seguir en Agile es la de definir un MVP (Minimum Viable Product), comparar los resultados según las métricas estratégicas preestablecidas (KPI’s), con las hipótesis que hemos aplicado, corregirlas y volver a iterar con el aumento de conocimiento obtenido.

Podemos observar algunos tipos de metricas.

https://firebasestorage.googleapis.com/v0/b/cv-adan-quintero.appspot.com/o/ScrumBacklog.jpg?alt=media&token=fe8dedfe-9a83-4ae1-aa62-8b1ad3942f28

Comparándolo con el enfoque de Scrum.org, las métricas estratégicas de las que hablamos anteriormente, podríamos llamarlas métricas directas, ya que tienen una aplicación directa sobre el valor que se desea generar: beneficio económico, beneficio social, mejora de la valoración de la compañía… Estas métricas nos informan del estado de los objetivos estratégicos de la empresa, pero por si solas no nos dan suficiente información para saber en dónde debemos poner el foco para mejorarlas. Para ello, debemos apoyarnos en las métricas circunstanciales, que son métricas que sólo aportan valor mediante su agregación y balanceo. Cuando comparamos las métricas directas con las circunstanciales provenientes de todos los aspectos posibles del proceso de construcción… ya no volverás llamar a Rappel para saber qué hacer. Incluso podrás hacer mediciones de aspectos olvidados por las empresas, como son los beneficios que provocan las inversiones en formación, patrocinios o mejoras del ambiente laboral. Vamos a nombrar algunas métricas agrupadas siguiendo el enfoque de Jason Tice:

Métricas sobre la salud del proceso. Enfocadas en evaluar las actividades necesarias para la entrega y los cambios que se producen durante todo el proceso de construcción: diagrama de flujo acumulado (nos permite ver y comparar de un vistazo el lead time, cycle time, WIP, tamaño del backlog,…), diagrama de control, flujo de la eficiencia, tiempo en progreso vs tiempo en proceso, tiempo de bloqueo por ítem…
Métricas sobre despliegues. Enfocadas en el proceso de entrega contínua: errores detectados y tiempo de resolución, tiempo de despliegue, ratio de despliegues con éxito, tiempo de estabilización de una release, tiempo entre despliegues con funcionalidad nueva, coste por release, ratio de adopción de una release / ratio de instalación
Métricas sobre el desarrollo del producto. Ayudan a medir el alineamiento entre las nuevas funcionalidades desarrolladas con las necesidades reales de los usuarios: valor de negocio entregado, NPS, burndown de riesgos, costes push/pull, pronóstico del producto, analítica de uso del usuario.
Métricas sobre el código. Para medir la calidad de la arquitectura y del código: índice de cobertura de test unitarios, tiempo necesario para crear el paquete, densidad de fallos, complejidad del código, ratio de indisponibilidad…
Métricas sobre el equipo. Métricas sobre factores humanos, ambiente de trabajo, compromiso del equipo: humor/felicidad/moralidad del equipo, Gallup Q12, log de aprendizaje, antigüedad del equipo, transparencia (acceso al cliente, a los datos, cómo se comparte el aprendizaje, éxitos y fracasos)…

Esta informacion fue extraidade la pagina oficial de paradigmadigital(https://www.paradigmadigital.com/techbiz/metricas-agile-opinion-interesante-datos/), su uso es unicamente informativo y para que las personas tengan una mejor persepcion de porque es importante mantener el control y una continua evaluacion de sus procesos para asegurar un exito en cualquier tipo de proyecto no solamente los de codigo de informacion, sino es aplicable hasta en la vida cotidiana, muchas gracias y nos vemos en otro post informativo compartanlo denme su voto! y comenten, Y si Eres Venezolano te invito a que me escribas y hagamos crecer nuestra comunidad!