Métricas de Producto.

Marco conceptual para las métricas de producto
la medición asigna números o símbolos a atributos de entidades en el mundo real. Para lograr esto, se requiere un modelo de medición que abarque un conjunto consistente de reglas. Aunque la teoría de la medición y su aplicación al software de computadora son temas que están más allá del ámbito de este libro, vale la pena establecer un marco conceptual fundamental y un conjunto de principios básicos que guíen la definición de las métricas de producto para el software.

Medidas, métricas e indicadores
los términos medida, medición y métrica con frecuencia se usan de modo intercambiable, es importante observar las sutiles diferencias entre ellos. En el contexto de la ingeniería del software, una medida proporciona un indicio cuantitativo de la extensión, cantidad, dimensión, capacidad o tamaño de algún atributo de un producto o proceso. La medición es el acto de de- terminar una medida. El IEEE Standard Glosary of Software Engineering Terminology define métrica como “una medida cuantitativa del grado en el que un sistema, componente o proceso posee un atributo determinado”.

El reto de la métrica de producto
Durante las cuatro décadas pasadas, muchos investigadores intentaron desarrollar una sola métrica que proporcionara una medida abarcadora de la complejidad del software. Fenton caracteriza esta investigación como una búsqueda del “imposible Santo Grial”. Aunque se han propuesto decenas de medidas de complejidad, cada una toma una visión un poco diferente de lo que es la complejidad y de qué atributos de un sistema conducen a la complejidad. Por analogía, considere una métrica para evaluar un automóvil atractivo.

Principios de medición
presenta una serie de métricas de producto que 1) auxilien en la evaluación de los modelos de análisis y diseño, 2) proporcionen un indicio de la complejidad de los diseños procedimentales y del código fuente y 3) faciliten el diseño de pruebas más efectivas, es importante comprender los principios de medición básicos. Roche sugiere un proceso de medición que puede caracterizarse mediante cinco actividades:

•Formulación. La derivación de medidas y métricas de software apropiadas para la representación del software que se está construyendo.
•Recolección. Mecanismo que se usa para acumular datos requeridos para derivar las métricas formuladas.
•Análisis. El cálculo de métricas y la aplicación de herramientas matemáticas.
•Interpretación. Evaluación de las métricas resultantes para comprender la calidad de la representación.
•Retroalimentación. Recomendaciones derivadas de la interpretación de las métricas del producto, transmitidas al equipo de software.

Medición de software orientado a meta
El paradigma Meta/Pregunta/Métrica (MPM) fue desarrollado por Basili y Weiss como una técnica para identificar métricas significativas para cualquier parte del proceso de software. MPM enfatiza la necesidad de: 1) establecer una meta de medición explícita que sea específica para la actividad del proceso o para la característica del producto que se quiera valorar, 2) definir un conjunto de preguntas que deban responderse con la finalidad de lograr la meta y 3) identificar métricas bien formuladas que ayuden a responder dichas preguntas.

Atributos de las métricas de software efectivas
Se han propuesto cientos de métricas para el software de computadora, pero no todas brindan apoyo práctico al ingeniero de software. Algunas demandan medición demasiado compleja, otras son tan particulares que pocos profesionales del mundo real tienen alguna esperanza de entenderlas y otras más violan las nociones intuitivas básicas de lo que realmente es el software de alta calidad.

Métricas para el modelo de requerimientos
El trabajo técnico en la ingeniería del software comienza con la creación del modelo de requerimientos. En esta etapa se derivan los requerimientos y se establece un cimiento para el diseño. Por tanto, son deseables métricas de producto que proporcionen comprensión acerca de la calidad del modelo de análisis.

Métrica basada en funciones
La métrica de punto de función (PF) puede usarse de manera efectiva como medio para medir la funcionalidad que entra a un sistema.4 Al usar datos históricos, la métrica PF puede entonces usarse para: 1) estimar el costo o esfuerzo requerido para diseñar, codificar y probar el software; 2) predecir el número de errores que se encontrarán durante las pruebas, y 3) prever el número de componentes y/o de líneas fuente proyectadas en el sistema implementado.

Métricas para calidad de la especificación
Davis et al. proponen una lista de características que pueden usarse para valorar la calidad del modelo de requerimientos y la correspondiente especificación de requerimientos: especificidad (falta de ambigüedad), completitud, corrección, comprensibilidad, verificabilidad, consistencia interna y externa, factibilidad, concisión, rastreabilidad, modificabilidad, precisión y reusabilidad.

