Después de muchos años, una pregunta que se repite una y otra vez entre las personas que están menos familiarizadas con JIRA es ¿qué puede o no puede hacer JIRA? Pues te adelanto que es una herramienta muy flexible que nos deja hacer «casi» de todo.

Este nivel de flexibilidad tiene una cara «B», hace que pueda llegar a tener una curva de aprendizaje más elevada que otras soluciones. OJO! Atlassian ha hecho un gran trabajo de mejora en los últimos dos años, y algo ha tenido que ver la compra de Trello.

En este tutorial me gustaría explicar cómo crear un proyecto personalizado paso a paso, de esta forma es fácil entender qué elementos intervienen y seréis capaces de pasar vuestro flujo de trabajo representado en un panel físico a la herramienta. Por supuesto hay un método más rápido, usar la configuración por defecto de JIRA, pero nosotros queremos que sea la herramienta la que trabaje como nosotros queremos y no al revés.

Para que no sea un tutorial excesivamente largo, voy a dejar expresamente fuera, la gestión de usuario y permisos, así como la gestión de componentes y versiones.

NOTA: Para poder realizar estas configuraciones debéis disponer de los permisos suficientes en vuestro usuario de JIRA, en caso de que no podáis realizarlas tendréis que hablar con vuestro administrador y ver la política de creación y configuración de proyectos que tenga vuestra empresa.

La versión sobre la que voy a trabajar es la SaaS (Cloud, en la nube como un servicio), si vuestra instalación es OnPremise (Server, instalada en vuestros propios servidores), ya os adelanto que habrá ligeras diferencias (o no tan ligeras) ya que las versiones no van alineadas en cuanto a funcionalidad y aspecto. Cloud está pensada para simplificar la vida en cuanto a instalación y mantenimiento, reduciendo algunas de las opciones, mientras que Server nos «abre la caja» para poder interactuar con todas las opciones de JIRA.

La versión exacta en el momento de acabar este tutorial es la 1001.0.0-SNAPSHOT. Incluso en esta versión ya han introducido algún cambio nuevo respecto a lo que explica este tutorial, como el Diseño de incidencias en la configuración del proyecto, pero como no afecta a nuestro objetivo lo he dejado fuera.

Registrarse en Atlassian

Lo primero que necesitamos es registrarnos en Atlassian para poder disfrutar de nuestros Trial de JIRA Cloud (una pena que del mes original se haya bajado a una semana, esto nos limita bastante jugar con él).

Una vez registrados, nos llegarán dos correos, uno de confirmación de nuestra dirección de email y un segundo con el enlace de acceso a nuestro site de JIRA , en mi caso: adictosaltrabajo.atlassian.com.

 

Una vez pulsemos el enlace del correo, tendremos que identificarnos en nuestro nuevo site.

Una vez accedamos, lo primero que nos aparecerá será el asistente de creación de proyectos. Nos hará varias preguntas sobre nuestra forma de trabajar para sugerirnos una plantilla adecuada. Pero siempre vamos a poder seleccionar después nosotros la que queramos.

En el siguiente paso seleccionamos la plantilla que queremos emplear como referencia, en mi caso Scrum. Quiero usar esta plantilla porque el equipo tiene una demanda predictiva, esto es, hay una pila de producto conocida que vamos a ir consumiendo y se quiere tener una estimación a futuro del esfuerzo que se lleva realizado y qué «queda» pendiente, informes que nos da la herramienta out-of-the-box.

Relación de los elementos de proyecto mencionados

Revisando el tutorial, he considerado importante incluir aquí de forma más o menos gráfica los elementos que componen un proyecto en JIRA, espero que viéndolo de forma visual, ayude a aquellos que estáis algo menos familiarizados a comprender la configuración que se explica en los siguientes puntos.

Antes de empezar, me gustaría aclarar que hay configuraciones a nivel de Sistema JIRA y otras configuraciones a nivel de Proyecto JIRA. Es importante que nos familiaricemos con el lugar de cada una de ellas para no volvernos locos.

Crear un proyecto

