Como se dijo muchas veces antes ( 1 , 2 , 3 ):
"No estime errores/defectos".
Sé que en Scrum tratamos de minimizar la tasa de defectos, pero sucede de vez en cuando. Arreglar tales tareas no estimadas podría tener grandes efectos en la velocidad real del equipo. Me pregunto si hay algún tipo de procedimiento o fórmula para que esto sea visible para el equipo y para los demás.
¿O es solo que un aumento en la tasa de defectos (= caída de la velocidad) es una señal de que debemos prestar más atención a nuestro control de calidad?
Como no estimamos errores, esta no es un duplicado de esa pregunta: Puntos de seguimiento gastados en errores durante el sprint
Si está midiendo un proyecto de larga duración con velocidad para tener una idea de cuándo se alcanzarán las características o los hitos, es una buena idea no estimar los defectos. Los defectos son trabajos que deberían haberse completado en otros puntos ya en el pasado. Si tiene muchos defectos ahora, probablemente tendrá la misma cantidad en el futuro, lo que ralentizará todo su proyecto. Daría una falsa sensación de velocidad si proporciona puntos de historia de trabajo no valiosos. La velocidad baja cuando tienes defectos o deudas técnicas .
Un aumento en los defectos o una disminución en la velocidad siempre debe resultar en un buen análisis de causa raíz durante una retrospectiva para encontrar formas de prevenir errores similares o mejorar el proceso. Si la causa es realmente su proceso de control de calidad, es algo que debe averiguar, ya que depende en gran medida de la situación.
Algunas métricas que me gusta usar para señalar problemas:
Estos deberían ser bastante estables o subir/bajar, dependiendo de la métrica.
Ahora, por experiencia, la causa raíz de la mayoría de los defectos no suele ser la falta de un proceso de control de calidad, sino una arquitectura o diseño que tiene muchas dependencias acopladas, lo que dificulta el mantenimiento y la ampliación de la base de código. A menudo es difícil crear una automatización de prueba para él y, por lo tanto, es difícil refactorizarlo y limpiarlo. Siempre sugiero ver el primer episodio de Clean Code para tener una idea de los problemas comunes con el código.
ppasler