Desiciones, Scrum(?).... Tu opinion es interesante, pero tengo datos

in #developer7 years ago (edited)

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.

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:  

  1. 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…
  2. 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
  3. 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.
  4. 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…
  5. 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!


Sort:  

Hi! I am a robot. I just upvoted you! I found similar content that readers might be interested in:
https://www.paradigmadigital.com/techbiz/metricas-agile-opinion-interesante-datos/