search
top

Jira Agile y Scrum, cómo combinarlos de manera correcta (3/4): Profundizando en las incidencias

Enlaces a los dos post anteriores de la serie: 

http://www.javiergarzas.com/2014/07/jira-agile-scrum-1.html

http://www.javiergarzas.com/2014/07/jira-agile-scrum-2.html

En este tercer post, vamos a bajar el nivel de abstracción respecto a los elementos de JIRA, explicando las incidencias de JIRA Agile y la forma correcta de gestionarlas en un proyecto de Scrum.

En un primer contacto con la herramienta cualquier persona se daría cuenta que JIRA por defecto llama a todo incidencia, por lo tanto podemos decir que  las incidencias son el corazón de JIRA.  Ya mencionábamos en los anteriores posts que la herramienta originariamente nació para gestionar incidencias, pero ha evolucionado, y ahora JIRA es una herramienta software para la gestión de proyectos.

Como expone Patrick Li, autor del libro “JIRA 5.2 Essentials”, las incidencias en JIRA representan el trabajo a realizar. Desde la perspectiva funcional es la unidad base para JIRA. Es importante tener muy claro que las incidencias tienen que pertenecer a uno, y sólo a uno, de los proyectos.

Identificación de las incidencias en JIRA Agile

Según se describe en  “JIRA 5.2 Essentials” un proyecto en JIRA es una colección de incidencias definidas según los requisitos de la organización. Cuando creamos un proyecto nuevo se le asigna: un nombre, una clave y un líder de proyecto. Una cuestión importante es que las claves de los proyectos son exclusivas.

Os dejamos una imagen en la que vemos que el nombre es Space Invaders y la clave del proyecto es SI. En este caso es la clave que se crea por defecto, son las iniciales del nombre del proyecto, sin embargo nos da la posibilidad de poner la clave que queramos, siempre y cuando sean por lo menos dos caracteres y en mayúsculas.

Clave

La importancia de esa clave es que las claves de las incidencias (que pueden ser historias de usuario) se generarán automáticamente, utilizando como prefijo la clave del proyecto y así sabremos a qué proyecto pertenece.

Con la siguiente imagen mostramos una incidencia, que pertenece a nuestro proyecto de Space Invaders y como se puede observar su identificador es la clave del proyecto más un número que hace que las claves de las incidencias sean únicas.

clave incidencia

Tipos de incidencias en JIRA Agile

A la hora de crear incidencias de un proyecto ágil, tendremos que escoger entre diferentes tipos de incidencias, lo que suele ser lioso, ya que por “incidencia” nos viene a la cabeza error en producción, por ello vamos a explicar cada tipo de incidencia.

– Error: se trata de un problema que dificulta o impide el funcionamiento del producto, se representa con el icono  idError. Es importante saber el icono que representa cada incidencia ya que es el que aparecerá en el Backlog de JIRA Agile y en el tablero.

– Historia:  acompañada del icono idHistoria  se utiliza para representar una historia de usuario. Recordamos que una historia de usuario representa la funcionalidad básica que aporta valor al cliente o usuario,  sin olvidar que no es una especificación de requisitos.

– Épica: identificada con la siguiente figura idEpopeya, se utiliza para una historia de usuario grande que debe desglosarse, es decir, es una epopeya.

– Mejora: representada con el icono idMejora , se trata de una mejora en la funcionalidad de las características actuales.

– Nueva función: es una nueva característica del producto, que aún no se ha desarrollado, es representada con la figura idNuevaFuncion .

– Tarea: aparece con el icono idTarea y representa una incidencia que necesita ser realizada. Lo normal es que representen historias técnicas. Hablaremos de este tipo de incidencia y de sus malas interpretaciones.

Para las subtareas, es decir, para las incidencias que forman parte de otras incidencias mayores, se dispone de dos tipos:

· Subtarea: representa una parte realizable de una incidencia que no es de tipo historia, y es identificada con el icono idSubtarea.

