Manejo de Incidentes con JIRA

En un post anterior, comentamos cómo el potencial de configuración de JIRA era muchas veces sub-utilizado y por ello revisamos una customización especifica orientada al manejo de proyectos de mantención de aplicaciones.

En esta ocasión vamos a revisar otra configuración de JIRA aplicada a incidentes que surgen del uso de aplicaciones. Este proceso busca enmarcarse dentro del modelo ITIL, práctica Incident Management, cuya definición establece:

“El primer objetivo del proceso de manejo de incidentes es restablecer la operación normal de un servicio tan rápido como sea posible      minimizando el impacto en procesos de negocio.

Objetivos

Los objetivos concretos que se buscan con esta configuración son:

  1. Controlar el avance de cada incidente individual y de grupos de incidentes.
  2. Gestionar una estructura estándar para todos los incidentes. En este caso, como se trata de incidentes de aplicaciones, tiene que haber actividades de analisis, diseño, construcción y pruebas que intervengan en la resolución.
  3. Utilizar linea base de fechas de plan junto con controles de cambio cada vez que se necesite modificar la linea base de la planificación de la resolución de un incidente.
  4. Incorporar el concepto de problema para asociar incidentes que tienen un síntoma común.

Jerarquia de issues

Para lograr los objetivos propuestos lo primero es definir una jerarquía de issues en JIRA. Un issue es el elemento básico para almacenar información. Los genéricos son bug, tarea, story, mejora, etc., pero aquí vamos a crear issues específicos con atributos específicos:

Jerarquia Mantencion Correctiva

En esta configuración el concepto de incidente lo hemos representado en un issue que se llama Mantención Correctiva. Lo podríamos haber llamado incidente, pero se usó este nombre para homologarlo con el de Mantención Evolutiva que revisamos en el post anterior. De esta forma las correctivas (incidentes) se hacen cargo de las acciones urgentes necesarias para volver a la operación normal de una aplicación, mientras que las evolutivas se focalizan en aumentar su funcionalidad.

Las acciones que se deben realizar para corregir un incidente se representan como una serie de tareas asociadas a la mantención correctiva: en efecto, cada vez que se crea una mantencion correctiva, automáticamente se generan 8 subtareas que representan las actividades de análisis, corrección, pruebas y liberación que es necesario ejecutar para completar el ciclo de un incidente.

Flujos

El flujo de una mantención correctiva se resume en el siguiente diagrama:

Estados Mantencion Correctiva

En JIRA cada issue está asociado un flujo. En esta configuración el flujo es relativamente simple: el incidente se abre por una mesa de ayuda (que recibió el reclamo del cliente de la aplicación) y se asigna a un gestor quien realiza un análisis (eventualmente puede solicitar más información a la mesa de ayuda). Si es efectivamente un incidente se corrige, lo que implica completar todas las subtareas definidas. Cuando la corrección está disponible se considera resuelto por el gestor, pero es la mesa de ayuda (o un representante del cliente) quien determina si la corrección se acepta (y se cierra el incidente) o se rechaza, con lo cual el ciclo de análisis-corrección empieza una nueva iteración.

En la práctica el flujo es un poco más elaborado que el de la figura, si tomamos en cuenta que podemos incorporar el concepto de problema donde una o mas incidencias se relacionan entre si, de manera que si una se resuelve las relacionadas se deben resolver también. Además hay otras transiciones posibles, como cuando la corrección del incidente no implica efectuar actividades de construcción y pruebas, etc.

Cada subtarea de la mantención correctiva tiene también su propio flujo. La mayoría son simples (abierto, en progreso, cerrado), pero en el caso de las actividades de QA estos son más elaborados.

Otro aspecto relevante de esta configuración es obligar el uso de la jerarquía de issues definida, de tal forma que no se modifique en cada instancia de una mantención correctiva. Para esto se establecen permisos y restringen opciones que por default están abiertas en JIRA.

Resultado

La imagen muestra un ejemplo de un issue tipo mantención correctiva tal como luce en JIRA:

Ejemplo Mantencion Correctiva

En la parte inferior (sección Sub-Tasks) están todas las actividades que se realizaron para resolver el incidente. Uno de los objetivos establecidos fue que todas las mantenciones correctivas tuvieran la misma estructura: si abrimos cualquier mantención que haya sido corregida, veremos siempre las mismas 8 subtareas.

En la parte derecha (sección Dates) aparecen una serie de fechas de planificación asociadas a cada actividad de análisis y corrección. Solo el Gestor puede modificar estas fechas, lo cual queda registrado en la mantención como un evento de replanificación.

También se usan una serie de campos ad-hoc (customfields de JIRA), como categoria (incidente o problema) y varios contadores, que registran las veces que una mantención fue rechazada en las actividades de QA y auditoría de código.

Conclusion

Hemos revisado cómo configurar JIRA para hacernos cargo de atender incidentes asociados al uso de aplicaciones. Al establecer una estructura estándar de issues JIRA, todos los incidentes son iguales desde el punto de vista del proceso que siguen para su corrección.

Un complemento óptimo a un flujo de mantenciones correctivas es el uso de JIRA SERVICE DESK, ya que así podemos relacionar la atención que ofrece la mesa de ayuda (en JIRA Service Desk) con las actividades de corrección ejecutadas por el área de desarrollo (en JIRA), cuando los incidentes son escalados desde la primera a la segunda.

Posted in Jira
  • Monica Moreno

    Buenas tar­des, me en­can­ta su blog, tal vez sea un co­men­ta­rio de mas pa­ra us­ted, sin em­bar­go quie­ro re­cal­car que ha si­do ba­se pa­ra mi co­mo nue­va en to­do el con­cep­to que en­glo­ba JIRA.
    Llevo dias tra­tan­do de so­lu­cio­nar un pro­ble­ma, he vis­to vi­deos y no lo­gro en­con­trar so­lu­cion, Podria ayu­dar­me?

    https://uploads.disquscdn.com/images/f01fb181ede73073867c95b1fffd5a10ac7b66d9ded6bef11c734981043f2246.png

    Al crear un nue­vo issue/sub-task/Epic, no lo­gro ac­ti­var los cam­pos den­tro del rec­tan­gu­lo ro­jo, la ima­gen la sa­que de un vi­deo, pe­ro en los vi­deos no men­cio­nan co­mo ac­ti­var­lo, so­lo men­cio­nan que de­bo ir a System>Issues>Issues features>Time tracking>Activar el bo­ton “Enable ti­me trac­king”, ya he se­gui­do los pa­sos y activarlo/desactivarlo/activarlo de nue­vo y aun si­guen sin sa­lir men­cio­na­dos cam­pos.

    Espero la in­for­ma­cion lo­gre ex­pli­car mi pro­ble­ma y pue­da pro­por­cio­nar­me el se­gui­mien­to co­rrec­to, es­pe­ro an­sio­sa su res­pues­ta, de an­te­ma­no gra­cias.

    • aca­sa­ri

      Hay que agre­gar el cam­po TimeTracking (o Original + Remaining Estimate por se­pa­ra­do) a las pan­ta­llas co­rres­pon­dien­tes.

  • Ruth Villalba

    Hola! muy in­tere­san­te su blog. En don­de en­cuen­tro la par­te II?