5 años de TRAC, 8 horas de JIRA

5 años de TRAC, 8 horas de JIRA

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:

  1. Gestión del ciclo de desarrollo tecnológico de las aplicaciones.
  2. Buzón de sugerencias de nuevas funcionalidades y mejoras, así como bugs encontrados en producción.
  3. 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.

JIRA logo

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.

JIRA Default Workflow

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!!!

Anuncios

16 comentarios en “5 años de TRAC, 8 horas de JIRA

  1. Hola Mauri;

    He encontrado tu post haciendo una busqueda de hashtag en Twitter. Me alegra que Jira te parezca tan buena herramienta.

    En mi empresa nos dedicamos a tratar de convencer a la gente que Jira es una herramienta que va mucho más allá de las herramientas de issue tracking tal como se la conoce y que ofrecer una versatilidad enorme mucho más allá: Pruebas, requisitos, procesos, etcétera.

    Nosotros tenemos incluso flujos de trabajo en Jira para implementar planes de Auditoria y hemos llegado a obtener una certificación ISO20000 basándo buena parte de los procedimientos en Jira. Como herramienta para una oficina de calidad es muy buena también.

    Si quieres estár atento a las novedades o contactar con otros usuarios de Atlassian y de Jira en concreto puedes buscar en linkedin un grupo de usuarios de Atlassian en Madrid o en facebook el grupo AUG Spain. Tuvimos una reunión hace unos días y la idea es juntarnos cada dos o tres meses. Hay cientos de usuarios de Jira y estamos buscando la manera de que pueda hacer un intercambio de conocimiento.

    Aunque estés en Barcelona puedes contactar por estos medios y además espero que alguna de las reuniones se haga muy pronto en barcelona porque hay muchísimos usuarios de Jira por allí.

    Cuando quieras, si necesitas algo o por la falta de tiempo hay aspectos que quieras conocer mejor, no lo dudes y coméntamelo. Jira es inmensamente potente y flexible.

    En twitter puedes seguir al que llaman ‘embajador de Atlassian en España’ @david_bonilla que

    Enhorabuena por el post y me alegro que estés contento con Jira

    • Guillermo, muchas gracias por tu comentario!

      Me alegra leer que hay una comunidad activa de usuarios de JIRA y de Atlassian por España, así seguro que en momentos de duda (que los habrá, porque son aplicaciones gigantes y lo parecen aun más si eres nuevo con ellas), tendremos alguien a quién acudir. Gracias también por ofrecerte como guía e indicarme quién es el gurú “oficial”, que siempre va bien.

      Espero que tomemos una decisión pronto al respecto, pero vaya, lo difícil sería no adoptar la herramienta 🙂

      Nos mantenemos en contacto,

      Saludos!

    • Hola Guillermom, estoy comenzado a utilizar Jira y me parece muy practico pero no si solo con ella se puede lograr certificarse en la ISO 29110 que cubre el ciclo de desarrollo de software para pymes y sobretodo lograr la trazabilidad entre las especificaciones, diseño y pruebas. No se si puedes proporcionarme información al respecto. Gracias

  2. Hola Mauri,

    yo he trabajado con Jira, dependiendo del cliente y/o proyecto. Es potente, aunque me parece algo enrevesado. Para el simple uso de bug tracker, prefiero Mantis, mucho más sencillo, sobre todo para el usuario.

    Usar Jira sólo para reportar incidencias, me parece perder tiempo, dinero y prestaciones.

    Una pregunta, ya que usas o has usado Track: sabes si Track soporta la gestión de requisitos y asociar tickets a ellos? Nada de casos de prueba y ejecuciones, simplemente meter requisitos, crear tickets y asociarlos a los requisitos.

    Gracias!

    • Hola de nuevo Arthur!

      Estoy muy de acuerdo contigo: si lo que necesitas es un bug-tracker, hay muchas soluciones gratuitas que cumplen con ese objetivo de un modo mas sencillo. En nuestro caso, hemos pensado con Jira para, además de logear los bugs, necesitamos una herremienta que pueda acoger el helpdesk, procesos internos, el ciclo productivo-comercial…

      Sobre el Trac, de salida no soporta requerimientos que yo sepa, sin embargo puede que haya algun plugin que lo permita. Nosotros hemos trabajado con uno llamado Agilo (http://agilosoftware.com/), que no es muy recomendable, pero permite esto que dices, dar de alta requerimientos y asociar otras tareas o bugs a ellos.

      Espero te sea de ayuda, saludos!

  3. Hola Mauri!

    Gracias por tu respuesta!!

    Me lo apunto como “plan B”. El “plan A” que hemos decidido es hacer otro conector como el que linka las ejecuciones de Testlink con las incidencias, en este caso en Mantis, para que se puedan asociar también a los requisitos.

    La decisión de usar esto es porque actualmente no se requieren pruebas, pero si gestionar requisitos y defectos asociados a ellos (o mejoras). Pero en un futuro (espero que no muy lejano), se quieren acometer pruebas. Así no tendríamos que cambiar de plataforma pues Testlink ya lo tendríamos para crear los planes de pruebas y asociarlos con los requisitos y demás.

    En principio parece fácil. Ya te contaré.

    Con respecto a Jira, para hacer lo que pretendéis tenéis de sobra. Incluso por lo que he visto y oído, funciona muy bien para gestión del código. Pero la interfaz… la veo un poco enrevesada…

    Un saludo y gracias!

    • Pues mucha suerte! Ya me contarás como va.

      PS: detecto que tienes experiencia tanto en Testlink (esto ya lo sabía) como en Mantis… Muy interesante muy interesante, ya hablaremos.

      Saludos!

    • Me gustaria saber si es conveniente usar JIRA para gestionar Casos de Prueba, crear el Plan de Prueba, los casos de Prueba y que te permita ejecutarlos y se puedan obtener reportes. Sirve para eso JIRA?, o seria mas conveniente TestLink?

      • Hola Cynthia, JIRA es una plataforma que te permite registrar y gestionar defectos y tareas de desarrollo, su objetivo no es gestionar casos de test. De todas maneras, JIRA es tan potente que puede extenderse fácilmente para convertirse en una completa herramienta de Test Management, de tal manera que ejecutes los casos de prueba en el mismo sistema donde puedas después dar de alta los defectos y sugerencias de mejora que estos hayan encontrado. Un ejemplo de plugin para extender JIRA en la dirección del Test Mangement es Zephyr, más información aquí: https://marketplace.atlassian.com/plugins/com.thed.zephyr.je

        Suerte!

    • Hombre! Ex-compañero!

      Ganas locas tengo de empezar a implantarlo, supongo que empezando por los proyectos de desarrollo, para luego abrirlo al resto de la empresa teniendo ya un poco más de experiencia.

      Me escucho el podcast este que me pasas, merci!!!

  4. Hola Mauri,

    qué hay de nuevo? Qué tal tu “pelea” con Jira?

    Te escribía sólo para comentarte una cosa: has trabajado con Redmine? Al final, por unos cambios de requisitos (tras hacer el conector requisitos/incidencias entre testlink/mantis…), no nos valía la combinatoria, al ser más útil y práctica una herramienta de gestión de demanda/ticketing/help desk… (ya sabes, depende del uso).

    Ayer me “pegué” con Readmine, echándo un vistazo al manual y con 10 minutos de exploración de la aplicación, ya la tenía configurada: categorías, flujos, estados, usuarios… es un bugtracking/help desk mucho más amigable que Mantis, más “bonita” y sobre todo, configurable 100% y sin tocar código!! Todo desde su interfaz! Además se puede integrar con herramientas de control de versiones (subversion, cvs,…) para desarrollo y con Testlink para calidad. La integración con Testlink es bidireccional! (No unidireccional como con Mantis).

    De momento la tengo instalada, corriendo y configurada. Más adelante me liaré con la integración de Testlink.

    Hay una demo online para probarla, pero se queda corta. Lo mejor, descargarla e instalarla.

    Un saludo!

    • Arthur! Cómo va todo?

      Disculpa el retraso en mi respuesta, entre el cierre anual y las vacaciones navideñas, el tiempo se vuelve un bien inalcanzable 🙂

      Personalmente no he visto nada de Redmine, estaba entre los futuribles en la búsqueda de un bugtracker, pero al elevar el tema a “asunto de estado” paramos esa búsqueda y ya saltamos a Jira, cuya implantación se producirá a lo largo de Enero con toda seguridad. De todas maneras, suena muy bien lo que comentas, vale la pena echárle un vistazo!

      Ya me contarás cómo te va, ok?

      Felices fiestas!

      PS: por cierto, yo te puedo seguir a ti en algun sitio? Blog, Twitter, Linkedin…

  5. Hola Mauri, quisiera saber si tienes otros post sobre jira con tu experiencia y algunas herramientas que se integren con esta y permitan la trazabilidad y muchas cosas más.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s