9 métricas que pueden marcar la diferencia para los equipos de desarrollo de software de hoy en día

Como señalé en el artículo «Por qué las métricas no importan en el desarrollo de software (a menos que las combine con los objetivos de negocio)», elegir métricas requiere una reflexión y un cuidado considerables para respaldar las preguntas específicas que una empresa realmente necesita responder. Este es el punto crítico: Las mediciones solo deben diseñarse como una forma de responder preguntas comerciales. Y esas preguntas nunca son, » ¿Cuántos KLOCs tenemos hasta ahora?»

Este artículo continúa donde lo dejó el anterior, discutiendo primero las métricas específicas que cada equipo debe comenzar a usar, o al menos planea usar pronto como una forma de mejorar el rendimiento notable. Ten en cuenta que el título de este artículo afirma que hay «9 métricas que PUEDEN marcar la diferencia because», porque lo que es realmente importante, lo que realmente marcará la diferencia, es cómo se usan esas métricas para mejorar el valor del negocio. Ese uso depende de ti. Luego, este artículo concluye explicando cómo puedes combinar estas métricas para crear significado, así como formular y probar una hipótesis de valor comercial.

Comience midiendo las cosas correctas

Aquí hay nueve métricas objetivas (marcadas con viñetas) que debe monitorear continuamente para realizar mejoras incrementales en los procesos y entornos de producción. Las mejoras en estos números no garantizarán que los niveles de satisfacción de sus clientes aumenten a pasos agigantados. Pero al menos estas son las cosas correctas a medir. En una sección posterior de este artículo, «Uniendo todo», verás por qué.

Métricas de procesos ágiles

Para los procesos ágiles y ajustados, las métricas básicas son el tiempo de entrega, el tiempo de ciclo, la velocidad del equipo y las tasas de apertura/cierre. Estas métricas ayudan a planificar e informar las decisiones sobre la mejora de los procesos. Si bien no miden el éxito o el valor añadido, y no tienen nada que ver con la calidad objetiva del software, de todos modos debe medirlos. Explicaré por qué a continuación.

• Plazo de entrega: cuánto tiempo le lleva pasar de la idea al software entregado. Si desea ser más receptivo con sus clientes, trabaje para reducir el tiempo de entrega, por lo general simplificando la toma de decisiones y reduciendo el tiempo de espera. El tiempo de entrega incluye el tiempo de ciclo.
• Tiempo de ciclo: cuánto tiempo le lleva realizar un cambio en su sistema de software y entregarlo en producción. Los equipos que utilizan la entrega continua pueden medir los tiempos de ciclo en minutos o incluso segundos en lugar de meses.
• Velocidad de equipo: cuántas » unidades «de software suele completar el equipo en una iteración (también conocido como»sprint»). Este número solo debe usarse para planificar iteraciones. Comparar velocidades de equipo no tiene sentido, porque la métrica se basa en estimaciones no objetivas. Tratar la velocidad como una medida de éxito es inapropiado, 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 se 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 con tendencias en direcciones alarmantes, no asuma una causa. Hable con el equipo, obtenga toda la historia y deje que el equipo decida si hay motivo de preocupación y, de ser así, cómo solucionarlo.

No puede saber ni asumir las causas raíz a partir de los números, pero estas métricas le dan una idea de dónde necesitan atención sus procesos esenciales. Una tasa de apertura alta y una tasa de cierre baja en algunas iteraciones, por ejemplo, puede significar que los problemas de producción son actualmente una prioridad menor que las nuevas características, o tal vez que el equipo se centra en reducir la deuda técnica para solucionar clases enteras de problemas, o que la única persona que sabía cómo solucionarlos se retira, o algo más. No se puede saber o asumir las causas raíz de los números.

Análisis de producción

• Tiempo medio entre fallos (MTBF)
• Tiempo medio de recuperación / reparación (MTTR)

Ambos son medidas generales del rendimiento de su sistema de software en su entorno de producción actual.

• Tasa de fallos de la aplicación: cuántas veces falla una aplicación dividida por cuántas veces se usó. Esta métrica está relacionada con MTBF y MTTR.

Tenga en cuenta que ninguna de estas tres métricas le informa sobre las características individuales o los usuarios afectados. Sin embargo, cuanto más pequeños sean los números, mejor. El software moderno de monitoreo de operaciones hace que la recopilación de métricas detalladas en programas y transacciones individuales sea bastante fácil, pero se necesita tiempo y una cuidadosa reflexión para configurar los rangos adecuados para alertas y/o disparadores para aumentar o reducir la escala (para sistemas basados en la nube).

