Nuestra experiencia en el Uso de las Métricas Ágiles Más Comunes

Nuestra experiencia en el Uso de las Métricas Ágiles Más Comunes

El uso de métricas ágiles para medir la productividad del equipo es la parte clave de la filosofía Ágil. Los gerentes de equipo y todos los miembros deben ver las consecuencias de su trabajo y usar estos datos para mejorar el flujo de trabajo y aumentar la eficiencia.

Los usuarios finales y los clientes también pueden beneficiarse del uso de métricas de proyecto ágiles que se centran en evaluar el resultado del producto. Las métricas permiten a los maestros de scrum, desarrolladores, diseñadores y probadores medir el rendimiento de la aplicación y hacer un seguimiento de si las tareas actuales y anteriores mejoran el producto.

En este artículo, revisaremos las métricas ágiles que importan y compartiremos nuestra experiencia de aplicar este panel de métricas ágiles a un proyecto de la vida real. Resulta que, para liderar un equipo con éxito y ofrecer resultados, no solo necesitas saber qué métricas aplicar, sino también cómo hacerlo: compartiremos cómo lo resolvimos.

Tipos de métricas ágiles comunes

La clasificación de las métricas ágiles no es definitiva, siempre está cambiando y reestructurándose. Sin embargo, a lo largo de los años, hemos visto el aumento de tres tipos principales de métricas ágiles en varios marcos ágiles.

1. Métricas Kanban: estas métricas se basan en medir el tiempo invertido (tiempos de ciclo) y los resultados entregados (rendimiento), y su relación.
2. Métricas de Scrum: métricas que se centran en planificar y comprender el flujo de trabajo y demostrar cuánto trabajo se realizó en un período determinado;
3. Métricas magras: la medición continua de la eficiencia de producción y la calidad del producto con evaluación técnica mediante pruebas de funciones, comprobación de posibles errores y previsión de efectos negativos.

Utilizamos los tres tipos de métricas para evaluar los principales aspectos del proceso de desarrollo de software y los resultados: calidad del producto, productividad del equipo y salud.

Métricas ágiles de calidad

Antes de comenzar a medir la velocidad y la eficiencia del equipo, debe saber si generalmente se está moviendo en la dirección correcta. ¿De qué sirve la entrega rápida de todas las tareas de desarrollo, si las tareas en sí se forman de manera incorrecta? La prioridad para cada equipo de desarrollo de software y gerente es asegurarse de que todas las actividades estén relacionadas con la mejora del producto, esto se hace midiendo su calidad y detectando tendencias negativas.

Defectos escapados

Cada proyecto Ágil tiene sprints o ciclos de trabajo, al final de los cuales se entrega una determinada tarea. Una vez completado el trabajo, el gerente del equipo tiene que evaluar la calidad de los resultados de torneado. Todos los cambios, ediciones y errores no arreglados son defectos escapados, problemas que los desarrolladores podrían haber solucionado pero no lo hicieron. Registre su número y naturaleza precisos para saber qué errores generalmente escapan a los ojos de los desarrolladores.

Después de haber hecho un informe sobre defectos escapados y recopilado estadísticas tangibles, debe discutir los resultados con su equipo. Asegúrese de que cada miembro del equipo sepa qué tipos de errores suele pasar por alto el equipo. Si tiene sugerencias individuales, discútalas con los miembros del equipo uno a uno.

Implementaciones fallidas

Si el producto se implementó pero no se lanzó o no atrajo a los usuarios, esto se registra como una implementación fallida. A veces, una implementación fallida sucede a las decisiones de una de las partes interesadas, o el modelo de negocio resulta ser poco confiable. Cualquiera que sea la causa del problema, debe registrar todas las implementaciones fallidas junto con las razones de su falla.

Antes de lanzar una nueva implementación, el equipo siempre puede echar un vistazo a la lista de implementaciones fallidas anteriormente y examinar si esta no puede someterse al mismo proceso. Analizar las razones del fallo de versiones anteriores permite evitar problemas futuros.

Lanzamiento del Net Promoter Score (NPS)

El Net Promoter Score es la métrica que implica evaluar las reacciones de los usuarios en forma cuantitativa (números, estadísticas, calificaciones medias) y cualitativa (revisiones, comentarios directos, mensajes, correos electrónicos, llamadas). Después de que el equipo recopiló y analizó los comentarios, cada miembro del equipo sugiere una puntuación que evalúa la probabilidad de que el usuario recomiende el producto (por lo general, las puntuaciones se establecen en límites de 1 a 10).

