Hace muchos años ya, entré a trabajar en un banco, éramos un grupo pequeño de tecnología, 3 desarrolladores, 2 de soporte, 1 de operaciones y 1 jefe. Lo que más me impactó cuando comencé a trabajar era que no había una forma de saber lo que faltaba por hacer, el jefe era el único que sabía en forma muy manual (una lista de papeles impresos en su escritorio) la lista de solicitudes desde la parte del negocio para IT.
En una de las primeras reuniones para dividir el trabajo, el jefe tomó de su escritorio los papeles con los correos impresos de las solicitudes, las leímos y nos las repartió, directamente el correo impreso con el requerimiento. Entré a una máquina del tiempo y regresé a los 50s.
Obviamente esto no funcionó así por mucho tiempo, sugerí usar un sistema open source, en ese tiempo creo que fue mantis que era un bug tracker escrito en php. La herramienta que se use realmente no es importante, a lo largo de mi carrera he usado muchos como jira, trello, unfuddle, mantis, bugzilla, github issues, pivotal entre otros.
Lo más importante es poder tener un lugar centralizado donde todo el equipo pueda saber el estado del proyecto, saber en qué se está trabajando cada persona, y sobre todo poder tener un lugar donde comentar acerca de un ítem en particular adjuntar documentos necesarios y que el resto del equipo pueda tener el contexto. Adicionalmente poder tener una idea de cuánto trabajo falta por hacer y tener un flujo de trabajo en el que los usuarios también puedan hacer revisiones.
Puede haber un poco de resistencia si trabajas solo, pero en proyectos personales también uso un sistema para saber lo que me falta aún si solo soy yo quien lo uso, hay mucho valor en tener esta base de datos.
Otra recomendación es enlazar los commits en el repositorio con los ítems del bug tracker. Ayuda bastante a trazar por qué una línea de código se agregó al proyecto.
Top comments (0)