Métricas para el modelo de diseño
Las métricas de diseño para software de computadora, al igual que todas las demás métricas de software, no son perfectas. El debate continúa acerca de su eficacia y sobre la forma en la que deben aplicarse. Muchos expertos argumentan que se requiere más experimentación antes de poder usar las medidas de diseño, aunque el diseño sin medición es una alternativa inaceptable.

Métricas del diseño arquitectónico
Las métricas del diseño arquitectónico se enfocan en características de la arquitectura del programa con énfasis en la estructura arquitectónica y en la efectividad de los módulos o componentes dentro de la arquitectura. Dichas métricas son “caja negra” en tanto no requieren conocimiento alguno del funcionamiento interior de un componente de software particular.

Métricas para diseño orientado a objetos
Hay mucho de subjetivo en el diseño orientado a objetos: un diseñador experimentado “sabe” cómo caracterizar un sistema OO de modo que implemente de manera efectiva los requerimientos del cliente. Pero, conforme un modelo de diseño OO crece en tamaño y complejidad, una visión más objetiva de las características del diseño puede beneficiar tanto al diseñador experimentado (quien adquiere comprensión adicional) como al novato (quien obtiene un indicio de la calidad que de otro modo no tendría disponible).

Métricas orientadas a clase: la suite de métricas C
La clase es la unidad fundamental de un sistema OO. Por tanto, las medidas y métricas para una clase individual, la jerarquía de clase y las colaboraciones de clase serán invaluables cuando se requiera valorar la calidad del diseño OO. Una clase encapsula datos y la función que los mani- pula. Con frecuencia es el “padre” de las subclases (en ocasiones llamadas hijos) que heredan sus atributos y operaciones. Usualmente colabora con otras clases. Cada una de estas características puede usarse como la base para la medición.

Métricas orientadas a clase: La suite de métricas MOOD
Harrison, Counsell y Nithi proponen un conjunto de métricas para diseño orientado a objeto que proporciona indicadores cuantitativos para características de diseño OO.
Aunque muchos factores afectan la complejidad, comprensibilidad y mantenimiento del software, es razonable concluir que, conforme el valor de FA aumenta, la complejidad del software OO también aumentará, y como resultado pueden sufrir la comprensibilidad, el mantenimiento y el potencial de reuso.

Métricas OO propuestas por Lorenz y Kidd
Metricas OO, Lorenz y Kidd dividen las métricas basadas en clase en cuatro amplias categorías; cada una tiene una relación en el diseño en el nivel de componen- tes: tamaño, herencia, internos y externos. Las métricas orientadas a tamaño para una clase de diseño OO se enfocan en conteos de atributos y operaciones para una clase individual y en valores promedio para el sistema OO como un todo. Las métricas basadas en herencia se enfocan en la forma en la que las operaciones se reutilizan a lo largo de la jerarquía de clases. Las métricas para interiores de clase se fijan en la cohesión y en los conflictos orientados a código. Y las métricas externas examinan el acoplamiento y el reuso.

Métricas de diseño en el nivel de componente
Las métricas de diseño en el nivel de componente para componentes de software convencional se enfocan en las características internas de un componente de software e incluyen medidas de cohesión de módulo, acoplamiento y complejidad. Dichas medidas pueden ayudarlo a juzgar la calidad de un diseño en el nivel de componente
6. Métricas de diseño en el nivel de componente
Las métricas de diseño en el nivel de componente para componentes de software convencional se enfocan en las características internas de un componente de software e incluyen medidas de cohesión de módulo, acoplamiento y complejidad. Dichas medidas pueden ayudarlo a juzgar la calidad de un diseño en el nivel de componente

Métricas orientadas a operación
Churcher y Shepperd analizan esto cuando afirman: “Los resultados de estudios recientes indican que los métodos tienden a ser pequeños, tanto en términos de número de enunciados como en complejidad lógica, lo que sugiere que la estructura de conectividad de un sistema puede ser más importante que el contenido de los módulos individuales.” Sin embargo, puede obtenerse algo de comprensión al examinar las características promedio para los métodos (operaciones).

Métricas de diseño de interfaz de usuario
Hay considerable literatura acerca del diseño de interfaces hombre/computadora, se ha publicado relativamente poca información acerca de las métricas que proporcionarían comprensión de la calidad y de la usabilidad de la interfaz.
Sears sugiere que la corrección de la plantilla (CP) es una métrica de diseño valioso para las interfaces hombre/computadora. Una GUI típica usa entidades de plantilla (íconos gráficos, texto, menús, ventanas y similares) para auxiliar al usuario a completar tareas.