Métricas ágiles de gestión de proyectos

Después de tener un historial completo de fracasos y éxitos anteriores, puede analizar la dirección tomada para todos los proyectos incompletos actuales y distribuir tareas relevantes, basándose en experiencias anteriores. Una vez que haya establecido la dirección del desarrollo, el «qué hacer» del producto», debe evaluar la eficiencia del equipo, es el factor «cómo lo estamos haciendo». Puede utilizar métricas de proyecto ágiles para saber si los miembros del equipo cumplen con sus expectativas, entienden sus tareas, gestionan los plazos y si todos los procesos están coordinados y sincronizados.

Tiempo de entrega

El tiempo de entrega es una métrica que permite a los equipos verificar cuánto tardó la entrada de productos atrasados en llegar al final del sprint. Se puede usar para rastrear productos en cualquier etapa de desarrollo, tarea por tarea, o evaluar los gastos de tiempo totales, desde la ideación hasta el lanzamiento. Es una métrica a largo plazo que los desarrolladores pueden usar al planificar su trabajo futuro y estimar los precios.

Asegúrese de registrar el tiempo de entrega para cada uno de sus proyectos. Es mejor mantener estadísticas generales que cubran todo el proyecto y que tengan métricas de sprint organizadas, para que puedas examinar cada etapa por separado.

Tiempo de ciclo

Si el tiempo de entrega se encuentra entre las métricas de rendimiento del equipo a largo plazo, el tiempo de ciclo se centra en tareas individuales. Esta métrica evalúa la duración de un solo ciclo, donde un ciclo se toma por una tarea, calcula el número de ciclos por proyecto y mide los resultados logrados para el usuario final si el producto ya está probado en versión beta o lanzado.

Con el tiempo de ciclo, los equipos pueden ver inmediatamente si una tarea lleva demasiado tiempo o si algunos miembros del equipo no están cumpliendo sus objetivos. Esta métrica a corto plazo hace que la gestión de proyectos sea mucho más fácil y ayuda a identificar rápidamente los problemas a medida que surgen.

Sprint evolución

Esta métrica se aplica tanto a corto plazo y a largo plazo. Los gerentes pueden crear informes de Scrum de reducción de sprints en tiempo real para rastrear el progreso de su equipo en el proyecto actual; para esto, necesitan estimar el número total de sprints y predecir los gastos de tiempo probables. También se puede usar a largo plazo: los gerentes pueden analizar informes de proyectos anteriores, identificar etapas que fallaron en los plazos esperados y analizar las causas de los retrasos.

Lo más importante es que sprint burndown permite realizar un seguimiento de la dinámica del flujo de trabajo de los equipos. Algunos miembros tienden a tomar el trabajo más lento en las primeras etapas, mientras que otros se agotan hacia el final del proyecto. Con los quemados de sprint, los líderes de equipo pueden detectar estas tendencias, determinar sus causas y ayudar a los miembros con la distribución del trabajo y la administración del tiempo.

Épica & Reducción de lanzamiento

Esta métrica es similar a la reducción de Sprint, la única diferencia clave es que se centra en la productividad del equipo antes y después del lanzamiento. Los gerentes pueden agregar nuevos requisitos e incorporar tareas que se basan en los comentarios de los usuarios finales. Es una versión mejorada de sprint burndown, ya que también incorpora tareas dadas después del lanzamiento del proyecto.

Velocidad

Esta métrica evalúa el número de puntos de historia completados durante un período determinado. En función de su historial, puede prever los gastos de tiempo para los puntos de historia futuros. La disminución de la velocidad del equipo en determinados sprints puede apuntar a malentendidos entre los miembros del equipo o tareas indicadas que son más difíciles de lo previsto anteriormente.

Métricas ágiles adicionales

Las métricas ágiles ayudan al equipo a conocer mejor su proyecto y a realizar un seguimiento de muchos aspectos importantes del desarrollo de productos. También hay métricas ágiles para ejecutivos sénior que permiten ver el panorama general del desarrollo y el bienestar del equipo. Según nuestra experiencia, estas métricas adicionales ayudan a medir cualquier aspecto de su trabajo. Sin embargo, definimos las características clave que más dicen sobre el producto final y ayudan a entregar un resultado completamente completo.

