Lo que no quiere escuchar es que la forma en que se manejan generalmente estas situaciones es no dejándolas crecer tanto. Pero me temo que ese es el caso.
Los programadores pragmáticos nos avisan Don't live with broken windows. El punto es que si dejamos algo roto en lugar de arreglarlo, quedaremos otras cosas y, antes de darnos cuenta, tenemos 480 elementos en nuestra lista de cosas por hacer. Además, existe el peligro de que una parte de nuestra aplicación dependa del comportamiento "roto", por lo que cuando abordamos el elemento TODO también tenemos la corrección que también.
No todos pueden cumplir con los altos estándares de los programadores pragmáticos.Un enfoque alternativo es tener una lista de las cosas en las que se debe trabajar (a veces conocido como Kaizen list). Las personas que están bloqueadas en su trabajo asignado pueden elegir una de esas tareas.
En cuanto a su situación actual ....
Tengo una regla que establece que nada se puede hacer en menos de media al día: ni una sola vez se incluye control de código fuente, documentación, discutiendo el cambiar con Bob, etc. Por supuesto, mi regla empírica no se aplica a tareas realmente triviales, pero si estas tareas fueran realmente triviales, se habrían solucionado en el acto, sin marcar como HACER, ¿no?
Así que estás buscando el barril de 240 días de esfuerzo. Si muchas de esas tareas se pueden combinar en una sola solución, entonces puede reducir el por tarea sobrecarga. Pero primero tienes un montón de trabajo solo para analizar las tareas, categorizarlas y priorizarlas. Esta es la razón por la cual lo llaman "deuda técnica": cuanto más la dejamos, más cuesta arreglarla, y tiene la tasa de interés compuesta del préstamo promedio.
A menos que tenga un gerente de proyecto/cliente de pago muy comprensivo, creo que tendrá que aceptar que no va a poder borrar todos estos elementos. Así que hay una breve triaging ejercicio: asignar a cada TODO en una de tres categorías:
- Rellene que es intolerable y debe que se fija en este momento
- materia que debe ser fijado como y cuando hay una oportunidad
- cosas que sólo vamos a tener que vivir con
Buena suerte!
Gracias por la información detallada.De hecho, me gustó seguir algunos !! – GustyWind
Esto realmente no aborda la cuestión, es un buen consejo, pero en realidad no es una respuesta. Vine aquí buscando resaltar tareas porque estoy usando REFACTOR: etiquetas para hacer un seguimiento del código que estoy comentando o cambiando, que debe limpiarse antes del final del sprint actual (no más de 2 semanas), así que estoy marcando 'ventanas rotas'. Una cosa tan flexible como el resaltado de etiquetas de tareas no necesariamente impone malas prácticas. –
@AdamTolley - una bandera TODO o REFACTOR es una admisión de deuda técnica, un pagaré sobre el trabajo futuro. No es automáticamente una mala práctica, siempre que los resolvamos más o menos de inmediato. Se convierte en una mala práctica cuando posponemos la eliminación de ellos en favor de otros problemas más apremiantes. Esta parece ser la situación en la que se encontraba el OP. YMMV – APC