¿Deberían reabrirse los tickets de error/regresión o crearse nuevos tickets?

Pregunta

Esta es una paradoja que tengo: cuando creo problemas de GitHub (o tickets de JIRA, o cualquier rastreador de problemas que use), a mis ingenieros les gusta hacerlos muy granulares, de modo que reduzcan el alcance para ellos. Pero al mismo tiempo, cuando entrego trabajo a los clientes y se quejan de errores de regresión, puedo abrir nuevos problemas o simplemente reabrir los antiguos (el primero es el enfoque granular, el segundo es el enfoque más simple de administrar) .

¿Qué enfoque es mejor? Resumiré los pros y los contras de los enfoques que estamos considerando.

Nuestro enfoque granular

Pro

Reduce el alcance más para los desarrolladores. Especialmente útil cuando realiza una compensación basada en la entrega, ya que limita el riesgo para los desarrolladores.

Estafa

Hace que el seguimiento de todos estos problemas sea más difícil, especialmente cuando se informa el progreso a los clientes. Por ejemplo:

  1. El error 324 estaba cerrado.
  2. Abrimos 452 como una regresión sobre 324.
  3. 452 fue arreglado.
  4. Abrimos 563 como otra regresión en 324, y está en progreso ahora mismo.

Nuestro enfoque más simple de administrar

El enfoque más fácil de administrar es simplemente lo opuesto al enfoque granular descrito anteriormente.

No es una respuesta a su pregunta, pero un buen enfoque al corregir errores es producir siempre una prueba de regresión automatizada para cada error antes de comenzar con la corrección. De esa manera, una vez que se haya solucionado el error, la prueba de regresión pasará. Luego puede ejecutar su conjunto de pruebas de regresión para verificar automáticamente que todos los errores corregidos no hayan regresado antes de realizar un lanzamiento. Esto reduciría su problema de seguimiento de errores, ya que reduciría las posibilidades de que un error se repita.

Respuestas (2)

TL;RD

Tiene un problema X/Y creado al omitir el análisis del problema del proceso a favor de un enfoque basado en herramientas. Los problemas de JIRA y GitHub son herramientas, no procesos, por lo que hasta que defina completamente el flujo de su proceso, seguirá estando en desventaja.

Debe definir qué está rastreando, por qué lo está rastreando y cómo utilizará los datos de rastreo para hacer visible el trabajo. Siempre que el equipo y la organización estén de acuerdo en cómo se hace esto y qué se está comunicando, cualquier enfoque puede funcionar.

Como regla general, solo se deben volver a abrir los boletos cerrados incorrectamente o prematuramente. Todos los demás trabajos representan un trabajo nuevo con su propio alcance.

¿Qué estás rastreando?

Está confundiendo "seguimiento de problemas" con "seguimiento de trabajo". Nunca son lo mismo, aunque ciertamente pueden estar interrelacionados. Reabrir tickets o crear nuevos realmente depende de lo que está tratando de rastrear y cómo planea usar las métricas.

Debe esforzarse por asegurarse de que su proceso se ajuste a una de las leyes de CodeGnome: "¡Ningún trabajo invisible, nunca!" Cualquiera que sea el enfoque que adopte, debe quedar claro qué trabajo está en progreso y cuánto esfuerzo implica. El estado del trabajo debe ser claramente visible y el proceso debe permanecer transparente para las partes interesadas.

Entradas nuevas

La apertura de nuevos tickets garantiza que todo el trabajo nuevo o reelaborado se trate como un elemento de seguimiento de primera clase. En particular, evita que la repetición del trabajo (ya sea por errores o desarrollo iterativo) quede oculto como trabajo invisible dentro de los tickets reabiertos, o que herede estimaciones de tiempo/esfuerzo heredadas que no se aplican al trabajo actual requerido.

La mayoría de los sistemas de emisión de boletos, incluidos los problemas de JIRA y GitHub, permiten que los boletos hagan referencia o se vinculen con otros boletos. Cuando sea posible, siempre recomiendo que a cualquier trabajo nuevo o reelaboración se le asigne un nuevo ticket y una nueva estimación, y luego se vincule a cualquier ticket heredado que pueda estar relacionado.

Boletos Reabiertos

Si bien puede haber otros argumentos razonables, desde una perspectiva ágil, un ticket solo debe reabrirse cuando resulta que el cierre fue prematuro porque el trabajo en el ticket no cumplió con la "Definición de Listo".

Si un ticket cumple con la definición de Listo del equipo, pero luego se encuentran regresiones o los requisitos han cambiado, entonces este es un trabajo que no estaba dentro del alcance del ticket anterior. El billete estaba debidamente cerrado; los errores o el alcance adicional representan un esfuerzo adicional requerido por parte del equipo para alcanzar un nuevo objetivo.

Ejemplos

Si bien no es exhaustivo, aquí hay un par de ejemplos simples para ayudarlo a pensar en la diferencia funcional entre el trabajo nuevo y el trabajo incompleto.

  1. Se cerró un ticket para embiggenar un widget como completo, pero no se realizó la prueba de integración. Este ticket se debe reabrir y se deben realizar los elementos restantes de la Definición de Terminado.
  2. Un ticket para reducir un dongle para que se ajuste a un nuevo widget de Model B se cerró como completo después de cumplir con la definición de Listo. Sin embargo, nadie se dio cuenta de que el dongle necesitaba bordes fresados ​​para adaptarse al nuevo modelo. Este cambio de especificación es un trabajo nuevo, y el trabajo debe tener un nuevo ticket aunque el ticket se pueda vincular a la historia "Prototipo del widget del modelo B".
  3. Se agregó una función de cosquillas al cliente a su producto. Sin embargo, el 12 % de sus clientes mueren por pinchazos oculares con las púas de las plumas, y el equipo de ventas clasificó este problema como un error de baja prioridad. Localizar y resolver el origen del error es un trabajo nuevo que requiere un nuevo ticket y debería convertirse en un elemento de seguimiento de primera clase. Luego, el Product Owner (o un rol de proyecto similar) debe priorizar adecuadamente este ticket y programarlo en consecuencia.

Los boletos solo deben reabrirse cuando no deberían haberse cerrado en primer lugar. Todos los demás trabajos representan un trabajo nuevo con un nuevo alcance y deben tratarse en consecuencia.

buena respuesta ... aunque se refirió a algunas leyes creadas por usted mismo (y aparentemente solo se refirió a usted ... pero seguiré con eso ... tiene sentido y agrega mucho valor :)
sin mencionar el uso de su propio vocabulario .. jajaja

La respuesta a esta pregunta es simple: gestiona su trabajo al nivel de descomposición/abstracción necesario para gestionar su trabajo.

Esta es una ecuación de más/menos. Por un lado, al mantenerlo en el nivel más alto, aumenta la capacidad de flexibilidad en el trabajo y ahorra una tonelada de dinero en seguimiento y control. Pero, por otro lado, al mantenerlo en el nivel más alto, aumenta el riesgo de perder valiosos indicadores de degradación del desempeño laboral, ya que esos indicadores quedarán enmascarados en el resumen del desempeño.

Elija cuidadosamente.

usaste "lo mantienes en un nivel más alto" dos veces... ¿puedes arreglar eso?
Hice eso a propósito. Mostré tanto una ventaja como una desventaja por mantener el trabajo en un nivel más alto de abstracción. Inherente a eso está el más y el menos para descomponer el trabajo, es decir, el efecto contrario.