La elección de métricas (Key Performance Indicators) para medir el éxito de un equipo de programadores remotos, requiere una considerable reflexión y cuidado para estar en sintonía con los objetivos específicos de la empresa (Objectives and Key Results). Las mediciones deben diseñarse para responder preguntas como: ¿nuestro software es de calidad? ¿estamos cumpliendo las fechas de lanzamiento para cada proyecto? ¿cuántos errores hay por cada 1000 invocaciones API? entre otras. Sin embargo, estas métricas nunca son para responder preguntas sobre ¿cuántas líneas de código se escriben por hora? o ¿cuántas horas de actividad tiene un desarrollador frente a la computadora?
Este artículo nos vamos a enfocar en las métricas específicas que cada equipo de desarrollo de software debe comenzar a usar, o al menos planear usar pronto como una forma de mejorar su rendimiento.
Comienza midiendo las cosas correctas.
Aquí hay quince métricas objetivas (marcadas con viñetas) que debes monitorear continuamente en tu equipo remoto para realizar mejoras en los procesos y entornos de producción. Las mejoras en estas métricas no garantizan que los niveles de satisfacción de tus clientes aumenten pero te pondrán en el camino correcto. En una sección al final de este artículo, “Poniendo todo junto”, verás por qué.
Métricas de procesos
Para procesos ágiles y lean, las métricas básicas son: el tiempo de entrega, el tiempo del ciclo, la velocidad del equipo y las tasas de apertura / cierre. Estas métricas ayudan a la planificación e informan las decisiones sobre la mejora de procesos. Si bien no miden el éxito o el valor agregado, y no tienen nada que ver con la calidad objetiva del software, debes medirlos de todos modos.
- Plazo de ejecución: cuánto tiempo le lleva pasar de la idea al software entregado. Si deseas responder más rápido a la demanda de tus clientes, trabaja para reducir tu tiempo de entrega, generalmente simplificando la toma de decisiones y reduciendo el tiempo de espera. El tiempo de entrega incluye el tiempo del ciclo.
- Tiempo del Ciclo: cuánto tiempo te lleva hacer un cambio en tu sistema de software y entregar ese cambio en producción. Los equipos que utilizan la entrega continua pueden tener tiempos de ciclo medidos en minutos o incluso segundos en lugar de meses.
- Velocidad del equipo: cuántas “unidades” de software suele completar el equipo en una iteración (también conocido como “sprint”). Este número sólo debe usarse para planificar iteraciones. Comparar las velocidades del equipo no tiene sentido porque la métrica se basa en estimaciones no objetivas. Tratar la velocidad como una medida de éxito no es apropiado, y convertir una velocidad específica en una meta distorsiona su valor para la estimación y la planificación.
- Tasas de apertura / cierre: cuántos problemas de producción se informan y cierran dentro de un período de tiempo específico. La tendencia general importa más que los números específicos.
Cuando alguna o todas estas métricas están fuera del rango esperado o tengan una tendencia en direcciones alarmantes, no asumas una causa. Habla con el equipo, obtén toda la historia y deja que el equipo decida si hay motivos de preocupación y, de ser así, cómo solucionarlo.
No puedes conocer o asumir las causas raíz de los números, pero estas métricas te dan una idea de dónde necesitan atención.
Métricas de Seguridad
La seguridad es un aspecto de la calidad del software que a menudo se pasa por alto hasta más tarde (o demasiado tarde). Las herramientas de análisis de seguridad se pueden utilizar en el proceso de construcción, además de evaluaciones y pruebas de estrés más especializadas.
Las métricas de calidad generalmente están relacionadas con el número de errores. La gama completa de prácticas de seguridad y métricas relacionadas son más de las que podemos cubrir hoy en este artículo, pero al igual que las métricas de procesos ágiles y las métricas de producción, hay algunas métricas específicas que pueden significar mucho para la satisfacción general de sus clientes.
- Incidentes en desarrollo: cuántos incidentes ocurren durante la etapa de desarrollo.
- Incidentes en puntos finales: cuántos puntos finales (dispositivos móviles, estaciones de trabajo, etc.) han experimentado una afectación durante un período de tiempo determinado
- MTTR (tiempo medio de reparación): en las métricas de seguridad, este es el tiempo entre el descubrimiento de una violación de seguridad y una solución de trabajo implementada. Si el valor de MTTR disminuye con el tiempo, los desarrolladores se vuelven más efectivos para comprender los problemas de seguridad, como los errores y cómo solucionarlos.
Puedes encontrar más formas de aplicar métricas de seguridad al desarrollo de software en los artículos Seguridad de aplicaciones para proyectos ágiles y Modelos de amenazas de seguridad: una introducción ágil.
Métricas de Pruebas de Calidad
Los KPI de pruebas de calidad demuestran la madurez y la preparación de producción del software. También establece la productividad de un equipo de control de calidad para minimizar errores de software y contribuir a lanzamientos de software de alta calidad.
- Prueba de cobertura: la cobertura de prueba muestra el porcentaje de requisitos de software cubiertos con casos de prueba. Mantener una cobertura de prueba alta mejora el cumplimiento del software con la especificación de requisitos.
- Defectos encontrados durante las pruebas de aceptación del usuario (UAT): los defectos encontrados durante UAT reflejan el nivel de calidad del software antes de la producción. Si la cantidad de errores descubiertos durante UAT es cercana a la cantidad de errores encontrados antes, las etapas de prueba e ingeniería de software pueden necesitar mejoras.
- Defectos encontrados en la producción: los errores que se introdujeron en la producción pueden causar pérdida de ingresos al rechazar a los usuarios del uso de software. Por lo tanto, debe asegurarse de eliminar al menos el 90% de los errores antes del lanzamiento del software.
Métricas de Calidad del Código
Las métricas de calidad del código evalúan el estado del software a través de revisiones de código automatizadas. Los valores bajos de KPI para la calidad del código significan que el código es demasiado complejo y puede plantear dificultades para ampliar la funcionalidad y ejecutar actividades de soporte.
Las principales métricas de calidad del código son:
- Índice de mantenibilidad: es una combinación de varias métricas, incluidas la complejidad ciclomática y las líneas de código promedio, así como la complejidad computacional, basada en la función de volumen de Halstead. El índice de mantenibilidad es un valor entre 1 y 100.
- Complejidad ciclomática: representa el número de rutas únicas a través de su código. Más simplemente, es el número de declaraciones “if”, bucles y casos de cambio en su código. El código con una alta complejidad ciclomática puede ser difícil de probar y mantener, ya que hay varias rutas diferentes a través del código que deben probarse. Para la Complejidad Ciclomática, un valor bajo es bueno y un valor alto es malo.
- Profundidad de herencia: indica el número de clases diferentes que se heredan entre sí, hasta la clase base.Cuanto mayor sea este número, mayor será la profundidad de la herencia y más posibilidades de causar cambios importantes en su código al modificar una clase base. Para la profundidad de herencia, un valor bajo es bueno y un valor alto es malo.
- Acoplamiento de clase: es una medida de las dependencias que una clase tiene en otras clases. Cuanto mayor sea este número, más probable es que un cambio en una clase afecte a otras clases. Para el acoplamiento de clases, un valor bajo es bueno y un valor alto es malo.
- Líneas de código: indica el número de líneas de código ejecutables en un método. Como es de esperar, cuantas más líneas de código haya en tu aplicación, más código tendrás que mantener. Para las líneas de código, un valor bajo es bueno y un valor alto es malo.
Herramientas como Microsoft Visual Studio calculan automáticamente estos indicadores de rendimiento.
Poniendo todo junto: el éxito es la métrica definitiva
Las empresas tienen objetivos. Los objetivos implican una serie de tareas que deben ser cuantificadas para medir el progreso hacia el éxito.
Cuando comprendemos cuál es el valor comercial de cada objetivo, podemos comenzar a hacer las preguntas que nos llevarán a las métricas que responden la pregunta.
Por ejemplo, para mejorar un proceso de pago de en una tienda online podemos haber llegado a la conjetura de que un pago más rápido generará más ventas. ¿Pero por qué pensamos eso? ¿Muchas personas abandonan sus carritos de compras durante el proceso de pago? Si ese es el consenso, entonces la hipótesis para establecer un KPI puede ser “Creemos que un proceso de pago más rápido dará como resultado una disminución de las tasas de abandono del carrito, lo que conducirá a mayores ventas y una mejor experiencia del usuario””.
Dicho de otra manera, las métricas sólo deben usarse para responder preguntas, para probar hipótesis que respalden un objetivo comercial específico. Y esto debe hacerse solo mientras las preguntas y respuestas ayuden a generar cambios positivos.
En algunos casos, las hipótesis pueden ser incorrectas, por lo que debemos hacer cambios en nuestros KPIs. En otros casos, la hipótesis puede ser correcta, por lo que seguimos impulsando mejoras en esta área durante años.
Cinco consejos para el uso efectivo de las métricas
Las condiciones cambian constantemente, por lo que, en lugar de resumir una fórmula a seguir, aquí hay cinco reglas generales, para ayudar a mantener el enfoque y la flexibilidad en la medición del progreso, que te ayudarán en tu viaje hacia el éxito empresarial:
- Las métricas no pueden contarte la historia; solo tu equipo puede hacer eso.
- Comparar lo incomparable es un desperdicio de tiempo.
- Puedes medir casi cualquier cosa, pero no puedes prestar atención a todo.
- Las métricas de éxito empresarial impulsan las mejoras de software, no al revés.
- Mide solo lo que importa.
Vacantes Recientes
Blogs Relacionados
-
Trabajar remoto ¿Qué significa?
Leer Más -
¿Qué Es Trabajo Remoto? ¿Cómo Funciona El Trabajo a Distancia? ¿Dónde Consigo Un Puesto Remoto?
Leer Más -
Esto aprendimos después de 5 años trabajando en home office
Leer Más -
Las Mejores Herramientas para el Trabajo Remoto Desde Casa
Leer Más -
Home Office y Trabajo Remoto: Preguntas y Respuestas
Leer Más
