Cómo crear un proyecto personalizado desde cero en JIRA Cloud con un Workflow Clásico

16
33605
Página principal de un proyecto JIRA Cloud

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).

Imagen del formulario de registro de usuario en portar Atlassian
Formulario de registro en Atlassian para poder darnos de alta.

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.

Imagen con el correo de confirmación de nuestra cuenta Atlassian.
Correo de confirmación de nuestra cuenta Atlassian.
Imagen del correo de Atlassian que nos remite con el acceso a nuestro site.
Correo de acceso a nuestro site una vez está disponible.

 

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

Imagen de la pantalla inicial de login en nuestro site de JIRA
Pantalla de login de nuestro JIRA Cloud

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.

Asistente para la creación de nuestro primer proyecto en JIRA
Asistente de configuración de nuestro primer proyecto.

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.

Plantillas que nos ofrece el asistente de creación de proyecto
Plantillas por defecto disponibles para crear nuestro proyecto.

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.

Diagrama que representa la estructura de un proyecto JIRA
Estructura de un proyecto JIRA

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.

Imagen con los datos necesarios para la creación de un proyecto en JIRA
Nombre e identificador al crear nuestro proyecto JIRA.

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

Imagen de la página principal del proyecto por defecto creado en JIRA
Página principal de nuestro proyecto 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:

Ejemplo de panel en una hoja de cuaderno para modelar en JIRA
Ejemplo de un flujo de trabajo en papel que modelar en JIRA.
  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:

Imagen que muestra una ventna modal para crear un nuevo tipo de incidencia en JIRA
Imagen del formulario para crear un nuevo Issue Type.

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.

Listado de tipos de incidencias de JIRA don de vemos un nuevo tipo de incidencia llamada Adictos
Listado de Issue Types con un nuevo tipo Adictos

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:

Lista de tipos de incidencias disponibles para agregar al esquema.
Lista de tipos de incidencias disponibles para agregar al esquema.

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í:

Imagen que representa la lista de issue types que he añadido a mi esquema de JIRA
Lista de Issue Types añadidos a mi esquema de tipos de incidencias de JIRA

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:

Imagen con el resumen del esquema de issue types que acabamos de crear
Listado donde aparece el esquema de issue types que acabamos de crear

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:

Imagen que muestra como asociar un esquema de issue types a proyecto
Asociación de un esquema a uno o varios proyectos.

 

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

Imagen que muestra una pantalla JIRA con la lista de flujos de tabajo disponibles y donde podemos crear uno nuevo
Lista de flujos de trabajo en JIRA

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.

Imagen del formulario de creación de un workflow con nombre y descripción.
Creación de un workflow con nombre y descripción.

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.

Imagen que muestra un workflow nuevo en modo visual para empezar a modelarlo.
Nuevo workflow para definir

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.

Imagen que muestra el formulario para editar un estado existente
Modificar un estado existente

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).

Imagen que refleja el formulario de creación de un estado nuevo.
Podemos incluir un estado nuevo en el workflow, exista o no previamente

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.

Imagen del gráfico de workflow donde aparece u nuevo estado separado sin unir mediante una transición.
Nuevo estado de JIRA incluido en un workflow pero sin 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.

Imagen que muestra el formulario para añadir una nueva transición en nuestro workflow
Como añadir una transición en JIRA

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.

Imagen que muestra una primera transición entre estados en JIRA
Mi primera transición entre estados

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.

Imagen que refleja el flujo de trabajo completo JIRA
Flujo de trabajo completo

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.

Imagen que muestra en la lista de esquemas el esquema de flujo de trabajo asignado por defecto
Esquema de flujo de trabajao asignado 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.

Imagen que muestra como cambiar flujo por defecto asignado
Cambiar flujo por defecto asignado
Imagen de la asociación de Issue Types con el Workflow Schema
Asociación de Issue Types con el Workflow Schema

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