El primer paso para la creación de un proyecto es darle un nombre, en mi caso AdictosAlTrabajo y un código al proyecto AAT (se auto-genera pero puedes ajustarlo a tu gusto), este código va a estar presente después en todas las issues (tarjetas) del proyecto.

Una vez hecho esto accederemos por primera vez al proyecto por defecto que nos ha creado JIRA.

Personalizar un proyecto

En la imagen podéis ver un panel que he dibujado en un cuaderno, y que representa el flujo de trabajo de un equipo en un panel físico que usan actualmente. El objetivo es llevar este panel físico a uno virtual de JIRA.

Recordemos que no es tanto la herramienta que usemos, como tener identificado nuestro flujo de trabajo y que la herramienta que elijamos sea capaz de representarlo. Nuestro panel se compone de:

1. Nuestro Product Backlog «el de toda la vida» que tiene todos los elementos que consideramos para nuestro producto/proyecto.
2. Ready to UX, para reflejar los elementos que ya tienen algo de contenido de negocio para que sea posible empezar a trabajar conjuntamente con el equipo de UX.
3. Ready to Dev, que contempla nuestro equivalente al Definition of Ready, ya que aquí solo podrán estar los elementos que dispongan de todos los elementos para ser abordados por el equipo de desarrollo.
4. Sprint Backlog, el bloque de funcionalidad que vamos a trabajar en la siguiente iteración.
5. Doing, aquellos elementos en los que estamos trabajando actualmente.
6. Blocked, esta columna es muy útil en equipos poco maduros y sobre todo en escenarios con fuertes dependencias de terceros.
7. Delivered, una vez finalizado el trabajo y asegurándonos de que cumple con el Definition of Done, se quedan aquí hasta que puedan pasar a Done.
8. Done, de nuevo poco que añadir, aquellos que han sido aprobados por el Product Owner y son potencialmente entregables a los usuarios finales pasando a formar parte del incremento.

Configuraciones de JIRA

Teniendo claro nuestro flujo de trabajo, lo primero que haremos será realizar aquellas configuraciones reutilizables que luego podremos aplicar en nuestro proyecto. Estas configuraciones son propias del sistema, aunque luego las apliquemos a nuestro proyecto.

Para que sea más sencillo entenderlo, diremos que un proyecto está compuesto de (además de otros elementos que no intervienen en este tutorial):

1. Incidencias (issues). Su nombre nos puede hacer pensar en errores, pero realmente son nuestras tareas o trabajos (post-its). Recordad que todo en JIRA es una issue, por lo que empleamos los tipos de incidencias (issue types) para diferenciarlos. Se pueden agrupar varios de estos tipos de incidencias en un bloque denominado esquema de tipos de incidencias (issue types scheme).
2. Flujo de trabajo (workflows). Es el «camino» por el que pueden pasar nuestras incidencias, y tenemos la flexibilidad de crear incluso workflows diferentes por tipo de incidencia. Podemos agrupar varios workflows dentro de un mismo esquema de flujos de trabajo (workflow scheme) que aplicaremos después a nuestro proyecto. Un workflow está compuesto por Estados y Transiciones, viendo la imagen anterior, Estados se corresponden con las columnas y las transiciones con los criterios de si una issue puede pasar de una columna a otra o no.
3. Pantalla (screens). Cuando interactuamos con una issue lo hacemos mediante un formulario de JIRA, este formulario es lo que se denomina pantalla. Podemos personalizar esta pantalla para que muestre solo los campos que necesitamos, organizados mediante pestañas en caso necesario. Podemos aplicar además pantallas diferentes según la operación (forma en la que interactuamos con el issue). Si lo estamos creando podemos querer unos campos diferentes a los que necesitamos al editarlo o al pasar de una columna a otra. Los Esquemas de pantallas (screen scheme) nos permiten definir y agrupar pantallas diferentes para cada una de las operaciones que podemos realizar con un issue. Si pensamos en un error o en un desarrollo, casi con total seguridad veremos diferentes datos necesarios, por ello empleando los Esquemas de pantalla de tipos de incidencias (Issue type screen scheme) podemos dar un paso más y crear diferentes por issue type.
4. Campos personalizados (custom fields). Ya hemos comentado que las incidencias se componen de campos y que podemos acceder a ellos mediante las pantallas. Pero… ¿Y si necesito un campo específico «número de agente» para un issue de tipo «Agente Secreto»? Pues para ello contamos con los campos personalizados que nos permiten crear estos campos específicos.

