tutorial

Cómo trabajar con tiques en Jira Software

La guía sobre cómo trabajar con incidencias en Jira Software 

Max Rehkopf Max Rehkopf
Buscar temas

Tutorial sobre tiques de Jira

En este tutorial, explicaremos cómo trabajar con incidencias en Jira Software. Ten en cuenta que los rituales de equipo que practicas fuera de Jira Software, como las reuniones de planificación de sprints, las retrospectivas o las reuniones rápidas diarias, no se tratarán en este tutorial. Puedes leer más sobre esas cuestiones en el artículo Cómo utilizar scrum con Jira Software.

Tiempo:

10 minutos de lectura.

Audiencia:

eres nuevo con Jira Software y no sabes realmente qué hacer con él

Requisito previo:

  • has creado una cuenta de Jira Software
  • has creado un proyecto de Jira Software

Pruébalo gratis

¿Qué es un tique?

En Jira, los equipos utilizan las incidencias para realizar un seguimiento del trabajo que debe completarse. En función de cómo tu equipo utilice Jira, una incidencia puede representar una tarea de proyecto, un ticket de asistencia técnica, un formulario de solicitud de vacaciones, etc. En Jira Software, las incidencias suelen representar cosas como funciones importantes, requisitos de los usuarios y errores de software.

Crea un tique

Existen diversas formas de crear incidencias:

Desde el menú general, en cualquier parte de Jira

From the global menu, anywhere in Jira

En el backlog

On the backlog

En tu tablero (solo tableros ágiles en Cloud)

On your board (agility boards only)

Opcional: Crea subtareas

Las incidencias también pueden tener subtareas que se asignan y a las que se les hace un seguimiento individualmente. Puede crear subtareas por cualquiera de los siguientes motivos:

  • Para dividir una incidencia en fragmentos aún más pequeños
  • Para dejar que se asignen varios aspectos de una incidencia a diferentes personas
  • Para crear una lista de tareas pendientes de una incidencia

Para crear una subtarea:

  1. Ve a una incidencia y selecciona más ( ••• ) > Crear subtarea.
  2. Completa los detalles según corresponda y, después, haz clic en Crear.
Estima tus tiques (solo scrum)

La estimación de incidencias en tu backlog te ayuda a predecir cuánto se tardará en entregar algunas partes del backlog.

¿Por qué estimar incidencias? La estimación tiene que ver, principalmente, con la velocidad. El principal propósito de aplicar estimaciones a los elementos del backlog es utilizar dicha información para averiguar cuánto se tardará en entregar partes del backlog.

En los equipos de desarrollo tradicionales, los gestores estimaban los elementos en "horas/hombre". A partir de ahí, podían contar las horas en el backlog, dividirlas por el número de personas del equipo y por las horas de la semana para llegar así a una fecha de pronóstico. Por supuesto, estas estimaciones a menudo demostraron ser muy inexactas porque no tenían en cuenta las características de estimación naturales del equipo (por una sobreestimación o una estimación insuficiente), las interrupciones inesperadas o el desarrollo del rendimiento del equipo a lo largo del tiempo.

Así pues, en el mundo de scrum, la mayoría de los equipos no tratan de obtener una estimación exacta; en su lugar, tratan de alcanzar una velocidad fiable. La velocidad es una medición del número de unidades de estimación que un equipo tiende a completar de un sprint a otro. Tras los primeros sprints, la mayoría de los equipos alcanzará una velocidad razonablemente estable. Equipados con velocidad y estimaciones de las incidencias del backlog, los equipos pueden predecir cuánto tardarán en completarse las partes del backlog.

Por ejemplo, si un equipo tiene capacidad de "hora/hombre" de 120 horas en cada sprint, pero una velocidad de 60 horas, dicha velocidad puede seguir utilizándose para estimar el número de sprints que tardarán en completarse las partes del backlog. Puede resultar tentador empezar a preguntarse dónde fueron "las otras 60 horas", dando a entender que algo va mal con la productividad del equipo. Sin embargo, normalmente, no tiene nada que ver con eso: las estimaciones de un equipo solo representan su visión de cómo de complicados serán los elementos, y las estimaciones siempre se verán afectadas por el comportamiento natural del equipo (por ejemplo, la sobreestimación o una estimación insuficiente), así como por sobrecarga organizativa. La velocidad es lo más importante desde el punto de vista de la planificación.

La mayoría de los equipos estiman utilizando puntos de historia. Los puntos de historia miden la complejidad de una incidencia en relación con los demás. Esto es lógico porque las principales preguntas que debemos responder son: "¿Con cuánto trabajo podemos comprometernos de forma realista para completar este sprint?" y "¿Cuánto tardaremos en entregar esta parte del backlog?". Un enfoque de puntos de historia puede ofrecernos las respuestas a estas preguntas sin que los equipos sientan ansiedad por la "exactitud" cuando se les pide que realicen una estimación en horas.

Para obtener más información sobre cómo puede realizarse un seguimiento de la estimación y la velocidad, consulta nuestro tutorial sobre trabajo pendiente.