Nos gustaría que nuestro software nunca fallara, pero eso es estadísticamente improbable. Cuando nuestro software falla, nos gustaría que nunca perdiera ningún dato crítico y se recuperara al instante, pero eso puede ser extraordinariamente difícil de lograr. Sin embargo, si su software es su fuente de ingresos, el esfuerzo vale la pena.

Más allá del MTBF y el MTTR, las mediciones más detalladas se basan en transacciones individuales, aplicaciones, etc., y reflejan el valor comercial entregado y el costo de remediar fallas. Si su aplicación de procesamiento de transacciones se bloquea una vez de cada cien, pero se recupera en uno o dos segundos y no pierde ninguna información crítica, esa tasa de bloqueo del 1 por ciento puede ser suficiente. Pero si cada bloqueo es de una aplicación que ejecuta 100,000 transacciones al día, pierde una venta de 1 100 y cuesta remedi 50 para remediar en el back-end, esa tasa de bloqueo del 1 por ciento será una prioridad. Arreglarlo tendrá un impacto significativo en el resultado final.

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). Se pueden utilizar herramientas de análisis de seguridad en el proceso de construcción, además de evaluaciones más especializadas y pruebas de resistencia. Los requisitos de seguridad a menudo son simples y de sentido común, pero el equipo de desarrollo de software debe ser consciente de ellos y de las métricas derivadas de ellos.

La gama completa de prácticas de seguridad y métricas relacionadas está más allá del alcance de este artículo, pero al igual que con 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 de punto final: cuántos puntos finales (dispositivos móviles, estaciones de trabajo, etc.).) ¿ha experimentado una infección por virus durante un período de tiempo determinado?
• MTTR (tiempo medio de reparación): en métricas de seguridad, este es el tiempo que transcurre entre el descubrimiento de una brecha de seguridad y un remedio operativo implementado. Al igual que con la métrica MTTR de producción mencionada anteriormente, el MTTR de seguridad debe rastrearse en intervalos de tiempo específicos. Si el valor de MTTR se reduce con el tiempo, los desarrolladores se están volviendo más eficaces para comprender los problemas de seguridad, como los errores y cómo solucionarlos.

Para ambas métricas, los números más pequeños a lo largo del tiempo significan que te estás moviendo en la dirección correcta. Menos incidentes de punto final hablan por sí solos. A medida que el valor de MTTR se reduce, los desarrolladores son cada vez más eficaces para comprender los problemas de seguridad, como los errores y cómo solucionarlos.

Puede 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.

Una nota sobre métricas de código fuente

Hoy en día es fácil conectar un escáner de código fuente a su canalización de compilación y producir montones de métricas objetivas. Hay promedios empíricos y rangos sugeridos y argumentos lógicos sobre la importancia relativa de estas métricas. Pero en la práctica, estas herramientas son más útiles para hacer cumplir los estilos de codificación, marcar ciertos anti-patrones e identificar valores atípicos y tendencias.

Simplemente no vale la pena quedarse colgado en los números. He aquí un ejemplo, a modo de explicación.

Supongamos que encuentra un método en una clase con una métrica ridícula, como una complejidad NPATH de 52 millones. Eso significa que se necesitarían 52 millones de casos de prueba para ejercer completamente cada ruta a través del código. Podría refactorizar el código en una estructura más simple, pero antes de hacerlo, considere cuál sería el impacto en el negocio. Lo más probable es que el código antiguo y feo funcione lo suficientemente bien (aunque su cobertura de prueba puede ser inadecuada). Llamar el anti-patrón al equipo para que puedan evitar repetirlo es un aprendizaje valioso, pero arreglarlo probablemente no movería la aguja en ninguna métrica comercial relevante.

Es mejor si el equipo está de acuerdo con el nivel de cumplimiento y las reglas a las que está sujeto su código, pero tenga en cuenta que examinar los valores atípicos y preocuparse por los cambios de tendencia puede perder mucho tiempo.

Luego junte todo: El éxito es la métrica definitiva

La alegría de usar herramientas automatizadas para rastrear y medir métricas de calidad y análisis de usuarios es que libera tiempo para enfocarse en las métricas que realmente importan: métricas de éxito.

Cómo usar métricas para el éxito

Las empresas tienen objetivos. Los objetivos implican preguntas como «¿Cómo es el éxito?»o» ¿Cómo afectará esto el comportamiento del cliente?»Las preguntas correctamente cuantificadas implican métricas.

Dicho de otra manera, las métricas solo se deben usar 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 impulsar cambios positivos.

Ahora, ¿no todos los proyectos en general tienen algún conjunto de objetivos, preguntas e hipótesis invariables, y por lo tanto métricas?