Ahora que ya conocemos los elementos con los que vamos a trabajar, vamos a empezar a desgranar cada uno y su proceso de configuración.

 

Crear tipos de incidencias y esquemas de tipos de incidencias

Insisto, todo elemento que maneja JIRA es un issue, es decir cada tarea o trabajo se refleja en un elemento de tipo issue independiente. Vamos, que cada elemento de JIRA se llama de forma genérica issue.

Los tipos de issues nos permiten por ejemplo diferenciar que issue es un error (bug), que es un evolutivo o que es una tarea de configuración.

Los esquemas son agrupaciones o juegos compuestos de diferentes tipos de issues que se aplican a un proyecto JIRA. Es decir, posteriormente a nivel de proyecto no asignamos issues independientes, sino esquemas.

NOTA: Los esquemas podemos encontrarlos a nivel de issues, workflows y pantallas, y en todos ellos funcionan de la misma manera.

Dependiendo de nuestro proyecto querremos tener un juego de tipos de issues personalizado o nos servirá el esquema establecido por defecto (Default Issue Type Scheme). Para poder personalizar o añadir un nuevo tipo de incidencia debemos ir a JIRA -> Configuración de JIRA -> Incidencias -> Tipos de incidencias.

En la parte superior derecha podemos emplear la función Añadir tipo de incidencia. Al usarla se abrirá una nueva modal donde podemos crear nuestra issue:

Cuando terminemos veremos cómo el nuevo tipo de incidencia Adictos se ha creado. También veremos que se ha asignado al esquema por defecto Default  Issue Type Scheme.

Fijaos en que por defecto al crear un nuevo issue type se asocia al esquema Default Issue Type Scheme.

En mi caso quiero emplear el siguiente juego de issues, que ya están contemplados por defecto en JIRA y no necesito añadir nuevos. Pero voy a incluir a efectos didácticos el nuevo issue type Adictos que he creado:

• Epic – Funcionalidad que no es posible que sea desarrollada dentro de un sprint.
• Story – Mínima pieza de funcionalidad completa (no por componente).
• Chore – Tarea técnica que no contempla funcionalidad, pero de la que dependen otras.
• Spike – Tarea de investigación que requiere una prueba de concepto para analizar la viabilidad o el esfuerzo de algo.
• Subtask (tienen un tratamiento ligeramente diferente por JIRA) – Son las subtareas técnicas que es necesario realizar para completar una Story, un Spike o un Chore.
• Bug – Incidencias encontradas en producción y que debe atender el mismo equipo que desarrolla.
• Adictos – A efectos didácticos

Voy a crear un esquema que contenga exactamente estos tipos para aplicar posteriormente a mi proyecto AdictosAlTrabajo. Para ello accedo a JIRA -> Configuración de JIRA -> Incidencias -> Tipos de incidencias

Una vez en aquí, en la parte superior derecha tengo la opción Agregar Esquema de Tipos de Incidencia que me abrirá la siguiente pantalla:

Arrastramos desde la lista de la derecha (todos los disponibles) hasta la lista de la izquierda que configura nuestro esquema. En mi caso quedaría así:

También he aprovechado a marcar de qué tipo son las issues por defecto que se crean con este esquema. Como en mi proyecto las que más se van a usar son de tipo Story, he puesto que sea éste por defecto. Al volver a la lista de esquemas, ya podremos ver el nuevo llamado AAT Issue Types Scheme:

El siguiente paso es asociar este esquema a nuestro proyecto, para ello hacemos clic en la opción Asociado. Después seleccionamos nuestro proyecto en la lista desplegable:

 

Crear un flujo de trabajo y un esquema de flujos de trabajo personalizados (workflow scheme)

