Título un poco raro. ¿qué es cada cosa?. La sopa de piedras hace referencia a una historia y una técnica para conseguir las cosas, explicada en "The pragmatic programmer". El capitán araña hace referencia al dicho "Capitán araña, que a todos embarca y a todos engaña".

En la historia de la sopa de piedras, unos soldados entran en una aldea enemiga y todos los aldeanos se esconden con toda su comida. Los soldados, hambrientos y sin posibilidad de conseguir comida de los aldeanos, cogen una olla, la llenan con agua de río y unas piedras. Lo ponen todo al fuego y empiezan a comentar lo rica que estará la sopa de piedras, típica de su país. Los aldeanos, con curiosidad por una cosa tan extraña se acercan y preguntan por la famosa sopa de piedras. Los soldados comentan que es un plato riquísimo, típico de su país, pero que no va a estar del todo buena porque le falta un poquito de sal. Los aldeanos traen la sal y entonces los soldados comentan que, para que la sope esté perfecta, necesitaría también unas patatas. Tras varias maniobras de estas, consiguen todos los condimentos para una sopa en condiciones (en cuanto sacan las piedras).

Según se comenta en el libro The pragmatic programmer, esta es una forma de conseguir las cosas. Cuando quieres conseguir algo y no encuentras apoyos, lo mejor es empezarlo tú mismo hasta donde puedas y enseñar los resultados a los demás. De esta forma, es más fácil que los demás estén dispuestos a añadir su granito de arena que tener que hacer ellos todo el trabajo.

Hace algún tiempo rubén puso un comentario en este blog indicando que le gustaba mi técnica de marketing viral para propagar las cosas entre mis compañeros de trabajo. Yo prefiero pensar que hago sopas de piedras. Que creo que es bueno usar Spring Framework, comienzo/modifco un proyecto para que use Spring Framework y le enseño a los demás como funciona y sus ventajas. Que creo que es bueno usar Javahelp, preparo la estructura por debajo, hago la ayuda de las primeras ventanas y enseño lo bonito que queda. Que creo que es bueno usar redmine, lo instalo, meto algún proyecto y lo enseño a la gente.

Pero claro, también está la versión de mi compañero de trabajo. Viene a decir algo así como "Empiezas las cosas hasta que ya no se puede volver atrás y luego no nos queda már remedio que seguir el camino que has empezado". Vaya, lo del capitán araña.

En fin, a mi me gusta más pensar en lo de la sopa de piedras y espero que mi "compa" me lo diga en broma, pero claro, también es mi opinión y es más subjetiva….

Primero hice la instalación de prueba. Me gustó y lo instalé en serio. Lo comenté con algunos compañeros, a los que gustó mucho a primera vista,  y metimos dos proyectos que nos estaban más cercanos. En uno de ellos, precisamente, acababamos de hacer una planificación con Microsoft Project, así que teníamos las tareas ya desglosadas y con fechas, puro trabajo de copy-paste.

Luego lo comenté con otros compañeros con los que tengo proyectos "compartidos". También les gustó y metimos también esos proyectos compartidos. Y ahí empezó la "difusión". Algunos de esos proyectos también son compartidos con otros departamentos de la empresa, por lo que hablamos con ellos, se dieron de alta … y conocieron redmine.

Y ahí empezamos a liarla. Al darse a concocer en otros departamentos, también gustó a otra gente, pero claro, no querían poner sus proyectos específicos en el redmine de nuestro departamento. Quería su propia instalación. Y como comenté hace tiempo en un post, sólo el 10% de los informáticos son "geeks" de la informática, así que uno nunca había oído hablar de ruby, el otro sí, pero no sabía instalarlo a través de un proxy, el otro no tiene ni idea de instalar mysql (y mira que es tonto el tema) y el otro …. El caso es que sin quererlo ni beberlo, empezó a circular gente por mi mesa para "demos" del redmine, llamadas telefónicas y correos para la instalación, etc, etc. Por supuesto, hice las demos, a todos les indiqué lo del bitnami stack redmine, instalación fácil. Pero no me libré de la configuración del correo, ya que muchos no saben ni siquiera los parámetros de conexión al smtp de la empresa.