Pantalla de JIRA que muestra los campos personalizados de JIRA
Campos personalizados de JIRA

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.

Imagen que muestra como crear el tipo de un campo personalizado de JIRa
Tipo de campo personalizado de JIRa

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

Imagen que muestra el nombre y descripción de campo personalizado JIRA
Nombre y descripción de campo personalizado JIRA

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.

Imagen que muestra como Asociar campo personalizado a un pantalla
Asociar en JIRA un campo personalizado a un pantalla

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

Imagen de JIRA que muestra la sección de configuración de pantallas
Configuración de pantallas de JIRA.

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.

Imagen de JIRA donde se muestra la capa modal para introducir el título y la descripción
Capa modal de JIRA que nos permite crear una nueva pantalla

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
Imagen que muestra la lista de nuevos campos para una pantalla de JIRA
JIRA, campos seleccionados para una nueva pantalla.

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

Imagen de la lista de esquemas de pantalla de JIRA
JIRA, lista de esquemas de pantalla

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

La imagen muestra una modal de JIRA para añadir esquema de pantallas
Añadir esquema de pantallas en JIRA

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.

IMagen de JIRA que muestra la pantalla de configuración de esquemas de pantallas
JIRA, esquema de pantallas por defecto.

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.

Imagen de una modal de JIRA donde asociar una operación a una pantalla
Asociación en JIRA de una operación a una pantalla

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.

Imagen de JIRA que muestra como se han asociado varias operaciones a diferentes pantallas en un mismo esquemas de pantalla
JIRA, múltiples operaciones con diferentes pantallas asociadas.

 

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

Imagen de JIRA que muestra como asociar esquema de pantallas por tipo de incidencia
JIRA, asociar esquema de pantallas por tipo 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.

Modal de JIRA en la que se puede asociar un esquema de pantallas a un issue type concreto
Asociación de un esquema de pantallas a un issue type concreto

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

Lista de JIRA donde se ven diferentes issue types con su esquema de pantallas asociado
Múltiples issue types con su esquema de pantallas

 

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.

Imagen que muestra como añadir una pantalla a una transición del workflow
Editar un transición del workflow para añadir una pantalla

 

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

Imagen de la página principal del proyecto por defecto creado en JIRA
Página principal de nuestro proyecto JIRA.

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.

Imagen que muestra como asociar esquema de tipos de incidencia a un proyecto
Asociar en JIRA un esquema de tipos de incidencia a un proyecto

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

imagen de JIRA con tipos de incidencia de un proyecto JIRA
Esquema de Tipos de incidencia asociado a un proyecto JIRA.

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

Imagen de JIRA que muestra el workflow de un proyecto
Workflow de un proyecto JIRA

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.

Imagen que muestra como cambiar es esquema de workflows de un proyecto
Cambiar esquema de workflow en un proyecto JIRA

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.

JIRA Migración de issues al cambiar workflow
Al cambiar un workflow JIRA nos permite migrar las incidencias para que se adapten

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

Imagen de la página principal del proyecto por defecto creado en JIRA
Página principal de nuestro proyecto JIRA.

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:

Imagen que muestra el menú desde el que configurar el tablero de JIRA
Acceso a la configuración del tablero JIRA
  • 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.

Imagen que muestra las columnas por defecto de un tablero JIRA
Columnas por defecto de un tablero JIRA

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

Ejemplo de panel en una hoja de cuaderno para modelar en JIRA
Ejemplo de nuestro flujo de trabajo en papel para modelar en JIRA.
Imagen que refleja el flujo de trabajo completo JIRA
Flujo de trabajo modelado en JIRA y sobre el que se apoyará nuestro panel

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).

Imagen que muestra las nuevas columnas del tablero de proyecto.
Nuevas columnas del tablero de proyecto.

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.

Imagen que muestra como asignar los estados a nuestras columnas del tablero JIRA
Asignamos los estados a nuestras columnas del tablero JIRA

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

