Cómo evaluar una prueba inestable
Cómo estimar una prueba inestable: por qué se necesitan dos estimaciones, y no una sola, y por qué es preferible fijar un plazo fijo antes que discutir sobre puntos cuando la respuesta depende de lo que se descubra.
Una prueba poco fiable consiste en dos estimaciones. Aún no sabe cuál de las dos es la correcta.
awaitUna de las versiones consiste en una corrección de una sola línea: una suposición sobre la sincronización, una dependencia en el orden de las pruebas, un elemento que faltaba. La otra versión supone tres días de investigación sobre una condición de carrera en el código de producción que, por casualidad, la prueba logró detectar. Cuando las tarjetas van del 2 al 13, el equipo no discrepa sobre la magnitud, sino sobre qué tipo de error es, que es lo que realmente se desconoce.
Hacer una estimación para averiguar cuál es la magnitud de algo, en lugar de hacerlo a posteriori, es lo que hace que esta historia acabe en el puesto 5 en la primera semana y en el 13 en la tercera. La solución no radica en una cifra más precisa, sino en un enfoque diferente del trabajo. Establezca un plazo para la investigación y, una vez se conozca el alcance, realice la estimación de la solución real.
Lo que se dice en la sala
Ingeniero A: «Si el problema se debe a lo que yo creo, esto es un 2».
Ingeniero B: «Si falla por la razón que yo creo, es un 13».
Titular: «¿Alguien lo ha ejecutado realmente de forma local con la semilla fijada?»
Pregunta: «Solo falla en la integración continua. Nunca en un equipo de desarrollo».
Preguntas que conviene plantearse antes de votar
- ¿Se reproduce el error en el entorno local o solo en CI?
- ¿Con qué frecuencia falla: 1 de cada 50, 1 de cada 5, cada dos veces?
- ¿Cuándo empezó a fallar? ¿En qué commit?
- ¿Es que la prueba da un resultado erróneo o está detectando algo real?
- ¿Hay alguien que lo esté desactivando mientras tanto, y a qué precio?
La diferencia entre el ingeniero A y el ingeniero B no es una discrepancia en cuanto a los puntos de historia que se pueda resolver promediando; es una incógnita que hay que investigar. Un «spike» breve y limitado la resuelve; una discusión más acalorada, no.
Asigne un plazo, no una solución. Medio día para investigar y, a continuación, un reportaje en toda regla sobre lo que se descubra.
Consulte «Estimación de un error sin reproducción» para ver un caso similar, y «Errores habituales en el Planning Poker» para estimar errores con precisión de característica. Eche un vistazo a los demás «Ejemplos prácticos de estimación», o «inicie una sesión gratuita de Planning Poker» cuando la investigación haya arrojado un resultado.