Estados de defectos: "NO ARREGLAR" frente a "Cancelado"

13

He estado involucrado en varios proyectos, ya sea como probador o desarrollador. En muchos proyectos hubo los siguientes estados para defectos:

NO SE ARREGLARÁ
Cancelado

¿Utiliza tales estados y cómo los difiere? Pregunto, porque la mayoría de la gente no puede explicar la diferencia. Mi entendimiento es:

NO ARREGLAR : el desarrollador no reparará el defecto, ya que no es un defecto;
Cancelado : el defecto no debe repararse debido a la prioridad más baja

tools issue-tracking

— sergionni
fuente

12

Como otros han señalado, estos nombres de estado no son muy claros. Preferiría nombres de estado más precisos y detallados:

No se arreglará (el costo de arreglar esto no está justificado)
Solución provista (y es suficiente para hacer felices a los usuarios)
No es un error (sino una característica)
No reproducible
Duplicar

— Péter Török
fuente

Solución provista, es algo nuevo, se conocen otros estados

— sergionni

1

"Arreglar en una versión posterior" puede ser otro estado útil. Por lo general, lo usamos cerca del final del período de desarrollo, porque no tenemos el tiempo o los recursos para solucionarlo (aunque nos gustaría). Hasta que se solucione, se notificará a los clientes a través de un SVA (evaluación de vulnerabilidad de software). Deshacerse de ese SVA, nos da un incentivo adicional para solucionarlo en la próxima versión.

— Sparky

es posible que sólo cambiar la versión de la tarea en Jira en lugar de utilizar "Fix en la versión posterior" status

— sergionni

6

Creo que tienes las respuestas al revés

No se solucionará : se aplicaría a un error menor que no afecta o puede estar en una versión anterior, por lo tanto, no vale la pena el costo de los desarrolladores para solucionarlo, pero reconocen que es un error.

Cancelado : esto podría ser un informe de error incorrecto si no es reproducible o puede no ser un error en absoluto.

yah Pensé que "cancelar" se aplicaría cuando el "arreglo" estaba en desarrollo pero no se completó porque en la segunda revisión se descubrió que no era necesario (ya sea porque la sección completa del código fue reemplazada por otra o porque se encontró no ser un problema) "No se solucionará" puede significar que decidió que no es un problema o que es tan pequeño que no vale la inversión necesaria para solucionarlo.

— Jwent

5

Tomando sus 2 descripciones:

NO ARREGLAR : el desarrollador no reparará el defecto, ya que no es un defecto;

Cancelado : el defecto no debe repararse debido a la prioridad más baja

Es obvio que la diferencia prevista es:

NO SE ARREGLARÁ : no está roto, intencionalmente pensamos para este comportamiento (por ejemplo, la característica no es un error);

Cancelado : aceptamos que está roto, pero es tan trivial / inconsecuente que nunca nos molestaremos en arreglarlo.

— Dan McGrath
fuente

En realidad, no hay estado "no es un error", también, que se cierra a su "no van a resolver el" comportamiento

— sergionni

Estas descripciones tienen tanto sentido si las invierte: "El boleto se canceló porque no es un error", "No lo arreglaremos porque es trivial"

— Kevin Laity

@ Kevin, estoy completamente de acuerdo. Yo diría que en realidad tienen más sentido cuando se invierten. Respondí basándome únicamente en la información de la pregunta.

— Dan McGrath

1

En mi empresa no utilizamos tales estados y creo que no son una buena opción de etiquetado para los estados que usted describió.

Nuestros estados consisten en

Nuevo
en progreso
Listo para probar
Cerrado
Reabierto

Y los estados deberían ser así de simples. Cualquier cosa más detallada como si fuera un error o si es una prioridad demasiado baja debe colocarse en una nota.

— Tim
fuente

1

La cancelación parece implicar que se inició una solución pero luego se detuvo, tal vez porque resultó necesitar más recursos de los que originalmente se pensaba y más de lo que justifica el defecto o que la persona que ingresó el ticket de defecto cambió de opinión acerca de que se trata de un defecto. No se solucionará parece que hay un acuerdo de que existe un defecto, pero que hay una razón para no querer arreglarlo en este momento (costo versus beneficio, impacto potencial en otras funciones, etc.).

— Jason
fuente