Flujo acumulativo

El nombre de la métrica comunica claramente su propósito: acumular todos los flujos del proyecto y evaluarlos en un solo diagrama. Tener un gráfico de este tipo le proporcionará una vista a gran escala, que se puede enviar a las partes interesadas del proyecto que no tienen tiempo para analizar informes ágiles más detallados.

El diagrama generalmente describe los siguientes procesos:

• Tareas en backlog: cuántas tareas en backlog tienen los miembros del equipo durante el período de tiempo dado;
• Trabajo aprobado: cuántas tareas entre las planificadas se completaron: el gerente del equipo ve inmediatamente las diferencias entre las actividades planificadas y finalizadas;
• Tareas de búfer: todo el trabajo que está esperando aprobación se define como una zona de búfer;
• En progreso: debe evaluar la carga de trabajo actual.

Pérdida de código

Esta métrica muestra las tendencias de los cambios en la base de código antes del lanzamiento. Los diagramas de rotación muestran cuánto código se agregó, eliminó o cambió de vez en cuando. En los primeros sprints, habrá muchos picos y caídas en el gráfico, porque el código sigue siendo inestable, pero a medida que avanza el proyecto, el gráfico de pérdida de código debería volverse estable, sin altibajos drásticos.

Antes de la publicación, el abandono debería sufrir un rechazo: agregar o editar código antes de la publicación significa que no se someterá a pruebas suficientes. En general, siempre que haya una irregularidad en los gráficos ágiles, investigue las razones.

Gráfico de control

Un gráfico de control es un gráfico en el que el equipo puede ver información sobre la duración de sus ciclos. El resultado ideal sería que la línea en el gráfico bajara constantemente con el tiempo, lo que significaría el aumento de la velocidad del equipo, se requiere menos tiempo por ciclo individual. Otro aspecto importante es la consistencia: los tiempos de ciclo deben permanecer uniformes independientemente del tipo de tarea, lo que significa que tiene una distribución de trabajo correcta.

Métricas de estado

Los equipos de desarrollo de software deben centrarse en las prioridades a largo plazo, como mantener una comunicación fluida entre los miembros y comprobar si todos están satisfechos. Agile es una metodología flexible, lo que significa que puede adaptarse a los intereses de los diferentes miembros, tan pronto como los gerentes saben a qué prestar atención. Así es como averiguamos si todos los miembros de nuestro equipo están satisfechos con el flujo de trabajo.

Felicidad

Si tienes relaciones informales de confianza en tu equipo, es más fácil comenzar con un diálogo abierto con cada miembro. Pida a todos que califiquen su experiencia en la empresa de 1 a 5. Puede hacer preguntas de ayuda: ¿cuáles son los mejores y los peores aspectos de su trabajo, qué se podría mejorar y qué podría aumentar la felicidad? Si el equipo no tiene hábitos de comunicación amigables, el uso de encuestas anónimas puede llevar a resultados más objetivos.

Moral del equipo

Moral del equipo y felicidad no son las mismas cosas. La felicidad tiene más que ver con la comodidad, mientras que la moral del equipo está ligada a la productividad, la autoestima, la evaluación de las propias cualidades profesionales. Una vez más, puede pedir a los empleados que califiquen su moral de 1 a 5 y hacer las siguientes preguntas;

• ¿El trabajo en la empresa te ayudó a mejorar tus habilidades?
• ¿Cuánto se explora todo su potencial con la carga de trabajo actual?
• ¿Disfrutas de tu trabajo?
• ¿Ves los resultados claros de tu trabajo?
• ¿Te entusiasman los nuevos proyectos?

El objetivo aquí es entender que la corriente de desarrollo del equipo va en la dirección correcta. A veces, el gerente del equipo de desarrollo de software realiza tareas rentables pero aburridas, ignorando los intereses de los miembros. Esta encuesta le ayudará a ver si los empleados están entusiasmados y desafiados por su trabajo.

Rotación de miembros del equipo