El siguiente paso va a ser crear un workflow de trabajo. ¿Y qué es esto de un workflow? Más allá de la representación visual de los issues en columnas (como las de nuestro panel en papel), tenemos que establecer el estado en el que se encontrarán dichas issues y bajo qué condiciones podrán o no pasar de una columna a otra. Por defecto nuestro panel tendrá un flujo de trabajo asignado. Pero podemos crear uno nuevo desde JIRA -> Configuración de JIRA -> Incidencias -> Flujos de trabajo

En la parte superior derecha podemos emplear la función Añadir flujo de trabajo. Para abrir la modal donde indicar el nombre que queremos dar al nuevo workflow.

Podemos elegir entre construir nuestro flujo de forma visual o en modo gráfico (diagrama). Yo voy a optar por esta última que me parece muy intuitiva.

A nivel de workflow se manejan dos conceptos, estados y transiciones. Los estados están relacionados con la estructura de nuestro proyecto. Podemos decir que equivalen a las columnas de nuestro panel. Por otro lado, las transiciones establecen cómo se produce la transición entre un estado y otro.

Lo primero que voy a hacer es cambiar el nombre al estado NEW por Product Backlog. De esta forma que refleja que todo lo que entre en mi panel va a formar parte del product backlog. Hacemos doble clic sobre New en el gráfico y le cambiamos el nombre. Después le damos a Guardar.

NOTA: Si este estado ya se usa en otro workflow JIRA nos avisará de que los cambios afectarán a estos otros workflows.

A continuación voy a crear un nuevo estado que sea Ready to UX  para reflejar aquellos issues que están preparados para ser abordados por el equipo. Para ello en la parte superior izquierda hago clic en Añadir estado y le doy el nombre (Ready2UX).

Una vez creado el nuevo estado veremos que aparece «suelto» en nuestro diagrama. Para poder conectarlo y avanzar con el flujo de trabajo, es necesario crear una transición, si nos fijamos en el lateral derecho JIRA ya nos está aconsejando Añadir Transición.

Una vez hemos pulsado, aparecerá una modal en la que podemos añadir la nueva transición. Una transición está compuesta por el estado Origen y el estado Destino, que refleja la dirección en la que pueden moverse posteriormente los elementos.

En la práctica, si quiero que un elemento pueda pasar del Product backlog a Ready2UX, y que pueda volver desde éste al Product Backlog, deberé crear 2 transiciones, una para cada sentido.

Vamos a crear la primera transición seleccionando en Estado Origen, Product Backlog, y en Estado destino Ready2UX.

A la hora de elegir un nombre os aconsejo que sea representativo de la transición. Por ejemplo ProductBacklog-Ready2UX. Cuando empecemos a manejar muchas transiciones, debemos tener claro con cuál estamos trabajando.

Por el momento no voy a hablar expresamente del elemento Pantalla, ya que lo veremos más adelante.

Ya tenemos nuestra primera transición. Repetimos la creación de estados y de transiciones tantas veces como sea necesario para reflejar nuestro flujo de trabajo. Hay que tener en cuenta además la direccionalidad de las transiciones.

NOTA: Hay una opción adicional cuando creamos un estado y es que se pueda llegar a él desde todos los demás.

Una vez hemos terminado de construir nuestro workflow, lo que tenemos que hacer es asociarlo a un proyecto. Después establecemos que issue types van a utilizarlo. Para ello nos desplazamos hasta JIRA -> Configuración de JIRA -> Incidencias -> Esquemas de flujos de trabajo

Dentro de un proyecto podemos aplicar uno o varios workflows dependiendo del issue type. No es lo mismo gestionar una incidencia que una nueva funcionalidad. En mi caso sí que voy a usar el mismo esquema para todos los issue types del proyecto. Para asociarlo hacemos clic en Editar para modificar el esquema por defecto.

Una vez estemos en el paso de edición es necesario hacer clic en Asignar. Así determinamos qué tipos vamos a poder usar con este workflow.

Para que las issues que no tienen un issue type asignado entren por este mismo flujo, es necesario marcar: Todas aquellas que no tengan issue type asignado.