Sí, pero solo desde el punto de vista del negocio. Las mediciones a nivel empresarial de cosas como la participación de los usuarios, las tasas de cierre, la generación de ingresos, etc., proporcionan información sobre cómo está funcionando el negocio en el mundo real. Los cambios en el software que afectan al negocio también afectarán a este tipo de métricas.

A un nivel de resolución más preciso, cada característica y cada historia de usuario pueden tener su propia métrica de éxito, preferiblemente solo una, y una que esté directamente relacionada con una medida de valor entregada al cliente. Completar nueve de cada diez historias en un sprint para funciones que nunca se entregan es un desperdicio, no un éxito. Entregar historias que los clientes no quieren o no usan es un desperdicio, no un éxito. Entregar una historia que mejore algún aspecto de la felicidad del usuario es un éxito. Entregar una historia que demuestre que no mejora la participación del usuario también es un éxito, porque habrá aprendido algo que no funcionó, invalidó una hipótesis de negocio y liberó recursos para buscar otras vías.

Cómo formular una hipótesis de valor

Una hipótesis de valor es una declaración sobre lo que cree que sucederá como resultado de la entrega de una característica específica. La relación entre el software, el resultado deseado y las métricas forma la hipótesis de valor de la característica (o sistema, o historia, o actualización, etc.).). La hipótesis debe expresar cómo se espera que cambie la métrica objetivo, en qué marco de tiempo y en qué medida se considerará efectiva. Tendrá que hablar con el equipo y el propietario del producto, como mínimo, para averiguar lo específico que esta característica o historia pretende crear o mejorar con respecto al negocio para formular su hipótesis de valor. Es posible que tenga que preguntar «por qué» varias veces (como un niño de tres años) para retirar las capas de suposiciones no declaradas; sea paciente. Cuando entiendas lo que se supone que es el valor del negocio, puedes comenzar a hacer las preguntas que te llevarán a las métricas que responden a la pregunta.

Por ejemplo, una historia «técnica» para mejorar la velocidad de un proceso de pago de comercio electrónico puede tener como premisa subyacente que un pago más rápido conducirá a 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 (porque ese consenso está respaldado por datos de referencia), entonces la hipótesis de valor puede ser «Creemos que un proceso de compra más rápido resultará en una disminución de las tasas de abandono del carrito, lo que conducirá a mayores ventas y una mejor experiencia de usuario.»

Probablemente puedas asumir que a los usuarios les gustará un pago más rápido, pero no está de más preguntar si se han dado cuenta. Las tasas de abandono de carrito y las ventas se pueden medir antes y después de que el nuevo proceso esté en marcha, durante un período de tiempo. Si la tasa de abandono del carrito disminuye y las ventas aumentan (más allá de las fluctuaciones estadísticas), la evidencia respalda la hipótesis y podría considerar si se justifican mejoras de velocidad aún mayores. Si no lo son, deje que esta métrica se desvanezca en el fondo (o elimínela, si distrae) y dirija su atención a la siguiente hipótesis. Si la tasa de abandono del carrito disminuye pero las ventas no cambian, mida por un período de tiempo más largo o reconsidere el vínculo supuesto entre el abandono del carrito y las ventas. En otras palabras, use métricas para aprender, y solo mientras resulten útiles para impulsar mejoras.

En algunos casos, la hipótesis puede ser claramente incorrecta, por lo que eliminamos las métricas (¡y deshacemos los cambios de software!) después de unos días. En otros casos, la hipótesis puede ser correcta, por lo que continuamos impulsando mejoras en esta área durante años.

Seis heurísticas para el uso eficaz de métricas

Hemos visto cómo las métricas de software subjetivas importan mucho más para el éxito empresarial que las métricas de calidad tradicionales y objetivas de antaño. El esfuerzo necesario para encontrar y medir métricas de negocio relevantes para las características se ve compensado por los conocimientos y las oportunidades de aprendizaje obtenidas. Las condiciones y oportunidades de negocio cambian constantemente, por lo que en lugar de resumir una fórmula a seguir, que puede ser frágil, aquí hay seis reglas empíricas, o heurísticas, para ayudar a mantener el enfoque y la flexibilidad. ¡Que le ayuden a guiarlo en su viaje hacia un software de calidad y el éxito empresarial!

1. Las métricas no pueden contarte la historia; solo el equipo puede hacerlo (con una punta de sombrero para Todd DeCapula).
2. Comparar copos de nieve es un desperdicio.
3. Puedes medir casi cualquier cosa, pero no puedes prestar atención a todo.
4. Las métricas de éxito empresarial impulsan mejoras de software, no al revés.
5. Cada característica agrega valor; mídala o no la hagas.
6. Mida solo lo que importa ahora.