Para realizar una estimación de una incidencia:

  1. En tu proyecto de scrum, selecciona una incidencia en tu tablero o en el backlog.
  2. En los detalles de la incidencia, haz clic en el campo Estimación.
  3. Introduce una estimación.

¿Puedo cambiar una estimación después de haberla introducido? En pocas palabras, sí, puedes. Pero si cambias el valor de estimación una vez iniciado un sprint, se mostrará como cambio de alcance en el diagrama de trabajo pendiente.

Si te resulta complicado estimar las incidencias, no te preocupes, ¡es algo totalmente normal! Consulta nuestra guía de estimación para ver los consejos y trucos acerca de cómo realizar las estimaciones adecuadas de tus incidencias.

Clasifica tus tiques por orden de prioridad

Al clasificar tus incidencias por orden de prioridad permites que el equipo vea en qué incidencias deberá trabajar después. Para clasificar las incidencias, ve a tu backlog o al tablero y haz clic y arrastra las incidencias para ordenarlas en función de su prioridad. A continuación, incluimos algunos ejemplos de dónde puedes hacer esto:

  • En un proyecto de scrum, cuando planifiques tu próximo sprint, puedes clasificar las incidencias en el backlog y, después, decidir poner las 10 primeras (o el número de incidencias que el equipo sea capaz de completar) en el sprint.

  • En un proyecto de kanban o de metodología ágil, puedes clasificar las incidencias en la columna Por hacer y pedir a los miembros del equipo que escojan una incidencia de la parte superior de la lista cuando necesiten más trabajo. Con este método, la columna con todas las incidencias Por hacer necesitará atención constante a medida que cambian las prioridades.

Nota: Debes disponer de los permisos Planificar incidencia y Editar incidencia para poder subir o bajar incidencias en tu tablero.

Marca un tique

Cuando trabajas en un tablero de kanban o en uno ágil, tienes la opción de marcar una incidencia. En los tableros ágiles, las incidencias marcadas se parecen un poco a esto:

La marcación de incidencias resulta útil, porque fomenta la colaboración y la comunicación de todo el equipo. A continuación, detallamos algunos ejemplos:

  1. Estás trabajando en una tarea, pero te das cuenta de que no tienes la capacidad de acabarla. Puedes marcar la incidencia y un miembro del equipo con capacidad disponible que consulte el tablero podrá intervenir y ayudarte.

  2. Una incidencia en la que estás trabajando se bloquea. Puedes marcar la incidencia, añadir un comentario explicando el impedimento y pasar a la siguiente tarea. Cualquiera que consulte el tablero verá que se ha marcado la incidencia y sabrá lo que ocurre cuando la abra.

Para marcar una incidencia:

  1. Ve a tu tablero de kanban o al tablero de metodología ágil.

  2. Haz clic con el botón derecho en una incidencia.

  3. Pulsa Añadir marca.

Tiques de transición

Las incidencias de transición muestran el progreso de tu flujo de trabajo. Para cambiar el estado de una incidencia de una columna a otra, arrastra la incidencia y déjala en su nueva columna.

Ten en cuenta que si ves que no puedes cambiar el estado de una incidencia a otra columna, puede que se deba a que el flujo de trabajo de tu proyecto te lo está impidiendo. Lo que convierte a Jira en una solución tan potente es que los administradores pueden forzar determinadas reglas en el flujo de trabajo del proyecto, como forzar los errores para que pasen a la columna de control de calidad o no dejar que las historias pasen directamente de la columna Pendiente a Finalizado. Para obtener más información, consulta nuestra documentación sobre flujos de trabajo.

Filtra tiques

Un filtro de incidencias te permite ocultar las incidencias que no quieres ver y centrarte en aquellas que sí te interesan. Jira Software cuenta con una opción de filtros rápidos, que te permite filtrar las incidencias de tu tablero. A continuación, tienes un ejemplo de cómo se ven en los tableros de scrum o kanban:

  1. Barra de búsqueda: muestra las incidencias que contienen un término de búsqueda y oculta el resto.

  2. Menú de filtros rápidos: de forma predeterminada, puedes filtrar por las incidencias que tienes asignadas y por las incidencias recientemente actualizadas. Cualquier filtro rápido que crees también se mostrará aquí.

  3. Menú de persona asignada: solo muestra las incidencias asignadas a las personas que selecciones.

Para crear tu propios filtros rápidos (en tableros de scrum y kanban):

  1. Ve a tu tablero y, después, selecciona más (Ellipses button) > Configuración del tablero.
  2. Haz clic en la pestaña Filtros rápidos.
  3. Introduce un nombre, la consulta con lenguaje JQL y la descripción del filtro. Para obtener más información sobre el lenguaje JQL, consulta nuestra documentación sobre búsquedas avanzadas.

  4. Haz clic en Añadir.

¿Quieres obtener más información?

Para obtener más información sobre cómo trabajar con incidencias en Jira Software, consulta nuestra documentación sobre incidencias.

¿Tienes preguntas? Pregunta a la Comunidad de Atlassian.