¿Deberían los defectos tener puntos de historia en Scrum?

7

Hasta donde sé, utilizamos puntos de historia para medir la complejidad de una historia en Scrum .

Pero ¿qué pasa con Defecto ? ¿Debería Defecto tener puntos de historia? Si lo hace, ¿qué significa completar estos puntos, dado que un Defecto no tiene valor comercial como una historia? ¿Deberíamos tener algo diferente de los puntos de la historia, por ejemplo, puntos de defecto?

    
pregunta hackjutsu 16.10.2015 - 20:34

7 respuestas

15
  

[...] dado que un Defecto no tiene valor comercial como una historia?

No estoy de acuerdo con esto. Como usuario, quiero que mi producto de software funcione y se comporte según lo previsto. Un defecto conocido va en contra de esto. Acumule e ignore los defectos suficientes y, tarde o temprano, sus clientes dejarán de usar su producto y, en su lugar, utilizarán los de otra persona.

Esto es algo conocido como retenido ingresos 1 , que incluye a los clientes que se irían si no se hace algo que el cliente quiere o necesita. Esto se menciona a menudo en términos de características, pero también puede incluir defectos. (¿Puede decir honestamente que su producto tiene alguna característica X si dicha característica está dañada? No lo creo).

Dado que se asume que cuando una característica o historia se acepta como "terminada" funciona como se esperaba, es perfectamente válido crear otra historia y estimarla de la misma manera que lo hace normalmente, especialmente si el defecto es descubierto por el cliente (s) después de la liberación. Si se sabe que el defecto anterior se ha liberado, tal vez el Propietario del producto debería haber rechazado el estado "terminado" de la historia y haberlo vuelto a "En curso" o un estado equivalente, pero no llamar "hecho".

  

Si tenemos algo diferente de los puntos de la historia, por ejemplo,   puntos de defecto?

No. Solo trátelo como cualquier otra historia en el registro de su equipo con una estimación de tamaño por su esfuerzo / complejidad y una prioridad que es relativa a otras historias.

Dado que los defectos son un ejemplo de "deuda técnica", y los errores se vuelven más costosos para solucionar a medida que más se retrasa su resolución después de ser descubiertos, el equipo y el P.O. Debería considerar dar a los defectos una prioridad ligeramente más alta. Lo que use para determinar esta prioridad (por ejemplo, visibilidad, molestia del cliente, ¿algo más?) Debe estar a la altura de su equipo.

Sólo mis 2 centavos.

1 Estimación y planificación ágiles, por M. Cohn

    
respondido por el code_dredd 16.10.2015 - 20:45
6

Argumentaría que un defecto representa una característica anterior que no se ha completado adecuadamente. Por lo tanto, la reparación de defectos no tiene puntos de historia.

Si aplica puntos de historia a los defectos, su índice de grabación se ve excelente "Completamos 20 puntos de características de este sprint", pero, 10 de esos puntos fueron correcciones de errores, por lo que su ritmo real de progreso es solo 10 en este sprint .

Ahora, no estoy abogando por corregir todos los errores en el sprint inmediatamente después del descubrimiento. Algunos errores simplemente no son tan críticos. Pero no "complete" una característica de 5 puntos, entonces el siguiente sprint le hará otros 5 puntos de correcciones de errores: enmascara la estimación errónea, la codificación incorrecta o ambas.

    
respondido por el mcottle 24.11.2015 - 02:16
2

Mi equipo puso puntos de historia en cualquier defecto identificado después del sprint en el que se completó la historia. Si se encuentra el defecto durante el sprint en el que se desarrolla la historia, consideramos esos errores de aceptación y formamos parte de la estimación original de la historia.

    
respondido por el jarmenia_accusoft 23.11.2015 - 18:44
1

Si está vinculando correctamente defectos a sus historias de usuario (ya sea directa o indirectamente), entonces debería tener rastreabilidad hacia atrás. Así que los puntos de la historia que son afectados por el defecto son su referencia. A partir de eso, si ya ha estimado la complejidad / tamaño / esfuerzo de cada punto de la historia que puede ayudarlo a estimar la complejidad / tamaño / esfuerzo del defecto.

    
respondido por el Andarta 16.10.2015 - 21:05
1

He estado en un par de equipos de scrum en los que hemos debatido esto, pero en última instancia, he llegado a la conclusión de que los defectos deben ser historias apuntadas como historias. La razón es el propósito por el que estamos usando los puntos de la historia: para medir la cantidad de puntos de historia completados en cada carrera, podemos obtener una métrica aproximada de la capacidad del equipo, cuánto trabajo puede completar el equipo en una carrera.

Si un defecto es lo suficientemente significativo como para quitar los recursos de desarrollo de otras historias, debe apuntarse y calcularse en la capacidad de su equipo para el sprint. Siempre he encontrado que una vez que el esfuerzo de prueba entra en la discusión, que a menudo incluye la escritura de pruebas de unidad / integración perdidas, siempre termina siendo un trabajo suficientemente significativo como para señalarlo. Si el error es tan ridículamente pequeño y no se requiere un esfuerzo real de prueba, siempre se le puede dar cero puntos de historia.

    
respondido por el Erik 24.11.2015 - 02:01
1

Los puntos de historia representan el valor comercial y la velocidad que un equipo puede alcanzar dentro de un sprint. Sí, en cierto sentido, el error de corrección tiene un valor comercial, pero si demuestra una capacidad de alta velocidad simplemente porque pone puntos de historia en defectos, su equipo descuidará la Garantía de calidad.

Por ejemplo, si un equipo tiene una velocidad óptima de 30 puntos de historia para la planificación de un sprint y después de su preparación, se dan cuenta de que solo pueden comprometerse con 20 puntos de historia debido a errores priorizados por el propietario del producto. Luego levanta una bandera para aumentar el control de calidad / gestión y el objetivo de reducir la cantidad de defectos.

El departamento de ingeniería necesita reaccionar, ajustar y solucionar cualquier problema cuando se note una disminución en la velocidad.

    
respondido por el QA Goods 24.11.2017 - 15:44
0

Tienes que asignar puntos de historia, de lo contrario no tienes forma de medir con precisión la velocidad de los equipos.

Si obtienes 50 puntos en un sprint, pero estás trabajando en 10 puntos de errores, tu velocidad solo sería 40. ¿Cómo explicarías esto en la próxima planificación de sprint?

    
respondido por el Karl Gjertsen 24.11.2015 - 07:00

Lea otras preguntas en las etiquetas