Métricas para equipos ágiles

En el desarrollo ágil de software, los equipo pueden considerar algunas de las métricas recomendadas por Andy Cleff. A continuación se dan a conocer las categorías de métricas recomendadas por este autor:

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?

Recomendaciones

  • No se debe intentar utilizar todas la métricas al mismo tiempo.
  • Es recomendable iniciar con una o dos métricas, luego ir agregando otras con el tiempo.
  • Dependerá del equipo elegir qué métricas consideran útiles para probar.
  • Los managers y coaches no pueden obligar el uso de ninguna métrica específica, ni un número mínimo de métricas.
  • Ni los equipos, tampoco los managers deben comparar las métricas entre los equipos.

Referencias

Leave a Reply

Your email address will not be published. Required fields are marked *