Métricas de diseño para Webapps
Un útil conjunto de medidas y métricas para webapps proporciona respuestas cuantitativas a las siguientes preguntas:

•¿La interfaz de usuario promueve usabilidad?
•¿La estética de la webapp es apropiada para el dominio de aplicación y agrada al usuario?
•¿El contenido se diseñó de tal forma que imparte más información con menos esfuerzo?
•¿La navegación es eficiente y directa?
•¿La arquitectura de la webapp se diseñó para alojar las metas y objetivos especiales de los usuarios de la webapp, la estructura de contenido y funcionalidad, y el flujo de nave- gación requerido para usar el sistema de manera efectiva?
•¿Los componentes se diseñaron de manera que se reduce la complejidad procedimental y se mejora la exactitud, la confiabilidad y el desempeño?

Métricas para código fuente
La teoría de Halstead de la “ciencia del software” propuso las primeras “leyes” analíticas para el software de computadora. Halstead asignó leyes cuantitativas al desarrollo de software de computadora, usando un conjunto de medidas primitivas que pueden derivarse después de generar el código o de que el diseño esté completo. Las medidas son:

n1, número de operadores distintos que aparecen en un programa.
n2, número de operando distintos que aparecen en un programa.
N1, número total de ocurrencias de operador.
N2, número total de ocurrencias de operando.

Métricas para pruebas
Las métricas de software para pruebas, la mayoría de las métricas proponen enfocarse en el proceso de las pruebas, no en las características técnicas de las pruebas en sí. En general, los examinadores deben apoyarse en las métricas de análisis, diseño y código para guiarlos en el diseño y la ejecución de los casos de prueba.

Métricas para pruebas orientadas a objetos
Las métricas del diseño OO anotadas en la proporcionan un indicio de la calidad del diseño. También ofrecen un indicio general de la cantidad de esfuerzo de prueba requerido para ejercitar un sistema OO.
Las métricas consideran aspectos de encapsulación y herencia.
Falta de cohesión en métodos (FCOM). Mientras más alto sea el valor de la FCOM, más estados deben ponerse a prueba para garantizar que los métodos no generan efectos colaterales.
Porcentaje público y protegido (PPP). Los atributos públicos se heredan de otras clases y, por tanto, son visibles para dichas clases. Los atributos protegidos son accesibles a los métodos en las subclases. Esta métrica indica el porcentaje de los atributos de clase que son públicos o protegidos. Valores altos de PPP aumentan la probabilidad de efectos colaterales entre las clases porque los atributos públicos y protegidos conducen a alto potencial para acoplamiento.
Fan-in (FIN). Cuando se usa en el contexto OO, el fan-in (abanico de entrada) en la jerarquía de herencia es un indicio de herencia múltiple. FIN > 1 indica que una clase hereda sus atributos y operaciones de más de una clase raíz. FIN > 1 debe evitarse cuando sea posible.
Número de hijos (NDH) y profundidad del árbol de herencia (PAH). Los métodos de superclase tendrán que volverse a probar para cada subclase.

Métricas para mantenimiento
Todas las métricas de software presentadas en este capítulo pueden usarse para el desarrollo de nuevo software y para el mantenimiento del software existente. Sin embargo, se han propuesto métricas diseñadas explícitamente para actividades de mantenimiento.
IEEE Std. 982.1-1988 sugiere un índice de madurez de software (IMS) que proporcione un indicio de la estabilidad de un producto de software (con base en cambios que ocurran para cada liberación del producto). Para ello, se determina la siguiente información:
MT, número de módulos en la liberación actual
Fc, número de módulos en la liberación actual que cambiaron
Fa, número de módulos en la liberación actual que se agregaron
Fd, número de módulos de la liberación anterior que se borraron en la liberación actual

Trabajo pendiente de los Sprint
Los equipos de scrum organizan el desarrollo en sprints con un tiempo asignado. Al inicio del sprint, el equipo plantea un pronóstico de la cantidad de trabajo que puede completar durante el sprint. Un informe de evolución de sprints supervisa la finalización del trabajo a lo largo del sprint. El eje de abscisas representa el tiempo y el eje de ordenadas se refiere a la cantidad de trabajo que queda por completar, medido en puntos de historia u horas. El objetivo es haber finalizado todo el trabajo previsto al final del sprint.

