Los tickets infinitos

En el trabajo tenemos una aplicación llamada Trac para dar seguimiento a los proyectos. Una vez que recibimos el encargo de un desarrollo, estudiamos a fondo el requerimiento. Luego lo dividimos en componentes y entregables. Los entregables, o milestones, los subdividimos a su vez en tickets. Así, por ejemplo para el entregable Fase 2, componente Web, dimos originalmente de alta unos 60 tickets.

Ay, pero ojalá una vez segmentado el proyecto todo fuera cumplir con los susodichos tickets, sin embargo es distinto. A veces, para poder cerrar uno, se deben abrir quince. La mecánica es más o menos así: para la sección de grupos (de usuarios) se necesita de: 1.- Tabla de grupos con botón de edición para cada uno, 2.- formulario de nuevo grupo, 3.- formulario de edición de grupo con botón para eliminarlo, 4.- botón de borrar grupo, y 5.- página de confirmación de la eliminación.

Es decir que el ticket Sección de grupos, se convierte en cinco otros. Pero resulta que la mejor solución para limitar un tipo de dato en los formularios, es usar un dropdown-menu (ddm), entonces los ítems 2 y 3 de la lista anterior se subdividen en: a) hacer método para generar ddm de tal información, b) integrar el método a tal formulario de grupos.

Pongamos que hasta ahí todo funciona, de repente otro formulario relaciona a los usuarios con un grupo (como estaba previsto), lo que provoca que ya no se pueda borrar al grupo, error aparatosísimo de la base de datos cuando lo intentas. Entonces surgen: i) modificar método borrador de grupos, ii) definir a qué grupo van a parar los usuarios desgrupados, iii) advertir al momento de eliminar un grupo las consecuencias que tendrá en los usuarios que le pertenecen, etc. Total, he estado cerrando y cerrando tickets, pero el proyecto no avanza al ritmo necesario y ya tenemos que entregarlo. Así pues, angustia.