La empresa en la que trabajo, netquest, está en pleno proceso de cambio. La compañía ha mantenido un ritmo de crecimiento sostenido desde su fundación hace ya más de 10 años y, a parte de los retos comerciales y productivos a los que se ha ido enfrentando, también ha tenido que ir haciendo los deberes en lo que a organización interna se refiere, puesto que no es lo mismo gestionar la actividad de 5 personas (2003) a la de más de 50 personas repartidas en 5 ciudades y 4 países distintos (2011).
Sin ir más lejos, y ya entrando en materia, el ciclo del desarrollo de software ha venido funcionando con el TRAC como herramienta de bug-tracking. Hasta aquí, ningún problema, me gusta el TRAC, es un bug-tracker sencillo pero potente. Sin embargo, la tecnología de netquest tiene una característica que hace que algunos procesos sean algo distintos con el resto de empresas que fabrican software: las aplicaciones son de uso interno. Entonces, rápidamente, el TRAC se estableció también como la herramienta para que los usuarios registraran bugs, nuevas funcionalidades y propuestas de mejora.
Aquí ya empiezan las «hostilidades», puesto que el bug-tracker está preparado y configurado para ser usado por miembros del equipo de desarrollo, en cambio el usuario final de las aplicaciones encuentra dificultades en la multiplicidad de campos presentes en el formulario y que no tienen sentido para él (cosas como Componente, Severity, Versión, Milestone… sin mencionar los campos predefinidos incorporados especialmente para el desarrollo de los proyectos).
Esto se puede superar con una buena documentación sobre cómo abrir buenos tickets (que así se llaman en el TRAC) y con la comprensión del usuario final (que debe cultivarse y mantenerse). Pero claro, la cosa se complica aún más si, dada la costumbre en el uso del bug-tracker, la herramienta se establece como la solución de helpdesk productivo de la compañía (aclaración: el ciclo productivo de netquest pasa por un uso intensivo de las aplicaciones desarrolladas en el área tecnológica por parte de los usuarios internos finales de las mismas), además este helpdesk ha ido evolucionando hacia un soporte de proyectos, tratando múltiples temas, no todos relacionados con las aplicaciones (por tanto, no competiendo todas ellas al departamento de desarrollo).
Total, que sin darnos cuenta (ejem…) tenemos un bug-tracker usado por toda la empresa para 3 cosas distintas:
- Gestión del ciclo de desarrollo tecnológico de las aplicaciones.
- Buzón de sugerencias de nuevas funcionalidades y mejoras, así como bugs encontrados en producción.
- Herramienta de helpdesk sobre aplicaciones y uso de las mismas en proyectos.
Esto, en términos prácticos, podemos verlo como 2 proyectos distintos, el desarrollo y mantenimiento de las aplicaciones (puntos 1 y 2 anteriores) y el helpdesk sobre el uso de las mismas y derivados. Cada uno de estos proyectos requiere sus campos, sus flujos, sus tareas, su funcionamiento, sus reports… El TRAC no puede proporcionar correctamente esa segmentación según su implementación inicial. Qué podemos hacer en este punto?
- Tirar de plugins y trac-hacks, para customizar la herramienta a nuestra medida.
- Desarrollar internamente los plugins necesarios, si lo anterior no fuera suficiente.
- Cambiar de herramienta (siempre hay que estar preparado para esto).
La primera se ha demostrado inútil según nuestras necesidades; la segunda requiere tiempo de desarrolladores (que dejan de dedicarlo a las aplicaciones correspondientes), cosa dificil de justificar. Solo nos queda la tercera. Si además añadimos a la equación que el ciclo la empresa necesita una renovación y mejora en sus procesos (implicando al bug-tracker o similar), apenas hay salida.
Total, que estamos evaluando la implantación de JIRA en la empresa.
Es muy difícil sacar tiempo para investigar o evaluar herramientas nuevas mientras tiras adelante tus tareas habituales. Lamentablemente solo he podido dedicar 8 horas de los 30 días de evaluación que hemos tenido, suerte que no era el único evaluador… 😦
Mi conclusión resumida es:
Wowwww.
Me explicaré, solo han sido 8 horas de inmersión, pero ni con 8 semanas te acabas todo lo que hay. JIRA es una herramienta enorme, sí sí, he dicho…
ENORME
Así de salida, creo que vamos sobrados con ella para hacer lo que queremos hacer y hacerlo tan bien que suponga un salto productivo de impacto, así como mejorar mucho en la eficiencia de la producción y el desarrollo.
En concreto, desde mi breve punto de vista, los aspectos que me han llevado a pensar así son:
1. Customización total, total de TODO:
Sea lo que sea lo que necesites, la interfície de la herramienta te lo permite hacer de manera sencilla, desde modificar los evidentes look & feel de la aplicación, proyectos, componentes, tipos de issues (que así se llaman en JIRA) hasta patrones de notificación en caso de modificaciones de issues, esquemas de permisos, nuevos campos de todos los tipos (textuales, menus de selección, checkboxes…), lo que necesites para customizar los formularios de apertura de nuevos issues. Ah, estos formularios pueden ser distintos según el tipo de issue que estés abriendo, también 😉
2. Herramienta diseñada para gestionar múltiples proyectos personalizados:
Esto nos va de perlas, puesto que era la principal deficiencia del TRAC. Además, JIRA no solo está pensado para gestionar distintos proyectos, sino que también permite gestionarlos de un modo distinto.
Los elementos que usan los proyectos (como los issues, los permisos, los usuarios y sus grupos, los flujos de issues…) se pueden customizar para cada uno de los proyectos. Por ejemplo, puedes tener un formulario muy simple para que los usuarios finales puedan registrar bugs encontrados durante el uso de las aplicaciones (dentro del proyecto de Helpdesk, por decir algo) y un formulario mucho más complejo y ajustado al ciclo de desarrollo para registrar bugs encontrados por el departamento de QA o los propios desarrolladores (dentro del proyecto de la aplicación X) y, si hubiera puntos de contacto entre proyectos (por ejemplo propuestas de mejora de aplicaciones logueadas en el proyecto de Helpdesk que debieran trasladarse al proyecto de desarrollo de la aplicación), los issues se pueden mover o clonar entre proyectos automáticamente y sin ningún problema.
Además, no solo JIRA está pensada para gestionar múltiples proyectos, sino que también está preparada para gestionar proyectos de todos los tipos, más allá del desarrollo tecnológico. Y eso, a la vista de la versatilidad ofrecida, se nota oiga. El gran ejemplo aquí son las sub-tasks, issues que están contenidos dentro de otros issues, como cuando una historia de usuario requiere distintas tareas de implementación, cada una de ellas con su estimación temporal de entrega, volumen de trabajo pendiente, etc.
3. Workflows, transitions y post functions
Rizando el rizo, el más difícil todavía. Además de customizar lo que quieras y añadirlo a los proyectos que tu quieras, en JIRA se puede configurar el flujo de los issues (workflow), sus estados y los movimientos de los mismos según el estado en el que se encuentran (transitions). Era necesario que así fuera, puesto que usar la aplicación para (por ejemplo) gestionar un ciclo de proyectos no tecnológico con el clásico flujo de bug-tracker reporter-developer-tester-closed no hubiera funcionado.
Workflow por defecto de JIRA (imagen sacada de la documentación oficial de Atlassian)
Pero lo mejor de este punto son las post functions, acciones que realiza la aplicación automáticamente dada una transition concreta. JIRA ofrece de salida un conjunto de post functions ya programadas (como actualizar campos del issue, disparar un mail al reporter original…) y permite al administrador programar las post functions que necesite para que sean disparadas en la ejecución de las transiciones. A partir de aquí, no hay límites, puedes montarte tu proyecto con tus componentes y tus flujos de trabajo, sin restricciones.
Además…
Por supuesto, todo viene con más documentación de la que pueda procesarse y guias, tutoriales para todos los niveles. Por otro lado, JIRA también ofrece soporte, obvio ya que es una herramienta de pago, y necesario, puesto que es fácil perderse en la enormidad y complejidad de la misma.
Para terminar, la usabilidad para el usuario es máxima, la navegación es sencilla, los links y el acceso a las acciones que necesitas en cada momento están en la pantalla en la que te encuentras cuando los necesitas (también con shortcuts!); puedes configurarte tu propio dashboard y compartirlo con otros usuarios, y un sinfín de etcéteras…
Lo único sería…
Si tuviera que decir algo que no haya visto claro sería la parte de reporting sobre issues. Así como en el TRAC, el reporting era sencillo y potente (configurable mediante UI, TracQuery language o el lenguaje de la DB que tuvieras debajo), JIRA viene de salida con un conjunto de reports establecidos y no queda claro que hay que hacer si quieres otros, no encuentro donde se configuran como administrador y en la documentación parece ser que debes referirte a un plugin que permite programar los reports en JAVA, pero tampoco queda demasiado claro.
En resumen:
Dada la customización, potencia, versatilidad y multidimensionalidad de JIRA, me inclino a pensar que es la herramienta que necesitamos en netquest en el momento presente, y no puedo esperar a que se implante para comprobarlo!!!
Testing funcional 