Trabajo pendiente de épicas y publicaciones
Los diagramas de trabajo pendiente de epics y versiones sirven para realizar el seguimiento del progreso del desarrollo a lo largo de una muestra más amplia de trabajo que en el diagrama de trabajo pendiente de sprints, y guía el desarrollo de los equipos de scrum y kanban. Dado que un sprint (en los equipos de scrum) puede contener trabajo de varios epics y versiones, es importante supervisar el progreso de los sprints individuales, así como de los epics y las versiones.

Velocidad
La velocidad es la cantidad media de trabajo que un equipo de scrum lleva a cabo durante un sprint, medida en puntos de historia u horas, y es muy útil para los pronósticos. El propietario del producto puede usar la velocidad para predecir la rapidez con la que un equipo puede recorrer el backlog, debido a que el informe supervisa el trabajo previsto y el completado a lo largo de varias iteraciones. Cuantas más iteraciones se contemplen, más precisa será la previsión.

Gráfico de control
Los gráficos de control se centran en el tiempo del ciclo de las incidencias individuales, es decir, el tiempo total para pasar de "en curso" a "finalizado". Los equipos con duraciones del ciclo más cortas seguramente tengan mayor rendimiento, y los equipos con duraciones del ciclo homogéneas en numerosas incidencias son más predecibles. Si bien la duración del ciclo es una métrica fundamental para los equipos de kanban, los equipos de scrum también pueden sacar partido una duración del ciclo optimizada.

Diagrama de flujo acumulado
El diagrama de flujo acumulado debería ser una curva suave de izquierda a derecha. Las burbujas o huecos en cualquier color indican limitaciones y cuellos de botella. Cuando veas uno de estos casos, busca maneras de suavizar las bandas de color en todo el diagrama.

Métricas adicionales
Las buenas métricas no están limitadas a los informes mencionados anteriormente. Por ejemplo, la calidad es una métrica importante para los equipos ágiles y hay varias métricas tradicionales que pueden aplicarse al desarrollo ágil:

•¿Cuántos defectos se encuentran?
•¿durante el desarrollo?
•¿después de la publicación al cliente?
•¿por personas ajenas al equipo?
•¿Cuántos defectos se aplazan para una versión futura?
•¿Cuántas solicitudes de servicio al cliente están llegando?
•¿Cuál es el porcentaje de cobertura de las pruebas automatizadas?

Personas / Equipo: Aspectos Humanos
Este grupo de métricas revelan los problemas que afectan el lugar sostenible y el nivel de compromiso de un equipo.

•Felicidad: Crea transparencia con respecto a la satisfacción de los miembros del equipo. Permite al equipo autogestionarse y mejorar la moral. Para ello se puede emplear:
•MoodApp: Fue diseñado y construido por Atlassian para capturar los comentarios de los empleados.
•TeamMood.com: Sigue el estado de ánimo a nivel de equipo con algunos análisis muy agradables.
•Barómetro de equipo: Se ejecuta como una encuesta en un taller. La encuesta consta de 16 características del equipo, empaquetadas como una baraja de cartas. Los miembros del equipo votan verde, amarillo o rojo para cada tarjeta en la reunión (o antes de la reunión como una encuesta anónima). Una vez que todas las tarjetas se hayan procesado, el equipo reflexiona y analiza los resultados. Toma entre 30-50 minutos.
•Registro de aprendizaje: Una simple lista de elementos que el equipo (o los miembros del equipo) han aprendido. Dirige el enfoque a la importancia del aprendizaje. Promueve el aprendizaje a lo largo de un proyecto, apoya la autogestión y mantiene la moral y el compromiso del equipo.
•Permanencia del equipo: Muestra cuánto tiempo ha permanecido cada miembro en el equipo. Fomenta actividades que reflejen la permanencia (tutoría para los nuevos miembros del equipo, compartir el trabajo/conocimientos por parte de los miembros antiguos).
•Estadísticas de Phone-A-Friend: Rastrea la cantidad de veces que un ex miembro del equipo necesita ser contactado para recibir asistencia. Se usa para evaluar la efectividad de las actividades de intercambio de trabajo, documentación y transferencia de conocimiento cuando cambia la composición del equipo. Fomenta el enfoque de todo el equipo y el trabajo compartido.
•Contribución de todo el equipo: Porcentaje de miembros del equipo que contribuyen a un ítem de trabajo a lo largo de su ciclo de vida. Proporciona una métrica cuantitativa para evaluar/mejorar el enfoque de todo el equipo.

