Jira es una gran herramienta, sin duda está entre las mejores con las que podemos sustituir, o complementar, un tablero físico de gestión visual para la gestión Ágil. Nada comparable, por ejemplo, con otras terroríficas mezclas, con ese Uruk-Hai de las herramientas… «Microsoft Project Agile» o con los intentos de hacerle un lifting Ágil a momias como Redmine.
Pero, aún así, esto no quiere decir que Jira no incite al pecado.
Puedes usar Jira y pasar de trabajar de manera Ágil, si te va bien… te felicito. Pero este post va por aquellos que dicen trabajar de manera muy Ágil usando Jira… aunque la realidad sea muy diferente. Y, recuerda, que hay algo peor que una mala práctica… una mala práctica automatizada.
Así que te voy a dejar unas cuantas prácticas (no me van a entrar 50, pero si 6), muy típicas en Jira, que son cualquier cosa… menos Ágiles.
Llamarle a todo lo que hay en un Product Backlog de Jira Historia de Usuario
Podemos empezar por aquí, por esta típica forma de ocultar el pecado y liberar nuestra conciencia: Llamar (tipificar) a todo lo que hay en un Backlog como «Historia de Usuario».
Yo siempre digo que llamar a las cosas por su verdadero nombre es, además de lo justo, un gran ejercicio de reflexión (la importancia de llamar a las cosas por su nombre).
Llamar por defecto a todo lo que entra en un Product Backlog de Jira «Historia» hace cómodo a la vista colar bugs, tareas, etc., como tales… sin serlo. Y de ahí que luego pasen cosas como que todo, cualquier cosa, hasta bugs vestidos de Historia, sumen a la gráfica de velocidad. O como colar un ciclo de vida en cascada en un Backlog de Jira.
Backlogs casi infinitos, con miles de Items
Cuando, en los viejos tiempos, se usaban tableros de gestión visual en la pared, con sus post-it de papel y todo eso, era más difícil, y más dañino para la vista, tener miles de post-it pegados por el tablero. En Jira, o en cualquier herramienta, crear miles de «tickets», Historias, Items, etc., fácilmente, rápido… llega a ser un vicio.
Y los Backlog grandes son un gran problema y una gran fuente de desperdicio. Son fuente de trabajo superfluo.
El campo descripción de cualquier Item, especialmente en las Historias de Usuario
Sería interesante recordar que una Historia de Usuario es, además de «end to end», funcional, pequeña, etc., y con una descripción breve. Descrita con un breve texto por aquello de evitar el desperdicio de los excesos documentales (típicos en la era Cascada – Requisitos), para en vez de escribir fomentar hablar (por aquello de interacción por encima de documentación), evitar contratos que mermen la colaboración, que sean «una promesa de conversación», etc.
De nuevo, aunque hay quien tiene mucho arte escribiendo con letra muy pequeña, el uso de post-it ayudaba a eso de escribir poco, pero el campo «descripción» de una Historia en Jira… parece no tener un final.
Portfolio como Gantt encubierto
Portfolio, esa extensión de Jira que ofrece una vista a, supuestamente, mayor nivel de abstracción, donde se ven fechas previstas de Release, barras de progreso, porcentajes de avance… es que ya solo con lo que estoy escribiendo… un sudor frío está mojando mi frente.
No me extiendo mucho en este punto ya que en su día le dediqué un post (cómo crear Cascadas y Proyectos, fácilmente, con Jira Ágil Portfolio), pero te resumo que es tremendamente fácil convertir Portfolio en una especie de Gantt y en un modelo de «fecha de entrega fija y alcance cerrado». Ten cuidado con ello, Portfolio es muy útil si los sabes usar bien, sino puede ser un infierno.
Epics que son Historias
Hay quien medio entendió que no era sensato describir el futuro, el Roadmap, en Historias de Usuario, era un trabajo de mucho esfuerzo y muy probable desperdicio, con lejanía entre lo teorizado y lo sucedería en la realidad, etc. Para ello, y otras cosas, estaban las Epics (sobre Roadmaps ágiles, una visión a largo plazo sin comprometer el cambio).
Incluso, según lo anterior, hay quien se dijo de no hacer Historias con una previsión más allá de 2 o 3 Sprints, y que a partir de ese horizonte se usasen sólo Epics. Pero, frente a esto, alguien también pensó… pues, entonces, escribamos Historias tipificadas como Epics.
Workflows
Y creo que todos los anteriores pueden ser pequeños pecados comparados con usar un Workflow de Jira escondido detrás de un tablero. Esto ya son palabras mayores. Esto ya es más sadomaso.
Esos Workflows grandes, llenos de permisos, que regulan cómo se mueven los items por un tablero, quién puede moverlos, quién autoriza que se puedan mover, que canalizan vueltas atrás, adelante, arriba, abajo por un tablero, que, siendo Ágil, se supone lo más simple posible, sin propietarios de columnas, con flujo izquierda derecha sin vuelta atrás.
Este mal en Jira me parece de los más peligrosos porque suele esconder problemas más profundos, más de cultura de Control, más de silos, más de poco entendimiento de la auto-organización.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Muy buen post, algunos de los puntos que comentas ahí son errores habituales que tenemos o hemos tenido. Al respecto, tengo un par de preguntas para ti:
– Hablas de hacer las historias lo más pequeñas posible. ¿Cuándo sabes que una historia es «demasiado grande»? ¿Cómo lo mides? Por otro lado, indicas que es mala práctica abusar de las descripciones de una historia. ¿También lo sería definir los criterios de aceptación de la historia antes de iniciar el desarrollo? (nuestra práctica habitual: antes de desarrollar, hacemos un kick-off por historia de usuario en el cual definimos las subtareas y los criterios de aceptación de la historia, definidos con el PO y el cliente)
– Cuando una historia de usuario depende del desarrollo de un punto de API (backend) y de la vista (frontend) la solemos dividir en dos historias, una por cada componente. ¿Considerarías esto una buena práctica ya que nos permite tener historias pequeñas o bien lo contrario ya que una de las historias por separado (punto de API) no definiría un desarrollo completo de valor para el usuario final?
Muchas gracias :).
La HU es end to end, una HU de backend ya no es una HU…
Creo que opinas desde el desconocimiento. Hace mucho que AzureDevops es, de lejos, la mejor herramienta para hacer Scrum o DevOps.
Por qué es mejor?
Es una imaginación mía o a la palabra sobras le falta una «m» para ser sombras
Hola Javier buscaba todos tus post donde haces referencia a jira, a mi me gustaria leer las 50 sombras, pienso que entonces la herramientas ha sido mal enfocada por personas que piensan en cascada pero si te dieran la oportunidad de cambiar el jira, quiero saber como puedo llevarla por el buen camino.