Enlaces a los dos post anteriores de la serie:
https://www.javiergarzas.com/2014/07/jira-agile-scrum-1.html
https://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.
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.
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 
. 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 
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 
, se utiliza para una historia de usuario grande que debe desglosarse, es decir, es una epopeya.
– Mejora: representada con el icono 
, 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 
.
– Tarea: aparece con el icono 
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 
.
· Tarea Técnica: se utiliza para representar una subtarea que desciende de una incidencia de tipo historia, aparece con el icono 
. 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 
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 
, 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 
, indica una pérdida importante en la funcionalidad.
– Menor, representado con el icono
, 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 icono
, 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.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Os dejo el enlace al post siguiente: https://www.javiergarzas.com/2014/07/jira-agile-scrum-4.html
Saludos!
Una pregunta, no me quedó claro la diferencia entre versión afectada y versión correctora. Puedes explicarlo con un ejemplo?