Métricas de la salud del proceso
Esta categoría evalúa las actividades diarias del equipo de delivery (entrega), y evalúa los cambios del proceso.

•Diagramas de flujo acumulativo: Permiten observar los Lead times (tiempo transcurrido entre que un cliente realiza un pedido y recibe el producto solicitado), Trabajo en progreso (WIP) en las diferentes etapas mientras se va logrando el “Done”.
•Gráficos de control: Permite observar el Lead time y el Cycle time (cantidad de tiempo necesaria para completar un ítem), promedio, promedio móvil, desviación estándar. Observa la dispersión para ver correlaciones positivas de cosas que se pueden medir.
•Porcentaje de Completo y Exacto: Mide el número de ítems completados y aceptables (de calidad) para ayudar al equipo en mejorar el delivery.
•Eficiencia de flujo: Realiza un seguimiento de la relación existente entre el Tiempo dedicado a trabajar en un ítem y el Tiempo que espera el ítem. El equipo puede usarlo para calibrar los límites de WIP para minimizar el retraso y promover el flujo.
•Tiempo de bloqueo por ítem: Mide la cantidad de tiempo que un ítem estuvo bloqueado mientras se lo completaba. Se utiliza para determinar el costo de la demora y proponer medidas preventivas para evitarlas.
•Agrupación de bloqueadores: Muestra la agrupación y frecuencia de ítems bloqueadores. Ayuda a identificar las mayores fuentes de retraso y proponer mitigaciones comunes.

Métricas de release (lanzamiento)
Dirigen su enfoque hacia la identificación de impedimentos para el delivery continuo.

•Defectos evadidos: Un recuento de defectos que se descubren en la producción. Se utiliza para identificar las causas raíz de por qué el defecto no se detecta antes del release. También permite crear un acuerdo claro sobre el nivel aceptable de defectos evadidos.
•Tiempo de resolución de defectos evadidos:Mide la cantidad de tiempo requerido para resolver un defecto evadido. Proporciona claridad sobre el costo no planificado de resolver defectos evadidos. Se utiliza para ayudar al equipo a lograr el equilibrio entre las pruebas proactivas y los acuerdos de nivel de servicio (SLA) sostenibles.
•Promedio de éxito de los releases: Es el promedio de releases aceptados y rechazados por el cliente. Fomenta la asociación entre el equipo y el cliente. El objetivo final es un alto porcentaje de releases aceptados como resultado de un proceso efectivo, consenso sobre criterios realizados y bucles de retroalimentación.
•Tiempo de release: Muestra la cantidad de tiempo requerida para realizar el release de un producto al entorno de producción. Se utiliza para establecer un consenso sobre el costo / tiempo sostenible para el release en producción, con el objetivo final de una automatización suficiente para reducir el tiempo / costo para el nivel deseado de agilidad empresarial.
•Tiempo desde el último release: Esta métrica muestra la cantidad de tiempo transcurrido desde la última vez que el equipo realizó el release de su producto a los usuarios finales. Poner el producto en manos de los usuarios permite a los equipos incorporar más retroalimentación de los usuarios en las actividades de desarrollo y así crear el producto "correcto".
•Costo por lanzamiento: Es el costo de completar un release de software (planificada y/o no planificada) permite considerar factores económicos al decidir cuándo/sí se lanzará. Fomenta las inversiones para reducir el costo de release a través de la automatización a un nivel acordado.
•Release Net Promoter Score: ¿Los equipos están "diseñando e implementando rápidamente una excelente experiencia para el cliente, una y otra vez en el tiempo"? Podrían estar moviéndose rápido, pero ¿se están moviendo rápido en la dirección correcta? Sí, esto se puede medir con: External Net Promoter Score (NPS).
•Adopción del release/ promedio de instalación: Mide el número de usuarios existentes que han realizado una actualización; número de nuevos usuarios obtenidos por el release. Se utiliza para evaluar el ROI en el desarrollo de productos y validar las suposiciones comerciales. ¿El ROI cumple o supera los supuestos comerciales? Permite identificar a los usuarios que no se han actualizado y determinar el por qué.

Métricas de desarrollo de productos
Ayudan a medir la alineación de las características del producto con las necesidades del usuario.

