Desarrollo de métricas de calidad de software como científico de datos: 5 lecciones aprendidas

Esta lista es el resultado de mis propias reflexiones y consejos de mis colegas sobre el desarrollo de métricas de calidad de software. Las métricas de calidad del software son herramientas esenciales para garantizar que un producto brinde la mejor experiencia a sus usuarios. Tuve que desarrollar dichas métricas durante mi pasantía como gerente de programa. Viniendo a este mundo como un Ph.D. investigador y científico de datos era bastante complicado. Aquí están los consejos.

1. Los datos en el software no son normales
2. Las métricas de calidad del software deben medir cada paso
3. Las estadísticas son geniales, pero...
4. Comparte tu trabajo en progreso
5. Piensa en todos los usuarios

1 Los datos en el software no son normales

Lo primero que noté cuando comencé a ver cómo se mide la calidad del software fue la distribución de datos, es decir, la forma de los datos. Veamos cuánto se tarda en enviar un mensaje de un teléfono a otro, es decir, la latencia del mensaje.

Su intuición podría decirle que hay un tiempo estándar como 1 segundo, y luego algunas personas reciben los mensajes antes y otras los reciben más tarde. Esto sugeriría algo parecido a una distribución Normal (ver la imagen de arriba). Calcular una media podría parecer una buena métrica para medir la calidad si los datos de latencia estuvieran distribuidos normalmente.

Sin embargo, los datos en el software tienden a tener colas más largas en el lado derecho. Considere el ejemplo del mensaje. La mayoría de los mensajes se entregan al receptor en menos de 1 segundo. Aún así, algunos de ellos pueden tomar más tiempo y los tiempos específicos pueden variar de 2 segundos a 24 horas. Dichos datos podrían seguir la distribución de Pareto (diferente de la regla 80/20 o un Principio de Pareto) bien conocida en las aplicaciones de control de calidad.

¿Podemos usar este hecho en el desarrollo de métricas de calidad del software?

Pensar en la distribución de Pareto dirige nuestra atención a la cola y a considerar a todos nuestros usuarios, incluidos los desafortunados. Por lo tanto, nos enfocamos en las experiencias de usuario menos probables en lugar del medio correspondiente a una experiencia más probable.

Esto significa que calcularíamos percentiles o cuantiles más altos en lugar de calcular la latencia media del mensaje. Por ejemplo, el percentil 95 describiría la peor experiencia medida para el 95 % de todos los usuarios. Entonces podemos evaluar si eso es aceptable.

Recomendaría este video para aclarar:

https://www.youtube.com/watch?v=IFKQLDmRK0Y

2 Las métricas de calidad del software deben medir cada paso

Cuando se trata de la calidad del software en el contexto de la gestión de productos, es fácil pensar principalmente en el front-end. Las partes específicas del front-end impactan claramente en la experiencia del usuario.

Después de todo, es lo que el usuario puede ver e interactuar. Sin embargo, las métricas de calidad del software para el back-end no deberían ser una ocurrencia tardía. Centrarse en partes individuales del back-end puede llevarlo a descubrir oportunidades para mejorar la velocidad de los procesos. Como probablemente sepa por su propia experiencia como humano que usa tecnología, odiamos esperar, por lo que las mejoras de velocidad son buenas.

3 Estadísticas es genial, pero...

Lo sé. Esto suena extraño viniendo de mí después de que el punto más largo de esta historia es sobre estadísticas. Eso debería decirle lo difícil que fue la transición de un contexto académico a uno empresarial y de la ciencia de datos a la gestión de productos.

Cuando comencé a desarrollar las métricas de calidad del software durante mi pasantía, traté de encontrar formas de medir la calidad del software que fueran computacionalmente eficientes, pero precisas. No pude evitarlo.

Luego le mostré esto a mi colega, y mientras le explicaba cómo funcionaría, me detuvo y me pidió que reflexionara sobre cuánto tiempo lleva explicar qué es. Tuve que preguntarme, ¿es mi propuesta mejor que los enfoques más estándar en todos los aspectos? Fue súper divertido para mí tratar de desarrollar algo nuevo. Sin embargo, luego estaba el aspecto de la comunicación. ¿Tendrá esto sentido para la alta dirección?

No quiere decir que no pueda usar estadísticas y cálculos más complejos en los negocios, pero incluso la navaja de Occam nos enseña a preferir lo simple a lo complicado. Los complicados algoritmos para estimar la calidad del software pueden ser geniales de desarrollar, pero son inútiles cuando la mayoría de las personas no entienden el resultado.

Si alguien te pide que pintes un retrato, no esperará un cuadro de Picasso.

4 Comparte tu trabajo en progreso

Fue sorprendente ver lo fácil que fue colaborar con las personas y cuánto valor aportaron al proceso general. En la mayoría de los sistemas escolares del mundo, a menudo se le evalúa según sus resultados individuales. Hay algunos proyectos de colaboración aquí y allá, pero la mayoría de nosotros aprendemos a confiar en nosotros mismos.

Si alguna vez ha tratado de aprender algo difícil, sabe que la mejor estrategia es seguir adelante e intentarlo hasta que lo haga bien. Esta perseverancia a veces puede obstaculizar nuestro progreso para hacer las cosas porque es posible que no pensemos en la colaboración como una herramienta.

Sorpresa sorpresa; las empresas quieren lograr los resultados lo antes posible. Aprovechar el conocimiento de sus colegas y recopilar comentarios sobre sus primeras ideas es la mejor manera de generar métricas de calidad de software que estén bien definidas y sean útiles en la toma de decisiones.

5 Piensa en todos los usuarios

Las métricas de calidad del software pueden medir diferentes capas de calidad. Podemos dirigir la atención hacia la función del producto, la experiencia del usuario pero también los aspectos técnicos. El software es complejo y, muy a menudo, los usuarios del producto o los clientes finales no son los únicos usuarios en los que debe pensar. Si está trabajando en un servicio de back-end, las personas que trabajan en el front-end son sus usuarios.

Por lo tanto, sus métricas de calidad de software deben considerar sus grupos de usuarios y qué tan lejos están de la pieza de software en la que está trabajando. Considere cuál es el impacto en los grupos de usuarios específicos cuando su métrica muestra un rendimiento mejorado o empeorado.

Métricas de calidad de software y ciencia de datos

La gestión de productos y la ciencia de datos tienen algunas superposiciones, y una de las más importantes son las métricas para la calidad del software. Si está pensando en cambiar su carrera de ciencia de datos, asegúrese de elegir las herramientas adecuadas de su caja de herramientas de ciencia de datos.

Como científico de datos, generalmente se enfoca en la codificación y las estadísticas, y la buena comunicación es una gran ventaja. Cuando trabaja como gerente técnico de productos o programas, la importancia de esas habilidades se invierte y la comunicación y la colaboración se vuelven cruciales.

Si se encuentra desarrollando métricas de calidad de software, también le recomendaría leer sobre el enfoque SixSigma crítico para la calidad .

¡Buena suerte!