· Tarea Técnica: se utiliza para representar una subtarea que desciende de una incidencia de tipo historia, aparece con el icono idTareaTecnica. Este tipo de incidencias son las que representan las tareas del Sprint Backlog en JIRA Agile.

Documentación de una incidencia en JIRA Agile

Antes de crear una incidencia debemos tener en cuenta que cada incidencia debería poder hacerse en un solo Sprint, ya que sino influye a la velocidad. Es decir, si estamos haciendo una incidencia en este Sprint y esa incidencia va a llevarnos varios Sprint… no la vamos a poder cerrar al finalizar el Sprint actual y por ello no podremos contabilizar la velocidad.

Además, si se empieza a planificar el siguiente Sprint, con reuniones de Grooming, por ejemplo, no podemos pasar la incidencia activa del Sprint actual al próximo, el que estamos planificando.

Por lo tanto, a la hora de crear incidencias debemos ser conscientes de que en teoría no deben durar más de un Sprint, si quieres que cubrir más de un Sprint… usa Epopeyas.

Una vez que tenemos claro lo anterior, debemos documentar la incidencia, rellenando los campos a la hora de crearla. Tendremos que rellenar la siguiente información.

  • Un resumen que muestre una idea explicativa sobre lo que tratará la incidencia, el título.
  • Una incidencia tiene un nivel de prioridad que indica su importancia, por defecto tendremos las siguientes opciones, según muestra la ayuda local de JIRA.

– Bloqueadora, se representa con el  icono Bloqueadora e indica que es una incidencia que bloquea las tareas de desarrollo. La aplicación no puede correr en ambiente de producción, es la prioridad más alta por encima de todo.

– Crítica, se simboliza con el icono Critica ,  indica que la incidencia está causando un problema y requiere atención urgente, como caídas, pérdida de datos, pérdidas de memoria…

– Mayor, aparece con el icono Mayor ,  indica una pérdida importante en la funcionalidad.

– Menor, representado con el iconoMenor , señala una pérdida menor en la funcionalidad, u otro problema para el cual existe una solución alternativa, entonces el impacto de la incidencia es relativamente menor.

– Trivial, aparece representada con el iconoTrivial ,  indica un problema como palabras mal escritas. Es la prioridad más baja.

  • Fecha de entrega.
  • Componente: es una agrupación lógica de incidencias dentro de un proyecto. Una incidencia puede pertenecer a uno o varios componentes de un proyecto, en este campo se hace referencia al componente del proyecto al que la incidencia se refiere.
  • Versiones afectadas: versión en la cual se manifiesta la incidencia.
  • Versiones correctoras: versión del proyecto en la cual la incidencia fue fijada.
  • Responsable: persona que realizará dicha incidencia.
  • Informador: persona que introduce la incidencia.
  • Entorno: en el que será desarrollado la incidencia.
  • Descripción.
  • Estimación original: el tiempo necesario para resolver las incidencias.
  • Estimación restante: estimación actual del tiempo que queda para resolver la incidencia.
  • Adjunto: añadir información, de manera que sea documentación útil, simple e inteligente, como por ejemplo Mockups los cuales complementan las historias de usuario y se están convirtiendo en una herramienta para el Product Owner.
  • Etiquetas: permiten clasificar una incidencia de manera más informal, y así se podrán hacer búsquedas de incidencias por etiquetas.
  • Enlace de épica: enlace a una epopeya de la que puede formar parte.
  • Sprint en el que será tratará la incidencia.

 

En el último post, de esta primera serie, el del miércoles que viene, os le dejaremos la relación entre las incidencias y los artefactos de Scrum y sus buenas prácticas.

2 Respuestas to “Jira Agile y Scrum, cómo combinarlos de manera correcta (3/4): Profundizando en las incidencias”

  1. Christian dice:

    Una pregunta, no me quedó claro la diferencia entre versión afectada y versión correctora. Puedes explicarlo con un ejemplo?

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top