Herramientas de gestión de incidentes

En esta lección veremos las características de las Herramientas de Gestión de

Incidentes y su importancia. 

Características

Es importante utilizar una herramienta para gestionar los incidentes, permite

establecer una comunicación fluida y centralizada entre los distintos actores del
proyecto.

A continuación listamos algunas de las características principales de las

herramientas de gestión de incidentes:

 Permitir el manejo de incidentes en forma centralizada, acompañando

todo el ciclo de vida del incidente.
 Interfaz gráfica web, que permita el acceso remoto, desde cualquier
equipo, sin necesidad de instalaciones.
 Fácil de usar: usuarios con diferentes perfiles accederán a la herramienta
que tendrá que desplegar la información correspondiente a cada perfil.
 Manejo de incidentes orientado a proyectos, para hacer el seguimiento
de incidentes en un proyecto determinado.
 Capacidad para almacenar toda la información relativa al incidente, así
como del contexto de ejecución.
 Posibilidad de adjuntar archivos: imágenes, videos o datos que ayuden a
reproducir el incidente reportado.
 Posibilidad de relacionar incidentes con puntos en común para evitar
reportes duplicados o por el contrario, que incidentes que están vinculados
aparezcan como aislados.
 Búsquedas de incidentes por todos los campos que contiene. O sea que
dada una palabra clave para la búsqueda, se revisen título, descripción,
pasos, notas y nombres de archivos adjuntos, entre otros.
 Notificaciones por email, rss ( (Really Simple Syndication) u otros
mecanismos internos. Es importante que la herramienta permita mantener
informados a todos aquellos involucrados con el incidente sobre los
cambios que ha experimentado.
 Personalización: no sólo de la terminología utilizada sino también la
posibilidad de agregar nuevos campos para atender las necesidades
específicas de un proyecto determinado. Por ejemplo, que se pueda indicar
los módulos y funcionalidades vinculados con el incidente o registrar
información de interés, como tiempos de resolución. Mediante la
personalización, se podrían definir campos para mantener la trazabilidad
deseada (con casos de prueba, sesiones de testing exploratorio, versiones,
etc.).
  Auditoría: llevar un histórico de los cambios de cada incidente para saber
quién lo hizo y cuándo.
 Seguridad: posibilidad de definir usuarios, grupos a los que pertenecen y
las restricciones de acceso que correspondan.
 Comunicación entre el usuario final y el equipo de desarrollo.
 Reportes: posibilidad de generar reportes visibles desde la web y también
exportarlos en distintos formatos.
 Exportar datos: poder exportar los datos de los incidentes a distintos
formatos.
 Establecer un flujo de trabajo basado en estados y la posibilidad de definir
un ciclo de vida para los incidentes, transiciones y qué usuarios pueden
realizarlas. Es deseable que la herramienta posibilite su configuración según
las necesidades de cada proyecto.

 Además es útil en general saber:

 Cuáles incidentes han sido resueltos en cada versión.

 En qué versión será corregido cada incidente, o sea conocer la planificación
para las próximas versiones.

¿Por qué una herramienta y no planillas de cálculo?

En la unidad anterior explicamos porqué no reportar los incidentes en mails o

en archivos sueltos.

Otra opción posible es reportar los incidentes en planillas de cálculo o documentos

que se compartan en un repositorio común.

La mejor opción para gestionar los incidentes depende del contexto.

En un proyecto en el que sólo participen 2 personas, ambas desarrollando y

probando, es posible que instalar una herramienta y reportar todo lo que detectan,
no sea lo más eficiente, y posiblemente se pueda gestionar el proyecto con
registros separados.

En cambio si en el proyecto participan varias actores reportando incidentes, se

precisa un repositorio centralizado al que accedan todos los actores y se
pueda ir verificando el estado de cada incidente.

Una herramienta de gestión de incidentes, además de brindarnos funcionalidades

útiles, nos permite despreocuparnos de:

 Revisar periódicamente la planilla buscando cambios para luego notificarle a

los involucrados (vía mail u otros medios).
  “Implementar” el flujo de trabajo del sistema de incidentes, definir qué
significa cada elemento y el comportamiento deseado al registrar la
información.
 Armar reportes para presentar con información relevante. 
 Controlar el esquema de permisos y acceso de los usuarios del sistema de
incidentes.

Si bien podemos registrar los incidentes en documentos almacenados en

repositorios compartidos, hay que considerar los costos ocultos de mantener
planillas y gestionarlas para que sean útiles a los efectos del seguimiento del
proyecto o del producto.

Las metodologías ágiles suelen utilizar tableros como por ejemplo Trello, les
dejamos este video explicando su uso.

Mantis Bug Tracker

Para ejemplificar sobre las herramientas de gestión de incidentes, vamos a

presentar la aplicación web Mantis Bug Tracker.

Está desarrollada en PHP y utiliza Mysql o Postgre SQL como base de datos.

Puede ser instalado en Windows, Linux, Mac OS, OS/2 y varios de los navegadores
web más difundidos funcionan como clientes.

Es una herramienta gratuita sujeta a los términos de la licencia GNU General Public

License (GPL).

Permite administrar varios proyectos llevando un control completo de cada uno,

mantener el historial de cada incidente en el tiempo, utilizar varios idiomas,
notificaciones por email, búsquedas y filtros.

Al reportar un incidente, es obligatorio:

 Elegir un proyecto.
 Seleccionar una categoría. Cada proyecto o subproyecto tiene que tener
asignados una serie de categorías.
 Indicar la reproducibilidad, o sea si el incidente se reproduce siempre, a
veces, en forma aleatorio o no se sabe.
 Indicar la severidad, o sea la gravedad del incidente
 En el resumen, describir de forma clara y breve las características del
incidente.
 En la descripción, explicar en forma detallada el incidente, su ubicación en
el sistema, y el camino seguido para detectarlo, estos datos facilitarán su
reproducibilidad. También es importante incluir el comportamiento
 esperado para ese caso, para ayudar a la persona que trata de comprender
el problema leyendo la descripción del incidente.

La regla sería que el desarrollador pueda reproducir el incidente utilizando la

información aportada en la descripción, sin necesidad de ayuda de la persona
que lo reportó.

Luego de confirmar el ingreso del incidente, el sistema le asigna y retorna un

identificador único.

También es posible filtrar por varios de los campos y hacer búsquedas avanzadas.

Estados definidos para los incidentes en Mantis

Los estados configurados por defecto en Mantis son los siguientes:

Nueva  Se necesitan más Aceptada  Confirmad

Asignad Resuelt Cerrad
datos  a
a a a

 Nueva: luego de ingresar una nueva incidencia

 Se necesitan más datos: son incidencias a las que les falta detalle o más
información para su evaluación y futura corrección.
 Aceptada: la incidencia ha sido revisada pero aún no se asignó a un
desarrollador para que la corrija.
 Confirmada: la incidencia fue aceptada por el técnico que comienza a
trabajar en su resolución.
 Asignada: la incidencia fue asignada al técnico que la resolvería.
 Resuelta: la incidencia fue corregida y/o respondida.
 Cerrada: la incidencia se cierra luego de verificar su resolución.

Los estados Aceptada y Confirmada pueden tener significados diferentes

dependiendo del contexto.

"Hoja de ruta" y "Registro de cambios"

Dos funcionalidades interesantes del Mantis son la "Hoja de Ruta" y el "Registro de

cambios".

El registro de cambios indica para cada versión, los incidentes que han sido
resueltos. Por lo tanto, si al pasar una incidencia al estado Resuelta, se selecciona la
versión, luego en el "Registro de cambios" se visualizará de la siguiente manera:
La hoja de ruta es el plan de corrección de los incidentes por versión. A medida
que los incidentes son resueltos, se visualiza el porcentaje de avance para cada
versión, hasta que la versión se marca como "liberada".

Para poder utilizar estas funcionalidades, es necesario crear previamente las

versiones en la sección de Administración del proyecto.

Luego de agregar cada versión, hay que indicar si ya fue liberada o no con un
checkbox.

Con la "Hoja de ruta" y “Registro de cambios” podemos tener información que

nos ayudará a gestionar el proyecto y saber en cada momento, dónde nos
encontramos referente a la planificación y ejecución del proyecto. 

Como con toda herramienta, la información que se obtenga, dependerá de la

fidelidad y calidad de los datos ingresados.

Es fundamental que todos los involucrados en el proyecto sean conscientes de

la importancia de registrar datos fieles a la realidad y actualizarlos en caso de
producirse modificaciones.