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?
fuente
Respuestas:
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.
fuente
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 .
fuente
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).
fuente
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.
En última instancia, siempre tendrá un montón de boletos de baja prioridad, pero los puntos anteriores deberían ayudarlo a minimizar eso.
fuente
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.
fuente
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.
fuente