Si los gerentes del equipo reemplazan con frecuencia a los miembros del equipo, significa que el ambiente de trabajo probablemente no sea saludable. Una cierta tasa de rotación con el tiempo es saludable; de hecho, no querrás tener más personas durante años, ya que significaría estancamiento. Sin embargo, debes tener cuidado con los picos repentinos en los meses de actividad, cuando varias personas abandonaron el equipo o se unieron muchas personas. Si tiene una adición repentina de muchos participantes nuevos, debe prestar atención al proceso de incorporación antes de ir directamente al trabajo relacionado con el proyecto.

Medir los beneficios para los usuarios finales

Los equipos ágiles deben saber qué tan bien se adapta el producto a las necesidades de un usuario final y propietario de negocio. Esto se hace con un análisis de código exhaustivo que determina la calidad del código y su usabilidad para un usuario final, así como posibles complicaciones de mantenimiento.

Análisis de código estático

Es el tipo simple de análisis de código cuando el software está inactivo. Con solo monitorear el código automáticamente con herramientas de código abierto, puede identificar problemas de seguridad, detectar deudas técnicas y errores, y enviar fragmentos de código problemáticos al recolector de basura.

Análisis de código dinámico

El análisis de código dinámico requiere que su equipo ejecute software para evaluar la experiencia recibida por los usuarios finales. Animamos a nuestros desarrolladores y probadores a ponerse siempre en el lugar de los usuarios, explorando los escenarios más comunes. Por ejemplo, pueden presentar a sus colegas y familiares la solución, solicitando comentarios, a menos que el acuerdo no lo prohíba. Lo más importante es que contamos con un equipo de profesionales de control de calidad que son totalmente responsables del análisis dinámico de código, aunque creemos que cuantas más personas contribuyan a probar métricas en Agile, mejor será la calidad del producto final.

Cómo aplicar las mejores métricas ágiles

De toda la variedad de métricas ágiles disponibles, debe seleccionar las que serán relevantes para su equipo y proyectos a largo plazo. Llevar un registro de estas características clave debe ser un hábito, mientras que no debe distraerlo del trabajo más urgente. Así es como incorporamos métricas ágiles a la perfección en nuestro flujo de trabajo.

Centrarse en el rendimiento, el presupuesto y la calidad

Debe asegurarse de que, después de seleccionar todas las métricas, podrá tener una imagen clara de la calidad, la carga, los gastos de tiempo y el presupuesto de su trabajo. En primer lugar, establecemos métricas a corto plazo que se relacionan con nuestros proyectos activos: tiempo de ciclo y velocidad para la evaluación ágil del rendimiento, análisis de código para la evaluación de la calidad del código y flujo acumulativo para realizar un seguimiento de todos los procesos de desarrollo y sus costos.

Durante el primer sprint, nos aseguramos de hacer lo siguiente:

• Definir cuántos sprints y ciclos tendrá el proyecto;
• Estimar los gastos de tiempo para todo el proyecto, teniendo en cuenta las necesidades del cliente;
• Evaluar soluciones competitivas para comprender el nivel de complejidad del producto final;
• Recopilar comentarios de los miembros de nuestro equipo sobre sus expectativas sobre los aspectos más emocionantes, desafiantes y difíciles del proyecto.

De esta manera, podemos saber cuánto tiempo pasaremos para completar el proyecto, establecer estándares de calidad basados en soluciones similares y si nuestro equipo está motivado para trabajar en las tareas o no (tiene un gran impacto en la productividad). Métricas

después del primer sprint

Aquí, nos centramos en obtener comentarios del cliente y de todos los miembros del equipo. Después del primer sprint, queremos saber que todas las partes involucradas en el flujo de trabajo entienden el proceso y se sienten cómodas. Además, hacemos hincapié en evaluar la calidad del código, incluso planificamos el análisis de código y la evaluación de la deuda tecnológica como parte de cada uno de nuestros próximos sprints. Tan pronto como se escribieron las primeras líneas de código, mantener su calidad es nuestra prioridad.

Velocity viene después de

Velocity es una de las métricas más importantes de nuestros proyectos, pero no la clave. Nos abstenemos de basar nuestro juicio en números de velocidad en las etapas iniciales. La estrategia de pasar rápidamente los primeros pasos es un desastre a punto de ocurrir: el equipo puede omitir la planificación u olvidarse de hacerle a un cliente varias preguntas cruciales. No nos apresuramos en las primeras etapas del producto, permitiendo que los clientes y los miembros del equipo encuentren su ritmo.