Así que de momento sé, en otros departamentos, de la instalación de tres redmines, y no hace un mes que instalé el mio (con vacaciones de navidad por el medio).

Y no acaba ahí la cosa. Poco después de una auditoria en que nos echaron en cara que las herramientas que usamos (a nivel de jefes, requisitos, actas de reuniones, etc)  no estaban bien integradas y no había trazabilidad entre unas cosas y otras, vinieron algunos de esos jefes (los más amiguetes) a contarme el problema y empezamos a pensar.

Lo primero, eliminar la base de datos que usan los de calidad con el cliente para incidencias. Es una base de datos access, escondida en un directorio compartido que requiere permisos de acceso, que actualizan los de calidad a mano y que los de calidad tienen que enterarse boca a boca de cómo van dichas incidencias para actualizarlas. A los desarrolladores se les da un listado en excel de dichas incidencias, que no tienen persona asignada (el de calidad no sabe a qué desarrollador le toca cada incidencia) y cada uno "elige" con buena voluntad cual cree que es suya. Creo que el 95% de las incidencias se quedan huérfanas por sistema.

Así que en redmine creé una tarea "incidencia oficial" (los errores de redmine los considero "incidencias internas"), le añadí los campos propios de la base de datos de calidad y junto con un compañero que sabe un montón de bases de datos, hicimos (sobre todo él), un script que lee las incidencias de access y las inserta en redmine. Calidad aceptó empezar a usar redmine y olvidarse del access. Nosotros también dejamos de lado bugzilla (la que usabamos para nuestras incidencias internas) y usamos ahora redmine.

Luego, lo que comenté en "Mega herramientas vs Algo de imaginación", cree un subproyecto GESTION debajo de los proyectos, con permisos de acceso a determinadas personas (jefes de proyecto casi todos ellos) y puse una tarea "Reunión", para las reuniones oficiales con el cliente. Añadí a esa tarea una serie de campos adicionales, como "asistentes a la reunión". Pues bien, los jefes de proyecto han empezado a meter ahí las reuniones, a adjuntar las actas y a asociar tareas a hacer.

En fin, que el tema va en marcha, aparentemente con buen ritmo y buena aceptación. Veamos hasta dónde llega y si una vez pasada la novedad, se sigue acutalizando.

En este tipo de proyectos, si se quiere cumplir con todo esto, lo habitual es lanzarse a mega herramientas, estilo la suite de rational o alguna otra similar. Pero estas herramientas tienen grandes inconvenientes.

En primer lugar, suelen ser licencias muy caras, por lo que tienden a racanearse o a no comprarse todas las herramientas de la suite. Son mega-herramientas que no son cómodas de utilizar y requieren bastante aprendizaje, por lo que tampoco se dan a conocer a todo el equipo de desarrollo. Si se compra, suelen comprarse licencias sólo para los jefazos del proyecto (¿cómo vamos a gastarnos 10000€ o más en un currito?). Por ello, o se pone a una o dos personas permanentemente ocupadas con la herramienta, enterándose de qué pasa en el proyecto y actualizando, o al final se queda toda la información desfasada.

¿Y cual es la solución a esto?

Evidentemente, una herramienta gratuita que nos permita gestionar las tareas y errores vía web no nos puede dar toda la funcionalidad completa de una de estas mega herramientas, pero con un poco de imaginación podemos cubrir el expediente de una forma efectiva.

Pongamos un herramienta gratuita y sencilla de usar estilo redmine o trac, con interface web y por tanto accesible por todos desde el navegador. Estas herramientas están pensadas para poner las distintas versiones o hitos, asociarles las tareas a realizar y los errores y llevar bien el control de cuánto hemos avanzado y cuánto nos queda. Por supuesto, no tiene nada que ver con casos de prueba, requisitos, reuniones … ¿ o sí ?

