Preámbulo

Uso «Hack» en el noble sentido del término. La traducción más comúnmente admitida es «apaño», así que muy lejos del tipo encapuchado detrás de una pantalla donde desfilan montones de líneas verdes sobre fondo negro. Voy a explicaros el uso no convencional que hago de los workflows de Jira. Si pensabais encontrar un truco para convertiros en super-administradores de la instancia … seguid vuestro camino.

Contexto

Jira es una herramienta ineludible en el mundo de la gestión de proyectos. Ha conseguido imponerse como la referencia en numerosos ámbitos. ¡Y es merecido! Flexible, personalizable, fiable, muy bien equipado (informes, gráficos, plug-ins, conectores, …). Puede convertirse rápidamente en el compañero imprescindible de toda una organización para el seguimiento de sus actividades. Una auténtica torre de control panóptica.
Sin embargo, un punto de frustración que he encontrado a menudo en los equipos es la restricción de los flujos de trabajo. Al escalar el producto, la tentación es grande de querer homogeneizar y controlar mínimamente su uso. Se le pueden encontrar ventajas, pero a menudo al precio de la creación de instancias de decisión y administración que se vuelven inexorablemente más pesadas. 🤢

El infierno son los flujos.

No es raro encontrar flujos de trabajo en Jira que han requerido semanas, incluso meses de trabajo de numerosas personas para ponerse de acuerdo sobre algo satisfactorio. Te encuentras entonces con cosas como esta 😱:

Fuente: https://abhilashshukla.com/business/best-practices/jira-workflow-for-software-development-and-quality-analyst-qa-teams/

No les echo la piedra, porque corresponde a su esquema de pensamiento y Jira induce fuertemente este tipo de solución. Yo mismo cedí a esa facilidad cuando me pidieron montar equipos. Pero finalmente, me topé rápidamente con varias limitaciones que me hicieron refunfuñar contra la herramienta.

• Complejidad de puesta en marcha
• Rigidez del proceso
• Falta de adhesión de los equipos
• Estandarización a ultranza
• Administración cronófaga
• …

Conviene saber que, potencialmente, cada proyecto Jira puede perfectamente tener su propio flujo de trabajo, sus propios tipos de tickets, sus propias prioridades, su propia gestión de derechos y perfiles, etc. La contrapartida es una administración más compleja para cada proyecto y, para quienes alojan su propia instancia, típicamente grandes cuentas, el rendimiento se ve fuertemente afectado. Forzosamente, ante estas limitaciones, sobre todo la última, se pone en marcha un gran esfuerzo de homogeneización, pero sobre todo de limitación. Lo que hace perder la mayoría de las ventajas citadas antes.

Mi visión

No digo que mi visión sea la mejor, pero después de haber usado y abusado de las posibilidades de esta herramienta, siempre vuelvo a algo más simple y adaptable. Tras una enésima queja sobre los flujos puestos en marcha, me tomé un momento de reflexión para intentar comprender por qué esta herramienta tan prometedora es tan detestada y si no se podría cambiar el rumbo. Y entonces me acordé del primero de los valores del manifiesto ágil:

Individuos e interacciones sobre procesos y herramientas

Y ahí está el problema: hemos hecho de Jira el alfa y la omega de la gestión de proyectos. Todo, o casi, debe quedar registrado, anotado, descrito, explicado en él. Todo eso para obtener bonitos gráficos que adornarán las revisiones de sprint. Para perfeccionar este seguimiento, los flujos de trabajo son imprescindibles, con la imputación del tiempo, los comentarios forzados (por tanto vacíos de sentido), los múltiples campos personalizados, etc.
Imponer un flujo de trabajo a un equipo es, en cierto modo, una señal de que no se confía en él para el seguimiento de los procesos. Se le infantiliza en la gestión del ciclo de vida de los tickets. Vamos, por tanto, en contra de la buena práctica de responsabilización y autogestión de los equipos.

Es necesario volver a la esencia de esta herramienta, que nos permite no perdernos en el avance del producto, sin florituras, de manera simple (KISS), fluida. Pero para ello hay que operar una ruptura radical en su utilización y los flujos de trabajo están en primera línea. ¡Así que hagamos las cosas bien! ¡Dinamitemos por completo estos condenados flujos! 🤯

1ª idea

Es muy simple de poner en marcha y de usar. Usa y abusa de la transición «Toutes» («Todas») 😈

Es una transición particular en Jira. No tiene un origen preciso, sino que abre la posibilidad de acceder desde cualquier punto del flujo de trabajo a la etapa señalada. Muy útil para estados de espera o de anulación, puesto que puede intervenir en cualquier momento.
¡Pues bien, todo reposa sobre esta propiedad! ¡Pongamos todo un montón de estados accesibles todo el tiempo desde cualquier punto de este no-flujo de trabajo!

El resultado es, con matices, un Trello (producto del mismo editor). 😜

Le veo varias ventajas:

• Facilidad de puesta en marcha (administración simplificada)
• Evolución sin impacto sobre lo existente (retrocompatibilidad)
• Configuración en Jira de un único sistema de flujos para todos los equipos (escalado)
• Personalización completa de los flujos por proyecto a través del tablero de tareas (aceptabilidad)

Pero tampoco está exenta de defectos:

• Numerosos estados inútiles, visibles y accesibles
• «Pérdida» de tickets más fácil si no están mapeados en las columnas.
• Menú de transición en el detalle de un ticket muyyy largo.