Con esto ya tendríamos definido que comportamiento (workflow) tiene que seguir un issue type concreto en nuestro proyecto.

 

Crear campos personalizados (custom fields)

Siguiendo el ejemplo que comentaba más arriba, si quiero usar el campo «número de agente» tengo que ir a: JIRA -> Configuración de JIRA -> Incidencias -> Campos personalizados

A continuación pulsamos en Añadir campo personalizado. y se abrirá una modal donde podremos especificar el tipo de campo. En mi caso de tipo numérico.

Después podremos seleccionar un nombre (Número de agente) y una descripción (la que queráis). Pulsamos Crear.

A continuación nos pide que especifiquemos en qué pantalla queremos que aparezca este campo. Esto ya está relacionado con el siguiente bloque de creación de pantallas personalizadas. Por el momento podemos dejarlo vacío pulsando Actualizar.

Crear pantallas personalizadas (Screens)

En primer lugar hay que entender que son las pantallas o screens. Para resumirlo, son los «formularios» o ventanas modales desde los que interactuaremos con nuestras issues en nuestro workflow.

Por defecto JIRA ya posee una serie de pantallas por defecto que podemos emplear en nuestro proyecto. Pero, como se trata de tener las nuestras propias personalizadas, vamos a crear y establecer algunas específicas.

Si recordáis, en nuestro proyecto habíamos creado un issue type de Historia de usuario. Vamos a emplear ése como referencia para crear una pantalla específica. Usaremos esta pantalla durante la creación de issues de tipo historia con los campos que nosotros necesitamos.

Crear una pantalla específica: JIRA -> Configuración de JIRA -> Incidencias -> Pantallas

En la parte superior derecha le damos a Añadir pantalla, y se nos mostrará una modal. En ella podemos introducir un Nombre y una Descripción. Os recomiendo que para el título empleéis la nomenclatura del JIRA. Ejemplo:

• El código de proyecto (en mi caso AAT para AdictosAlTrabajo)
• El tipo de issue que va a poder usar esta pantalla User Story
• Y, por último, la denominación Screen para recordar a qué está haciendo referencia.

Esto quedaría: AAT: User Story Screen. La Descripción la dejo a vuestra elección.

Con esto tendremos creada la pantalla como tal, pero se trata de un mero esqueleto que solo no funciona. Una vez creada la pantalla, tenemos que configurarla, indicando qué elementos va a ver el usuario.

Hay que aclarar que una pantalla está compuesta por Pestañas y Campos. Las Pestañas nos permite organizar los campos que va a utilizar el usuario.

Lo primero es renombrar la Pestaña de campo como User Story y seleccionar los campos que quiero que contenga. Para ello usamos el desplegable Selecciona un campo...:

• Descripción
• Componentes
• Épica
• Enlace a la épica
• Etiquetas
• Story points

Aquí ya podríamos seleccionar el campo personalizado del apartado anterior.

Hay que tener en cuenta que el orden en el que los establezcamos, es el mismo en el que aparecerán después. Por ello, deberíamos cuidar el orden en el que se introducen de forma que ahorremos tiempo después a los usuarios.

En mi caso usaré una única pestaña, pero podríamos separar toda la información de la épica en una pestaña independiente. No es muy usable pero es un ejemplo didáctico.

Una vez tenemos nuestra pantalla configurada, lo siguiente que tenemos que hacer es crear un esquema de pantallas. Y la asociamos para indicar qué operaciones van a utilizar esta pantalla.

Una operación es lo que podemos hacer con el issue type para el que hemos creado la pantalla. Si pensamos en el de Historia de usuario que hemos usado de referencia, podríamos crearlo, editarlo o visualizarlo. Por ello podemos asociar hasta 3 pantallas diferentes, una para cada una de esas operaciones.

Para crear un esquema de pantallas vamos a: JIRA -> Configuración de JIRA -> Incidencias -> Esquemas de Pantallas

Veremos que no está vacío, ya que JIRA nos va creando algunos por defecto cuando creamos los proyectos. Podemos añadir uno nuevo con la opción de la parte superior derecha: Añadir esquema de pantallas. Donde podremos asignar el Nombre, la descripción y la pantalla por defecto