Aumentar la velocidad de nuestro equipo se convierte en una de nuestras prioridades cuando estamos en el punto de ejecución. Tan pronto como se presentan todas las características y el diseño, nos esforzamos por minimizar los gastos de tiempo y completar todas las tareas lo más rápido posible.

Métricas individuales

Cada una de las métricas utilizadas debe estar disponible para todo el equipo y los miembros individuales por igual. Los desarrolladores, probadores y diseñadores deben ser capaces de ver el ritmo y los resultados de su trabajo, no solo un equipo en su conjunto. Para lograrlo, utilizamos herramientas de productividad y rastreadores de tiempo, como Jira y Hubstaff. Todos los informes generales se sincronizan con los individuales: los miembros pueden ver qué porcentaje del tiempo productivo total hacen sus horas.

Preguntas frecuentes

¿Qué es KPI en Agile?

Los Indicadores Clave de rendimiento en Agile son valores mensurables que muestran la eficiencia del equipo en el logro de los objetivos de negocio. Los KPI de alto nivel se centran en resultados a largo plazo que dependen de muchos factores: cuántos usuarios se sintieron atraídos por el producto final, las tasas de conversión, la calidad de los comentarios. Los KPI de bajo nivel son valores a corto plazo que no están influenciados por muchos factores conectados — el tiempo dedicado al proyecto (generalmente calculado en horas), el presupuesto del proyecto (inversión por tarea), etc.

Agile es una metodología de desarrollo basada en la mejora continua: el desarrollo de software analiza los datos y se adapta a ellos. El equipo analiza KPI ágiles sobre su rendimiento y calidad de trabajo, e implementa cambios de inmediato, en el siguiente sprint.

¿Qué son las métricas de Sprint?

Las métricas de Sprint son métricas que evalúan los entregables del equipo de desarrollo de software, verificando cuánto valor se entregó al cliente final al final de cada sprint . Este valor se puede medir con una nueva característica, mejoras de diseño o eliminación de errores.

El siguiente objetivo de sprint metrics es medir la efectividad del equipo en términos comerciales: qué tan rápido se entregó la solución al mercado, cuáles son los comentarios del cliente y los niveles de conversión. Por último, las métricas tienen que mostrar la satisfacción de los desarrolladores con su proyecto y con la dirección que el equipo está tomando en general.

¿Por qué son importantes las métricas para los proyectos ágiles?

El objetivo de la metodología Ágil es que los desarrolladores siempre puedan hacer correcciones en el proceso después de cada sprint. Tener datos tangibles, estadísticas y gráficos permite a los desarrolladores comprender qué cambios realizar para el próximo sprint y evaluar la calidad del producto final; de lo contrario, sería fácil atraparse en los detalles técnicos y de organización.

¿Qué es un sprint en Agile?

Un sprint es un período claramente definido con la fecha de inicio y finalización cuando el equipo se dispone a completar un cierto número de tareas. Los sprints son la base de Scrum, Agile y DevOps: los equipos dividen su carga de trabajo en trozos manejables más pequeños y hacen un seguimiento de los resultados de cada sprint. Cada uno de estos períodos se trata como un mini-proyecto con una planificación previa, evaluación de riesgos, asignación de responsabilidades y análisis posterior al sprint.

Cada proyecto se compone de una serie de sprints. Debido a que se evalúa cada sprint, es fácil detectar problemas desde el principio y eliminarlos en el siguiente sprint, por lo que el flujo de trabajo se optimiza constantemente.

¿Cuáles son las métricas para el desarrollo de software?

Las métricas de desarrollo de software son valores cuantitativos que permiten medir la calidad, el rendimiento y la salud del equipo del proyecto de desarrollo de software. Ayudan a mejorar el proceso de desarrollo a medida que avanza el proyecto y se pueden usar para el trabajo futuro del equipo para mejorar la organización y la planificación.

Hay seis tipos principales de métricas de desarrollo de software:

