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:
- Nuestro Product Backlog «el de toda la vida» que tiene todos los elementos que consideramos para nuestro producto/proyecto.
- 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.
- 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.
- Sprint Backlog, el bloque de funcionalidad que vamos a trabajar en la siguiente iteración.
- Doing, aquellos elementos en los que estamos trabajando actualmente.
- Blocked, esta columna es muy útil en equipos poco maduros y sobre todo en escenarios con fuertes dependencias de terceros.
- 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.
- 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):
- 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).
- 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.
- 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.
- 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.
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.
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.
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.
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.
¡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?
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.
Hola! Gracias por el post, es bastante util.
Y solo una duda, has generado algun contenido acerca de la gestion de accesos y usuarios?
Saludos!
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
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.
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