Imagen que muestra la configuración finalizada de nuestro panel en JIR
Configuración finalizada de nuestro panel en JIRA.

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.

Imagen que muestra la transición de una issue entre las columnas de nuestro panel.
Transición de una issue entre las columnas de nuestro panel.

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.

16 COMENTARIOS

  1. Buenas tardes.

    Ante todo muy bueno el tutorial, gracias. Pero le escribo debido a que soy relativamente nueva usando JIRA y no entiendo la funcionalidad de múltiples tableros para un proyecto.

    Actualmente llevo un proyecto tipo scrum, en el cual quisiera dividir las actividades de cada equipo de desarrollo (backend, frontend, etc) en un tablero por separado; el procedimiento que realizo es:
    1. Crear los tableros antes de crear tareas
    2. Creo las tareas en el backlog por cada tablero y le asigno todos los datos pertinentes (responsable, estimación, comentarios, etiquetas, versión, épica, adjuntos, etc).
    El problema se presenta, en que 1ro. debería permitirme llevar un Sprint por cada tablero (el menú dice Sprints Activos en plural) y no lo hace, no se si se puede configurar para que lo permita; y 2do. que si en todo caso es 1 Sprint por proyecto, debería permitir colocar las tareas en cada tablero de manera separada y no mezclarlas todas en la columna de TO DO o se deberían filtrar de alguna manera. ¿Que filtro debo aplicar para poder dividir las tareas en cada tablero o como se deben configurar los tableros para poder hacer ésta separación? Gracias.

    Saludos cordiales.

    • Hola Lorena,
      El poder disponer de multiples tableros en un mismo proyecto permite que puedan personalizarse las visualizaciones manteniendo siempre la misma información base. De esa forma se puede conseguir por ejemplo visualizaciones cuando nuestros equipos trabajan por componentes (que por tu comentario entiendo que es como están trabajando los equipos). Sin entrar en la propia gestión de scrum, lo que puedes hacer es emplear los componentes de JIRA para etiquetar las issues que quieres que vea cada equipo. Y a continuación puedes crear un panel para cada equipo donde incluyas en la JQL (la consulta, puedes acceder a ella desde Board setting > General > Edit filter query) que filtra las issues de cada panel de forma que solo se vean las de ese equipo. Por ejemplo, vamos a pensar en tres componentes, UX, Front y Back. Una vez creados, habría que crear 3 paneles con las JQL del tipo: project = TUPROYECTO and component = UX , project = TUPROYECTO and component = FRONT y project = TUPROYECTO and component = BACK.

      Con restos filtros podrás mantener la misma gestión del sprint, pero separando por cada equipo usando los componentes. En cualquier caso se mantiene el sprint y la entrega de valor integrada que es lo que buscamos. Espero que esto te ayude. Saludos.

    • Hay una segunda opción que es usar el mismo panel (de hecho JIRA es tan flexible que normalmente podrás emplear varias soluciones para el mismo fin), pero visualizando swimlanes por componente (visualizar como carriles de una piscina para cada equipo en el mismo panel), aplicaría el uso de componentes comentado en el caso anterior, es decir creamos los componentes y usamos las JQL de referencia en la sección Board setting > Swimlanes > Base swimlanes on queries. Saludos.

  2. Hola, primero felicitarte por tu post, segundo pues no entiendo como darle color a las tarjetas para diferenciarlas. Por ejemplo me gustaria crear etiquetas personalizadas con un color en particular por etiqueta pero no sé como. Espero puedas darme alguna pista de como hacerlo.
    Gracias de antemano.

    • Hola Juan, hasta la fecha JIRA no soporta esa funcionalidad de la misma forma en la que lo hacen otras aplicaciones como Trello o Github, la única forma actual de dar color a las tarjetas para solucionar lo que comentas es:
      1. Accede a la configuración del panel con el que estés trabajando
      2. En el menú de configuración del panel (a la izquierda) busca la opción «Card colours»).
      3. En el desplegable «Colours based on», selecciona Queries.
      4. Te aparecerá una linea de con figuración donde puedes seleccionar el color (por ejemplo el azul) y además aparece un campo de texto donde incluir una JQL. Puedes usar algo así: labels=»azul» (o la etiqueta que tú quieras).

      Es una forma rudimentaria, ya que te obliga a crear una entrada por cada nuevo color que quieras añadir. Espero que te sirva.

  3. Hola,
    Primero, felicitarte por el post; me ha sido de gran ayuda.
    Tengo varias preguntas sobre el máximo de algunos componentes / campos:
    – ¿Qué máximo de issues se pueden dar de alta en un proyecto de Jira? ¿O dónde se puede configurar ese máximo de issues por proyecto?
    – Máximo de Etiquetas y/o Componentes que se pueden asociar a una issue.
    – Máximo de caracteres del campo Comentario de una issue,
    Muchas gracias de antemano.

    • Hola Roberto, no sé si entiendo bien el enfoque de las preguntas.
      1. El máximo del producto en palabras el propio Atlassian es infinito, lo que empezarás a acusar cuando hablemos de millones es que el rendimiento puede verse afectado. Por otro lado si lo que comentas es limitar tú el máximo de issues de un proyecto ¿por qué querrías hacerlo? Tus necesidades pueden cambiar y estarías condicionado. Si lo que quieres es limitar quien puede hacerlo para que no se dispare el número de issues (pensemos en un proyecto tradicional con un numero de elementos fijo, aunque no sea la mejor práctica 😉 ), puedes hacerlo gestionando los permisos del proyecto, tendrías que quitar le permiso «Create issue» a todos excepto a aquellos que quieras que puedan crear las issues. No tienes un máximo pero sí un control.
      2. De nuevo el producto como tal no limita la cantidad de etiquetas/componentes, si bien atendiendo a un numero muy elevado de ellas puede condicionar el funcionamiento del producto. Es decir, JIRA puede manejar tantas como se necesite, pero si es un uso masivo puede de nuevo afectar al rendimiento.
      3. Esta configuración solo está disponible en la versión OnPremise, en la Cloud por el momento no (hay una petición abierta a Atlassian para implementarlo). En la actualidad ni siquiera usando «Custom fields» en su lugar podrías limitarlo, aunque por defecto estos cuentan con un límite de 255 caracteres. Si cuentas con una instalación OnPremise, sí que puedes configurar este límite de forma general para todos los proyectos de tu instancia JIAR (no solo para uno específico). Puedes configurarlo desde «Administration > General Settings > Advanced». Espero que te ayuden las respuestas.

  4. Estimado Jesus muy bueno el Tutorial, quisiera saber si hay otros, fui usario de Jira Server en 2015 en Venezuela y actualmente estoy en Chile y tengo una propuesta de trabajo con Jira Cloud.

    Me registre tal cual lo indicas en el tutorial, tengo unas dudas mas alla del tutorial y quisiera me puedas apoyar:

    1. Como logro en Jira Software Cloud, habilitar la barra de navegacion lateral del lado izquierdo , he visto tutoriales que aparece de ese lado pero en este cloud el boton Crear aparece en la parte superior, querría saber como activar esa barra lateral-

    2. El cliente que voy atender tiene 200 usuarios de Jira Cloud con proyectos de sus Gerencias de Redes y Operaciones, si ellos quieren incorporar a otras gerencias cual seria el esquema:

    a) Crear una nueva instancia de 100 usuarios con nuevas gerencias y como le podemos enviar informacion a la instancia de 200 usuarios, o sea como seria la integracion?, para mantener los 2 separados

    b) Podria migrarse todo ese ambiente de 200 usuarios al nuevo que se adquiera

    c) O mas simple aumentamos el numero de usuarios del actual y no hay que crear una nueva instancia

    • Hola Francisco,
      Te intento responder a tus dudas.

      1. Sobre la barra de navegación y su posición entiendo que te refieres a la opción para crear incidencias (issues), si es así en JIRA Cloud la posición siempre es la misma por defecto, no es algo que personalices. Por lo que comentas si está en la parte superior, puede ser una señal de que estén usando la versión OnPremise en lugar de la Cloud, y en esta efectivamente está situado en la parte superior.

      2. Si ya tienen una instancia JIRA lo lógico parece aumentar el numero de usuarios sobre esa instancia, a priori no le veo la razón a tenerlas independientes.

    • Hola Francisco, te actualizo, en la última versión de JIRA Cloud, Atlassian ha modificado la interfaz, de forma que las opciones del menú lateral izquierdo se han desplazado de nuevo a la cinta superior.

  5. ¡Excelente trabajo! Llegué aquí buscando una solución a algo que quiero hacer y no se realmente si se puede.
    Soy QA Manager, y lo que estoy buscando es ahorrarnos tiempo de trabajo a mi y al resto de los QA a la hora de generar los reportes.
    Actualmente usamos el campo de descripción, no solo para la descripción, sino también para incluir:
    • Pasos a Reproducir
    • Resultado Obtenido
    • Resultado Esperado

    Me interesa poder separarlos y que imiten el campo de Descripción (en todo sentido), por lo que he creado para probar, el campo de Pasos a Reproducir mediante el Custom Field.

    Logré imitarlo a la hora de realizar el ticket para que se vea igual. El problema que tengo es con la visualización cuando el ticket es creado.
    Lo que está ocurriendo es que se ven en la parte superior junto con las prioridades, el ambiente, el sprint, y demás, y no solo eso, sino que se ve plegado.

    Lo que quisiera es que pueda verse debajo del campo descripción y se vea desplegado, al igual que la descripción.
    Se que en una época tenía forma de cambiar la disposición de la visualización del issue, pero ahora no estoy viendo nada de eso.
    ¿Hay forma?

  6. Buenas tardes,

    Gran trabajo y muy util para montar nuestro propio Jira, pero estoy intentando relacionar los tipos de incidencia de las siguientes estructura:

    Grupo Funcional –> Épica –> Historia de Usuario –> Tarea –> Subtarea
    Grupo Funcional –> Épica –> Historia de Usuario –> BUG –> Subtarea

    ¿Sería posible o existe algún plugin gratuito?

    Saludos.

  7. Muchas gracias Jesús, muy bien explicado. Aunque no encontré lo buscaba (categorias y organizaciones), pero me ayudó a aclararme en ese mar que es Jira

  8. Buenas tardes

    Tengo una duda, tengo un proyecto que al momento de crear una tarjeta desde el backlog enves de hacerlo desde ahi mismo, me sale un popup para llenar los campos, quiero quitar nose si es configuracion y me deje crear de forma simple.

  9. Muchas gracias por este tutorial.
    Quisiera consultarte algunas preguntas.
    La primera es que ma ha pasado que en un workflow definí un nombre de una transición y una pantalla asociada. Todo funciona bien excepto que el nombre de la transición cuando paso la tarea de un estado al otro me aparece la transición con otro nombre «Aprobar», es decir, el nombre que definí en la transición en el workflow no es el mismo que se refleja cuando hago la transición de la issue.
    Tambien quería preguntarte si es necesario que para cada pantalla se cree un esquema de pantalla, es que no entiendo muy bien como funciona esto de los esquemas de pantalla, para que se usan, y además no entiendo la diferencia entre «Asociar un tipo de incidencia con un esquema de pantalla» y «Asociar una operación de incidencia a una pantalla», no entiendo cual es la finalidad de cada una o la diferencia.
    Finalmente, ¿tu ofreces formación por horas? Me gustaría invertir en alguna clase para verificar lo que he podido hacer.

    Muchas gracias

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad