5 malas prácticas en JIRA

proibidoMucho se habla de las buenas o mejores prácticas. Pero casi nunca se cuentan las malas (o peores), que en la realidad son las que más se ven. De hecho cualquier mejor práctica tiene que tener como contraparte una mala práctica.

JIRA no se queda fuera de esta realidad: se trata simplemente una herramienta de software. Es su uso lo que va a determinar el valor real que entrega a un grupo de personas y finalmente a la organización. Y su uso está determinado por la experiencia, habilidades y actitudes de sus usuarios. Al igual que con un martillo o un taladro, los clavos quedarán firmes y derechos y los hoyos no agrietarán la pared si las personas que las usan lo hacen correctamente.

A continuación presentamos una lista con las peores prácticas que he me ha tocado ver reiteradamente como Atlassian Expert y la cura que se puede aplicar para cada una.

1. Compromisos vencidos

Juan crea una tarea, ingresa la fecha de compromiso (duedate) y la asigna a José.
Llega la fecha de compromiso y la tarea no está resuelta. Al día siguiente Juan se da cuenta que el compromiso solicitado no se cumplió. Agrega un comentario exigiendo una explicación y así pasan varios días más entre comentarios y réplicas.
Sin embargo la fecha de compromiso de la tarea sigue siendo la misma, aunque ya no aporta ningún valor, porque el compromiso no se cumplió!

Comentario: José debería haber modificado la fecha de compromiso el mismo día que debió haber quedado resuelta o antes, si ya sabía que no iba a poder cumplir en la fecha solicitada. No actualizar la fecha de compromiso de un issue es una de las peores prácticas en JIRA: rápidamente se pierde la confianza en esta fecha clave y si esto ocurre JIRA deja de tener utilidad, ya que recordemos que su rol último es ser un issue tracker, hacer seguimiento, pero cómo puedo hacer seguimiento de un dato del cual ya no confío?

Aunque se pueden usar ayudas para monitorear cuántos días quedan antes de cumplir la fecha de compromiso (como programar un customfield que calcula la diferencia en días hábiles entre el duedate y la fecha actual y mostrarlo con colores de alerta), es finalmente responsabilidad de cada uno vigilar que los duedates de los issues que tenga asignados representen fielmente su compromiso de atenderlos o resolverlos antes de esa fecha.

Regla: No se aceptan compromisos vencidos.

2. Abuso de adjuntos

Juan crea una tarea que pide la corrección de un programa y la asigna a José.
José siente que la manera de demostrar que está de lleno dedicado a la corrección es comenzar a adjuntar la mayor cantidad de archivos posibles: requerimientos (Word), datos/casos de prueba (Excel), comunicaciones con usuarios (emails), código (zips), etc.
Más aun, algunos de estos archivos se versionan en el mismo issue con sufijos o fechas en el nombre para representar diferentes versiones.
El resultado final es que el issue termina con 10,15 o más adjuntos.

Comentario: JIRA no es un document manager ni tampoco un version control. José podría usar Confluence para guardar documentos y en el issue guardar solo el link a la pagina Confluence. Los beneficios de la integración de JIRA y Confluence son conocidos (ver Referencias). También podría usar GIT/SVN y en el issue guardar el link al repo o usar un addon que integre a JIRA con GIT/SVN.

Existen addons que permiten restringir los tipos de archivos que se pueden adjuntar a un issue. Así se podría permitir adjuntar solo imágenes, dejando el resto en otros repositorios como Confluence o GIT/SVN.

3. Quién es el responsable?

Juan crea una tarea y la asigna a José.
José ve que falta información e ingresa un comentario, mencionando a @paula.
A partir de este momento la tarea no tiene un responsable real, se diluyó, ya que José se queda esperando la respuesta y Paula no es la asignada, sigue siendo José.
El responsable se diluye más aún con cada nuevo mencionado en los comentarios que sigan.

Comentario: José debió haber asignado la tarea a Paula junto a su mención en el comentario. De esta manera Juan, José, Paula y cualquiera que vea la tarea sabe quien está efectivamente a cargo. Si Paula pide información a otra persona, además de usar menciones debe asignar la tarea, y así sucesivamente.

3 y 1 están muy relacionados: cuando veo un issue necesito confiar que la persona que está actualmente asignada se hace responsable de cumplir el compromiso dado por el duedate, aunque esta persona no sea quien creó o a quien originalmente se le asignó el issue.

Regla: Si estoy asignado entonces soy el responsable de cumplir el compromiso.

4. Una sola gran tarea

Juan crea una tarea y la asigna a José. Pasan los días y muchos otros se incorporan, registran y comentan en la (misma) tarea. Al final tenemos varias páginas de comentarios, algunos con varios niveles de réplica.
A esta altura se nos hace difícil entender qué está pasando con esta tarea si no estamos directamente involucrados.

Comentario: José debió haber creado subtareas, asignarlas a si mismo (o a quien corresponda) y dejar todo registro y comentarios en el contexto de cada una.

Si suponemos que el grupo/organización cuenta con procesos formales y maduros (CMM/ITIL), José debería crear un tipo específico de issue (un upgrade de aplicacion por ejemplo), que tenga etapas y tareas específicas definidas por sus procesos, y asociarla a la tarea que Juan creó (que bajo el mismo supuesto habría sido una solicitud de upgrade). Usar tipos y estructuras de issues JIRA que representen procesos formales de la organizacion es definitivamente una mejor práctica (ver Referencias), ya que permite estandarizar en JIRA estos procesos evitando así saltarse etapas o controles, lo que probablemente ocurra si dejamos que se creen en forma adhoc, y establecer niveles de cumplimiento (SLA).

5. Abuso de links

Juan crea una tarea y se la asigna a José. Pasan los días y si vemos el issue nos encontramos con 10,15 o más links a issues de los más diversos tipos y en diferentes proyectos.
José trató aquí de crear una combinación de Gantt con una WBS (Work Breakdown Structure), usando el único recurso a mano en JIRA: links.
El problema es que en la malla de links que esto produce (imaginemos que todos comienzan a hacer lo mismo) nadie entiende nada, excepto quizás José.

Comentario: Así como vimos en el punto 2 que Jira no es un document manager ni un version control, tampoco fue pensado para Gantts/WBS y otras funciones que encontramos en productos como MS Project y otros similares. El valor de JIRA está dado por su capacidad de definir flujos (que pueden ser muy complejos y sofisticados con la ayuda de un par de addons claves en este aspecto). A esto agregamos la integración con Confluence para manejar entregables tipo documentos (como requerimientos y especificaciones) y con otras herramientas Atlassian para el ciclo de vida (como Bitbucket para entregables de código y Bamboo para control de los ambientes).

José puede elegir usar algún addon que integre JIRA con MS Project y de esta forma mantener la Gantt/WBS allí. O bien optar por alguno que agregan una Gantt/WBS dentro de JIRA (hay varios y de diferente valor). Independientemente de los addons que se puedan usar, definir antes una jerarquía de issues (y links) es esencial para ordenar el trabajo de una persona y de cada grupo. La rapidez con que se adopte esta definición está directamente relacionado al grado de formalidad y madurez de los procesos del grupo o área (ver Referencias).


Esta cinco malas prácticas tienen un alto impacto en las expectativas que el uso de JIRA produce en una organización. Por ello es muy importante que todos los involucrados hagan su mejor esfuerzo en reducir (idealmente eliminar) su uso.

Referencias:

Integración de Jira y Confluence para gestión de proyectos

Manejo de Incidentes con Jira

Gestión de Portfolios IT con JIRA

 

 

Posted in Jira