Tutorial sobre tiques de Jira
En este tutorial, explicaremos cómo trabajar con incidencias en Jira. Ten en cuenta que los rituales de equipo que practicas fuera de Jira, 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.
Duración:
Lectura de 10 minutos de duración.
Público:
Eres nuevo con Jira y no sabes realmente qué hacer con esta herramienta
Requisito previo:
- Has creado una cuenta de Jira
-
Has creado un proyecto de Jira
En Jira, los equipos pueden utilizar 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 abandono, etc. En Jira, las incidencias suelen representar cosas como funcionalidades importantes, requisitos de los usuarios y errores de software.
Crea un tique
Existen diversas formas de crear tiques:
En la barra de navegación superior de Jira
En el backlog
En tu tablero (solo en proyectos gestionados por el equipo)
Opcional: Crea subtareas
Los tiques 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 un tique en fragmentos aún más pequeños
- Para dejar que se asignen varios aspectos de un tique a diferentes personas
- Para crear una lista de tareas pendientes de un tique
Para crear una subtarea:
- Ve a un tique y selecciona más (•••) > Create Sub-Task (Crear subtarea).
- Completa los detalles según corresponda y, después, haz clic en Create (Crear).
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 tiques? 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 entonces, 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án una velocidad razonablemente estable. Equipados con velocidad y estimaciones de los tiques 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. Pero, normalmente, no tiene nada que ver con eso: las estimaciones de un equipo simplemente representan su visión de cómo serán los elementos más exigentes, 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 los gastos organizativos. 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 un tique 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 evolución.
Para realizar una estimación de un tique:
- 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 evolución.
Si te resulta complicado estimar los tiques, 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 tiques.
Clasifica tus tiques por orden de prioridad
Al clasificar tus tiques por orden de prioridad permites que los equipos vean en qué tiques deberán trabajar después. Para clasificar los tiques, ve a tu backlog o al tablero y haz clic y arrastra los tiques para ordenarlos 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 una plantilla de kanban puedes clasificar las incidencias en la columna Por hacer y pedir a los miembros del equipo que se vayan encargando de ellas. Con este método, el equipo tendrá que ir controlando la columna Por hacer y trabajar en función de las prioridades del momento.
Nota: Debes disponer de los permisos de planificación de tiques y edición de tiques para poder subir o bajar tiques en tu tablero.
Marca un tique
Puedes marcar una incidencia, como se muestra en esta imagen:
La marcación de tiques resulta útil porque fomenta la colaboración y la comunicación de todo el equipo. A continuación, detallamos algunos ejemplos:
-
Estás trabajando en una tarea, pero te das cuenta de que no tienes la capacidad de acabarla. Puedes marcar el tique, y un miembro del equipo con capacidad disponible que consulte el tablero podrá intervenir y ayudarte.
-
Un tique en el que estás trabajando se bloquea. Puedes marcar el tique, añadir un comentario explicando el impedimento y pasar a la siguiente tarea. Cualquiera que consulte el tablero verá que se ha marcado el tique y sabrá lo que ocurre cuando lo abra.
Para marcar un tique:
-
Ve a tu tablero.
-
Haz clic con el botón derecho en un tique.
-
Pulsa Add flag (Añadir marca).
Tiques de transición
Los tiques de transición muestran el progreso de tu workflow. Para iniciar la transición de un tique de una columna a otra, arrastra el tique y déjalo en su nueva columna.
Ten en cuenta que si ves que no puedes iniciar la transición de un tique a otra columna, puede que se deba a que el workflow 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 workflow del proyecto, como forzar los bugs para que pasen a la columna de control de calidad o no dejar que las historias pasen directamente de la columna To Do (Por hacer) a la columna Done (Hecho). Para obtener más información, consulta nuestra documentación sobre workflows.
Filtra tiques
Un filtro de incidencias te permite ocultar las incidencias que no quieres ver y centrarte en aquellas que sí te interesan. Jira 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:
-
Barra de búsqueda: Muestra los tiques que contienen un término de búsqueda y oculta el resto.
-
Menú de filtros rápidos: De forma predeterminada, puedes filtrar por los tiques que tienes asignados y por los tiques recientemente actualizados. Cualquier filtro rápido que crees también se mostrará aquí.
-
Menú de responsables: Solo muestra los tiques asignados a las personas que tú selecciones.
Para crear tu propio filtro rápido (en tableros de scrum y kanban):
- Botón de puntos suspensivosVe a tu tablero y, después, selecciona más (
) > Board settings (Configuración del tablero). - Haz clic en la pestaña Quick Filters (Filtros rápidos).
-
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.
-
Haz clic en Add (Añadir).
Convierte la automatización en tu arma secreta
Con Jira, llevas el control de tu trabajo. A veces, hay tantas tareas que hacer que puede resultar difícil estar pendiente de todo. La automatización es la clave para mantener todas las incidencias al día. Descubre las automatizaciones más utilizadas de la Biblioteca de plantillas de Jira Automation.
¿Quieres obtener más información?
Para obtener más información sobre cómo trabajar con incidencias en Jira, consulta nuestra documentación sobre incidencias. ¿Estás impaciente por empezar? Echa un vistazo a nuestras plantillas gratuitas de Jira.
¿Tienes alguna pregunta? Pregunta a la comunidad de Atlassian.
.jpg?cdnVersion=2474)