En el momento que pulsemos Añadir,  se creará un esquema de pantallas con la operación «Por Defecto». A este esquema se le se asociará la pantalla que hemos definido y que aplica a cualquier operación.

Podemos aplicar diferentes pantallas dependiendo de la operación. Para ello tenemos que emplear la opción de la parte superior derecha Asociar una operación de incidencia con una pantalla. Nos aparecerá una modal en la que podemos indicar el tipo de operación y la pantalla que queremos que se utilice para dicha operación.

Una vez rellena, pulsamos Añadir. Veremos a continuación como en la lista aparecen nuevos registros con la operación y la pantalla que hemos asociado.

 

Vale, ya tenemos creada y configurada nuestra pantalla con las pestañas y los campos. También hemos indicado en qué operación queremos que aplique. Pero nos falta asociar el esquema de pantallas para el tipo de incidencias determinado. Con esto vamos a terminar de especificar que campos queremos mostrar cuando se realice una operación. Las operaciones son de un tipo concreto (crear issue, editar issue…) Y aplican para un issue type (user story, bug…) determinado. Lo sé, es un poco enrevesado de leer, pero más fácil de que lo que parece.

Para asociar un esquema de pantallas a un issue type concreto vamos a JIRA -> Configuración de JIRA -> Incidencias -> Esquemas de Pantallas de Tipos de incidencia

Una vez añadido el nuevo esquema nos aparecerá la siguiente pantalla. En ella podremos seleccionar el issue type sobre el que aplican.

Según vayamos configurando veremos como se actualiza la lista.

 

Ahora vamos a volver atrás en el tiempo. Cuando hablaba al principio del tutorial de los workflows os dije que hablaría específicamente de las pantallas más adelante. Ahora que ya conocemos que son las pantallas, podemos volver a nuestro workflow y asociar una pantalla a una transición. Recordad que no deja de ser una operación de edición de un issue.

Nos desplazamos a JIRA -> Configuración de JIRA -> Incidencias -> Flujos de trabajo, editamos nuestro workflow AdictosAlTrabajo., seleccionamos la transición backlog-ready2ux y asociamos la pantalla AAT: User Story Screen.

 

Hasta aquí hemos realizado toda la configuración generalista, es decir aquella que podríamos reutilizar en diferentes proyectos.

Es importante aclarar que aunque hemos usado el acrónimo AAT o la denominación Adictos, no esta relacionado con él. Simplemente sirve como referencia para identificar en la configuración de JIRA la que hemos creado para este proyecto.

Vamos a pasar ahora sí, a las configuraciones específicas de nuestro proyecto de JIRA.

 

Configuraciones de Proyecto

Para modificar la configuración propia del proyecto, accedemos desde dentro del propio proyecto. Una vez dentro, en el menú del lateral izquierdo Proyecto -> Configurar el proyecto

Tipos de incidencia

Lo primero es vincular el esquema de tipos de incidencias que hemos creado a nuestro proyecto. Proyecto -> Configurar el proyecto -> Tipos de incidencia

Desde la lista de tipos de incidencias hacemos clic en la parte superior derecha en la opción Acciones. En el desplegable seleccionamos Utilizar un esquema diferente. Tenemos que seleccionar Elige un esquema de tipos de incidencia ya existente y buscamos el que habíamos creado previamente.

Una vez seleccionado ya tenemos nuestro esquema de tipos de incidencia asociado al proyecto, quedará así:

Workflows

El siguiente paso es asociar el flujo de trabajo que habíamos creado, para ello nos vamos a Proyecto -> Configuración de proyecto -> Flujos de trabajo

Desde aquí vamos a la opción Cambiar el Esquema en la parte superior de la pantalla. En el desplegable que aparece, seleccionamos el esquema de pantalla que habíamos creado anteriormente.

NOTA: Si el proyecto está en uso, tendremos que migrar las incidencias que no encajen con los nuevos estados. JIRA nos facilitará esa tarea en el siguiente paso. En nuestro caso como no hay nada que migrar simplemente tenemos que pulsar Asociado.

