¿Cómo maneja los crecientes montones de problemas que se resolverán "en algún momento"?

Estamos utilizando JIRA para realizar un seguimiento de los problemas en nuestros proyectos de software. Un efecto que notamos es que a menudo creamos un nuevo problema, pero aún no sabemos cuándo / si el problema se solucionará en absoluto. Así que inventamos un hito falso de 'Futuro distante' al que se asignan estos problemas.

Como sucede, la pila de problemas asignados a este hito sigue creciendo todo el tiempo, por lo que parece que este no es un buen enfoque. Hay tantos de ellos en este momento que se hizo bastante trabajo revisarlos para verificar su validez. Algunos de ellos dejaron de ser válidos ya que el componente con el que están relacionados fue eliminado. Algunos de ellos fueron duplicados por otros problemas. Algunos de ellos tienen una descripción tan pobremente redactada que ya nadie sabe de qué se trata.

¿Cómo tratan otros equipos de desarrollo de software los problemas que son válidos, pero que podrían no solucionarse en ningún momento? ¿Te molestas en grabarlos? ¿Los asigna a la próxima versión planificada y luego los mira nuevamente a medida que se acerca el próximo lanzamiento? ¿Algo más?

Estos son buenos errores de primer contacto para corregir los nuevos desarrolladores que acaban de unirse a su empresa. O para que los desarrolladores junior gasten su conocimiento del sistema.

De lo contrario, puede marcarlos como "no se solucionarán" si no son lo suficientemente graves como para justificar el tiempo que tomaría repararlos.

Debe corregir un error solo si la aplicación es más valiosa sin el error.

Si un campo de texto está desalineado y tarda tres días en solucionarlo, entonces el costo probablemente sea demasiado alto y debería dejarlo. Por el contrario, si los usuarios no pueden escribir nada en el campo de texto, entonces debe solucionarlo y rápidamente.

En general, es más fácil solucionar un problema inmediatamente después de que se haya descubierto. Si deja pasar el tiempo, los desarrolladores pueden olvidar cómo funciona esa parte del código y solucionar el error llevará más tiempo y, por lo tanto, será más costoso.

Algunas compañías no escriben una línea de código nuevo si todavía hay errores pendientes. Otros no se molestan hasta la fase de prueba antes del parto.

En su empresa, obviamente, está dejando pasar mucho tiempo antes de corregir nuevos errores para que se acumulen. También es malo para la moral del equipo ver una gran lista de errores.

Le sugiero que pase un día solo para resolver los errores existentes, decidir los que vale la pena corregir y los que no lo son, y asignar los que se solucionarán a los miembros del equipo existentes con el objetivo de resolver los problemas antes del próximo hito .

En nuestro seguimiento de problemas, hay un estado "con límite de tiempo". Si un problema tiene varios meses o incluso años, y ningún cliente lo insta o vuelve a presentar el problema, entonces este estado se utiliza como estado final. Esto no se hace automáticamente, sino manualmente, siempre que los gerentes nos soliciten que limpiemos los problemas pendientes. Durante este proceso, también es probable que algunos de los problemas se solucionen porque son fáciles de solucionar y / o relativamente importantes (a pesar de que no se instan ni se vuelven a presentar).

No uso JIRA, tengo fogbugz en el trabajo, pero estoy seguro de que esto se aplica a la mayoría de los rastreadores de errores. Mientras escribía esto me di cuenta de que mi forma de trabajar es más ágil que la cascada, los plazos no son concretos para mí y lo que importa es la prioridad.

• Si a tu jefe le importan que se abran demasiadas entradas, no crees las triviales en primer lugar. Debe ser prigamático y no agregar ninguna característica / corrección que no tenga beneficios. Si le hará la vida más fácil pulir algún código o ajustar la interfaz de usuario, entonces seguro, agréguelo. No solo trabaje para usted tratando de corregir fallas menores en el producto, nada es perfecto.
• Coloque los errores / características sin importancia en el hito actual pero con una prioridad baja. Si se mencionan más quejas / solicitudes sobre el problema, puede aumentar la prioridad.
• Cierre / resuelva lo que pueda, ya que no se solucionará, no se reproducirá, no se duplicará, etc. Algunos errores son demasiado triviales para solucionarlos o son solicitudes de funciones que tomarían demasiado tiempo. A veces solo necesita decirle a la persona que solicita estas correcciones / características "No, lo sentimos, no tenemos tiempo".
• Priorice los errores según sea necesario y ordene su lista de tickets por prioridad e hito.
• Si no van a lograr el hito, entonces muévalos a un hito futuro.
• Si un ticket depende de que se complete otro ticket, márquelo como bloqueado u organícelo en una jerarquía, por lo que es obvio que ticket-x y ticket-y están relacionados.
• Si un boleto requiere algún comentario de alguien, asígnelo a esa persona.

En última instancia, siempre tendrá un montón de boletos de baja prioridad, pero los puntos anteriores deberían ayudarlo a minimizar eso.

Usamos JIRA y tenemos un estado de resolución adicional llamado Suspended: si una característica / error es algo a lo que solo tenemos que renunciar por un tiempo, se resuelve como Suspendido. De esta manera, no se mezcla con la lista de problemas actualmente activos en los que tenemos que mantener nuestra atención o con la lista de problemas resueltos que sabemos que se han manejado de manera satisfactoria, y todavía está en la base de datos.

La lista de problemas suspendidos es algo que reviso periódicamente (pero no muy a menudo) para volver a abrir según sea necesario.

No estoy seguro de la terminología correcta de JIRA, pero considere poner una fecha de vencimiento en cada "boleto". Si no se ha escalado, por necesidades de características o por la gravedad del error, a la implementación dentro de un cierto período de tiempo, probablemente no fue tan importante en primer lugar. Esto debería ayudar a mantener la pila recortada automáticamente. A menudo obtengo boletos basados ​​en "¿no sería bueno" o "esto no funciona perfectamente como quiero". Si nadie más presiona lo suficiente, o ese usuario no tiene suficiente influencia, no se hace y cierro el ticket después de un par de meses.