•Valor entregado al Cliente/Negocio: Es la cantidad de valor comercial proporcionado por cada ítem, epic, feature, ó release completado. Permite que el equipo y los Stakeholders administren el ROI, enfocándose primero en los ítems de mayor valor.
•Burndown de riesgo: Mide la cantidad de riesgo conocido y no mitigado que se muestra a lo largo de un período de tiempo. Alienta la autogestión del equipo para reducir el riesgo del proyecto.
•Push/Pull: Es el ratio entre la cantidad de ítems completados y los nuevos items agregados. Se utiliza para evitar que los equipos se vean abrumados con trabajos que pueden comprometer el enfoque y el compromiso.
•Pronóstico del producto: Establece tendencias futuras (el mejor de los casos, el peor de los casos) basadas en el rendimiento histórico de ítems completados. Se usa para predecir cuándo se completará el trabajo futuro utilizando el recuento de ítems. Puede conducir a un rendimiento estable para permitir una mejor previsión.
•Net Promoter Score (NPS) del producto:NPS se usa para medir la respuesta a la pregunta: ¿Recomendaría este producto a un colega? Permite recopilar feedback de los usuarios sobre si el producto satisface sus necesidades, y se puede utilizar para identificar elementos exitosos del diseño del producto y oportunidades/ideas para aumentar la adopción del usuario.
•Analítica de usuario: Identifica patrones de uso dentro del producto. Determina la efectividad del diseño; muestra patrones de uso emergentes que justifican la consideración de futuras inversiones. Es excelente para aumentar las actividades de análisis de negocios y diseño de productos con el comportamiento real del usuario. Se puede utilizar Google Analytics y AppSee.

Técnica / métricas de código
Ayudan a determinar la calidad de la implementación y la arquitectura.

Cobertura de pruebas: Monitorea el porcentaje de código que ha sido revisado por varios tipos de pruebas automatizadas. Guía los esfuerzos/inversiones para mejorar la cobertura de prueba a niveles suficientes.
•Time Build: Mide el tiempo de compilación y ejecución de pruebas para proporcionar feedback al equipo de desarrollo.
• Densidad del defecto: Rastrea el porcentaje de defectos en cada área del sistema, determinado por la funcionalidad o la arquitectura del código. Ayuda a identificar partes de la aplicación/código donde se puede mejorar la calidad. Los datos pueden ayudar a identificar deuda técnica.
•Code Churn: Mide el número de líneas de código cambiadas (agregadas, eliminadas, modificadas) para completar un ítem. Se puede utilizar para evaluar si la cantidad de código modificado refleja el ítem abordado. Promueve la comprensión de todo el equipo sobre el código y la alineación con los patrones y estándares de diseño acordados.
•Propiedad del código: Muestra la frecuencia con la que los miembros del equipo cambian o realizan commit en la base del código. Se utiliza para iluminar, evaluar y promover la propiedad del código colectivo.
•Complejidad de código: La complejidad ciclomática monitorea una puntuación del código determinada por una herramienta. Promueve prácticas de ingeniería para crear código limpio utilizando datos cuantitativos. Permite al equipo evaluar y comprender la tendencia ascendente/descendente de la complejidad del código.
•Cumplimiento de estándares de codificación: Este es un puntaje de evaluación de alineación del código con los estándares de arquitectura. Se utiliza para promover los estándares de codificación acordados para crear código limpio. Permite el aprendizaje en equipo para alinear mejor el código con los patrones de diseño acordados; identifica el código que puede mejorarse para que no sea observado durante la revisión del código.
•Promedio de Crash: Es un registro de incidentes que provocan el bloqueo de una aplicación/producto. Se utiliza para realizar el análisis de causa raíz para reducir los bloqueos. Permite al equipo obtener información sobre los errores del producto en el código publicado que tienen un impacto significativo en la experiencia del usuario.

¿Cómo elegir las métricas?
Se debe considerar lo siguiente al momento de seleccionar las métricas a utilizar

1.¿Por qué “esta métrica”? - ¿Por qué es importante? ¿A quién le interesa?
2.¿Qué ideas podemos obtener de “esta métrica”?
3.¿Qué se espera que cambie? ¿Estamos buscando variabilidad, consistencia, tendencias o valores absolutos?
4.¿Cómo podría ser burlado, usado de mala manera (o uso indevido)?
5.¿Cuáles son algunas compensaciones / costos de mejora?
6.¿Con qué frecuencia nos gustaría "registrar los datos"?
7.¿Cuánto tiempo llevaremos a cabo el experimento?
8.¿Cómo saber cuándo se ha "terminado" con esta métrica?
9.¿Cómo hacer que las mediciones sean transparentes?
10.¿La métrica es un indicador adelantado o rezagado?