Solo nos quedaría mencionar otra opción que hay disponible en esta pantalla, que es Agregar Flujo de Trabajo.  Esta opción nos permite añadir al proyecto sin modificar el esquema original nuevos workflows. Podemos añadir uno que ya exista previamente o podemos incluso acceder al marketplace para descargar uno.

Configurar el panel

El panel es la representación visual de nuestro flujo de trabajo. Podemos configurar uno o varios para un mismo proyecto JIRA. Por defecto se creará uno. Para  acceder a él vamos a Proyecto -> Tablero

En la parte superior derecha tenemos un menú […] desde el que podemos acceder a la opción Configuración del tablero. Dentro de este menú de configuración encontramos las siguientes opciones:

• General. Podemos ajustar cosas como el título, administrador, proyecto al que pertenece, si hay filtros para las issues que se ven…
• Columnas. Las mismas que nuestro panel físico, tenemos que mapear los estados con estas columnas. Se diferencian en que es posible tener varios estados en una misma columna. Ej: Columna Bloqueado, puede ser por el estado Pendiente de pruebas de usuario final, o Pendiente de Arquitectura.
• Carriles. Nos permiten partir horizontalmente el tablero para mejorar la visualización del trabajo. Ej: Si tenemos desarrolladores especializados, podríamos dividir por las personas para ver la carga de trabajo en el sprint planning. Con esto podemos detectar cuellos de botella.
• Filtros rápidos. Podemos establecer filtros rápidos que aparecerán en la cabecera del panel para aplicar recurrentemente. Ej: Ver solo las incidencias de UX.
• Colores de las tarjetas. Se puede aplicar un patrón de color a la propia tarjeta basado en varias opciones, para facilitar la identificación visual. Por defecto no se aplica ninguno.
• Diseño de la tarjeta. Se puede configurar que las tarjetas muestran algunos campos adicionales, más allá de los que tiene preestablecidos JIRA.
• Estimación. Podemos identificar si empleamos Story Points u horas y controlar la dedicación.
• Días laborables. Permite establecer el calendario de trabajo del equipo, e incluso incluir los días no laborables.
• Vista de datos de incidencia. Nos permite configurar como visualizamos los detalles de una incidencia cuando accedemos a ella para ver toda la información.

 

Para el ejemplo, me voy a quedar solo con Columnas y Estimaciones. Los otros son elementos sencillos que podéis investigar vosotros mismos.

Vamos a empezar con las Columnas, por defecto solo tendremos 3, Por hacer, En curso y Listo.

Usando como referencia nuestro panel físico, vemos que es necesario adaptar las columnas al igual que hicimos con el workflow.

Vamos a cambiar el título de la columna «Por hacer» a BACKLOG. Después mediante la opción Añadir columna (parte derecha) vamos a agregar: READY2UX, READY2DEV y REOPENED. Con estas tres tendríamos definidas todas las columnas relacionadas con el trabajo en estado «pendiente» (gris).

Lo siguiente es asociar estos estados que hemos creado en nuestro workflow a las columnas. En nuestro caso la relación es 1:1, pero recordad que podemos tener varios estados para una misma columna.

Hacemos lo mismo para el resto de columnas que quedan pendientes de nuestro flujo de trabajo.

Una vez que hayamos terminado, solo nos quedará arrancar el Sprint. En la opción de menú Sprints activos ya podremos ver nuestra nueva y flamante visualización del panel.

Cuando movamos los issues, veremos a qué columnas podemos desplazarlos en base a las transiciones definidas en el workflow.

Espero que os ayude a comprender un poco mejor JIRA y a hacer que la herramienta trabaje a vuestro servicio.

Como nota final, la flexibilidad y el control tienen un precio, desperdicio de tiempo y complejidad. Un panel físico es más sencillo y por eso es nuestra recomendación siempre para empezar a trabajar con los equipos. Cuando se alcanza un grado de madurez mínimo nos podemos plantear migrar a uno virtual, sea la herramienta que sea.