Como señalan algunas otras respuestas, la pregunta correcta aquí es probablemente: ¿por qué tiene un rastreador de problemas? Una buena respuesta a esta pregunta (no solo desde la perspectiva de la administración sino también desde la perspectiva del desarrollador) es imprescindible si desea que un sistema de seguimiento de problemas realmente funcione y se actualice regularmente.
En muchas empresas, el sistema de seguimiento de problemas se utiliza principalmente como herramienta de informes de gestión. Hacer que los programadores actualicen los problemas solo para que la administración pueda ejecutar un informe no funciona bien. Y obligar a los programadores a actualizar los problemas tampoco funciona: es posible que tenga problemas actualizados, pero debe cuestionar los datos.
En mi experiencia, la única forma de que los desarrolladores (y probadores, administradores, etc.) realmente utilicen un sistema de seguimiento de problemas es integrarlo en el proceso de desarrollo. Esto significa que la salida de una parte del proceso se convierte en la entrada a la siguiente parte del proceso.
Para dar autoridad al sistema de seguimiento de errores, sugeriría lo siguiente:
- Los desarrolladores solo trabajan en errores / características registradas en el rastreador de problemas y no se realiza ningún trabajo fuera de él. Todas las ideas, proyectos de refactorización, nuevas características, herramientas personalizadas para ser desarrolladas, etc. también deben registrarse
- Las cuestiones se trabajan en orden de prioridad. La prioridad debe estar determinada en parte por la administración, pero los desarrolladores definitivamente también deben tener voz en la determinación de prioridades. Esto es especialmente cierto cuando se trata de problemas de mantenimiento y refactorización.
En cuanto al proceso, puede usar algo como lo siguiente:
- El estado 'nuevo' indica que un desarrollador aún no ha resuelto un problema y todavía está en la cola de problemas priorizados
- El estado 'asignado' indica que se ha asignado a un desarrollador. Esto podría hacerlo el desarrollador u otra persona, como el líder del equipo. Creo que funciona bien tener algunos problemas asignados a cada desarrollador y, por lo general, una combinación de 'trabajo pesado', como nuevas características y selecciones fáciles, como errores simples o algún trabajo de mantenimiento simple. Esto permite a los desarrolladores elegir el trabajo en función de su estado de ánimo.
- El estado 'en progreso' significa que un desarrollador está trabajando en un problema. Solo uno o dos problemas por desarrollador deben estar 'en progreso' en cualquier momento.
- Una vez que se ha resuelto un problema, el desarrollador puede cambiar el estado del problema a "necesidades de prueba" y cambiar el propietario al probador. Este es un paso importante, ya que también es la cola de trabajo de los evaluadores.
- los evaluadores pueden cambiar el estado a 'prueba fallida' y cambiar la propiedad al desarrollador, lo que significa que va a la parte superior de la cola para el desarrollador, o pueden cambiar el estado a 'listo para implementar'.
- los problemas con el estado de 'listo para implementar' pueden fusionarse y liberarse de acuerdo con el ciclo de lanzamiento por quien sea responsable de los lanzamientos.
En resumen: haga que el sistema de seguimiento de problemas sea una parte esencial del proceso de desarrollo y no tendrá que preocuparse por problemas que no se actualicen.