• Métricas de código formal: son valores cualitativos objetivos que calculan cuánto trabajo se realizó al determinar el número de líneas de código (LOC), la Longitud de la ruta de instrucción y otros.
• Métricas de eficiencia del desarrollador: el equipo puede calcular el código de asignación, los días activos y el tiempo dedicado a la tarea.
• Métricas de proceso ágil: cuando el proyecto se divide en sprints, el equipo puede medir la eficiencia de partes más pequeñas del proyecto: tiempo de espera (cuánto tiempo se gastó en una etapa de desarrollo determinada, que puede contener varios sprints), tiempo de ciclo (un sprint generalmente cae dentro de un solo ciclo) y velocidad (cuántas tareas se realizaron en un marco de tiempo particular).
• Métricas operativas: estas métricas comprueban las características de ejecución del software y determinan la eficacia del personal de la empresa en el mantenimiento de la herramienta sin ayuda de terceros. Tiempo medio entre Fallos y Tiempo Medio de Recuperación (MTTR) compruebe cómo se ejecutará el software en circunstancias naturales y cuán equipado está el equipo interno para manejar la carga.
• Métricas de prueba: estas métricas evalúan la cobertura del código, cuánto código se probó, el número de errores y el porcentaje de deuda tecnológica.
• Satisfacción del cliente: el equipo obtiene información sobre las reacciones de los usuarios finales al producto midiendo Net Promoter Score, Customer Satisfaction Score y Customer Effort Score. Estas métricas evalúan, respectivamente, si los usuarios recomendarían el producto y si están satisfechos con el resultado.

Las métricas ágiles forman parte de las redes de software y pueden abarcar otras categorías, como puede observar en nuestra guía.

¿Qué son las métricas SDLC?

SDLC es un ciclo de vida de desarrollo de software, un conjunto de etapas que una tecnología típica experimenta durante su concepción, ejecución y finalización. Un SDLC promedio consta de las siguientes etapas:

• Evaluar los sistemas existentes y definir sus características, ventajas, problemas;
• Definir los requisitos para la funcionalidad, el diseño, el público objetivo del nuevo proyecto, etc.;
• Diseñar el sistema y delinear una ruta de usuario típica;
• Desarrollar el software, lo que significa escribir código, preparar hardware y crear funciones;
• Probar el rendimiento, la funcionalidad, la seguridad, la interfaz del software, etc.;
• Desplegar el software en su entorno natural, donde la tecnología se ejecutará a largo plazo;
• Mantener el sistema actualizando el código, reemplazando o editando ciertos fragmentos y eliminando errores.

Cada etapa de SLDC se puede medir con las siguientes características.

• Requisitos: el equipo debe recopilar todos los requisitos para el proyecto y evaluar la implementación de cada uno de ellos en términos de tiempo y dinero;
• Calidad del software: todas las métricas de calidad Ágiles se pueden utilizar en la etapa de desarrollo de un SDLC;
• Casos de prueba: el equipo tiene que calcular el número de actividades de prueba realizadas, su velocidad y cobertura final de código;
• Defectos: para medir la eficiencia de su trabajo, los desarrolladores y los evaluadores deben ser conscientes del número exacto de problemas que surgen durante el desarrollo;
• Tareas: medir el tiempo y el dinero ganado por tarea permite evaluar si todos los miembros del equipo son productivos o no.

Todas las métricas, descritas en nuestra guía, se pueden utilizar en diferentes etapas del Ciclo de vida de desarrollo de software. El proyecto tiene la mayor necesidad de monitoreo cerca de la versión porque los problemas se pueden acumular y es fácil pasar por alto un defecto crítico en el producto.

¿Qué es el rendimiento en métricas ágiles?

Es la métrica que calcula el número de historias completadas por sprint. En Scrum, una métrica similar se conoce como Velocidad de Sprint.

Conclusión

Las métricas ágiles establecen una base sólida para tomar decisiones informadas a lo largo de un proyecto de desarrollo de software. Los desarrolladores pueden utilizar estos conocimientos para aumentar su eficiencia en los próximos sprints y mejorar constantemente la calidad de su producto. Sin embargo, vale la pena señalar que las métricas de desarrollo no deben convertirse en una prioridad absoluta en el proyecto de desarrollo de software. Los desarrolladores deben confiar, en primer lugar, en las necesidades del proyecto y las preferencias de la audiencia.

En Jelvix, utilizamos un enfoque personalizado para aplicar métricas al proyecto. Primero, discutimos el MVP del proyecto con el cliente, investigamos el público objetivo, analizamos soluciones competitivas y solo entonces elegimos las métricas que mejor se ajustan al proyecto. No nos esforzamos por aplicar cada KPI, sino que seleccionamos los que más reflejan las necesidades del proyecto.