Personalmente, encuentro que la balanza se inclina muy fuertemente del lado de las ventajas.
Muy entusiasmado con esta idea y recientemente catapultado a responsable de las prácticas Jira en mi misión, hice la ronda de los jefes para vender mi idea. Digamos que no desencadenó un entusiasmo exuberante 😅
Por parte de los administradores Jira, se mostraron circunspectos ante la idea, porque salía completamente del marco. Por parte de los jefes, me recordaron amablemente que aun así había que extraer ciertas métricas de Jira y que ciertas etapas debían ser ineludibles para tener algunos datos fiables.

2º intento

Volví, por tanto, a mi mesa de dibujo para satisfacer lo mejor posible a todas estas partes interesadas.
Después de haberle dado bastantes vueltas y torturado la herramienta de diseño de Jira, finalmente conseguí obtener algo convincente que respondía a las exigencias de cada uno.

NB: si una línea no tiene flecha, es que es bidireccional

En este flujo hay 4+1 etapas ineludibles: Backlog, Todo, Doing, Done + Canceled. Este último estado es un poco aparte, porque es una vía de garaje sin gran interés para nuestro tema. Las 4 etapas principales son todas accesibles por la transición «Toutes», por lo que es perfectamente posible pasar de Backlog a Done, aunque no sea el objetivo.
Se ve claramente el desglose en 3 partes distintas de este flujo y el paso de una a otra de estas partes solo puede hacerse a través de nuestras 4 etapas indispensables. Por sección, también se constata que todas las etapas están conectadas entre sí de manera bidireccional. Lo que significa que desde cualquier estado de una sección se puede pasar a cualquier otro estado del mismo tipo. Simulamos, en la medida de lo posible, la transición «Toutes», limitando esta posibilidad a una sección del flujo.
Para pasar de un tipo de estado a otro, estamos, pues, obligados a pasar por una de nuestras 4 etapas esenciales … objetivo alcanzado.

• Por el lado de las ventajas, retomamos idénticamente las de la primera idea y, debido a la obligación de pasar por ciertas etapas, mejoramos la fiabilidad de la metrología y de las estadísticas.
• Por el lado de los inconvenientes, reducimos sensiblemente la longitud del menú de transiciones en el detalle de los tickets; el número de estados accesibles también es un poco más limitado.

Así que, al final, no salimos realmente perdiendo y nadie tuvo realmente nada que objetar. Por tanto, la puesta en producción fue aceptada sin demasiada dificultad.

Uso

Visualmente, para el uso de todos los días, da esto:

Ya no hay limitación sobre el desplazamiento de los tickets y, detalle interesante, en la columna «Terminé», tenemos los estados «Done» y «Canceled» bien identificables. Es un efecto colateral interesante de haber hecho estos dos estados accesibles todo el tiempo: ya no es posible colocar tickets en el estado «Canceled» por descuido.
En los flujos más clásicos, el estado «Canceled» a menudo tiene la transición «Toutes», mientras que el «Done» solo era accesible por el camino impuesto. Así que cuando se quería terminar un ticket hacia un estado que normalmente no podía acceder a él Y el estado «Canceled» estaba mapeado en esa misma columna, la columna seguía siendo accesible, pero no para el estado que se suponía … y a menudo recuperé tickets abandonados por error.
Con mi solución, esto ya no es posible.

Otros cambios notables

Prioridades

Un comportamiento por defecto de Jira que me parece engañoso es el posicionamiento por defecto de los tickets en «Medium / Moyen» al crearlos. ¿Cómo distinguir los tickets recién creados, potencialmente con una prioridad aún no definida, de los que están realmente a ese nivel? Hice, por tanto, modificar el sistema de prioridades como sigue, integrando un valor «Not prioritized / Non priorisé» como valor por defecto.

En sí, nada revolucionario, pero un pequeño ajuste bienvenido.

Soporte

Considero los tickets de soporte al margen del proyecto y pueden ser objeto de un flujo de trabajo particular y más adaptado. ¿Por qué digo «al margen del proyecto»? Porque las personas susceptibles de crear un ticket de este tipo no forman obligatoriamente parte del equipo, que no tienen necesariamente la costumbre de utilizar esta herramienta y que hay que facilitarles la tarea lo más posible guiándolas al máximo. Por tanto, en este caso, ni hablar de dejarles cambiar el estado del ticket de manera demasiado libre.

Retorno de experiencia

Tras algunas semanas de puesta en marcha en un proyecto piloto, no he tenido muchos ajustes que hacer. Dos estados a nivel de realización, automatismos en las transiciones, pero nada más. Habiendo promocionado un poco este flujo, otros proyectos pidieron pasarse a él … luego se convirtió en el flujo de referencia para el programa, lo que incitó fuertemente a los demás proyectos a pasarse.
Pasaron unas semanas más y el conjunto de los proyectos está contento. Recientemente, también he hablado de ello fuera del programa y algunas personas parecían interesadas, lo cual es alentador para el futuro. Cosa interesante: los proyectos, al ver que se podía realmente adaptar la herramienta para hacerla más agradable, vinieron a pedirme otras modificaciones. Por ejemplo, los campos, demasiado numerosos y de una utilidad dudosa.

Conclusión

Una vez más, no sé si lo que he puesto en marcha se adaptará a vuestra situación. En mi caso, estoy satisfecho y los equipos también lo parecen, así que ¿por qué privarse? 😁.
No dudéis en darme vuestra opinión si os habéis inspirado en los flujos presentados aquí, estaré muy contento de hablarlo en persona 😄.