Echémosle un poco de imaginación y en nuestro proyecto vamos a crear una tareas "imaginativas". Redmine, por ejemplo, nos permite definir qué tipos de tareas tenemos, además de "tarea" y "error". Pongamos tareas estilo "reunión", "requisito", "caso de prueba", etc.

En una tarea reunión símplemente escribimos un resumen de la reunión y adjuntamos el fichero con el acta de la reunión (un doc, pdf o lo que sea). De esa reunión saldrán tareas a realizar. Pues las añadimos y las relacionamos con la tarea "reunión". También podemos meter nuestras tareas "requisito" y asociarlas con lo que queramos (reuniones o tareas normales). Igualmente, podemos crear nuestras tareas "caso de prueba" y asociarlas las tareas normales, a las tarea "requisito", etc. Podemos incluso hacer subproyectos separados para cada tipo de tarea. Nuestro PROYECTO puede tener subproyectos REUNIONES, REQUISITOS, PRUEBAS, DESARROLLO, de forma que según el perfil del "currito/jefe", se le den accesos a unas u a otras. Así, por ejemplo, un desarrollador trabaja en el subproyecto DESARROLLO de forma normal a como se hace en una de estas herramientas, con sus hitos, tareas y errores, pero tiene acceso inmediato, quizás de sólo lectura, a los requisitos que debe cumplir a los protocolos de pruebas que debe pasar su código. Y si los jefes son malos (que casi siempre lo son), no tendría ni siquiera acceso de lectura al de REUNIONES, para que no ve

¿La ventaja de todo esto?. Al ser fácilmente accesible por todo el mundo, es fácilmente modificable y se puede tener permanentemente actualizado con un mínimo de disciplina, cada uno actualizando lo que le corresponde.

¿La pega?. Estas herramientas no están pensadas para esto, así que no admiten de una forma fácil y rápida sacar informes adecuados o grandes listados. Sí se puede consultar para una tarea concreta, sea del tipo que sea, las otras tareas relacionadas, siguiendo los enlaces. Así, de un requisito concreto, podemos ver qué tareas se han realizado para cumplirlo, qué prueba comprueba dicho requisito o de qué reunión ha venido. Pero no se puede sacar un listado que nos relacione directamente todos los requisitos con sus pruebas asociadas. De todas formas, lo importante es que está todo relacionado en la base de datos de redmine y haciendo un pequeño esfuerzo adicional, bien con phpmyadmin como comenté hace unos días, o bien haciéndose una herramienta a posta, podemos sacar los informes que queramos.

En fin, no sé si en la práctica todo esto es realizable o si es realmente eficiente. Lo que sí sé es que no se suele cumplir toda la trazabilidad que se debe cumplir, precisamente por lo caro de las herramientas, escasas licencias y falta de gente para meter los datos en ellas día a día. Suele ser mejor algo incompleto pero bien hecho, que algo completo totalmente mal hecho.

Y ahí el tema de este post. Esa antigua base de datos de access venía con su aplicación access, que permitía generar informes muy personalizados. Redmine, una vez configurados los bugs para que tengan los campos "oficiales" de calidad, no tiene posibilidad de generar informes tan a medida. Tiene los suyos propios, que básicamente son un listado de bugs o tareas en el que puedes elegir algunos de los campos a mostrar.

Así que me puse a investigar como podríamos hacer esos informes. Por supuesto, la primera idea es hacerte tus propios scripts que accedan a la base de datos de redmine y generen el informe a tu gusto, haciendo los select que quieras y presentando la información que quieras. Pero, maravilla de las maravillas, mirando la base de datos de redmine con phpMyAdmin, un compañero mio se dio cuenta de que phpMyAdmin tiene posibilidad de crear vistas en la base de datos y de exportar a un montón de formatos (excel, pdf, csv, etc).

Y esa va a ser la forma de hacer los informes. Primero, con phpMyAdmin, haremos un select todo lo complejo que nos haga falta, con joins y wheres kilométricos, de forma que obtengamos una tabla de resultados a nuestro gusto. Luego, crearemos una vista (una especie de tabla "ficticia" en la base de datos), que contendrá ese select monstruoso. De esta forma, no será necesario escribir el select cada vez que queramos generar un informe.

