2011-01-17 24 views
71

Puede volver a abrir un problema resuelto y cerrado en JIRA. ¿Cuál es la diferencia práctica? (además de requerir diferentes permisos para resolver/cerrar problemas, por ejemplo, si está involucrado el control de calidad)JIRA: ¿cerrar o resolver?

Tenemos algunas diferencias de opinión en nuestro equipo sobre si resolverlas o cerrarlas, y me gustaría señalar algo de autoridad y decir "nosotras" debería hacerlo de esta manera ".

+1

Esta cuestión parece ser fuera de tema, ya que es sobre el uso de JIRA – John

Respuesta

61

El flujo de trabajo de problemas típicos es que la persona que trabaja en el error lo resuelve, y la persona que abrió el error es quien decide si la resolución es aceptable. Si es así, lo cierran. Si no, vuelven a abrir el error para una discusión/trabajo/disputa adicional.

La excepción a esto es cuando un error es un duplicado, a menudo la persona que está trabajando en el error se da cuenta de que es un duplicado, y luego puede cerrar el error como un duplicado. O quizás lo resuelvan como un duplicado, el abridor lo acepta y lo cierra.

IIRC, JIRA tiene un flujo de trabajo bastante flexible (aunque complicado), por lo que puede configurar cualquier proceso que considere apropiado para su equipo y los grupos que enviarán problemas.

Editar: me di cuenta que en realidad no dirijo reabrir temas cerrados. En mi experiencia, a menudo no sucede porque las personas buscan en el sistema de problemas errores existentes que muestran el mismo comportamiento que lo que están viendo. Y eso si tienes suerte, con frecuencia los errores se abren sin ninguna investigación sobre los problemas existentes.

Una vez dicho esto, un miembro del personal de control de calidad o irá "Recuerdo ese error. Maldita sea, dijeron que lo arreglaron" un tiempo después de que el propietario original lo cerró. En este punto, pueden volver a abrir el error anterior o crear uno nuevo y vincularlo al original. Mi preferencia es que haya un nuevo error y que se enlace, en lugar de volver a abrirlo. La razón es que el "nuevo" problema puede exhibir el mismo comportamiento, pero podría tener una causa completamente diferente. Este suele ser el caso cuando los mensajes de registro de errores realmente genéricos se escupieron.

16

La forma en que lo hacemos, en contra de nuestros clientes externos, es cuando le hemos cobrado al cliente que cerramos el incidente (esto puede ser un problema o una tarea SED), hasta entonces, el incidente simplemente permanece resuelto.

Creo que no debe volver a abrir un incidente cerrado, ese es el libro, mientras que un incidente resuelto puede volver a abrir.

Por cierto, sería bueno leer lo que ITIL dice sobre esto. Como se ha dicho en este page:

Reglas para la reapertura de incidentes

A pesar de todo el cuidado adecuado, habrá ocasiones en que los incidentes se repiten a pesar de que se han cerrado formalmente. Debido a estos casos, es aconsejable tener reglas predefinidas sobre si y cuándo se puede volver a abrir un incidente. Podría tener sentido, por ejemplo, acordar que si el incidente se repite dentro de un día hábil, puede volver a abrirse, pero que más allá de este punto debe plantearse un nuevo incidente, pero vinculado a los incidentes anteriores. El umbral de tiempo/las reglas exactas pueden variar entre organizaciones individuales, pero deben acordarse y documentarse reglas claras y debe brindarse orientación a todo el personal de Service Desk para que se aplique uniformidad.

+0

1 por citar ITIL. –

+0

+1 para dar enlace a ITIL. Un montón de información con respecto a la organización del flujo de trabajo. Justo lo que necesitaba. –

40
  • resolver es por lo general "listo para la prueba"
  • cerrado es por lo general "Funcionó"

También puede querer ver this blog post para más detalles acerca de cómo JIRA utiliza los estados resueltos/Cerrado y el campo de resolución del sistema.

+1

corto y al grano :) – dokaspar

+0

Después de leer la mayoría otra respuesta, esta era la mejor manera de entender! – kirtan403

4

Usted (por lo general) no puede editar ni Registro de tareas en contra de un tema cerrado, y usted debe tener esto en cuenta.

Mi consejo es: sólo probadores Cerrar

+0

Aunque puede cambiar el flujo de trabajo para permitir la edición de problemas cerrados. – mdoar

0

Por lo general, Dev/recurso debe resolver y único reportero puede cerrar.