Hace ya un tiempo que tengo pensado escribir una entrada sobre este tema, pero por unas cosas o por otras lo he ido dejando en la pila de «por escribir». Hoy, esperando a que se suban unas 270 fotos para revelar, me he planteado que puede ser un buen momento.
Desde hace un par de años venimos usando Trac como sistema central para la gestión de proyectos software (y los que no son software en general también) en la empresa donde trabajo. Trac es un sistema web centrado en un wiki, con sistemas montados alrededor de él: tags, blog, sistema de tickets/incidentes… y un montón de plugins, extensiones y macros. Está pensado para la organización de proyectos de desarrollo software de forma principalmente colaborativa.
En un principio hemos estado usando Trac de una forma intensa pero sin un objetivo definido. Simplemente viene bien para documentar, tracear bugs, información personal y demás.
Una de las cosas que más me ha convencido Trac con el pasar del tiempo es lo bien que se puede usar en un entorno o grupo de desarrollo que tenga implantada una metodología tipo scrum. Scrum es una forma de gestionar/avanzar en proyectos de desarrollo software (principalmente, aunque no exclusivamente). Está basada en el concepto de que un pequeño grupo de gente auto-organizada responde mejor a los cambios y es más eficiente, sobre todo si se auto establecen objetivos a muy corto plazo y se mantiene una comunicación muy muy muy fluida entre todos los miembros del equipo.
Sin entrar en excesivos detalles, scrum tiene tres conceptos centrales: Pila de producto (o proyecto), pila del sprint y el propio scrum. La pila de producto es una lista de funcionalidades (u objetivos) a medio/largo plazo que se establecen en el proyecto de desarrollo. Generalmente esta pila no está definida por completo nunca y siempre está cambiando, su dueño es el gestor del producto (product manager). Esta pila es la guía final del proyecto, aquí están representado lo que quiere nuestro cliente (o lo que se establece en un estándar) y es a lo que hemos de ir a buscar.
La pila de sprint es, como su nombre indica, las cosas que el grupo se propone hacer para el sprint. Un sprint no es más que un periodo de corto relativamente corto, de entre 2 y 6 semanas, en el que se establecen unos objetivos sacados de la pila de producto y que se meten en la pila de sprint. El equipo es responsable de calibrarse, de asumir los trabajos y de gestionarse para conseguir que al final de mes la pila de sprint esté vacía.
Por último, el scrum en sí, además de la metodología, es una mini-reunión diaria que se establece para, básicamente, permear el conocimiento y la gestión en el grupo e intentar resolver cualquier problema de ahora o del futuro próximo. Se han de responder tres simples preguntas: ¿Qué has hecho desde el último scrum?/¿Qué harás para el siguiente?/¿Algún problema?.
Insisto en que Trac me gusta porque trae herramientas incorporadas que permiten la implantación de una filosofía tipo scrum de manera bastante sencilla. El propio wiki es una forma extremadamente colaborativa de documentar un proyecto, o cualquier cosa, que se lleva muy bien con la filosofía de gestión scrum. Pero es que además:
El blog permite documentar, si se desea, los sprints de una forma rapidísima y muy útil para una referencia futura.
Los milestones, que pueden tener fecha o no, permiten implementar tanto la pila del producto (sin fecha), como la del sprint (con fecha).
Los tickets, pueden asociarse fácilmente a las entradas en la pila de producto o de sprint, y es sencillo ir traspasando tickets de una pila a otra y ver cómo se van quemando los sprints según se van cerrando los tickets.
Además me gustan especialmente dos funcionalidades de trac. Por un lado los tags me parecen un sistema realmente muy potente y natural de organizar la información. La metainformación es una forma de no preocuparse por complicadas jerarquías o estructuras de organización de la información, si no simplemente de asignar palabras clave a un documento, blog o ticket. Posteriormente una consulta a los tags apropiados y recuperamos todos los documentos asociados. Si se es solo un poco ordenado con los tags, se pueden crear complejas estructuras de información, muy sencillas de acceder, con la información totalmente a mano siempre.
Por otro lado el blog, además de para documentar reuniones, es muy potente para animar al equipo a documentar. Creo que la excesiva formalidad o burocracia está detrás del anquilosamiento de los proyectos, y estoy convencido de que metodologías menos formales como el wiki o mejor aún, un blog basado en wiki como el de trac, incentivan a la gente a escribir documentación para uno mismo o para los demás. La clave del éxito total pasa por asignar unos tags correctos y ya tendremos una forma de indexar esas entradas, además de la temporal, por supuesto.
Mi recomendación con respecto a proyectos de software, al menos hasta grupos de 6-10 personas, es intentar implantar un sistema trac y si encima se le une una filosofía scrum de gestión, pues mejor.
Otras cosas... (y ProyectoRadio) 