¿Deberían reabrirse los casos por errores, o deberían abrirse los errores como un caso nuevo?

Actualmente en mi lugar de trabajo utilizamos FogBugz para administrar todas nuestras funciones y errores para nuestras diferentes aplicaciones web.

Cuando se agrega una nueva función a una de nuestras aplicaciones web, se crea un nuevo caso. Por ejemplo, "Crear formulario de carga CSV".

Luego trabajo en el caso registrando la cantidad de tiempo que he dedicado. Una vez que se completa este caso, lo resuelvo y se lo asigna nuevamente al abridor de casos (generalmente el gerente del proyecto), quien luego cierra el caso.

Si hay algún error con la función, mi Gerente de Proyecto vuelve a abrir el caso y me lo devuelve con una lista de errores.

En mi opinión, creo que estos errores puntiagudos deben abrirse como casos de errores individuales, para que puedan rastrearse más fácilmente y no saturarse con las notas de casos de características originales.

Mis gerentes no están de acuerdo conmigo porque afirman que es más fácil calcular el tiempo total dedicado a la función, si es todo en un caso.

Además, creen que es menos confuso para nuestros clientes, ya que solo tienen 1 referencia de número de caso para la función. Sin embargo, destacaría que los errores deben tratarse como casos separados, ya que esto es posterior a la finalización del caso original.

¿Estoy en lo cierto al afirmar que los errores deben reabrirse como un nuevo caso? ¿Y cuáles son las ventajas y desventajas de cada forma de gestionar esto?

Tanto usted como su gerente tienen buenas razones para tratar la forma en que cada uno de ustedes prefiere, y no hay necesidad real de comprometerse. Hay una solución que funciona para mí y aborda ambas preocupaciones.

Para casos como el suyo, uso el enfoque de tareas de alto nivel / subtareas de bajo nivel (concepto que elegí de JIRA , no puedo decir si FogBugz lo admite explícitamente ^{parece que lo hace} ). De esta manera, las listas con viñetas "orientadas al cliente" van a tareas de alto nivel, mientras que las "iteraciones del desarrollador" que son importantes para mí se reflejan en subtareas.

Cuando la tarea de alto nivel se "vuelve a abrir", creo una nueva subtarea para rastrear el esfuerzo adicional por sí mismo .

De esta forma, el desarrollador puede reflejar claramente todas las permutaciones, perversiones y giros que se pasan por la especificación de características, y aún así permite al gerente presentarlo a los clientes como si fuera perfecto. Por cierto, la presentación como si fuera perfecta tiene su valor para mí como desarrollador, porque tenerla más fácil de leer para los clientes ayuda a obtener ajustes más precisos.

Naturalmente, esto también permite tener una justificación clara en los casos en que la implementación de características lleva mucho más tiempo del previsto originalmente.

_{En cuanto al seguimiento del tiempo por tarea o subtarea, dado que JIRA permite incluir el seguimiento de subtareas en un resumen de nivel superior, es aceptable para el gerente que yo haga un seguimiento del tiempo en las subtareas. Sin embargo, incluso si este no fuera el caso, podría vivir con un tiempo de seguimiento formal en la tarea "principal"; en este caso, solo usaría comentarios de subtareas para indicar cuánto tiempo se ha dedicado a una iteración particular.}

Si todo esto sucede antes de que la función se lance al cliente, solo tiene un caso. El argumento aquí es que el caso no está realmente completo hasta que haya pasado el control de calidad y esté listo para ser lanzado. Los otros beneficios: un número de caso único para que los usuarios finales de facturación y referencia sean válidos e importantes.

Una vez que se ha lanzado la función y se han encontrado errores, estos deberían aparecer como nuevos problemas en su software de seguimiento de problemas.

Estoy completamente de acuerdo con usted, y también lo hace FogBugz, es por eso que define diferentes categorías para errores y características. FogBugz no fue diseñado para ser una herramienta para rastrear el uso del tiempo; Este es un subproducto accidental de la introducción de la programación basada en la evidencia.

Los errores de una función completa pueden vincularse con el caso principal de la función (en FogBugz, mediante el uso de un nombre de etiqueta o una referencia cruzada, o haciéndolos sub-casos). Puedo ver que este es un poco más de trabajo para su PM para consolidar la información en varios casos, pero a menudo también tiene sentido poder separar el tiempo dedicado al desarrollo original y el tiempo dedicado al mantenimiento, especialmente para contratos de precio fijo, y pierdes la capacidad de hacer esto si pones todo en un caso.

Es mi opinión que una vez que se cierra un boleto, debe permanecer cerrado, su rastreador de errores debe ser capaz de vincularse a otros casos de todos modos. Intentaría señalar que crear nuevos errores y vincularlos al caso original proporciona mejores beneficios que el método que usted describe.

• Los clientes aún pueden tener un número de referencia que contiene enlaces a cada error.
• el estado de cada error se puede rastrear individualmente, lo que permite una mejor priorización e informes de estado.
• tener errores separados le permitirá al administrador desglosar el tiempo dedicado a los errores frente al tiempo dedicado al desarrollo de nuevas funciones, y solo debe ser un esfuerzo adicional mínimo para obtener un número total de todos los errores relacionados con un cambio y el desarrollo de ese cambio.
• la separación de errores hace que sea mucho más fácil para su gerente recopilar otras métricas como errores totales, tiempo promedio por corrección de errores, proporciones de errores cerrados / en progreso / corregidos.
• casos separados por error permite que las tareas se dividan mejor entre todos los desarrolladores y responsabilicen a cada uno por su propio trabajo, o permite esta posibilidad en caso de que se contraten más desarrolladores en una fecha posterior.

La única ventaja de su configuración actual es que es extremadamente simple para las personas que no son los principales usuarios del sistema. El propósito de un rastreador de errores es que el desarrollador tenga un lugar para informar todo sobre un error en un solo lugar que también sea lo suficientemente amigable para que otros vean el progreso, su sistema actual parece socavar casi todas las partes de eso.

¿Se encuentran los errores antes o después de que el producto haya sido 'enviado / lanzado' a los clientes?

Si es antes de un lanzamiento, los errores deben rastrearse contra el ticket original.

Si es después de un lanzamiento, cada error debe ser su propio boleto.

Donde trabajo, solo las personas de QA pueden cerrar un caso. Tenemos casillas de verificación para Código revisado, Probado por ingenieros y Demostración a partes interesadas (en su caso, Gerente de proyecto). Si el equipo de control de calidad ve un caso marcado como "Listo" que no tiene todos estos campos marcados, lo marcarán como deshecho y nos lo enviarán.

Una vez que un caso ha pasado todas estas fases y QA cierra el caso, cualquier problema nuevo que encuentre se registra como error.

Este sistema parece funcionar bien para nosotros.

Creo que puedes hacer una discusión en ambos sentidos. Trataría de sentarme con el primer ministro y explicarle por qué cree que tener problemas discretos lo ayudará. Personalmente, quiero que cada elemento de tarea sea su propio boleto, pero puedo ver por qué lo quiere de esa manera.