Con eso estaría todo listo. Cuando queramos un informe, pulsaremos en la vista (a todos los efectos como una tabla más de la base de datos, salvo que no se puede insertar, borrar o modificar, sino sólo consultar), obtendremos los resultados y le daremos al botón de export. Habrá que crear tantas vistas como tipos de informes queramos obtener.

Más detalles de cómo hacer esto, en crear informes con phpMyAdmin.

Por un lado, usamos habitualmente bugzilla, que es una herramienta específica para llevar el tema de bugs. Y por supuesto, una herramienta específica que lleva ya bastante tiempo en funcionamiento es mucho más completa y con más posibilidades que una gestión de incidencias en una herramienta que hace más cosas y es más nueva. Ahí van unas cuantas cosas que echo en falta (y que algunos compañeros me han comentado también):

• En redmine no hay posibilidad de poner "con copia" en los bugs para que reciba el correo no solo la persona asignada, sino quizás también su jefe u otra persona que pueda saber algo sobre ese bug aunque no sea la encargada de resolverla. Parece que tampoco puede enviar automáticamente el correo semanal recordando a la gente que tiene "un montón de bugs pendientes".
• También echo en falta la facilidad de bugzilla para cambiar estados de los bugs. Con redmine me he encontrado, por ejemplo, que no puedo reabrir una incidencia cerrada, pero no sé en qué ocasiones, porque en otras sí me deja.
• Finalmente, la posibilidad de generar informes con las incidencias, no es que bugzilla sea ninguna maravilla generando informes, pero tiene más posibilidades que redmine.
• Tampoco parece muy lógico en redmine que mezcla los comentarios de resolución de incidencias/tareas con comentarios de cambios en el porcentaje de tiempo invertido en la tarea. Si miro la historia de una incidencia/tarea, veré consecutivamente todos los comentarios asociados, tanto específicos de la resolución, como de cambios de tiempos.

En cuanto a la wiki integrada en redmine, estoy acostumbrado a usar mediawiki, otra herramienta específica de wiki con mucha andadura (de hecho, es la que usa wikipedia). No he usado demasiado la wiki de redmine, pero da la impresión de ser más sencilla que mediawiki.

Así que todo esto me está haciendo replantear algunas cosas:

• Seguir usando redmine, pero sólo como herramienta de planificación, con hitos, versiones y tareas a realizar.
• Seguir usando bugzilla para los bugs, pero sólo bugs de los que son fallos, no mejoras.
• Usar la wiki de redmine para especificaciones y cosas propias de los proyectos. Seguir usando mediawiki para cosas más generales no específicas de un proyecto concreto, como guía de estilo, de buenas costumbres, tutoriales, normas generales a seguir en todos los proyectos, etc.

No me gusta lo de tener las tareas por un lado y los bugs por otro, así que le daré otra "pensada" al tema.

Tras ver que trac se me resiste y fisgando los instalables que tienen en bitnami, me he encontrado con redmine. Es una herramienta de gestión de proyectos y bugs similar a trac, así que me he decidido a probarla.

El bitnami stacks de redmine me falló, al igual que el de tracks. Se instala bien, se abre el navegador con la página inicial de bienvenida de bitnami, pero cuando pinchas el enlace que te lleva a la aplicación, da un error de proxy. Así que lo desinstalo, lo borro y me decido a hacerlo a mano.

