En cada proyecto complejo, usamos muchas dependencias y herramientas externas. Por supuesto, tienen errores.
Gracias a Github y similares, es muy fácil bifurcar un proyecto y rastrear problemas en las dependencias de las bibliotecas, por lo que ese no es el alcance de esta pregunta.
Sin embargo, las herramientas pueden ser mucho más complejas de inspeccionar, depurar y enviar. Limitémonos aquí a las herramientas de código abierto.
Si la herramienta solo se usa con fines de desarrollo y prueba, la prioridad para corregir estos molestos errores es bastante baja. Es por eso que, a menudo, ni siquiera informamos el problema tan pronto como alguien encuentra una solución.
Esto es malo. Debemos realizar un seguimiento de los problemas de herramientas, ya que explica mucho sobre la vida del proyecto y tenerlos en algún lugar les muestra a todos que podemos solucionarlo , y será de algún valor en estas correcciones. Pero, por otro lado, no podemos poner estos problemas en el mismo cubo que el proyecto porque no están relacionados y contaminarán nuestro rastreador de problemas.
La felicidad de mi equipo es una de mis principales prioridades, y lloro por dentro cuando los veo tener que documentar rituales complejos para situaciones aleatorias que involucran condiciones específicas que se cumplen una vez a la semana o menos.
¿Cómo maneja los problemas relacionados con sus herramientas? ¿Cómo prioriza estos errores?
Me doy cuenta de que mi pregunta es bastante vaga, pero espero que sea clara de todos modos. Estaré feliz de mejorarlo si ves algunos flujos.
Debemos realizar un seguimiento de los problemas de herramientas, ya que explica mucho sobre la vida del proyecto y tenerlos en algún lugar les muestra a todos que podemos solucionarlo, y será de algún valor en estas correcciones.
Todos los proyectos acumulan una cierta cantidad de conocimiento tribal durante el ciclo de vida típico del proyecto. Con lo que parece estar luchando es cómo capturar adecuadamente ese conocimiento.
Parte de la dificultad de su proceso puede provenir de la creencia de que todos los procesos pueden encajar en una sola herramienta; en su caso, sería Trello. Si bien puede ser tentador utilizar una única técnica de seguimiento para rastrear todo , a veces esto puede ser contraproducente. No tenga miedo de agregar rastreadores adicionales, repositorios de conocimiento o herramientas según sea necesario. Lo importante es asegurarse de que todos en el proyecto sepan dónde es probable que se encuentre la información esencial.
Hay dos rutas obvias. En el caso de herramientas externas, como proyectos de código abierto en GitHub, no es necesario parchear la herramienta para contribuir de manera efectiva. GitHub, en particular, generalmente admite problemas específicos del repositorio y wikis, y estos son un buen lugar para documentar problemas y soluciones, incluso si no puede proporcionar una solución permanente. Los proyectos que no son de GitHub tienen otros mecanismos, por supuesto, pero contribuir aguas arriba es realmente la mejor solución a largo plazo.
Para herramientas internas o para proyectos externos que no brindan una forma de contribuir con el conocimiento a la comunidad, a menudo encuentro que una base de conocimiento específica del proyecto o wiki es inmensamente útil. La herramienta utilizada para la captura de conocimiento no es lo importante aquí; lo que importa es que está capturando sus flujos de trabajo y sus soluciones en una cámara de compensación central que está disponible para todo el equipo del proyecto.
Para garantizar la eficiencia y la repetibilidad del proceso, las herramientas y la infraestructura siempre deben tener un proceso documentado para implementar componentes. Este debe ser un documento vivo y, si se mantiene actualizado, contendrá esos fragmentos de conocimiento tribal que actualmente se están desviando.
En los proyectos de software, esta "documentación viva" a menudo puede tener la forma de scripts de aprovisionamiento o configuración. Nadie tiene que perder tiempo leyendo la documentación, siempre y cuando el equipo del proyecto se tome el tiempo para mantener los scripts actualizados. Esta es esencialmente una forma de pagar continuamente la deuda técnica, y probablemente debería ser una tarea recurrente integrada en su Definición de Hecho para cada iteración (si es ágil), o revisarse en hitos críticos o puntos de control si está siguiendo un metodología más tradicional.
Podría estar equivocado, pero parece que tienes una gran esperanza de corregir estos errores, ¡pero es posible que nunca llegues a asignar desarrolladores para corregirlos!
En su lugar, pídale al equipo que dedique la pequeña cantidad de tiempo que se necesita para crear los tickets en el rastreador de errores de las herramientas de código abierto correspondientes. Agregue pasos para reproducir, mensajes de error, capturas de pantalla... y así sucesivamente. Si ha encontrado soluciones alternativas, agréguelas también.
Esto ayuda de las siguientes maneras:
Si alguna vez encuentra el tiempo, siempre puede regresar para encontrar estos boletos y arreglarlos.
Mientras tanto, cualquier otra persona puede arreglarlos también.
Y no contaminará su rastreador de problemas.
MCW
Tomas Wickham