Jira prioridad y automatización
¿Cuáles son las columnas organizativas de tareas de un proyecto? pues, depende del proyecto. Para algo simple tal vez basta con las 4 establecidas en Jira, nuestro por hacer, haciendo y hecho. Sin embargo sabemos que la vida real es más compleja que eso.
Podemos establecer la columnas de nuestro tablero de tareas de la siguiente manera dentro de los estados por defecto de Jira:
| Estado pendiente | Estado en progreso | Estado finalizado |
| Por hacer Urgente | En progreso Revisión Rechazado | Terminado Cancelado |
Teniendo finalmente 7 columnas en nuestro proceso. Las actividades finales de «cancelado» definen una tarea descartada de plano. Al definir una actividad rechazada, ¿esta se descarta completamente o puede volver al flujo para rehacerla o mejorarla? yo apuesto a esto último. Y para ello debemos establecer una transición para «reactivar» esta tarea, pero quién la hace? esa acción, personalmente, se la dejo al encargado original de la tarea.
Automatización simple
En aquellos proyectos generales donde se necesite establecer trabajos prioritarios o urgentes, opto por crear una automatización simple que transicione a «urgencia» en cuanto se establezca una prioridad alta o media alta a una tarea.
Esta automatización debiera ser activada por el informador quién define la prioridad y que alerta mediante correo al usuario responsable del paso a la categoría de urgente.
Para otras automatizaciones mas complejas podemos activar el desencadenador de regla para responder a otras reglas, pero en este caso simple no es necesario.
Para el flujo mostrado aquí podemos automatizar basntante mas, como por ejemplo avisos de alerta para el informador para revisar tareas y al responsable al ser rechazada una tarea. Solo para empezar.
Flujo de trabajo con revision/reactivar.
Una falencia de Jira Work Management (JWM) es que no tiene un ciclo de aprobación sin una extension adicional de pago, a diferencia de Jira Service Management. Por tanto, para procurar esa aprobación utilizo al usuario «informador» como «aprobador» de la tarea.
Entonces, en el flujo indicado más abajo, la actividad en progreso es marcada para «revisar» solo por el usuario responsable (el sabe cuando termina su tarea asignada). En el estado siguiente es el «informador» quien debe aprobar/rechazar/cancelar la tarea. Puede ser interesante avisar al usuario informador cuando debe supervisar una tarea.
La activación se la dejo al usuario responsable, que es quién definirá finalmente cuando tomará la tarea y eso quedará registrado.
Finalmente, para este artículo y avisado el responsable de que su tarea ha sido rechazada, solo él puede reactivarla para mejorarla en su estado de progreso.
Para este flujo se han definido transiciones y reglas básicas de control de usuario y roles.