Primera sorpresa agradable de redmine respecto a trac. La página en la que te explica la instalación está muy clarita, indicándote paso a paso qué hacer, qué descargarte previamente (ruby on rails) y cómo configurar el correo (cosa que considero básica en una de estas herramientas). Y siguiendo los pasos, me ha funcionado a la primera. Con trac seguí los pasos, me dio errores, me pelee con él, conseguí que funcionara, me dieron errores los scripts de administración para crear proyectos, me pelee con ellos y al final pasé. Por supuesto, ni intenté lo del correo porque no he visto cómo (tampoco lo buscado). Sé que existe easy_install para instalar fácilmente trac, pero ese easy_install no es nada easy de install (perdón por el juego de palabras). Si sigues el link de easy_install desde trac te lleva a una página que a su vez te redirige a otra de python y después de instalarlo no funciona a través de un proxy que requiere autentificación y tienes que ponerte a rebuscar en una documentación poco clara a ver si hay alguna forma de hacerlo funcionar  y ves que quizás si te instalas un APS proxy server a lo mejor funciona, pero entonces tendrías el problema de ver cómo ese APS proxy server se configura para que acceda a internet a través de tu proxy que requiere autentificación. En fin, bastante easy.

Segunda sorpresa agradable con redmine. Toda la administración se hace través de la web y bastante sencilla. Creas los proyectos, configuras los repositorios de fuentes, das de alta a los usuarios o incluso ellos pueden registrarse. Con trac necesitas un comando que viene con apache para dar de alta un usuario o bien copiar un trozo de script python para generarlos. Sí, ya sé que trac viene con un plugin para administración desde la web, incluso dice que a partir de la versión 0.11 ya viene por defecto, pero hay que habilitarlo en un fichero de configuración que no encontré en ningún sitio de la instalación y que en ningún sitio de la documentación he visto donde hay que ponerlo. Por cierto, la instalación de trac no se si instala algo en algún sitio, porque lo único que ha hecho es meterme un montón de scripts en el directorio donde tengo instalado python (cosa que me parece un poco "guarra").

Más sorpresas agradables, redmine soporta directamente varios controles de versiones, incluido CVS. Trac sólo soporta subversion, salvo que le instales más plugines. Algunos se quejan de que redmine no soporta Git, que es el que está ahora de moda, pero a mi de momento no me afecta.

Así que me pongo a jugar con redmine y veo que aparentemente tiene todo lo que tiene trac (navegar por el código, línea de tiempo y bugs) y más cosas. Soporta varios proyectos con subproyectos, pero en tu página de acceso tienes las tareas asignadas a tí de todos ellos. No tienes que ir visitando todos los proyectos uno a uno para ver qué tienes que hacer como en trac. Tiene foro por proyecto. Tiene posibilidad de subir documentos por proyecto. Y saca un gráfico de Gannt con la evolución del proyecto (quizás no sirva de mucho, pero queda bonito). Presenta además estadísticas de horas gastadas por proyecto, por componente, por persona, por tipo de tarea, etc. Eso sí, habría que ir poniendo todos los días cuántas horas gastas, cosa que seguramente no consiga que todos lo hagamos con la suficiente diligencia.

Además es muy configurable en determinadas cosas. Puedes poner los roles de usuario que quieras, borrando los de defecto o añadiendo nuevos. Para cada rol puedes modificar los permisos, incluido qué cambios de estado de los bugs son permitidos para cada usuario según su grupo: por ejemplo, un desarrollador puede marcar una incidencia como resuelta, pero no como cerrada. También puedes decidir los tipos de tareas a realizar (por defecto diseño y codificación), prioridades de bugs, etc.

En cuanto a pegas y pros a favor de trac o redmine, la gente se queja de trac por no soportar de forma cómoda múltiples proyectos y no tener cosas como, foro, gannt, etc. He visto en foros problemas de instalación similares a los mios. Es decir, son problemas o carencias reales. En cambio, las quejas de redmine son menos tangibles, coas como que es una herramienta muy nueva y no está tan probada como trac (sin indicar ningún problema concreto (bugs tendrá, como todos los proyectos, incluido trac)) o como que es más fiable el python de trac que el ruby on rails de redmine (es posible, no conozco ninguno de los lenguajes en profundidad como para saber si es un problema real, pero desde luego no me ha dado ningún problema en las pruebas que he hecho).

Así que por mi parte la decisión está tomada. Por facilidad de instalación y administración, claridad de la documentación, así como por tener más posiblidades sin complicarse la vida, el lunes lo instalaré en el curro y meteremos un proyecto del que precisamente tenemos que empezar a hacer la planificación.