Cómo gestionar la cartera de pedidos de un rastreador de problemas

Llevamos varios años utilizando Trac de manera diligente y nuestra lista de "tickets activos" ha crecido a casi 200 artículos. Estos incluyen errores que son de baja prioridad y demasiado complicados de solucionar por ahora, solicitudes de funciones que han sido diferidas, problemas que nunca han generado quejas, pero todos están de acuerdo en que algún día deberían corregirse, refactorizaciones de código planificadas y otras infelicidades de diseño que nosotros no ' No quiero perder de vista, etc.

Como resultado, con casi 200 de estos problemas, la lista es casi abrumadora; ya no es útil como fuente de lo que se necesita trabajar en este momento.

¿Cuál es la mejor manera de realizar un seguimiento de los problemas de este tipo?

Parte del problema es que algunos de estos problemas tienen una prioridad tan baja que es posible que nunca se resuelvan. Odio perder el rastro de estos artículos (similar a no querer tirar algo de mi casa en caso de que algún día lo necesite); ¿Necesito tirarlos independientemente (marcándolos como wontfix) y asumir que puedo encontrarlos en el futuro si alguna vez los necesito?

Primero, haga que cada desarrollador mire cada uno de los elementos y revise / pruebe cada elemento para ver si todavía es un problema (puede funcionar mejor dividirlos entre las personas). Luego, cierre cualquiera que ya no sea un problema o que ya haya sido atendido con otros esfuerzos de desarrollo.

Ahora asegúrese de que cada uno esté marcado como un esfuerzo de desarrollo grande, mediano o pequeño. Esta es una estimación muy aproximada que se utiliza para clasificar más fácilmente los proyectos y para ayudar a unir las cosas. Si todo ya está estimado, entonces ayudará, pero no te obsesiones con las horas. Solo ve con un rápido control intestinal. A menudo funciona para poner a los desarrolladores en una habitación y solo revisar cada elemento y usar el esfuerzo que la mayoría de las personas siente que es apropiado.

Revise cada uno de los tres grupos de esfuerzo y marque cada elemento en el grupo con una prioridad de Crítico, Alto valor comercial, Alto valor técnico, Valor medio, Valor bajo y Nunca se va a arreglar.

En este punto, usted realmente conoce la lista de adentro hacia afuera y realmente comprende el trabajo que implica su trabajo atrasado y puede comenzar a tomar una decisión sobre qué hacer con los elementos. Tome todos los elementos marcados como que nunca se van a arreglar y archívelos fuera de su cartera de pedidos.

Ahora, cuando programe los elementos para su próxima versión, puede utilizar los elementos críticos y de gran importancia como el núcleo de su versión. Revise la lista de elementos de prioridad media y baja y agregue cualquiera que se pueda trabajar al mismo tiempo que los otros elementos de su lista porque los desarrolladores ya estarán trabajando en esa parte del sistema.

La lista de elementos marcados con prioridad media o baja se puede usar como una lista de cosas para que las personas trabajen cuando tienen un poco de tiempo libre o como capacitación para nuevos empleados. Siempre encuentro que es bueno tener una persona en el equipo durante cada iteración trabajando en estos elementos y ayudando al resto del equipo cuando sea necesario. De esta manera, aún está completando el trabajo en la iteración actual, pero tiene a alguien que es flexible y puede ayudar a apagar incendios cuando sea necesario, pero está manejando los problemas que normalmente no llamarían la atención.

Una cosa que encontramos agradable fue que, entre cada iteración, tuvimos un corto período de 2 semanas en el que todo el equipo solo trabajaría en los elementos marcados con un pequeño esfuerzo de desarrollo. Nos enfocaríamos en cerrar una gran cantidad de boletos en poco tiempo.

¿Trac tiene una configuración de prioridad? ¿Algo así como 1 para los principales show-stoppers y 5 más o menos para cosas que sería bueno haber hecho alguna vez?

Si puede ordenar por prioridad, puede ignorar las cosas de menor prioridad por ahora.

leer: http://en.wikipedia.org/wiki/5S_%28methodology%29

Póngalos en el ático, espere un año, luego muévase de casa. Eso es lo que hago.

En serio, si no vas a arreglarlo, entonces olvídalo. Ver programación extrema.

Pero para artículos sobre código. Puede ponerlos en un sistema de revisión de código, como observaciones menores. Este sistema se puede configurar para marcar problemas cuando se edita esa parte del sistema. Descubrí que esto no funcionaba como compañeros de trabajo, pensé que esto era lo que se esperaba y no abordó las observaciones de revisión.

La única forma de hacerlo es la priorización despiadada. Hazlo ahora o no te molestes.

Esta no es realmente una pregunta de control de versiones, sino una cuestión de flujo de trabajo y prioridad comercial. Hacer un seguimiento de las cosas que se sabe que están mal es una buena idea, incluso si es poco probable que "alguna vez" se arreglen, tiene algunos beneficios. Por un lado, significa que el control de calidad (si tiene un equipo de control de calidad separado) sabe que no debe registrar un nuevo error. Otro beneficio es que si surge un nuevo problema, pero su causa principal se debe a uno de estos problemas de "lo sabemos pero es de baja prioridad", cualquier análisis de la solución ya se rastrea, lo que puede hacer que el más nuevo, más alto, La versión prioritaria del error es mucho más fácil de solucionar.

Otro aspecto de esto es que puede haber cierto margen para abordar parte de este trabajo, ya sea ahora o en el futuro. Tal vez algún día obtenga un pasante y pueda asignarles algunos de los más simples como introducción para mojarse los pies en la base de código.

Si los desarrolladores creen que estos problemas serían buenos para solucionarlos, por ejemplo, si representan una deuda técnica, y facilitaría trabajar con la base de código para solucionarlos, pero no tienen valor comercial, podría valer la pena discutirlo. con las partes interesadas del negocio y ver si se puede llegar a un acuerdo donde esos elementos de la cartera de pedidos se recogen ocasionalmente. He visto a los equipos scrum hacer cosas como bloquear de 3 a 5 puntos de velocidad por sprint para los elementos de "trabajo atrasado técnico"; esto puede requerir un refinamiento político dependiendo de la relación del equipo de desarrollo con las partes interesadas del negocio, pero he visto Funciona muy bien.

Esto realmente depende de algunas cosas.

1. Qué tan grande es el equipo: si el equipo es lo suficientemente grande, puede asignar boletos de una manera que permita completar los elementos de menor prioridad.
2. ¿Con qué frecuencia realiza lanzamientos ?: si el ciclo de lanzamiento es lo suficientemente largo, puede evitar agregar más cosas o retrasar un lanzamiento hasta que haya resuelto todos los tickets.