En el desarrollo de Unkasoft Platform y otras cosas que están por venir, como en cualquier proyecto de software de cierta envergadura, mantener documentación de lo que se ha hecho, de lo que se está y de lo que se va a hacer es fundamental. Esto como todo, cuando se trabaja en grupo ya no es una necesidad más, es tarea prioritaria.

En Unkasoft hasta hace poco tiempo hemos estado usando gforge para mantener el tracking de nuestros proyectos. Fundamentalmente nos servía como contenerdor de bugs, features a desarrollar y ramas de desarrollo dentro del sistema de control de versiones. Gforge como sistema básico es usable aunque a medida que se avanza en el control del desarrollo del proyecto las herramientas de tracking deben ir avanzando a la par y llegamos a un punto en el que necesitabamos ciertas cosas que gforge no podía dar. Las más importantes:

1.- Utilidades para trabajar con SCRUM : hasta el momento habíamos estado usando una hoja de excel creada por Juan Palacios (navegapolis) que era muy útil pero que tenía dos problemas. Uno de ellos que era una pesadez de actualizar y otro que no se integraba con los items del tracker.

2.- Integración con Subversion. Es sumamente importante saber que ha pasado con el código y con los logs de subversion y los diff muchas veces no son suficiente. Necesitabamos saber en qué rama estaba resuelto un ticket, cuando se habían mezclado dos ramas, si las ramas estaban activas, etc, etc. En el fondo lo que hacemos es programar y todas las acciones llevan detrás líneas de código así que lo mejor es que tengamos una relación entre item y código.

3.- Facilidad de mantenimiento: si falla la información que tenemos en el tracker es posible que tengas a un programador parado varias horas buscando la aguja en el pajar. Además, por experiencia, los programadores somos vagos y todo lo que no es programar nos cuesta horrores, con lo que mantener al día el tracker si no tienes una metodología bien marcada puede ser un infierno. Con lo cual actulizar datos debe ser simple y llevar poco tiempo.

Después de mirar algunas opciones decidimos usar trac. Las razones son muchas, pero las más interesantes son las siguientes:

- Tiene pluggins para SCRUM, con lo cual queda resuelto el problema 1. Cada item (bug, feature) se le pueden asignar unas horas e ir modificandolas. Del mismo modo se pueden planificar cada sprint gracias a los milestones y ver las gráficas de esfuerzo. Además, con la ventaja de que todo está integrado :)

- Integración con subversion: otro resuelto. La integración es impecable, puedes ver todos los commit, ver los diff en web, tener asociados commits a items, etc. Además desde el propio commit puedes actulizar los items, por ejemplo, añadirle horas a un bug sobre el que estás trabajando, cerrarlo, etc. Esto soluciona de paso el punto 3 también.

- Facilidad de uso: Aparte de su integración con subversion es muy simple crearse tus propias querys, poder suscribirte por RSS para ver que va pasando en un bug, poder además tener un wiki para anotar por ejemplo, documentación de features, hacerte tus propios plugins en python (se puede pedir más?:), etc.

Hasta ahora la migración está funcionando bien, falta aún mucho trabajo de adaptación a nuestro sistema de trabajo, mejorar algunas cosas que tiene un poco cojas (como por ejemplo la gestión de usuarios), terminar de poner los hooks adecuados a subversion, crearnos todas las query que necesitamos y una larga lista, la típica que nunca acaba. Otro detalle que falta y que es la mar de útil es el gráfico de ramas. En esta versión de trac no tienen el pluggin para poder ver el gráfico y la subversion hasta la versión 1.5 no tendrá un sistema propio de tracking de ramas. A ver si la gente de códice integra su visor con subversion :)

Etiquetas: SCRUM, trac, tracker