jira user guide 1.01

Enrico M. Crisostomo

Atlassian JIRAThe Definitive Guide

Volumen iGuía del usuario

Casos de uso y ejemplos

Volumen i:Guía del usuario

Casos de uso y ejemplos

Volumen ii:Instalación

Guía del administradorCasos de uso y ejemplos

Atlassian JIRA, The Definitive Guide, Volumen i.2012 — Versión 1.01.

Este libro está protegido por la licencia Creative Commons Attribution—Noncommercial—NoDerivs 3.0 Unported (CC BY—NC—ND 3.0) cuyo términos pue-den consultarse en [3].Bajo los términos de esta licencia al usuario se garantiza el derecho de:

(i) Compartir este libro, copiando, distribuyendo y transmitiendo esta obra.Bajo esta condiciones el usuario:

(i) Debe atribuir el trabajo al autor de esta obra en las formas especificadaspor el autor o quién licencia esta obra (pero no en ninguna forma quesugiera que éstos aprueban al usuario o al uso que éste hace de la obra.

(ii) No puede utilizar la obra por fines comerciales.(iii) No puede alterar, transformar esta obra o construir sobre esa trabajos

derivados.Se entiende que:

(i) Cualquiera de las condiciones mencionadas pueden derogarse en el caso elusuario obtenga el permiso del titular del copyright.

(ii) Cuando la obra, o parte de la misma, esté en el dominio público [4] bajolas leyes aplicables, dicho status no será afectado por los términos de estalicencia.

De ninguna forma esta licencia afectará a los siguientes derechos:(i) Derechos de uso justo [5] u otras excepciones o limitaciones a las leyes sobre

el copyright.(ii) Los derechos morales del autor [6].(iii) Los derechos que otros sujetos puedan tener sobre la obra misma o en su

utilización, tales como la publicidad [7] o el derecho a la privacidad.Para cualquier utilización o distribución de la obra, es obligatorio aclarar lostérminos de licencia de la obra. La mejor manera de hacerlo es hacer una citacióna [2] o, incluso, replicar el contenido de esta página.

JIRA, GreenHopper, Confluence, FishEye, Crucible, Bamboo y Crowd son marcasregistradas de Atlassian.

Atlassian JIRAThe Definitive Guide

Índice general

Índice general v

Índice de figuras xv

Índice de tablas xxiii

Prefacio xxviiRelación con la documentación oficial de JIRA . . . . . . . xxviiA quién está dirigido cada volumen . . . . . . . . . . . . . . xxviiiNomenclatura . . . . . . . . . . . . . . . . . . . . . . . . . . xxxConvenios tipográficos . . . . . . . . . . . . . . . . . . . . . xxxEl formato de este libro . . . . . . . . . . . . . . . . . . . . xxxiSugerencias . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi

Prefacio a la guía del usuario xxxiii

1 Introducción 31.1 Interfaz gráfica . . . . . . . . . . . . . . . . . . . . . . 31.2 Los cuadros de mandos . . . . . . . . . . . . . . . . . 51.3 JIRA es OpenSocial . . . . . . . . . . . . . . . . . . . 51.4 Flexibilidad . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Facilidad de gestión . . . . . . . . . . . . . . . . . . . 71.7 Elegir una licencia . . . . . . . . . . . . . . . . . . . . 8

1.7.1 Licencias comerciales . . . . . . . . . . . . . . . 81.7.2 Licencia gratuita . . . . . . . . . . . . . . . . . 91.7.3 Contactar con un Experto . . . . . . . . . . . . 9

v

Índice general

2 Conceptos básicos 112.1 Proyectos . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 Componentes . . . . . . . . . . . . . . . . . . . 122.1.2 Versiones . . . . . . . . . . . . . . . . . . . . . 14

2.2 Incidencias . . . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Tipo de incidencia . . . . . . . . . . . . . . . . 182.2.2 Campos . . . . . . . . . . . . . . . . . . . . . . 192.2.3 Prioridad . . . . . . . . . . . . . . . . . . . . . 212.2.4 Estado . . . . . . . . . . . . . . . . . . . . . . . 222.2.5 Resolución . . . . . . . . . . . . . . . . . . . . 23

2.3 Flujos de trabajo . . . . . . . . . . . . . . . . . . . . . 242.4 Organización de los conceptos . . . . . . . . . . . . . . 262.5 Esquemas . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5.1 Desacoplamiento de proyectos y reutilización deesquemas . . . . . . . . . . . . . . . . . . . . . 30

2.5.2 Tipos de incidencias disponibles . . . . . . . . 302.5.3 Configuración de campos . . . . . . . . . . . . 302.5.4 Configuración de pantallas . . . . . . . . . . . . 312.5.5 Flujos de trabajos disponibles . . . . . . . . . . 322.5.6 Notificaciones . . . . . . . . . . . . . . . . . . . 322.5.7 Políticas de seguridad . . . . . . . . . . . . . . 352.5.8 Niveles de seguridad de las incidencias . . . . . 36

3 Primeros pasos 393.1 Login: acceder a JIRA . . . . . . . . . . . . . . . . . . 393.2 Cuadro de mando . . . . . . . . . . . . . . . . . . . . . 403.3 Barra de las herramientas . . . . . . . . . . . . . . . . 41

3.3.1 Menú Dashboards . . . . . . . . . . . . . . . . 423.3.2 Menú Projects . . . . . . . . . . . . . . . . . . 433.3.3 Menú Issues . . . . . . . . . . . . . . . . . . . . 433.3.4 Menu Administration . . . . . . . . . . . . . . 443.3.5 Menu del usuario . . . . . . . . . . . . . . . . . 45

3.4 Atajos de teclado . . . . . . . . . . . . . . . . . . . . . 453.4.1 Tecla modificadora . . . . . . . . . . . . . . . . 453.4.2 Atajos globales . . . . . . . . . . . . . . . . . . 473.4.3 Atajos de las ventanas de incidencias . . . . . . 473.4.4 Atajos en los formularios . . . . . . . . . . . . 47

4 Explorar un proyecto 514.1 Estructura . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.1 Acceso rápido a la creación de incidencias . . . 53

vi

Índice general

4.1.2 Acceso a información adicional . . . . . . . . . 554.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2.1 Activity Stream . . . . . . . . . . . . . . . . . . 584.3 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.4 Road Map . . . . . . . . . . . . . . . . . . . . . . . . . 584.5 Change Log . . . . . . . . . . . . . . . . . . . . . . . . 604.6 Popular Issues . . . . . . . . . . . . . . . . . . . . . . 614.7 Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.7.1 Builds de la versión . . . . . . . . . . . . . . . 634.8 Components . . . . . . . . . . . . . . . . . . . . . . . . 654.9 Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.10 Builds de Bamboo . . . . . . . . . . . . . . . . . . . . 684.11 Fisheye changesets: cambios en las fuentes . . . . . . . 69

5 Manejo de incidencias 715.1 Creación de una incidencia . . . . . . . . . . . . . . . 73

5.1.1 Citación de otros usuarios y envío de mail . . . 775.2 Ventana de detalle de incidencia . . . . . . . . . . . . 785.3 Operaciones disponibles . . . . . . . . . . . . . . . . . 795.4 Compartir una incidencia por correo electrónico . . . . 81

5.4.1 Citar un usuario . . . . . . . . . . . . . . . . . 815.4.2 Compartir una incidencia . . . . . . . . . . . . 81

5.5 Adjuntar ficheros o capturas de pantallas a una incidencia 825.6 Gestionar los ficheros adjuntos . . . . . . . . . . . . . 85

5.6.1 Ordenar los ficheros adjuntos . . . . . . . . . . 865.6.2 Acceder al contenido de adjuntos de tipo ZIP . 865.6.3 Eliminar ficheros adjuntos . . . . . . . . . . . . 875.6.4 Bajar todos los adjuntos en un archivo ZIP . . 875.6.5 Adjuntar una captura de pantalla . . . . . . . . 88

5.7 Comentarios . . . . . . . . . . . . . . . . . . . . . . . . 905.7.1 Modificar un comentario . . . . . . . . . . . . . 915.7.2 Eliminar un comentario . . . . . . . . . . . . . 925.7.3 Crear un enlace a un comentario . . . . . . . . 92

5.8 Campos de texto formateado . . . . . . . . . . . . . . 925.8.1 Macros . . . . . . . . . . . . . . . . . . . . . . 935.8.2 Sintaxis de las macros . . . . . . . . . . . . . . 945.8.3 Macro code . . . . . . . . . . . . . . . . . . . . 94

5.9 Sub-tareas . . . . . . . . . . . . . . . . . . . . . . . . . 955.9.1 Crear sub-tareas . . . . . . . . . . . . . . . . . 965.9.2 Gestión de sub-tareas . . . . . . . . . . . . . . 985.9.3 Convertir una incidencia en sub-tarea . . . . . 100

vii

Índice general

5.9.4 Convertir una sub-tarea en incidencia . . . . . 1015.10 Duplicar una incidencia . . . . . . . . . . . . . . . . . 102

5.10.1 Crear un enlace a una incidencia duplicada . . 1035.10.2 Prefijo del título de las incidencias duplicadas . 1045.10.3 Duplicación de incidencias y sub-tareas . . . . 104

5.11 Enlaces entre incidencias . . . . . . . . . . . . . . . . . 1045.11.1 Gestionar los enlaces entre incidencias . . . . . 108

5.12 Planificar las incidencias . . . . . . . . . . . . . . . . . 1095.12.1 Filtrar incidencias utilizando la fecha de reso-

lución . . . . . . . . . . . . . . . . . . . . . . . 1095.13 Proteger una incidencia . . . . . . . . . . . . . . . . . 113

5.13.1 Caso de uso: segmentación de usuarios . . . . . 1135.13.2 Caso de uso: proteger información confidencial 1155.13.3 Proteger una incidencia . . . . . . . . . . . . . 115

5.14 Poner etiquetas a una incidencias . . . . . . . . . . . . 1175.14.1 Eliminar una etiqueta . . . . . . . . . . . . . . 119

5.15 Trabajar sobre una incidencia . . . . . . . . . . . . . . 1205.15.1 Hacer una estimación del trabajo requerido . . 1225.15.2 Registrar trabajo sobre una incidencia . . . . . 1235.15.3 Registrar trabajo durante una transición de es-

tado en el flujo de trabajo . . . . . . . . . . . . 1255.15.4 Crear un enlace a un registro de trabajo . . . . 1275.15.5 Modificar un registro de trabajo . . . . . . . . 1275.15.6 Eliminar un registro de trabajo . . . . . . . . . 128

5.16 Mover una incidencia . . . . . . . . . . . . . . . . . . . 1295.17 Modificar múltiples incidencias a la vez . . . . . . . . 132

5.17.1 Inhabilitar las notificaciones durante una ope-ración masiva . . . . . . . . . . . . . . . . . . . 134

5.17.2 Efectuar una operación masiva . . . . . . . . . 1345.17.3 Operación masiva de eliminación . . . . . . . . 1365.17.4 Operación masiva de migración . . . . . . . . . 1375.17.5 Operación masiva de modificación . . . . . . . 140

5.18 Registro histórico de cambios de una incidencia . . . . 1445.19 Integración de JIRA con otras aplicaciones . . . . . . 147

5.19.1 Crear enlaces a incidencias en otras instanciasde JIRA . . . . . . . . . . . . . . . . . . . . . . 147

5.19.2 Enlaces a páginas de Confluence . . . . . . . . 1495.19.3 Enlaces a páginas web . . . . . . . . . . . . . . 1505.19.4 Revisiones de Crucible . . . . . . . . . . . . . . 1505.19.5 Changesets de FishEye . . . . . . . . . . . . . . 1515.19.6 Builds de Bamboo . . . . . . . . . . . . . . . . 153

viii

Índice general

5.20 Observar y votar una incidencia . . . . . . . . . . . . . 153

6 Buscar y filtrar incidencias 1576.1 Búsquedas simples . . . . . . . . . . . . . . . . . . . . 158

6.1.1 Panel principal de búsqueda . . . . . . . . . . . 1596.1.2 Panel de búsqueda por componentes y versiones 1616.1.3 Panel de búsqueda por atributos de incidencia 1636.1.4 Panel de búsqueda por fechas . . . . . . . . . . 1646.1.5 Panel de búsqueda por porcentaje de trabajo

realizado . . . . . . . . . . . . . . . . . . . . . 1676.1.6 Panel de búsqueda por campos personalizados 1676.1.7 Modificar manualmente una query simple . . . 168

6.2 El navegador de incidencias . . . . . . . . . . . . . . . 1726.2.1 Crear un enlace permanente a una búsqueda . 1726.2.2 Herramientas en el navegador de incidencias . . 1736.2.3 Ordenar los resultados . . . . . . . . . . . . . . 1736.2.4 Visualizar las incidencia . . . . . . . . . . . . . 177

6.3 Configurar el navegador de incidencias . . . . . . . . . 1776.3.1 Configurar las columnas visualizadas . . . . . . 1786.3.2 Configurar el número de líneas visualizadas . . 180

6.4 Búsquedas de texto . . . . . . . . . . . . . . . . . . . . 1816.4.1 Estructuras de las consultas . . . . . . . . . . . 1826.4.2 Búsquedas aproximadas . . . . . . . . . . . . . 1846.4.3 Búsquedas fuzzy . . . . . . . . . . . . . . . . . 1846.4.4 Búsquedas por proximidad . . . . . . . . . . . 1846.4.5 Búsqueda por importancia . . . . . . . . . . . . 1856.4.6 Operadores . . . . . . . . . . . . . . . . . . . . 185

6.5 Búsquedas rápidas . . . . . . . . . . . . . . . . . . . . 1876.5.1 Navegar a una incidencia . . . . . . . . . . . . 1886.5.2 Incidencias asignadas a uno mismo . . . . . . . 1886.5.3 Incidencias por reporter . . . . . . . . . . . . . 1896.5.4 Incidencias en un proyecto . . . . . . . . . . . . 1896.5.5 Incidencias atrasadas . . . . . . . . . . . . . . . 1896.5.6 Incidencias por fecha . . . . . . . . . . . . . . . 1896.5.7 Incidencias por estado . . . . . . . . . . . . . . 1906.5.8 Incidencias por resolución . . . . . . . . . . . . 1906.5.9 Incidencias por prioridad . . . . . . . . . . . . 1906.5.10 Incidencias por tipo . . . . . . . . . . . . . . . 1906.5.11 Incidencias por versión . . . . . . . . . . . . . . 1916.5.12 Incidencias por versión de resolución . . . . . . 1916.5.13 Incidencias por componente . . . . . . . . . . . 191

ix

Índice general

6.5.14 Integración con navegadores . . . . . . . . . . . 191

7 Búsquedas avanzadas 1957.1 Estructura de una query JQL . . . . . . . . . . . . . . 1967.2 Caracteres reservados . . . . . . . . . . . . . . . . . . 1977.3 Palabras reservadas . . . . . . . . . . . . . . . . . . . . 1977.4 Campos . . . . . . . . . . . . . . . . . . . . . . . . . . 1977.5 Palabras claves . . . . . . . . . . . . . . . . . . . . . . 198

7.5.1 Palabra clave and . . . . . . . . . . . . . . . . . 1997.5.2 Palabra clave or . . . . . . . . . . . . . . . . . 1997.5.3 Palabra clave not . . . . . . . . . . . . . . . . . 2007.5.4 Palabra clave empty . . . . . . . . . . . . . . . 2007.5.5 Palabra clave null . . . . . . . . . . . . . . . . 2017.5.6 Palabra clave order by . . . . . . . . . . . . . 201

7.6 Operadores . . . . . . . . . . . . . . . . . . . . . . . . 2017.6.1 Operador equals . . . . . . . . . . . . . . . . . 2027.6.2 Operador not equals . . . . . . . . . . . . . . 2027.6.3 Operador greater than . . . . . . . . . . . . . 2037.6.4 Operador greater than equals . . . . . . . . 2047.6.5 Operador less than . . . . . . . . . . . . . . . 2047.6.6 Operador less than equals . . . . . . . . . . 2057.6.7 Operador in . . . . . . . . . . . . . . . . . . . 2057.6.8 Operador not in . . . . . . . . . . . . . . . . . 2067.6.9 Operador contains . . . . . . . . . . . . . . . 2067.6.10 Operador does not contain . . . . . . . . . . 2077.6.11 Operador is . . . . . . . . . . . . . . . . . . . 2087.6.12 Operador is not . . . . . . . . . . . . . . . . . 208

7.7 Órden de evaluación . . . . . . . . . . . . . . . . . . . 2087.8 Auto-finalización de las consultas . . . . . . . . . . . . 2097.9 Modificar una búsqueda avanzada con la interfaz de

búsqueda simple . . . . . . . . . . . . . . . . . . . . . 214

8 Grabar una búsqueda en un filtro 2178.1 Organización de los filtros . . . . . . . . . . . . . . . . 2188.2 Creación de un filtro . . . . . . . . . . . . . . . . . . . 2198.3 Sumario de un filtro . . . . . . . . . . . . . . . . . . . 2228.4 Gestión de filtros . . . . . . . . . . . . . . . . . . . . . 2238.5 Eliminar un filtro de la lista de favoritos . . . . . . . . 2258.6 Añadir un filtro a la lista de favoritos . . . . . . . . . 2258.7 Modificación de los atributos de un filtro . . . . . . . . 2268.8 Compartir un filtro con otros usuarios . . . . . . . . . 227

x

Índice general

8.9 Buscar un filtro . . . . . . . . . . . . . . . . . . . . . . 2308.10 Copiar un filtro existente . . . . . . . . . . . . . . . . 2328.11 Modificación de un filtro . . . . . . . . . . . . . . . . . 2338.12 Configurar el orden de columnas de un filtro . . . . . . 235

8.12.1 Modificar la configuración de columnas de unfiltro . . . . . . . . . . . . . . . . . . . . . . . . 237

8.12.2 Eliminar la configuración de columnas de un filtro2388.13 Utilizar la configuración de columnas por defecto . . . 2398.14 Configuración de columnas y exportación de datos . . 240

9 Explotar los resultados de búsqueda 2419.1 Suscribirse a un filtro . . . . . . . . . . . . . . . . . . . 241

9.1.1 Periodicidad . . . . . . . . . . . . . . . . . . . 2439.1.2 Cualquier valor . . . . . . . . . . . . . . . . . . 2489.1.3 Listas de valores . . . . . . . . . . . . . . . . . 2489.1.4 Intervalo de valores . . . . . . . . . . . . . . . . 2499.1.5 Incremento de un valor . . . . . . . . . . . . . 2509.1.6 Último valor . . . . . . . . . . . . . . . . . . . 2509.1.7 Ocurrencias . . . . . . . . . . . . . . . . . . . . 251

9.2 Recibir resultados de búsqueda en un feed RSS . . . . 2529.2.1 Autenticar el usuario de un feed RSS . . . . . . 253

9.3 Recibir resultados de búsqueda en XML . . . . . . . . 2549.3.1 Selección de campos devueltos en el documento 255

9.4 Exportar resultados de búsqueda a Microsoft Word . . 2559.5 Exportar resultados de búsqueda a Microsoft Excel . . 2569.6 Visualizar los resultados en un gráfico . . . . . . . . . 257

9.6.1 Visualizar los resultados de búsqueda en el cua-dro de mandos . . . . . . . . . . . . . . . . . . 258

10 Generar reportes 26510.1 Workload pie chart . . . . . . . . . . . . . . . . . . . . 26710.2 User workload . . . . . . . . . . . . . . . . . . . . . . . 27010.3 Version workload . . . . . . . . . . . . . . . . . . . . . 27110.4 Time tracking . . . . . . . . . . . . . . . . . . . . . . . 27310.5 Single level group by . . . . . . . . . . . . . . . . . . . 27610.6 Created vs. resolved issues . . . . . . . . . . . . . . . . 27710.7 Resolution time . . . . . . . . . . . . . . . . . . . . . . 28110.8 Pie chart . . . . . . . . . . . . . . . . . . . . . . . . . 28310.9 Average age . . . . . . . . . . . . . . . . . . . . . . . . 28710.10Recently created issues . . . . . . . . . . . . . . . . . . 28810.11Time Since Issues Report . . . . . . . . . . . . . . . . 290

xi

Índice general

10.12Caché de los navegadores . . . . . . . . . . . . . . . . 294

11 Gestionar los cuadros de mandos 29511.1 Contenedores de gadgets OpenSocial . . . . . . . . . . 29611.2 Gestión de los cuadros de mandos . . . . . . . . . . . . 298

11.2.1 Gestión de cuadros de mandos favoritos . . . . 29911.2.2 Ordenar los cuadros de mandos favoritos . . . . 30011.2.3 Creación de un cuadro de mandos . . . . . . . 30011.2.4 Copiar un cuadro de mandos . . . . . . . . . . 30311.2.5 Modificar un cuadro de mandos . . . . . . . . . 30311.2.6 Eliminar un cuadro de mandos . . . . . . . . . 304

11.3 Búsqueda de cuadro de mandos . . . . . . . . . . . . . 305

12 Personalizar el cuadro de mandos 30912.1 Operaciones sobre un cuadro de mandos . . . . . . . . 30912.2 Selección de la distribución de un cuadro de mandos . 30912.3 Añadir gadgets al cuadro de mandos . . . . . . . . . . 31112.4 Operaciones sobre un gadget en un cuadro de mandos 31312.5 Mover un gadget en un cuadro de mandos . . . . . . . 31412.6 Eliminar un gadget de un cuadro de mandos . . . . . . 31512.7 Gadgets disponibles . . . . . . . . . . . . . . . . . . . 31512.8 Activity stream gadget . . . . . . . . . . . . . . . . . . 31712.9 Administration gadget . . . . . . . . . . . . . . . . . . 31812.10Assigned to me gadget . . . . . . . . . . . . . . . . . . 32012.11Average age chart gadget . . . . . . . . . . . . . . . . 321

13 Gestionar el perfil del usuario 32513.1 Modificar los detalles del usuario . . . . . . . . . . . . 327

13.1.1 Modificar el avatar del usuario . . . . . . . . . 32713.1.2 Modificar la contraseña . . . . . . . . . . . . . 328

13.2 Modificar las preferencias del usuario . . . . . . . . . . 33013.2.1 Cambiar las columnas del navegador de inci-

dencias . . . . . . . . . . . . . . . . . . . . . . 330

A Documento XML de búsqueda 335

B Campos y funciones JQL 341B.1 Campos . . . . . . . . . . . . . . . . . . . . . . . . . . 341

B.1.1 ¿Nombres o identificadores? . . . . . . . . . . . 341B.1.2 Tipos de campos JQL . . . . . . . . . . . . . . 342B.1.3 Operadores soportados por los campos . . . . . 343

xii

Índice general

B.1.4 Campos de tipo versión . . . . . . . . . . . . . 345B.1.5 Campos de tipo usuario . . . . . . . . . . . . . 346B.1.6 Campos de tipo categoría . . . . . . . . . . . . 347B.1.7 Campos de tipo texto . . . . . . . . . . . . . . 347B.1.8 Campos de tipo componente . . . . . . . . . . 349B.1.9 Campos de tipo fecha . . . . . . . . . . . . . . 349B.1.10 Campos de tipo filtro . . . . . . . . . . . . . . 351B.1.11 Campos de tipo incidencia . . . . . . . . . . . . 352B.1.12 Campos de tipo nivel de seguridad . . . . . . . 352B.1.13 Campos de tipo duración . . . . . . . . . . . . 353B.1.14 Campos de tipo prioridad . . . . . . . . . . . . 354B.1.15 Campos de tipo proyecto . . . . . . . . . . . . 354B.1.16 Campos de tipo resolución . . . . . . . . . . . . 355B.1.17 Campos de tipo estado . . . . . . . . . . . . . . 356B.1.18 Campos de tipo tipo de incidencia . . . . . . . 357B.1.19 Campos de tipo número . . . . . . . . . . . . . 358

B.2 Funciones . . . . . . . . . . . . . . . . . . . . . . . . . 358B.2.1 Función cascadeOption . . . . . . . . . . . . . 360B.2.2 Función componentsLeadByUser . . . . . . . . 362B.2.3 Función currentLogin . . . . . . . . . . . . . . 363B.2.4 Función currentUser . . . . . . . . . . . . . . 363B.2.5 Función issueHistory . . . . . . . . . . . . . . 364B.2.6 Función lastLogin . . . . . . . . . . . . . . . . 365B.2.7 Función linkedIssues . . . . . . . . . . . . . . 366B.2.8 Función membersOf . . . . . . . . . . . . . . . . 366B.2.9 Función now . . . . . . . . . . . . . . . . . . . . 367B.2.10 Función projectsLeadByUser . . . . . . . . . 367B.2.11 Función projectsWhereUserHasPermission . 368B.2.12 Función projectsWhereUserHasRole . . . . . 369B.2.13 Función releasedVersions . . . . . . . . . . . 370B.2.14 Función standardIssueTypes . . . . . . . . . 371B.2.15 Función subtaskIssueTypes . . . . . . . . . . 371B.2.16 Función unreleasedVersions . . . . . . . . . 372B.2.17 Función votedIssues . . . . . . . . . . . . . . 373B.2.18 Función watchedIssues . . . . . . . . . . . . . 373

B.3 Palabras reservadas . . . . . . . . . . . . . . . . . . . . 374

C Changelog 377C.1 1.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Índice alfabético 379

xiii

Índice general

Bibliografía 389

xiv

Índice de figuras

2.1 Componentes de un proyecto . . . . . . . . . . . . . . . . 132.2 Versiones de un proyecto . . . . . . . . . . . . . . . . . . . 162.3 Road map de un proyecto . . . . . . . . . . . . . . . . . . 162.4 Ventana de detalle de incidencia . . . . . . . . . . . . . . 172.5 Relación entre estado de una incidencia y flujo de trabajo 232.6 Flujo de trabajo por defecto de JIRA . . . . . . . . . . . 252.7 Organización de los conceptos en JIRA . . . . . . . . . . 28

3.1 Ventana de login de JIRA . . . . . . . . . . . . . . . . . . 403.2 Ventana de signup de JIRA . . . . . . . . . . . . . . . . . 413.3 Sección de menus de la barra de herramientas de JIRA . . 423.4 Sección de herramientas de la barra de herramientas de

JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5 Barra de herramientas de JIRA — Administración — Par-

te izquierda . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6 Barra de herramientas de JIRA — Administración — Par-

te derecha . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.7 Ventana de ayuda de los atajos de teclado . . . . . . . . . 46

4.1 Navegador de proyecto. . . . . . . . . . . . . . . . . . . . 524.2 Navegador de proyecto. . . . . . . . . . . . . . . . . . . . 534.3 Navegador de proyecto — Barra de creación de incidencias. 554.4 Navegador de proyecto — Ventana Summary. . . . . . . . 574.5 Navegador de proyecto — Barra de herramientas de la

ventana Summary. . . . . . . . . . . . . . . . . . . . . . . 574.6 Navegador de proyecto — Ventana Issues. . . . . . . . . . 594.7 Navegador de proyecto — Ventana Road map. . . . . . . . 604.8 Navegador de proyecto — Ventana Changelog. . . . . . . . 61

xv

Índice de figuras

4.9 Navegador de proyecto — Ventana Popular issues. . . . . 624.10 Navegador de proyecto — Ventana Versions. . . . . . . . 624.11 Navegador de proyecto — Detalle de versión. . . . . . . . 644.12 Navegador de proyecto — Detalle de versión — Builds . . 654.13 Navegador de proyecto — Detalle de versión — Build Plans 664.14 Navegador de proyecto — Ventana Components. . . . . . 664.15 Navegador de proyecto — Ventana Labels. . . . . . . . . . 684.16 Navegador de proyecto — Ventana Source. . . . . . . . . . 694.17 Navegador de proyecto — Ventana Source. . . . . . . . . . 70

5.1 Botón de creación de incidencia . . . . . . . . . . . . . . . 745.2 Navegador de proyecto — Barra de creación de incidencias. 745.3 Ventana de creación de incidencia . . . . . . . . . . . . . . 755.4 Ventana de creación de incidencia — Configuración de

campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.5 Citación de otro usuario . . . . . . . . . . . . . . . . . . . 785.6 Ventana de detalle de incidencia . . . . . . . . . . . . . . 795.7 Menú de acciones . . . . . . . . . . . . . . . . . . . . . . . 805.8 Compartir una incidencia. . . . . . . . . . . . . . . . . . . 825.9 Ventana para adjuntar ficheros a una incidencia . . . . . . 835.10 Vista previa de los ficheros adjuntos a una incidencia . . . 855.11 Vista de galería de los ficheros adjuntos a una incidencia . 855.12 Menu de operaciones sobre ficheros adjuntos a una incidencia 865.13 Vista previa de un fichero adjunto de tipo ZIP o JAR . . 875.14 Ventana de gestión de ficheros adjuntos . . . . . . . . . . 875.15 Ventana de confirmación para ejecutar un applet Java . . 885.16 Ventana para adjuntar capturas de pantalla . . . . . . . . 895.17 Formulario de creación de un comentario . . . . . . . . . . 905.18 Comentarios colapsados y expandidos . . . . . . . . . . . 915.19 Iconos para operar sobre un comentario . . . . . . . . . . 915.20 Iconos para operar sobre un comentario . . . . . . . . . . 935.21 Iconos para operar sobre un comentario . . . . . . . . . . 935.22 Fragmento de código formateado con la macro code . . . 955.23 Fragmento de XML formateado con la macro code . . . . 955.24 Ventana de creación de sub-tarea . . . . . . . . . . . . . . 965.25 Ventana de detalle de sub-tarea . . . . . . . . . . . . . . . 975.26 Lista de sub-tareas de una incidencia . . . . . . . . . . . . 975.27 Operaciones de una sub-tarea . . . . . . . . . . . . . . . . 985.28 Menu de operaciones de una sub-tarea . . . . . . . . . . . 995.29 Formulario de creación de sub-tarea en el panel Sub-tasks 995.30 Formulario de conversión de incidencia a sub-tarea . . . . 100

xvi

Índice de figuras

5.31 Formulario de conversión de campos para la conversión asub-tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.32 Formulario de confirmación de conversión de incidencia asub-tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.33 Formulario de creación de un enlace entre incidencias . . . 1065.34 Formulario de creación de un enlace entre incidencias . . . 1065.35 Búsqueda de una incidencia por código o título . . . . . . 1075.36 Búsqueda de una incidencia utilizando un filtro . . . . . . 1075.37 Detalle de un enlace entre incidencias . . . . . . . . . . . 1085.38 Ventana de gestión de enlaces entre incidencias . . . . . . 1085.39 Sección de filtrado por fecha de resolución en el navegador

de incidencias . . . . . . . . . . . . . . . . . . . . . . . . . 1105.40 Ejemplo de filtrado por fecha de resolución en el navegador

de incidencias . . . . . . . . . . . . . . . . . . . . . . . . . 1115.41 Formulario para la creación de un criterio de búsqueda por

fecha de resolución con intervalos temporales relativos. . . 1125.42 Segmentación de usuarios con niveles de seguridad de in-

cidencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.43 Modificar el nivel de seguridad de una incidencia . . . . . 1165.44 Nivel de seguridad de una incidencia en la ventana de detalle1175.45 Nivel de seguridad de una incidencia en la ventana de detalle1175.46 Nivel de seguridad de una incidencia en la ventana de detalle1185.47 Formulario de creación de una etiqueta en una incidencia 1195.48 Panel Time tracking de una incidencia . . . . . . . . . . . 1205.49 Pestaña Work log del panel Activity de una incidencia . . 1215.50 Campos para la estimación del trabajo requerido de una

incidencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225.51 Formulario de registro de trabajo . . . . . . . . . . . . . . 1245.52 Registro de trabajo con controles de gestión . . . . . . . . 1265.53 Formulario de registro de trabajo en una ventana de reso-

lución de incidencia . . . . . . . . . . . . . . . . . . . . . 1265.54 Registro de trabajo modificado . . . . . . . . . . . . . . . 1285.55 Ventana de eliminación de registro de trabajo . . . . . . . 1295.56 Asistente de migración de incidencias — Paso 1 . . . . . . 1315.57 Asistente de migración de incidencias — Paso 2 . . . . . . 1315.58 Asistente de migración de incidencias — Paso 3 . . . . . . 1325.59 Asistente de migración de incidencias — Paso 4 . . . . . . 1325.60 Inhabilitar las notificaciones durante una operación masiva 1345.61 Operación Bulk change en el menú Tools . . . . . . . . . . 1355.62 Selección de las incidencias sobre las cuales efectuar la

operación masiva . . . . . . . . . . . . . . . . . . . . . . . 135

xvii

Índice de figuras

5.63 Selección del tipo de operación masiva . . . . . . . . . . . 1365.64 Confirmación de una eliminación masiva . . . . . . . . . . 1365.65 Aviso de exclusión de sub-tareas durante una migración

masiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375.66 Selección de proyecto y tipo de incidencia de destino en

una migración masiva . . . . . . . . . . . . . . . . . . . . 1385.67 Selección de tipo de sub-tarea de destino en una migración

masiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385.68 Actualización de campos de una incidencia en una migra-

ción masiva . . . . . . . . . . . . . . . . . . . . . . . . . . 1395.69 Ventana de confirmación de una migración masiva . . . . 1415.70 Ventana de modificación de campos en una operación de

modificación masiva . . . . . . . . . . . . . . . . . . . . . 1455.71 Ventana de modificación de campos en una operación de

modificación masiva . . . . . . . . . . . . . . . . . . . . . 1465.72 Asistente de migración de incidencias — Paso 4 . . . . . . 1465.73 Incidencia — Revisión de Crucible . . . . . . . . . . . . . 1515.74 Incidencia — Changesets de FishEye . . . . . . . . . . . . 1525.75 Incidencia — Builds de Bamboo . . . . . . . . . . . . . . 1545.76 Panel de Personas en la ventana de detalles de incidencias 1545.77 Panel de Personas en la ventana de detalles de incidencias 1555.78 Ventana de gestión de Watchers de una incidencia . . . . 156

6.1 Paneles de búsqueda del navegador de incidencias — 1 . . 1606.2 Navegador de incidencias — Aviso de refresco . . . . . . . 1616.3 Paneles de búsqueda del navegador de incidencias — 2 . . 1626.4 Navegador de incidencias — Campos Reporter y Assignee 1636.5 Navegador de incidencias — Campos Reporter y Assignee 1646.6 Formulario para la creación de un criterio de búsqueda por

fecha de creación con intervalos temporales relativos. . . . 1666.7 Criterio de búsqueda de ejemplo. . . . . . . . . . . . . . . 1706.8 Criterio de búsqueda de ejemplo en el interfaz de búsqueda

avanzada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706.9 Modificación del criterio de búsqueda de ejemplo en el in-

terfaz de búsqueda avanzada. . . . . . . . . . . . . . . . . 1716.10 Modificación del criterio de búsqueda de ejemplo en el in-

terfaz de búsqueda avanzada. . . . . . . . . . . . . . . . . 1716.11 Navegador de incidencias. . . . . . . . . . . . . . . . . . . 1726.12 Menú Actions de una incidencia en el navegador de inci-

dencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746.13 Menú Actions y Tools del navegador de incidencias. . . . 174

xviii

Índice de figuras

6.14 Ventana de detalle de la incidencia con controles de bús-queda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6.15 Jerarquía de configuración del navegador de incidencias. . 1786.16 Ventana de configuración de campos del navegador de in-

cidencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796.17 Ventana de configuración de campos del navegador de in-

cidencias — Establecer configuración por defecto. . . . . . 1806.18 Panel Preferences del perfil de usuario. . . . . . . . . . . . 1816.19 Control de búsqueda rápida. . . . . . . . . . . . . . . . . . 1876.20 Aviso de activación de búsqueda inteligente. . . . . . . . . 1876.21 Registración de un motor de búsqueda OpenSearch. . . . 1936.22 Ejemplo de búsqueda desde el control de búsqueda del

navegador. . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

7.1 Ventana de búsqueda avanzada. . . . . . . . . . . . . . . . 1967.2 Auto-finalización de un campo en una consulta JQL. . . . 2107.3 Auto-finalización de un operador en una consulta JQL. . . 2107.4 Auto-finalización de un valor en una consulta JQL. . . . . 2117.5 Formulario de creación de consultas JQL. . . . . . . . . . 2127.6 Auto-finalización de un campo en una consulta JQL. . . . 2127.7 Auto-finalización en consultas JQL — Selección de campos.2137.8 Auto-finalización en consultas JQL — Selección de opera-

dores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2137.9 Auto-finalización en consultas JQL — Selección de valores

y funciones. . . . . . . . . . . . . . . . . . . . . . . . . . . 214

8.1 Filtros favoritos en la barra de herramientas de JIRA. . . 2208.2 Creación de filtros. . . . . . . . . . . . . . . . . . . . . . . 2208.3 Ventana de creación de filtros. . . . . . . . . . . . . . . . 2218.4 Sumario de un filtro. . . . . . . . . . . . . . . . . . . . . . 2228.5 Menú Issues — Operación Manage filters. . . . . . . . . . 2238.6 Ventana de gestión de filtros — Pestaña Favorite. . . . . . 2248.7 Ventana de gestión de filtros — Pestaña Search. . . . . . . 2248.8 Aviso de eliminación de filtro favorito. . . . . . . . . . . . 2258.9 Ventana de modificación de un filtro. . . . . . . . . . . . . 2268.10 Controles para la modificación de las identidades con las

cuales se comparte un filtro. . . . . . . . . . . . . . . . . . 2288.11 Compartir un filtro con un grupo de usuarios. . . . . . . . 2288.12 Compartir un filtro con un rol de proyecto. . . . . . . . . 2298.13 Ventana de búsqueda de filtros. . . . . . . . . . . . . . . . 2318.14 Resultados de búsqueda de filtros. . . . . . . . . . . . . . 232

xix

Índice de figuras

8.15 Resultados de búsqueda de filtros. . . . . . . . . . . . . . 2338.16 Modificación del criterio de búsqueda de un filtros. . . . . 2348.17 Modificación del criterio de búsqueda de un filtros. . . . . 2358.18 Jerarquía de configuración del navegador de incidencias. . 2358.19 Jerarquía de configuración del navegador de incidencias —

Filtros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2368.20 Ventana de gestión de filtros - Operaciones. . . . . . . . . 2378.21 Navegador de incidencias - Configuración de columnas de

un filtro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2378.22 Navegador de incidencias — Menú Tools — Modificación

de la configuración de columnas de un filtro. . . . . . . . . 2388.23 Navegador de incidencias — Eliminar configuración de co-

lumnas de un filtro. . . . . . . . . . . . . . . . . . . . . . 2398.24 Navegador de incidencias — Selección de la configuración

de columnas. . . . . . . . . . . . . . . . . . . . . . . . . . 240

9.1 Suscripción a filtro. . . . . . . . . . . . . . . . . . . . . . . 2429.2 Formulario de suscripción a un filtro. . . . . . . . . . . . . 2439.3 Formulario de suscripción a un filtro — Selección de franja

horaria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2449.4 Formulario de suscripción a un filtro — Selección de días

de la semana. . . . . . . . . . . . . . . . . . . . . . . . . . 2459.5 Formulario de suscripción a un filtro — Selección de días

del mes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2469.6 Formulario de suscripción a un filtro — Expresión cron. . 2469.7 Feed RSS de JIRA visualizado en el navegador Apple Safari.2539.8 Ejemplo de documento Microsoft Word generado de una

búsqueda en JIRA. . . . . . . . . . . . . . . . . . . . . . . 2569.9 Ejemplo de documento Microsoft Excel generado de una

búsqueda en JIRA. . . . . . . . . . . . . . . . . . . . . . . 2579.10 Gráfico Agerage age. . . . . . . . . . . . . . . . . . . . . . 2599.11 Gráfico Created vs. resolved. . . . . . . . . . . . . . . . . . 2599.12 Gráfico Created vs. resolved. . . . . . . . . . . . . . . . . . 2609.13 Gráfico Pie chart. . . . . . . . . . . . . . . . . . . . . . . 2609.14 Gráfico Recently created. . . . . . . . . . . . . . . . . . . . 2619.15 Gráfico Time since. . . . . . . . . . . . . . . . . . . . . . 2619.16 Navegador de incidencias — Tipos de gráfico. . . . . . . . 2629.17 Navegador de incidencias — Ver como gráfico. . . . . . . 2629.18 Navegador de incidencias — Personaliza gráfico. . . . . . 2639.19 Grabación de gráfico en el cuadro de mando — Selección

de cuadro de mando. . . . . . . . . . . . . . . . . . . . . . 264

xx

Índice de figuras

9.20 Grabación de gráfico en el cuadro de mando — Creaciónautomática de un cuadro de mando. . . . . . . . . . . . . 264

10.1 Cuadro de manos de un proyecto — Menú Reports. . . . . 26610.2 Cuadro de manos de un proyecto — Menú Reports desple-

gado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26610.3 Workload pie chart — Configuración. . . . . . . . . . . . 26810.4 Ventana de selección de proyecto o filtro. . . . . . . . . . 26810.5 Report Workload pie chart. . . . . . . . . . . . . . . . . . 26910.6 User workload — Configuración. . . . . . . . . . . . . . . 27010.7 Report User workload. . . . . . . . . . . . . . . . . . . . . 27110.8 Version workload — Configuración. . . . . . . . . . . . . . 27210.9 Report Versión workload. . . . . . . . . . . . . . . . . . . 27210.10Time tracking — Configuración. . . . . . . . . . . . . . . 27310.11Report Time tracking. . . . . . . . . . . . . . . . . . . . . 27510.12Report Time tracking — Barras de resumen. . . . . . . . 27610.13Single level group by — Configuración. . . . . . . . . . . . 27710.14Report Single level group by. . . . . . . . . . . . . . . . . 27810.15Created vs. resolved — Configuración. . . . . . . . . . . . 27910.16Report Created vs. Resolved — Gráfico. . . . . . . . . . . 28010.17Report Created vs. Resolved — Tabla de datos. . . . . . . 28110.18Report Created vs. Resolved — Gráfico. . . . . . . . . . . 28210.19Resolution time — Configuración. . . . . . . . . . . . . . 28210.20Report Resolution time — Gráfico. . . . . . . . . . . . . . 28410.21Report Resolution time — Tabla de datos. . . . . . . . . . 28510.22Pie chart — Configuración. . . . . . . . . . . . . . . . . . 28510.23Report Pie chart — Gráfico. . . . . . . . . . . . . . . . . 28610.24Report Pie chart — Tabla de datos. . . . . . . . . . . . . 28610.25Average age — Configuración. . . . . . . . . . . . . . . . . 28710.26Report Average age — Gráfico. . . . . . . . . . . . . . . . 28810.27Report Average age — Tabla de datos. . . . . . . . . . . . 28910.28Recently created issues — Configuración. . . . . . . . . . 29010.29Report Recently created issues — Gráfico. . . . . . . . . . 29110.30Report Recently created issues — Tabla de datos. . . . . . 29210.31Time since issues — Configuración. . . . . . . . . . . . . . 29210.32Report Time since issues — Gráfico. . . . . . . . . . . . . 29310.33Report Time since issues — Tabla de datos. . . . . . . . 294

11.1 Cuadro de mandos vacío. . . . . . . . . . . . . . . . . . . 29711.2 Cuadro de mandos — Disponer un gadget. . . . . . . . . 29711.3 Menú Dashboards. . . . . . . . . . . . . . . . . . . . . . . 298

xxi

Índice de figuras

11.4 Ventana de gestión de cuadros de mandos. . . . . . . . . . 29811.5 Ventana de gestión de cuadros de mandos. . . . . . . . . . 29911.6 Confirmación de eliminación de un cuadro de mandos de

la lista de favoritos. . . . . . . . . . . . . . . . . . . . . . 30011.7 Control de creación de cuadros de mandos. . . . . . . . . 30111.8 Formulario de creación de cuadros de mandos. . . . . . . 30211.9 Ventana de gestión de cuadros de mandos — Operación

Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30311.10Ventana de gestión de cuadros de mandos — Operación

Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30411.11Ventana de modificación de cuadros de mandos . . . . . . 30411.12Ventana de gestión de cuadros de mandos — Operación

Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30511.13Ventana de confirmación de eliminación de cuadro de mandos30511.14Ventana de búsqueda de cuadro de mandos . . . . . . . . 30611.15Ventana de búsqueda de cuadro de mandos — Resultados 306

12.1 Ventana de cuadro de mandos — Operaciones . . . . . . . 31012.2 Ventana de cuadro de mandos — Menú Tools . . . . . . . 31012.3 Ventana de selección de distribución del cuadro de mandos 31112.4 Ventana de selección de gadget . . . . . . . . . . . . . . . 31212.5 Barra de herramientas de un gadget . . . . . . . . . . . . 31312.6 Barra de herramientas de un gadget — Menú de operaciones31412.7 Mover un gadget en un cuadro de mandos . . . . . . . . . 31412.8 Ventana de confirmación de eliminación de un gadget de

un cuadro de mandos . . . . . . . . . . . . . . . . . . . . 31512.9 Gadget Activity stream — Configuración . . . . . . . . . . 31812.10Gadget Activity stream . . . . . . . . . . . . . . . . . . . . 31912.11Gadget Administration . . . . . . . . . . . . . . . . . . . . 31912.12Gadget Assigned to me . . . . . . . . . . . . . . . . . . . . 32012.13Gadget Assigned to me . . . . . . . . . . . . . . . . . . . . 32112.14Gadget Average age chart . . . . . . . . . . . . . . . . . . 32212.15Gadget Average age chart . . . . . . . . . . . . . . . . . . 323

13.1 Barra de herramientas — Perfil de Usuario . . . . . . . . 32613.2 Perfil de Usuario . . . . . . . . . . . . . . . . . . . . . . . 32613.3 Perfil de usuario — Edición de los detalles de usuario . . 32713.4 Perfil de usuario — Edición del avatar del usuario . . . . 32813.5 Perfil de usuario — Edición del avatar del usuario . . . . 32913.6 Perfil de usuario — Cambio de contraseña . . . . . . . . . 32913.7 Perfil de usuario — Modificación de las preferencias . . . 331

xxii

Índice de tablas

1.1 Licencias comerciales . . . . . . . . . . . . . . . . . . . . . 9

2.1 Campos estándar de una incidencia . . . . . . . . . . . . . 202.2 Eventos en el esquema de notificaciones . . . . . . . . . . 33

3.1 Tecla modificadora por navegador y sistema operativo . . 463.2 Atajos de teclado globales . . . . . . . . . . . . . . . . . . 473.3 Atajos de teclado en las ventanas de incidencias . . . . . . 483.4 Atajos de teclado en los formularios de JIRA . . . . . . . 49

4.1 Navegador de proyecto — Información relativa al proyecto. 544.2 Navegador de proyecto — Información relativa a las ver-

siones del proyecto. . . . . . . . . . . . . . . . . . . . . . . 544.3 Navegador de proyecto — Información relativa a los com-

ponentes del proyecto. . . . . . . . . . . . . . . . . . . . . 554.4 Navegador de proyecto — Paneles de la ventana Summary. 564.5 Navegador de proyecto — Paneles de la ventana Issues. . 594.6 Navegador de proyecto — Ventanas de versiones. . . . . . 634.7 Navegador de proyecto — Ventanas de componentes. . . . 67

5.1 Nombre de ficheros adjuntos — Caracteres no permitidos 845.2 Macro del wiki-style renderer . . . . . . . . . . . . . . . . 945.3 Campos estándar de una incidencia . . . . . . . . . . . . . 143

6.1 Acciones en el menú Actions en el navegador de incidencias.1756.2 Acciones en el menú Actions en el navegador de incidencias.1766.3 Caracteres especiales en las búsquedas de texto. . . . . . . 1836.4 Términos especiales en las búsquedas de texto. . . . . . . 183

xxiii

Índice de tablas

7.1 Caracteres JQL reservados. . . . . . . . . . . . . . . . . . 1977.2 Campos JQL. . . . . . . . . . . . . . . . . . . . . . . . . . 198

9.1 Tipos de campos JQL. . . . . . . . . . . . . . . . . . . . . 2449.2 Valores de los campos de una expresión cron de JIRA. . . 2479.3 Significado de los caracteres especiales de una expresión

cron de JIRA. . . . . . . . . . . . . . . . . . . . . . . . . 2479.4 Significado de los caracteres especiales de una expresión

cron de JIRA. . . . . . . . . . . . . . . . . . . . . . . . . 250

10.1 Reportes integrados en JIRA. . . . . . . . . . . . . . . . . 26710.2 Reporte — Intervalos temporales. . . . . . . . . . . . . . . 279

11.1 Controles para el ordenamiento de los elementos de la lista. 301

12.1 Cuadro de mandos — Distribuciones . . . . . . . . . . . . 31012.2 Barrade herramientas de un gadget — Controles . . . . . 31312.3 Gadgets para el cuadro de mandos de JIRA . . . . . . . . 317

B.1 Tipos de campos JQL. . . . . . . . . . . . . . . . . . . . . 343B.2 Operadores soportados por los campos JQL. . . . . . . . . 344B.3 Operadores JQL soportados por campos personalizados. . 345B.4 Operadores y funciones soportados por campos de tipo

versión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345B.5 Operadores y funciones soportados por campos de tipo

usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346B.6 Operadores y funciones soportados por campos de tipo

categoría. . . . . . . . . . . . . . . . . . . . . . . . . . . . 347B.7 Operadores y funciones soportados por campos de tipo texto.348B.8 Operadores y funciones soportados por campos de tipo

componente. . . . . . . . . . . . . . . . . . . . . . . . . . . 349B.9 Operadores y funciones soportados por campos de tipo fecha.350B.10 Operadores y funciones soportados por campos de tipo filtro.351B.11 Operadores y funciones soportados por campos de tipo

incidencia. . . . . . . . . . . . . . . . . . . . . . . . . . . 352B.12 Operadores y funciones soportados por campos de tipo

incidencia. . . . . . . . . . . . . . . . . . . . . . . . . . . 352B.13 Operadores y funciones soportados por campos de tipo

nivel de seguridad. . . . . . . . . . . . . . . . . . . . . . . 353B.14 Operadores y funciones soportados por campos de tipo

duración. . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

xxiv

Índice de tablas

B.15 Operadores y funciones soportados por campos de tipoprioridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

B.16 Operadores y funciones soportados por campos de tipoproyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

B.17 Operadores y funciones soportados por campos de tiporesolución. . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

B.18 Operadores y funciones soportados por campos de tipoestado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

B.19 Operadores y funciones soportados por campos de tipotipo de incidencia. . . . . . . . . . . . . . . . . . . . . . . 357

B.20 Operadores y funciones soportados por campos de tiponúmero. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

B.21 Funciones JQL soportados por tipo de campo de campo yclase de operador. . . . . . . . . . . . . . . . . . . . . . . 359

B.22 Tipo de campo de campo y clase de operador soportadapor cascadeOption. . . . . . . . . . . . . . . . . . . . . . 360

B.23 Tipo de campo de campo y clase de operador soportadapor componentsLeadByUser. . . . . . . . . . . . . . . . . 362

B.24 Tipo de campo de campo y clase de operador soportadapor currentLogin. . . . . . . . . . . . . . . . . . . . . . . 363

B.25 Tipo de campo de campo y clase de operador soportadapor currentUser. . . . . . . . . . . . . . . . . . . . . . . 364

B.26 Tipo de campo de campo y clase de operador soportadapor issueHistory. . . . . . . . . . . . . . . . . . . . . . . 364

B.27 Tipo de campo de campo y clase de operador soportadapor lastLogin. . . . . . . . . . . . . . . . . . . . . . . . . 365

B.28 Tipo de campo de campo y clase de operador soportadapor linkedIssues. . . . . . . . . . . . . . . . . . . . . . . 366

B.29 Tipo de campo de campo y clase de operador soportadapor membersOf. . . . . . . . . . . . . . . . . . . . . . . . . 367

B.30 Tipo de campo de campo y clase de operador soportadapor now. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

B.31 Tipo de campo de campo y clase de operador soportadapor projectsLeadByUser. . . . . . . . . . . . . . . . . . . 368

B.32 Tipo de campo de campo y clase de operador soportadapor projectsWhereUserHasPermission. . . . . . . . . . . 369

B.33 Tipo de campo de campo y clase de operador soportadapor projectsWhereUserHasRole. . . . . . . . . . . . . . . 369

B.34 Tipo de campo de campo y clase de operador soportadapor releasedVersions. . . . . . . . . . . . . . . . . . . . 370

xxv

Prefacio

B.35 Tipo de campo de campo y clase de operador soportadapor standardIssueTypes. . . . . . . . . . . . . . . . . . . 371

B.36 Tipo de campo de campo y clase de operador soportadapor subtaskIssueTypes. . . . . . . . . . . . . . . . . . . 371

B.37 Tipo de campo de campo y clase de operador soportadapor unreleasedVersions. . . . . . . . . . . . . . . . . . . 372

B.38 Tipo de campo de campo y clase de operador soportadapor votedIssues. . . . . . . . . . . . . . . . . . . . . . . 373

B.39 Tipo de campo de campo y clase de operador soportadapor watchedIssues. . . . . . . . . . . . . . . . . . . . . . 373

B.40 Palabras JQL reservadas. . . . . . . . . . . . . . . . . . . 375

xxvi

Prefacio

Este libro está dividido en dos volumenes: la Guía del usuario y laGuía del administrador. La Guía del usuario describe las funcionali-dades de JIRA y las herramientas a disposición del usuario. El volú-men comienza con una rápida introducción a los conceptos básicos dela plataforma y progresa adentrándose en las funciones más comunestales como creación, trabajo y filtrado de incidencias. Los últimoscapítulos del volúmen se dedican a funcionalidades más avanzadas lafuncionalidad de generación de reportes y la gestión de los cuadros demandos.

El segundo volumen, la Guía del administrador, está dedicado adescribir los procedimientos de administración de la plataforma: elvolumen comienza con los procedimientos de instalación en las plata-formas soportadas, progresa con los procedimiento de personalizaciónde cada esquema de configuración de JIRA hasta llegar a funciona-lidades más avanzadas, menos comunes pero no menos importantestales como migración y archivado de proyectos y administración diariadel server.

Relación con la documentación oficial de JIRA

Atlassian desempeña un excelente trabajo manteniendo la documen-tación de sus productos siempre actualizada y disponible en la weboficial [10] y reconozco que, sin esa excepcional fuente de información,esta guía tampoco existiría, por lo menos en la forma en la que estápresentada.

Una de las necesidades que me impulsaron a escribir esta guía,de hecho, fue la “escasez”, por decirlo con un eufemismo, de docu-mentación e información en castellano de calidad. El primer intento

xxvii

Prefacio

fue comenzar a traducir la documentación de JIRA en castellano alo-jándola, además, en una instancia de Atlassian Confluence, el mismogestor de contenido con el cual se publica la documentación oficial deJIRA. De esta forma, podía mantener la estructura y la subdivisiónen secciones de la documentación oficial, facilitando la explotación dela información a los usuarios acostumbrados a utilizar la documenta-ción de Atlassian. Sin embargo, según el trabajo progresaba, empecéa darme cuenta que, aún excelente y sorprendentemente detallada, ala documentación de JIRA falta algo importante: no se parece a unaguía, sino a documentación de referencia.

Empecé a escribir este libro, pues, para traducir y enriquecer a ladocumentación oficial, introduciendo la información de una forma másaccesible a los usuarios con escasa experiencia e intentando guiarlespaso por paso añadiendo explicaciones, buenas prácticas, casos deusos típicos y ejemplos.

Confesando una personal inclinación para la lectura sobre papelen lugar de sobre pantalla, espero proporcionar a los usuarios quecompartan conmigo esta “debilidad” un producto más agradable aleer y utilizar. Un libro, además, tiene la innegable ventaja de estarsiempre disponible sin la necesidad de una conexión a internet.

Por otro lado, el mantenimiento de un libro de estas característi-cas no facilita la labor de sincronización de la documentación oficialcon esta guía. Atlassian mejora sus productos con una velocidad ad-mirable, y no me es siempre posible actualizar inmediatamente estadocumentación. De hecho, no excluyo siquiera que algunas caracte-rísticas nuevas o modificadas no se vean reflejadas en este libro porun error, y no por una decisión informada. Por las mismas razones,las imágenes incluidas en este libro podrían no estar siempre actuali-zadas.

A quién está dirigido cada volumen

He ha intentado organizar el conocimiento de JIRA por categorías deusuario y a cada una de ellas he dedicado un volumen de este libro:por un lado están las personas que utilizan JIRA como herramienta detrabajo, los usuarios, y por el otro están las personas que administrany configuran la herramienta, los administradores.

Sin embargo, incluso en casos de usos muy comunes, la fronteraente las dos categorías de usuarios se hace borrosa: los usuarios, parapoder formular adecuadamente sus requerimientos, deberán conocer,

xxviii

Prefacio

al menos de forma somera, las características de la plataforma. Unconocimiento limitado de las funcionalidades de JIRA así como decualquier otro sistema pueden llevar los usuarios a utilizar la herra-mienta de forma “distorsionada”, ineficiente y no optimizada a susreales necesidades. Los usuarios que ignoran la existencia de algúntipo de funcionalidad corren el riesgo de “renunciar” a ella sin llegarsiquiera a solicitarla a los administradores. De acuerdo a nuestra ex-periencia esta situación no se da solo en el caso de alguna función“exótica” de la plataforma o alguna otra función inhabilitada por de-fecto: este problema se manifiesta también con funciones “básicas”de la plataforma como la personalización de los esquemas de configu-ración de un proyecto y, sobre todo, los flujos de trabajo asociados alos tipos de incidencias manejados.

Los administradores, por otra parte, para interpretar e implemen-tar correctamente los requerimientos, solicitudes e incluso los “deseos”de los usuarios, deberán familiarizarse con los conceptos y los proce-dimientos de trabajo básicos de la herramienta.

Adicionalmente, es necesario tener en cuenta que algunos usuariospodrían tener un “rol” que los acerca naturalmente a los administra-dores, por lo menos limitadamente al proyecto en que trabajan. Losjefes de proyecto, por ejemplo, serán frecuentemente interlocutores delos administradores: casi siempre en fase de creación y configuracióndel proyecto, cuando los usuarios definan por primera vez los requeri-mientos de negocio que el mismo deberá satisfacer, y a veces en fasessucesivas, como la de mantenimiento de un proyecto, cuando vayanincorporándose modificaciones necesarias a satisfacer las nuevas ne-cesidades del proyecto. Aunque limitadamente a un subconjunto defunciones, los administradores podrían delegar la administración deun proyecto a un grupo de usuarios que no sean administradores deJIRA.

Por estas razones, aunque esté dirigido principalmente a los usua-rios, el primer volumen debería ser una lectura recomendada tambiéna los administradores que, de esta forma, conocerán los principios querigen la interacción entre usuario y plataforma, las funciones disponi-bles, así como las limitaciones y las idiosincrasias de la misma.

Viceversa, limitadamente a los usuarios que requieran este tipo deconocimiento tales como los jefes de proyecto, el segundo volumen,dirigido principalmente a los administradores de JIRA, debería seruna lectura recomendada para aprender cuales son todas las funcionesproporcionadas por la plataforma, muchas de las cuales, por razón deespacio y audiencia, no se tratan con el debido detalle en la Guía del

xxix

Prefacio

usuario.He tomado la precaución, allí donde considero que se está pre-

sentando una funcionalidad que pueda interesar a una audiencia másamplia, de avisar el lector e incorporar referencias cruzadas entre losdos volúmenes.

Nomenclatura

Considero importante aclarar una cuestión acerca de la nomenclatu-ra que comúnmente se utiliza relativamente a JIRA. Aunque JIRAes una herramienta que nació para resolver un problema común en elmundo del desarrollo, la gestión de bugs, JIRA se diferencia de otrosprograma similares por su flexibilidad, virtud que le permite ser uti-lizada para gestionar con éxito todo tipo de “proyecto”. No obstante,se ha arraigado el uso de la terminología de los gestores de inciden-cias y, por lo tanto, se suele llamar incidencia al “objeto” gestionadoen un proyecto y manejado en un flujo de trabajo y desarrollador alusuario cuyo “rol” es el de trabajar en una incidencia.

Es importante, pues, subrayar como las palabras “incidencia” y“desarrollador” sean insuficientes para expresar la infinidad de “ob-jetos” y casos de uso que se puedan gestionar en JIRA así como losroles de usuarios que puedan crearse para manejar dichos objetos:documentos, facturas, pedidos o cualquier otra entidad que puedamanejarse en un flujo de trabajo son ejemplos de objetos candidatosa ser gestionados en JIRA.

En esta guía, para conformarnos a esta costumbre, seguiremosutilizando esta nomenclatura aunque reiteradas veces advertiremosal lector de como la palabra “incidencia” haya que considerarse máscomo una costumbre “histórica” que una limitación, o más sencilla-mente el objetivo, de esta herramienta.

Convenios tipográficos

Para facilitar la lectura de esta guía se utilizarán los siguientes con-venios tipográficos:

• Para los comandos se utilizará una fuente mono-espacio.• Para enfatizar conceptos o hacer referencias a identificadores deventanas, de control o de menú se utilizará una fuente itálica.• Para hacer referencias se utilizarán Small Caps.

xxx

Prefacio

• Los ejemplos se editarán en un bloque de texto parecido al si-guiente:

Ejemplo 0.1. El ejemplo terminará con un tombstone.

El formato de este libro

Este libro ha sido editado en una hoja de tipo DIN A5 (210 mm×148mm), un formato de hoja estándar cuyo tamaño es igual al tamañode una hoja DIN A4 (297 mm×210 mm) cortada a la mitad y giradade 90 grados.

La elección de este formato me ha permitido editar este volumenmanteniendo una estructura de página “agradable” y fácil de leer,un objetivo difícil de conseguir en una hoja DIN A4 a menos de no“desperdiciar” papel utilizando márgenes demasiado grandes.

El formato DIN A4 es, probablemente, el formato de papel máscomún en Europa y, aunque no sea difícil conseguir papel en formatoDIN A5, este libro podrá imprimirse comodamente en formato A4manteniendo el tamaño original de las páginas gracias al hecho queuna hoja DIN A4 puede cortarse exactamente en 2 hojas DIN A5.Algunas impresoras permiten, incluso, organizar la impresión de 4páginas en una hoja A4 de forma que el usuario pueda cortar laspáginas a la mitad y obtener el ordenamiento natural de las páginasdel libro.

Otra opción, que es mi preferida cuando deseo imprimir un librode ciertas dimensiones, es imprimirlo en fascículos. De esta forma,en lugar de obtener decenas o centenares de hojas sueltas, obtengoun número mucho más reducido de fascículos los cuales, además, sonmás fácil de sujetar con una normal grapadora de oficina. Un librocomo este, de aproximadamente 400 hojas, impreso en fascículos de32 hojas en papel A4, se convierte en una docena de fascículos, cadauno compuesto por 8 hojas A4 dobladas por la mitad. El resultado,en mi opinión, es más fácil de imprimir y grapar y, por supuesto, deleer y llevar consigo.

Sugerencias

Estaré agradecido a quién deseara enviarme correcciones, sugerenciaso cualquier otro tipo de solicitud: no hay mejor manera de refinarun trabajo sino a través del feedback de tus usuarios. Os ruego de

xxxi

Prefacio a la guía del usuario

dirigir vuestras sugerencias al buzón de correo electrónico indicado acontinuación:

[email protected]

Estaré encantado de responder a los comentarios y, en los casos queconsidere oportuno, a aplicar las modificaciones sugeridas.

Donde encontrar este libro

La licencia de este libro permite su redistribución. Sin embargo, siem-pre aconsejo obtener la última versión a la siguiente dirección [1]:

http://thegreyblog.blogspot.com/


xxxii


La documentación oficial de JIRA [10] es un producto de excelen-te calidad: alojada en una instancia de Atlassian Confluence paraser consultada online, y también disponible en formato PDF, estádividida por sujeto y proporciona toda la información necesaria pa-ra instalar, configurar, utilizar y administrar una instancia de JIRA.Este recurso valioso ha sido la documentación de referencia para edi-tar este libro y sin ella, con toda seguridad, este libro no sería tandetallado. Entonces, ¿por qué decidí de escribir esta guía?

La primera razón que me impulsó a redactar esta guía es una razónlingüística. La documentación oficial de Atlassian, por lo menos hastala fecha de redacción de este libro, está disponible exclusivamente enInglés. Aunque el inglés sea la lengua franca del mundo tecnológico,he constatado que en muchos casos, todavía, la barrera lingüísticaes un factor que limita la adopción de muchas soluciones ya que losusuarios temen que puedan tener problemas a la hora utilizar la docu-mentación o recibir soporte en lengua Inglés. El Castellano, además,es la segunda lengua nativa más utilizada en el mundo: disponer dedocumentación en este idioma, por lo tanto, puede contribuir a favo-recer la adopción de estas soluciones en el colectivo hispano-hablante.Ya que esta guía no es simplemente una traducción sino una exten-sión de la Guía del usuario de JIRA, incluso usuarios con buenosconocimientos de Inglés se podrán aventajar de una mayor cantidadde información.

La segunda razón fue el deseo de reorganizar y extender el conteni-do de la documentación de Atlassian. La documentación oficial es un“compendio” exhaustivo de la funcionalidad de JIRA, organizado portema y fácilmente explotable. Sin embargo creo que muchos usuarios,tanto principiantes como expertos, podrían beneficiarse de informa-

xxxiii


ción adicional tal como casos de uso y ejemplos, que son notables“ausentes” en la documentación oficial.

Por esta razón, empecé a redactar este volumen con el objetivo deproporciona una guía que pudiera satisfacer las necesidades de usua-rios de de cualquier nivel de experiencia. Para guiar a los usuariosinexpertos en el descubrimiento de JIRA y de toda su funcionalidad,he intentado añadir ejemplos, sugerencias y casos de uso para acla-rar el por qué de las cosas, sin limitarme simplemente al como sehacen. Para usuarios expertos, he intentado poner en luz la varie-dad de funciones que la plataforma ofrece a sus usuarios, incluso lasmás inusuales, estableciendo relaciones con las tareas administrativascuando lo consideré oportuno.


xxxiv

Guía del usuario

1

1Introducción

Atlassian JIRA es una herramienta versátil utilizada principalmen-te como gestor de incidencias y gestión de proyectos. JIRA es unaproducto propietario desarrollada por Atlassian, una software houseaustraliana, que proporciona soporte y código fuente de la plataformaa clientes que adquieran una licencia comercial.

Quiénes hayan utilizado otra aplicación para la gestión de inci-dencias tales como Bugzilla, Mantis, HP Quality Center, Trac, etc.,notará que, a primera vista, el mínimo común múltiple entre estasaplicaciones es un comportamiento bastante parecido: un grupo deusuarios serán quienes creen las incidencias y otro grupo de usuarios,los operadores (los desarrolladores en la jerga de JIRA) serán quieneslleven a cabo el “trabajo” sobre las incidencias. Cada tipo de inci-dencia que se esté manejando está opcionalmente sometido a flujosde trabajos distintos: los operadores que tengan permiso de hacerlopodrán mover la incidencia en la red de estados definida en el flujode trabajo asociado al específico tipo de incidencia.

JIRA es una aplicación extremadamente versátil y el valor añadi-do que aporta es una grande flexibilidad y la posibilidad de configurarprácticamente cualquier parámetros en lo que concierne las inciden-cias, su flujo de trabajo y las ventanas a través de las cuales losusuarios trabajan sobre las incidencias. En las siguientes secciones seexplorarán someramente las características de JIRA más importantesque hacen que sea la plataforma ideal para cualquier proyecto.

1.1 Interfaz gráfica

JIRA proporciona múltiples maneras para interactuar con ella, cadauna de las cuales satisface distintas necesidades y distintos casos deuso. Los usuarios, normalmente, acceden e interactúan con JIRA a

3

1. Introducción

través de su interfaz web. La interfaz web proporciona un entornode última generación, intuitivo y fácil de utilizar, que ofrece todaslas herramientas necesarias para desempeñar las labores de usuariosy operadores.

La interfaz de gestión de las incidencias proporciona un conjuntode ventanas, configurables tanto a nivel global como a nivel de pro-yecto, con las cuales el usuario puede examinar las incidencias, susatributos, su historia y su estado actual.

La ventana de detalle de las incidencias encapsula la mayoría dela funcionalidad, concentrando en un único “cuadro de mandos” todala información y las actividades que pueden desempeñarse sobre unaincidencia. De esta forma, los usuarios no necesitarán moverse enmuchas ventanas distintas y podrán, de una forma rápida y intuitiva,operar sobre incidencias de cualquier tipo a través de una interfazhomogénea.

La ventana de detalle de las incidencias proporciona todas lasoperaciones definidas en el flujo de trabajo asociado con la inciden-cia, ofreciendo al usuario exclusivamente las operaciones que puedenefectuarse en el estado en que se encuentra la incidencia y con lospermiso de los que el usuario disponga. Incidencias de tipos distintosasignadas a flujos de trabajo distintos se manejarán a través de lamisma interfaz: el tiempo necesario para que un usuario aprenda autilizar la herramienta se reduce, por lo tanto, al mínimo.

La interfaz web de JIRA ofrece también múltiples herramientaspara buscar e filtrar incidencias, cada una de las cuales satisfacenexigencias distintas. El interfaz de búsqueda simple, por ejemplo,proporciona al usuario una ventana con la cual construir consultasutilizando exclusivamente herramientas gráficas. Usuarios más ex-pertos, que necesiten el máximo control sobre las consultas creadas,podrán utilizar el interfaz de búsqueda avanzada en la cual podráncrear consultas utilizando el lenguaje de búsquedas de JIRA, JQL,en una interfaz igualmente fácil de utilizar que proporciona “ayudasinteligentes” mientras el usuario está tecleando la consulta.

También en lo que concierne la gestión de los proyectos y la ad-ministración de la plataforma, la interfaz gráfica de JIRA tambiénofrece herramientas excelentes y fáciles de utilizar. Sin embargo, ladescripción de las mismas está fuera del alcance de este libro y setratarán el el Volumen ii.

4

1.2. Los cuadros de mandos

1.2 Los cuadros de mandos

Otra herramienta muy flexible que JIRA proporciona a sus usuariosson los cuadros de mandos. Los cuadros de mandos son ventanasque pueden ser creadas y compartidas por los mismos usuarios en lascuales el pueden añadirse gadgets de distinta naturaleza.

JIRA ofrece un conjunto muy extenso de gadgets que permiten,por ejemplo, visualizar los resultados de una búsqueda grabada en unfiltro, generar gráficos, visualizar estadísticas o flujos de actividad.En un cuadro de mando podrá incluirse cualquier gadget OpenSociale, incluso, los usuarios o las organizaciones que posean la competen-cia necesaria podrán desarrollarse sus propios gadgets utilizando lasherramientas del Atlassian SDK.

Los cuadros de mandos son herramientas ideales no solo para losusuarios y los operadores de JIRA, sino para roles tales como losjefes de proyectos o los clientes. Un cuadro de mando permite crearrápidamente ventanas donde filtrar, agregar, resumir y analizar datosprovenientes de JIRA y, por lo tanto, ser vehículo de información fácilde explotar y siempre actualizada.

Un jefe de proyecto o un cliente que necesite comprobar que seestén respetando los acuerdos de nivel de servicio (ANS) por un con-junto de incidencias en un proyecto podrán, por ejemplo, definir lasconsultas necesarias a extraer dicha información y presentarla en uncuadro de mando. La información presentada, ya sea como resulta-do de una búsqueda o como gráfico, podrá ser una fuente de eventosy, por lo tanto, avisar inmediatamente a los usuarios “interesados”cuando dicha información varía, como en el caso en que la fecha deresolución de una incidencia supere el “plazo de vencimiento” definidopor el ANS.

1.3 JIRA es OpenSocial

Las últimas versiones de JIRA son “contenedores OpenSocial”. Open-Social es un conjunto de interfaces de programación (APIs) que fa-cilitan la construcción de aplicaciones sociales y que promueven lainteroperabilidad y la portabilidad de componentes web. OpenSociales promovido por organizaciones y redes sociales del calibre de Googley MySpace y que es utilizado, por ejemplo, en aplicaciones web deúltima generación como iGoogle.

Tanto si se desea crear un componente web para expandir la fun-cionalidad de JIRA, tanto si se desea integrar un gadget OpenSocial

5

1. Introducción

existente1, JIRA podrá importar e utilizar de forma inmediata losgadgets y el usuario podrá añadirlos y disponerlos a su gusto en loscuadros de mando de la aplicación (§??).

1.4 Flexibilidad

JIRA es una herramienta moderna que proporciona al usuario unainterfaz web de última generación, clara y fácil de utilizar. Cadausuario maneja incidencias2 en el ámbito de un proyecto y cada pro-yecto puede parametrizarse para ajustarse a los requerimientos de sususuarios.

En el contexto de un proyecto pueden definirse, por ejemplo, lostipos de incidencias que se desea manejar. Cada tipo de incidencia,a su vez, podrá asociarse a una configuración de campos que definecuales campos pueden ser utilizados en la definición de una incidenciay las propiedades de los mismos.

En un proyecto con incidencias de tipo factura, por ejemplo, podrádeclararse que dichas incidencias poseen como campos adicionales loscampos cliente, importe y fecha de emisión, que todos los campos sonobligatorios, que el campo importe es un campo numérico y que elcampo fecha de emisión contiene un valor de tipo “fecha”.

De la misma forma, el tipo de incidencia de tipo factura estarávinculado a un flujo de trabajo personalizado que prevea, por ejemplo,los estados emitida, rechazada, parcialmente pagada y pagada.

Ya que las operaciones de un flujo de trabajo pueden protegersecon políticas de seguridad, los objetos de tipo factura podrán servisibles solo a un subconjunto de usuarios y, entre ellos, solo unaparte podrá operar sobre una factura.

1.5 Seguridad

El modelo de seguridad basada en roles de JIRA permite definir polí-ticas de seguridad con “grano muy fino” y aplicarlas en casi cualquier

1Como por ejemplo los gadget de iGoogle o gadget proporcionados por otrasaplicaciones de la suite de Atlassian

2Como explicado en el prefacio, seguiremos la costumbre de Atlassian y lla-maremos incidencias a los “objetos” gestionados en el ámbito de un proyecto.La flexibilidad de JIRA permite fácilmente parametrizar proyectos que manejenobjetos de cualquier naturaleza y, en esos casos, el significado de la palabra “in-cidencia” no transmite de forma suficientemente clara las potencialidades de laaplicación.

6

1.6. Facilidad de gestión

operación ejecutable en la aplicación. De esta forma, los jefes de pro-yectos podrán subdividir su base de usuarios en roles y asignar a cadauno de ellos los permisos que requieren durante el desempeño de suslabores diarias.

Los permisos de proyecto disponibles en la definición de las políti-cas de seguridad, así como la aplicación de las mismas, permiten con-trolar el acceso a prácticamente cualquier “entidad” gestionada porJIRA, tales como proyectos, incidencias, ficheros adjuntos, comenta-rios, filtros, búsquedas o perfiles de usuarios, así como las operacionesque pueden efectuarse sobre dichas entidades.

Los usuarios que soliciten acceso a información protegida a la queno pueden acceder, de acuerdo a los privilegios que poseen, no podránsiquiera saber que dicha información existe. En el caso de las búsque-das, por ejemplo, JIRA ocultará oportunamente los datos inaccesiblesal usuario que está efectuando la solicitud.

Por otro lado, la flexibilidad de las políticas de seguridad quepueden crearse, permite no solo proteger a los datos almacenados enJIRA, sino construir flujos de trabajo que involucren usuarios distin-tos, con permisos distintos, en distintas fases del mismo: definiendolos roles de proyecto adecuados para cada proyecto, es muy sencillocrear políticas de seguridad basadas en roles que, siendo una propie-dad de cada proyecto, se asignen a las identidades que se requierancon independencia de los demás proyectos en los que operan.

1.6 Facilidad de gestión

La organización de las configuraciones en jerarquía de objetos reutili-zables llamados esquemas, además, proporciona una herramienta fácilde utilizar que minimiza las labores administrativas permitiendo en-capsular comportamiento común aplicable en distintos contextos enesquemas que puedan grabarse y aplicar a proyectos distintos cadavez que se detecte la necesidad.

La configuración basada en esquemas, además, es la herramien-ta fundamental que permite desacoplar los proyectos entre sí y pro-porcionar múltiples entornos de trabajos distintos y estancos a losusuarios de JIRA. Así mismo, por ejemplo, los flujos de trabajo a losque se someten las incidencias en un proyecto pueden ser definidosy modelados por los usuarios: esto permite gestionar sin esfuerzo ya través de una interfaz común no solo incidencias de proyectos dedesarrollo sino las entidades más diversas en proyectos de todo tipo.

7

1. Introducción

Documentación, riesgos de proyecto, facturas, órdenes de pago yentregas de material son solo algunos de los objetos gestionados porinstancias de JIRA en las organizaciones más distintas.

JIRA se integra perfectamente con otros productos de la suiteAtlassian tales como Crowd, FishEye/Crucible, Confluence y Bam-boo y permite agregar información procedente de cualquiera de estasherramientas en un único cuadro de mando utilizando la tecnologíade los gadgets.

1.7 Elegir una licencia

Comenzar a utilizar JIRA es fácil: Atlassian proporciona licencias deevaluación de la duración de 30 días que se pueden solicitar directa-mente en la web oficial de Atlassian. Una aplicación con licencia deprueba no tiene restringida prácticamente ninguna funcionalidad: laúnica forma de darse cuenta que se está utilizando una instancia deJIRA con licencia de evaluación será un aviso en el pié de página delinterfaz web avisando de esta condición con un mensaje parecido alsiguiente:

THIS JIRA SITE IS FOR DEMONSTRATION PURPOSES ONLY.

Después de haber probado libremente a JIRA con una licencia deevaluación, a menos de no encontrarse en el supuesto necesario parasolicitar a Atlassian una licencia gratuita (§??), es necesario adquiriruna licencia comercial para poder utilizar JIRA en un entorno deproducción.

1.7.1 Licencias comerciales

JIRA es una herramienta propietaria que requiere una licencia co-mercial para poderse utilizar. El modelo de licencia de JIRA se basaen el número máximo de usuarios activos que se desean utilizar en lainstancia de JIRA a licenciar: hoy en día existen licencias para 10,25, 100 e ilimitados usuarios.

En el Cuadro 1.1 se detallan las opciones y los precios de laslicencias comerciales de JIRA actualmente en comercio. Los preciosindicados en éste Cuadro se proporcionan a título informativo: paraconsultar los precios actualmente en vigor es necesario contactar conAtlassian [8] o con un Atlassian Partner [12] en cualquier país delmundo.

8

1.7. Elegir una licencia

Licencias comerciales10 Usuarios $1025 Usuarios $120050 Usuarios $2200

100 Usuarios $4000100+ Usuarios $8000

Tabla 1.1: Licencias comerciales

Pequeños proyectos con menos de 10 usuarios pueden solicitar lalicencia básica que es disponible a un precio simbólico de $10 cuyosbeneficios Atlassian destina a obras de beneficencias.

1.7.2 Licencia gratuita

También existe una licencia gratuita de JIRA que puede ser solicitadapor proyectos open source y organizaciones que cumplan una serie derequisitos entre los cuales figuran los siguientes:

(i) ser una organización sin ánimo de lucro;(ii) ser una organización no gubernamental;(iii) ser una organización no académica;(iv) ser una organización no comercial;(v) ser una organización no política;(vi) ser una organización secular.

1.7.3 Contactar con un Experto

Existe una red de expertos oficiales de Atlassian (Experts) a nivelmundial a los cuales los usuarios y las organizaciones pueden acu-dir para solicitar licencias o cualquier tipo de ayuda e informaciónadicional.

La lista de Partners oficiales de Atlassian está disponible a lasiguiente dirección [9]:

http://www.atlassian.com/resources/experts

9

2Conceptos básicos

A menudo los usuarios inexpertos de JIRA tienden a pensar en losproyectos solo como a una subdivisión “lógica” de incidencias en laplataforma: un conjunto de “sacos” con nombre, muy similares entreellos, donde almacenar las incidencias.

Esta visión, aún correcta en su esencia, es demasiado limitada yno toma en consideración ninguna de las características que hacen deJIRA la plataforma tan flexible que supo salir del nicho de la gestiónde proyectos de desarrollo y diferenciare de su “competencia”.

Esta percepción por parte de los usuarios puede a menudo generarproblemas a la hora de utilizar la herramienta lejos de los “paráme-tros” para los cuales ha sido creada y con los cuales está, todavía,siendo distribuida. JIRA, por defecto, proporciona un conjunto detipos básicos de incidencias y un flujo de trabajo estándar pero, adiferencia de otras herramientas, proporciona mucha flexibilidad a lahora de definir los “parámetros de trabajo”: prácticamente cualquieraspecto del entorno de trabajo puede configurarse.

Es imperativo que los usuarios, antes que nadie, entiendan cualesson los puntos de fuerza de JIRA y sean conscientes de las funcionali-dades que ésta puede ofrecer. Solo disponiendo de este conocimientolos usuarios podrán formular adecuadamente los requerimientos quemejor satisfagan a sus necesidades e impulsar la implementación delos mismos, por parte de los administradores, en el conjunto apropia-do de esquemas de configuración y “modelar” así la funcionalidad deun proyecto.

Por esta razón, en este capítulo introductivo se presentarán losconceptos básicos manejados en JIRA, tales como proyecto, incidenciay flujo de trabajo, y las relaciones que se establecen entre ellos, conel objetivo de familiarizar al usuario con estas “entidades” y con la

11

2. Conceptos básicos

organización de conceptos dentro de la plataforma ya que éstos sonlos objetos fundamentales que se manejan en JIRA.

2.1 Proyectos

En lo que concierne los usuarios de JIRA, un proyecto es el contenedorde las incidencias, el lugar donde los usuarios pueden abrir incidenciaso trabajar sobre ellas. El proyecto, además, es el contexto dondese aplican las configuraciones que satisfacen los requerimientos y lasfuncionalidades solicitadas por los usuarios. Siempre que un usuarioopera sobre una incidencia, lo hace en el contexto de un proyectoy la mayoría del comportamiento de JIRA y de las incidencias estádeterminado por las configuraciones que se han establecido a estenivel.

Aunque dominio de los administradores, es importante que losusuarios conozcan las herramientas que proporciona JIRA para con-figurar un proyecto y adecuarlo a sus necesidades. Para un usuario,el proyecto debe poderse considerar una instancia de JIRA “priva-da”, aislada de los demás proyectos. Los usuarios podrán entoncesdefinir sus requerimientos en libertad y solicitar a los administradoresla personalización de su proyecto para ajustarlo a las necesidades delnegocio que necesitan gestionar.

En las siguientes secciones (§2.5) se introducirá el concepto deesquema, se aclarará como los esquemas definen el “comportamiento”de las incidencias dentro de un determinado proyecto y se detallaránlos aspectos más importantes que los usuarios de un proyecto podránajustar a sus necesidades.

2.1.1 Componentes

Un proyecto puede dividirse opcionalmente en componentes. Un com-ponente es una agrupación “lógica” de incidencias y una incidenciapuede pertenecer a ninguno, uno o muchos componentes a la vez. Uncomponente tiene los siguientes atributos:

(i) Nombre.(ii) Descripción.(iii) Responsable del componente.

Un componente puede pensarse también como un “sub-proyecto”,con un responsable y un conjunto de incidencias a gestionar. JIRA,

12

2.1. Proyectos

de hecho, proporciona un cuadro de mando de componente, idénticoal cuadro de mando de proyecto, donde se visualizan los indicadoresde actividad del proyecto y otras estadísticas.

El responsable de un componente se un operador al que, por de-fecto, se asignan las incidencias de un componente: de esta manera,si entran incidencias en el sistema sin ser asignadas esplicitamentea un usuario, JIRA podrá asignarlas al “mejor” operador utilizandolos componentes a ella asignados como parámetros para tomar estadecisión.

La subdivisión de un proyecto en componentes, o sub-proyectos,será un requerimiento de los usuarios ya que, a menudo, no solo es unapartición lógica sino que refleja la organización del equipo. La ges-tión de los componente puede ser efectuada por usuarios que tenganlos permisos correspondientes, es decir, el permiso de proyecto Admi-nister projects. Aunque es común efectuar esta operación al principiodel proyecto, JIRA permite modificar la lista de componentes en cual-quier momento y añadir, por ejemplo, los nuevos componentes que sevayan necesitando con el tiempo.

En Figura 4.14 puede verse un detalle de la ventana de confi-guración de proyecto de Figura 4.4, el panel de componentes de unproyecto.

Figura 2.1: Componentes de un proyecto

Ejemplo 2.1. Un proyecto de desarrollo de una aplicación web po-dría organizar sus incidencias en componentes tales como:

(i) Database.(ii) Interfaz web.(iii) Documentación de proyecto.(iv) API.(v) Web Services.(vi) Pruebas.

13


En este caso cada componente refleja las tecnologías que se estánempleando para construir la aplicación y esta subdivisión permiteorganizar las incidencias en grupos que pueden ser asignados a equiposdistintos.

Ejemplo 2.2. Los usuarios de un proyecto JIRA para la gestiónde incidencias en un call center de una empresa de logística podríanrequerir una subdivisión del mismo en los siguientes componentes:

(i) Pedidos.(ii) Facturación.(iii) Transporte.

En este caso cada componente refleja una unidad organizativa dentrode la empresa.

2.1.2 Versiones

Algunas tipologías de proyecto podrían beneficiarse de una subdivi-sión en “fases” llamadas versiones. Una versión tiene los siguientesatributos:

(i) Nombre.(ii) Descripción.(iii) Fecha de entrega.(iv) Planificación.

Una versión puede estar en uno de los siguiente estados:

(i) Unreleased: la versión todavía no se ha entregado.(ii) Released: la versión se ha entregado.(iii) Archived: la versión se ha archivado.

Las versiones no están organizadas en jerarquías sino que son unconjunto de “atributos” de un proyecto que pueden relacionarse conlas incidencias en campos de tipo versión. Las incidencias de JIRAllevan por defecto dos campos relacionados con las versiones, Affectsversion(s) y Fix version(s), a través de las cuales pueden establecerselas relaciones básicas entre incidencia, i, y versione, v:

(i) La incidencia i afecta la versión v:

iafecta−−−−→ v (2.1)

14

2.1. Proyectos

(ii) La incidencia i se soluciona en la versión v:

ise soluciona en−−−−−−−−−→ v (2.2)

El usuario, sin embargo, podrá solicitar la creación de campos per-sonalizados de tipo versión y, por lo tanto, definir cualquier relaciónnecesite. Las versiones, en este sentido, pueden pensarse como untipo de “agrupación” más de incidencias de un proyecto.

A pesar del nombre y del origen de este tipo de campos, los usua-rios pueden utilizar campos de tipo versión para subdividir el proyec-tos en grupos de incidencias los cuales tienen como factor común unatributo con las características “peculiares” de una versión, es decir:una planificación y un estado (véase el Ejemplo 2.3).

Ejemplo 2.3. Los usuarios de un proyecto quisieran poder organizarlas incidencias en grupos utilizando el parámetro año. En este caso,el administrador de proyecto podrá definir una versión por cada añoque comienza. La fecha de vencimiento de la incidencia será el 31Diciembre del año correspondiente y, cada vez que termine un año, laversión se entregará para que cambie de estado y los usuarios vean elestado actualizado en los controles de tipo versión.

En este caso, la versión se utilizará simplemente para “registrar”las incidencias en el año corriente con independencia de los demás decampos de tipo fecha utilizados para la planificación de las incidencias.

Ejemplo 2.4. Un proyecto de desarrollo ha decidido utilizar la me-todología ágil Scrum [32] la cual sugiere dividir las actividades dedesarrollo en unidades básicas, llamadas sprint, de duración limitaday prefijada.

Para organizar las incidencias en JIRA de acuerdo a los princi-pios de Scrum y facilitar las labores del equipo, se pueden utilizarlas versiones para representar a un sprint y seguir un procedimientoparecido al siguiente:

(i) Al momento de la creación de las incidencias en JIRA no seutilizan los campos de tipo versión.

(ii) El Scrum Master (o quién tenga responsabilidades parecidas),después de cada reunión de planificación de un sprint, crea unaversión para representar el sprint.

(iii) Se “asignan” las incidencias a resolverse durante el sprint utili-zando campos de tipo versión.

15


(iv) La fecha de entrega de la versión corresponderá a la duraciónestablecida al sprint en curso.

(v) Al final de cada sprint, se entrega la versión correspondiente.

En Figura 4.10 puede verse un detalle de la ventana de configura-ción de proyecto de Figura 4.4 con las versiones de un proyecto.

Figura 2.2: Versiones de un proyecto

Las versiones pueden utilizarse para generar change logs y roadmaps disponibles, por defecto, en el cuadro de mando de JIRA comoilustrado en Figura 4.7.

Figura 2.3: Road map de un proyecto

2.2 Incidencias

Las incidencias son los “objetos de negocio” que se manejan en JIRA.Como explicado en el prefacio de esta guía, la utilización de la pala-bra “incidencia” radica en la costumbre de utilizar JIRA en proyectos

16

2.2. Incidencias

relacionados con el desarrollo y el control de calidad del software. Sinembargo, JIRA permite manejar proyectos e “incidencias” de cual-quier naturaleza.

En Figura 2.4 puede verse una captura de pantalla de la ventanaestándar de detalle de incidencia de JIRA. En la parte superior de laventana, debajo del título de la incidencia, pueden verse los botonesque representan todas las operaciones que el usuario puede efectuarsobre la incidencia. Los botones visibles dependerán de los privilegiosdel usuario y solo estarán disponibles las operaciones que estén habi-litadas de acuerdo a los permisos que el usuario conectado tenga enel contexto del proyecto utilizado.

La lista de campos visibles en esta ventana podrá depender de lasconfiguraciones personalizadas que el administrador haya implemen-tado en el proyecto y, por lo tanto, la ventana de detalle de incidenciade otro proyecto u otro tipo de incidencia podrá ser distinta de ven-tana de la ilustración.

Figura 2.4: Ventana de detalle de incidencia

17


2.2.1 Tipo de incidencia

Todas las incidencias en un proyecto pertenecen a un tipo de inciden-cia. El tipo de incidencia es uno de los parámetros fundamentalesque gobiernan el comportamiento de las incidencias en un proyectode JIRA ya que es la entidad con la que se establecen “enlaces” conlas demás categorías de parámetros de configuración relacionados conlas incidencias tales como:

(i) El comportamiento de las incidencias de cada tipo en un flujode trabajo.

(ii) Los datos almacenados en cada incidencia en una configuraciónde campos.

(iii) Las pantallas utilizadas por los usuarios en una configuraciónde pantallas.

Por defecto, JIRA proporciona los siguientes tipos de incidencia:

(i) Bug(ii) Improvement(iii) New feature(iv) Task

Dependiendo de los requerimientos de los usuarios, se podrán crea-rán los tipos de incidencias que cada proyecto necesite.

Ejemplo 2.5. Un proyecto para la gestión de auditorías de calidadde software podría requerir la definición de los siguientes tipos deincidencias:

(i) Riesgo: para modelar los riesgos de proyecto manifestados porlas aplicaciones a auditar.

(ii) Entregable: para modelar los entregables que las aplicacionessometen a auditoría.

(iii) Hito: para modelar los hitos en la planificación de las aplicacio-nes auditadas.

(iv) Auditoría: para modelar las auditorías solicitadas por las apli-caciones.

Ejemplo 2.6. Un un proyecto de desarrollo y mantenimiento de soft-ware podría requerir la definición de los siguientes tipos de incidencias:

18

2.2. Incidencias

(i) Dependencia: para modelar la dependencia con otro departa-mento u organización.

(ii) Documentación: para modelar la documentación a producirse.(iii) Instalación: para modelar la instalación de la aplicación en un

entorno.(iv) Configuración: para modelar la configuración de la aplicación

en un entorno.

2.2.2 Campos

Las incidencias, por defecto, llevan una serie de campos detallados enTabla 2.1.

Los campos estándar de las incidencias de JIRA no pueden ni bo-rrarse ni modificarse: a lo sumo, algunos campos pueden esconderse,siempre que sean campos opcionales de las incidencias.

Sin embargo, los usuarios no están limitados a utilizar exclusi-vamente los campos de incidencia estándar de JIRA: la plataformapermite “extender” el significado de las incidencias definiendo campospersonalizados y asignándolos a los tipos de incidencias que se deseanmodificar. De esta forma, los usuarios podrán solicitar los camposque necesitan almacenar en cada tipo de incidencia e modelar asílibremente la estructura de los objetos manejados por su negocio.

Ejemplo 2.7. Un proyecto para la gestión de auditorías de calidad desoftware podría requerir la definición de campos personalizados paralas incidencias de tipo riesgo y entregable vistas en el ejemplo 2.5.Para las incidencias de tipo riesgo se podrían definir los siguientescampos:

(i) Aplicación: la aplicación que manifiesta el riesgo.(ii) Tipo: el tipo de riesgo.(iii) Estado: el estado del riesgo (manifestado, mitigado, etc.).(iv) Impacto: el impacto del riesgo.

Para las incidencias de tipo entregable se podrían definir los si-guientes campos:

(i) Aplicación: la aplicación que somete a revisión el entregable.(ii) Tipo: el tipo de entregable.(iii) Estado: el estado del entregable (rechazado, aceptado, etc.).

19


Nombre DescripciónProject El proyecto al que pertenece la incidencia.Key El identificador único de la incidencia. El forma-

to del identificador es PKEY-IKEY donde PKEY esel identificador único del proyecto y IKEY es elidentificador único de la incidencia en el proyec-to.

Summary Título de la incidencia.Type El tipo de incidencia. (§2.2.1)Status El estado de la incidencia. (§2.2.4)Priority La prioridad de la incidencia. (§2.2.3)Resolution El estado de resolución de la incidencia (§2.2.5).Affect version(s) Opcional. Las versiones del proyecto en las cua-

les se está manifestando la incidencia.Fix version(s) Opcional. Las versiones del proyecto en las cua-

les estará resuelta la incidencia.Component(s) Opcional. Los componentes del proyecto relacio-

nados con la incidencia.Label(s) Opcional. Las etiquetas asignadas a la inciden-

cia.Environment Opcional. El entorno al que está relacionada la

incidencia.Description Descripción de la incidencia.Links Enlaces a incidencias relacionadas.Assignee El operador al que está asignada la incidencia.Reporter El usuario que ha abierto la incidencia.Votes Los votos otorgados a la incidencia.Watches El número de usuarios que están “observando” la

incidencia.Due Opcional. La fecha estimada de resolución de la

incidencia.Created Fecha de creación de la incidencia.Updated Fecha de última actualización de la incidencia.Resolved Fecha de resolución de la incidencia.Estimate Estimación del tiempo requerido para solucionar

la incidencia.Remaining Estimación del tiempo que queda para solucionar

la incidencia.Logged Suma del tiempo dedicado por los operadores a

la resolución de la incidencia.

Tabla 2.1: Campos estándar de una incidencia

20

2.2. Incidencias

Ejemplo 2.8. En un proyecto de desarrollo de software podrían asig-narse campos personalizados a los tipos de incidencias que represen-tan solicitudes a otros departamentos u otras organizaciones (véaseejemplo 2.6) para mantener traza de las mismas en el caso en que nose puedan utilizar enlaces de incidencias. Los campos que se podríandefinir son, por ejemplo:

(i) Número de ticket: el identificador de la solicitud.(ii) Acuerdo de nivel de servicio: para reflejar el acuerdo de nivel

de servicio que aplica a este tipo de incidencia.(iii) Contacto: para almacenar la persona de contacto a cargo de la

incidencia.

2.2.3 Prioridad

La prioridad de una incidencia es un campo que permite establecerla “importancia” relativa de una incidencia con respeto a otras in-cidencias en el mismo proyecto. Por defecto JIRA proporciona lassiguientes prioridades, en orden decreciente de importancia:

(i) Blocker : prioridad asignada a incidencias que bloquean el pro-gresar de otras labores.

(ii) Critical: prioridad asignada a incidencias de importancia críticaque, al momento, no están bloqueando otras labores.

(iii) Major : prioridad asignada a incidencias de importancia mayor.(iv) Minor : prioridad asignada a incidencias de importancia menor.(v) Trivial: prioridad asignada a incidencias de importancia trivial.

El administrador de JIRA puede definir niveles adicionales de priori-dad aunque dichos niveles no serán limitados al contexto de un pro-yecto sino a toda la plataforma.

La prioridad se utiliza primariamente en operaciones de filtradode incidencias, asignación y reporting.

Ejemplo 2.9. El jefe de proyecto o un cliente podrían estar interesa-dos a saber cuales incidencias alcanzan el nivel de prioridad critical yblocker. Las incidencias que alcanzan estos niveles de prioridad pue-den, por ejemplo, filtrarse a través de una búsqueda personalizadacuyo resultado puede utilizarse para poblar un gadget del cuadro de

21


mando o desencadenar una notificación por correo electrónico a losusuarios suscritos a dicho filtro.

2.2.4 Estado

El estado de una incidencia es un flag que indica en que punto de suflujo de trabajo (§2.3) se encuentra una incidencia. Los estados quepor defecto están definidos en el flujo de trabajo estándar de JIRAson los siguientes:

(i) Open: Estado inicial de una incidencia antes de que se empiecea operar sobre ella.

(ii) In progress: Incidencia sobre la cual un operador está trabajan-do.

(iii) Resolved: Incidencia que ha sido resuelta.(iv) Reopened: Incidencia que se ha vuelto a abrir después de haber

estado resuelta o cerrada.(v) Closed: Incidencia cerrada.

No es necesario que exista una relación “uno a uno” entre losestados de las incidencias y los estados del flujo de trabajo asociado aesa incidencia: normalmente, de hecho, distintos estados de un flujode trabajo pondrán ser relacionados al mismo estado de la incidencia.

Ejemplo 2.10. Un estado que a menudo puede estar asociado amúltiples estados de un flujo de trabajo es el estado In progress. Si unproyecto decide extender el flujo de trabajo estándar de JIRA parareflejar actividades de auditoría sobre el trabajo realizado, podríadecidir añadir los siguientes estados:

(i) Entregado.(ii) Auditando.(iii) Auditado.

Sin embargo, de cara a los operadores, puede considerarse innecesariocrear estados adicionales a relacionarse con dichos estados del flujode trabajo ya que, en lo que concierne el trabajo de los usuarios, laincidencia puede considerarse en progreso.

La relación entre estados de una incidencia y estados de un flujo detrabajo se establecen a nivel de flujo de trabajo y, por lo tanto, puedenconfigurarse en el contexto de un proyecto a través de un esquema deflujo de trabajo (§??). En Figura 2.5 se ilustran las relaciones entre

22

2.2. Incidencias

los conceptos de estado de incidencia y estado de un flujo de trabajo.

Figura 2.5: Relación entre estado de una incidencia y flujo de trabajo

Ejemplo 2.11. Un proyecto con necesidades parecidas al proyectoilustrado en el ejemplo 2.10 podría decidir de querer reflejar en el es-tado que una incidencia se encuentra en “espera” mientras los actoresexternos trabajan sobre ella. En este caso se podrían definir nuevoestados, tales como el estado En espera, y asignarlos a uno o másestado del flujo de trabajo de éste tipo de incidencia.

2.2.5 Resolución

A las incidencias que entran en un sistema no siempre se solucionande la misma forma: a veces se implementa una solución, otras veceslas incidencias no son tales y otras veces se toma la decisión de nosolucionarla. El campo resolución define “como” y “si” una incidenciase ha solucionado. Las resoluciones que JIRA define por defecto sonlas siguientes:

(i) Fixed: la incidencia ha sido resuelta.(ii) Won’t fix: la incidencia no se resolverá.(iii) Duplicate: la incidencia no se resolverá porque es un duplicado.(iv) Incomplete: la incidencia no se resolverá porque ha sido descrita

de forma incompleta.

23


(v) Cannot reproduce: la incidencia no se resolverá porque no sepuede reproducir siguiendo las instrucciones proporcionadas porel usuario que ha reportado la incidencia.

Los usuarios que necesiten definir nuevos tipos de resolución po-drán solicitarlas a los administradores de JIRA y las resolucionescreadas se añadirán al conjunto de resoluciones que existen en la pla-taforma.

Las resoluciones son un parámetro global de JIRA y, por lo tanto,serán visibles a todos los proyectos.

Ejemplo 2.12. En un proyecto donde se están gestionando inciden-cias proporcionando el servicio definido en un contrato de soporte,podrían definirse resoluciones adicionales para tener traza de la ca-suística que puede presentarse:

(i) Soporte insuficiente: la incidencia no se resolverá porque el ni-vel de soporte contratado por el usuario no cubre este tipo deincidencias.

(ii) Solicitud de mejora: la incidencia no se resolverá porque seconsidera una solicitud de mejora y, por lo tanto, deberá abrirseuna nueva incidencia del tipo correspondiente.

2.3 Flujos de trabajo

Los flujos de trabajo definen la máquina de estados asociada a unoo más tipos de incidencias en JIRA. JIRA proporciona un flujo detrabajo por defecto que no puede modificarse y que está ilustrado enFigura 2.6: las “cajas” son los estados de la máquina y las flechasson las transiciones entre estados. El flujo de trabajo por defectocontempla los siguientes estados:

(i) Open: una incidencia ha sido creada y todavía no se ha comen-zado a trabajar sobre ella.

(ii) In progress: se está trabajando sobre la incidencia.(iii) Resolved: la incidencia se ha resuelto.(iv) Closed: la incidencia se ha cerrado.(v) Reopened: la incidencia se ha vuelvo a abrir después de haber

sido resuelta o cerrada.

24

2.3. Flujos de trabajo

Figura 2.6: Flujo de trabajo por defecto de JIRA

Subrayamos que la aparente duplicidad entre el estado resuelta ycerrada se debe a que JIRA proporciona dos permisos de proyectodistintos para resolver y cerrar incidencias. Esta flexibilidad puedeutilizarse, por ejemplo, para otorgar el permiso de cerrar incidenciassolo a un subconjunto de usuarios que tienen como responsabilidadla supervisión del trabajo de los operadores.

Cada proyecto distinto puede tener necesidades de negocio dis-tintas y los flujos de trabajo asociados a cada tipo de incidencia sonuna parte fundamental de la adaptación de la herramienta a las ne-cesidades del negocio y de los usuarios. Un proyecto para gestionarcampañas de captación de clientes, por ejemplo, requerirá flujos detrabajo completamente distintos a los que requiera un proyecto dedesarrollo de software o un proyecto para la gestión de solicitudes desoporte técnico.

La creación de flujos de trabajos personalizados permite imple-mentar cualquier comportamiento que los usuarios requieran para to-dos los tipos de incidencias gestionados en su proyecto, siempre quedicho comportamiento se pueda modelar con una máquina de estados.

Un flujo de trabajo se modela de forma sencilla utilizando el inter-faz web de JIRA. Los usuarios, que normalmente no pueden utilizar

25


esta herramienta, deberán definir los siguientes requerimientos y pro-porcionarlos a los administradores de la plataforma:

(i) Los estados de la máquina de estados.(ii) Las transiciones entre estados.(iii) La relación entre estado de una incidencia y estado del flujo de

trabajo.

Adicionalmente, a cada transición podrán asignarse validadores, con-diciones y una pantalla a visualizarse durante la transición.

El administrador puede definir los flujos de trabajos necesariospara los proyectos de su organización y asignarlos a tipos de inciden-cias en el contexto de un proyecto a través de un esquema de flujo detrabajo.

Ejemplo 2.13. Un proyecto que utilice los tipos de incidencia intro-ducidos en el ejemplo 2.5 (riesgo, entregable, hito y auditoría) podríandesear asociarlas a flujos de trabajo personalizados.

El flujo de trabajo de las incidencias de tipo riesgo, por ejemplo,podría tener los siguientes estados:

(i) Manifestado.(ii) Mitigado.(iii) Transferido.(iv) Rechazado.

El flujo de trabajo de las incidencias de tipo auditoría podríaobtenerse copiando y “reduciendo” el flujo de trabajo estándar deJIRA:

(i) Open.(ii) In progess.(iii) Closed.

2.4 Organización de los conceptos

Parte de la flexibilidad de la plataforma se debe a la organizaciónmodular y jerárquica de los conceptos gestionados por la misma. Porun lado, JIRA organiza y subdivide las “configuraciones” en gruposde atributos, llamados esquemas, funcionalmente relacionados entreellos. Existen, por ejemplo, esquemas de configuración de campos, en

26

2.4. Organización de los conceptos

los cuales se establece el conjunto de parámetros de configuración delos campos de las incidencias, o esquemas de configuración de panta-lla, en los cuales se establece cuales pantallas se utilizarán por cadaoperación definida en el esquema.

Por el otro lado, el administrador selecciona los “módulos de con-figuración” necesarios a satisfacer las necesidades de un proyecto ylos asocia con el mismo. La estructura jerárquica resultante es el me-canismo a través del cual las configuraciones se aplican en el contextode los proyectos a ellas relacionados y garantizan que, con un me-canismo parecido a las “muñecas rusas”, cada proyecto de JIRA seaun entorno de trabajo completamente aislado de los proyectos que nocomparten esquemas con él.

Como explicado en §2.1, los usuarios de JIRA, cuando operansobre las incidencias, actúan siempre dentro en el contexto de unproyecto. El proyecto es el “contenedor” donde se agregan todos losesquemas de configuración de JIRA que estarán activos en el contextodel mismo: configuración de campos, pantallas, flujos de trabajo yseguridad son solo algunos ejemplos de las configuraciones que puedenestablecerse a nivel de proyecto.

Los esquemas que componen la configuración de un proyecto sonelementos que pueden reutilizarse cuando proyectos distintos compar-ten similitudes. Es importante, no obstante, subrayar que compartiresquemas genera un acoplamiento entre proyectos distintos y que, porlo tanto, cada modificación aportada en un esquema compartido sereflejará de inmediato en todo proyecto que lo esté utilizando.

Es responsabilidad de los usuarios determinar si, y cuando, com-partir esquemas entre proyectos distintos teniendo en cuenta de lasventajas y de los problemas que esta elección conlleva. Para facilitarlas tareas de administración parece conveniente reducir al mínimo elnúmero de esquemas existentes y fomentar la reutilización de configu-raciones que ya se han establecido. Sin embargo, nadie mejor que elusuario puede determinar cuando es conveniente crear nuevos esque-mas y dedicarlos exclusivamente a un proyecto o cuando es preferiblecompartirlos con otros.

Durante la toma de esta decisión habrá que analizar muchos fac-tores y oportunidades. Es necesario evaluar, por ejemplo, si las nece-sidades de un grupo de proyectos están sujetas a variar con el tiempoy acabar divergiendo.

En caso de duda, y siempre cuando se está considerando de com-partir esquemas con proyectos fuera de nuestro control, es convenientereducir las “interferencias” al mínimo y empezar solicitando esquemas

27


distintos. La consolidación de esquemas, cuando se detecta que esbeneficioso compartir esquemas y reducir la redundancia de configu-ración, siempre se podrá efectuar a posteriori.

2.5 Esquemas

Para aclarar este concepto es importante saber que, desde el puntode vista administrativo, un proyecto es una partición de JIRA conun nombre y un código de identificación en la cual se establecen lasrelaciones con los esquemas de configuración de JIRA. En Figura 2.7puede verse la relación que JIRA establece entre esquemas y proyec-tos.

Figura 2.7: Organización de los conceptos en JIRA

Las configuraciones establecidas en los esquemas relacionados conun proyecto determinan un gran número de parámetros de funciona-miento incluyendo, aunque la lista no sea exhaustiva, las ventanasdel proyecto, los tipos y los atributos de la incidencia y los flujos detrabajo. En la actualidad, un proyecto de JIRA establece relacionescon los siguientes esquemas:

(i) Esquema de tipos de incidencia (§2.5.2).(ii) Esquema de configuración de campos (§2.5.3).(iii) Esquema de pantallas para tipos de incidencia (§2.5.4).(iv) Esquema de flujo de trabajo (§2.5.5).(v) Esquema de notificación (§2.5.6).(vi) Esquema de permisos (§2.5.7).(vii) Esquema de seguridad de incidencia (§2.5.8).

Los esquemas son el medio a través del cual proyectos distintospodrán implementar requerimientos de negocios completamente dis-tintos. Como hemos visto en los ejemplos de las secciones precedente,

28

2.5. Esquemas

un proyecto de desarrollo de software podrá definir un conjunto detipos de incidencias, campos y flujos de trabajos que reflejen las ne-cesidades de un proyecto de ese tipo utilizando los correspondientestipos de esquemas. Un proyecto para gestionar una campaña de mar-keting, por otro lado, implementará las características únicas de sufuncionalidad en un conjunto de esquemas distintos que satisfagan asus necesidades.

Los esquemas de configuración, en las versiones de JIRA hastala fecha, solo pueden ser creados por los administradores de JIRA.Sin embargo, el conocimiento funcional para definir las característi-cas de cada esquema y si un esquema puede o no reutilizarse entreproyectos distintos es responsabilidad de los usuarios que han solici-tado dichos esquemas. Es fundamental, por lo tanto, que tanto losadministradores como los usuarios se familiaricen con este conceptosy sea conscientes de las implicaciones que existen cuando proyectosdistintos comparten algún esquema.

Ejemplo 2.14. Los tipos incidencias manejadas por los usuarios enel contexto de un proyecto, por ejemplo, están determinados por elesquema de configuración de tipos de incidencias. Proyectos que ma-nejen incidencias de tipos distintos se asociarán, por lo tanto, a es-quemas de tipos de incidencia distintos.

Ejemplo 2.15. El esquema de configuración de campos define el“significado” de las incidencias definiendo los atributos que estas al-macenan. Es por lo tanto posible que proyectos distintos estén com-partiendo un tipo de incidencia, como por ejemplo el tipo factura: sinembargo, cada uno de los proyectos podrá definir los atributos de ca-da tipo de incidencia y, por lo tanto, es en el contexto de un proyectodonde las incidencias cobran el significado que se les ha otorgado envirtud de las necesidades del mismo.

Ejemplo 2.16. Cada tipo de incidencia puede asociarse a un flujode trabajo a través del esquema de flujos de trabajo. Las operacionesdisponibles para cada tipo de incidencias están entonces definidaspor los flujo de trabajo a ellas asociados en el contexto del proyecto:los usuarios tiene, por lo tanto, plena libertad de definir sus flujoscon independencia de las elecciones que se hayan tomado en otrosproyectos.

29


2.5.1 Desacoplamiento de proyectos y reutilización deesquemas

Los esquemas de configuración de JIRA son una herramienta pode-rosa que permiten al administrador desacoplar las configuraciones delos proyectos a los que aplican. De esta forma los esquemas se con-vierten en componente reutilizables donde encapsular configuracionescomunes a más que un proyecto.

De la misma forma los esquema “aislan” proyectos distintos y per-miten crear, aplicar o modificar parámetros de configuración sin quedichas modificaciones interfieran en otros proyectos no relacionadoscon los esquemas modificados.

Una buena recomendación es que, a menos que los usuarios pidanexplícitamente que algunos proyectos compartan esquema, el admi-nistrador aísle todo proyecto creando un conjunto de esquemas “adhoc”. Para facilitar estas labores JIRA proporciona tanto la posi-bilidad de crear un nuevo esquema copiando un esquema existentecuanto la posibilidad de comparar esquemas distintos, comprobar sison equivalentes y reducir la redundancia. Es más seguro consolidaresquemas “a posteriori” que correr el riesgo que los proyectos interfie-ran el uno con el otro cuando se modifiquen algunas configuracionescompartidas.

2.5.2 Tipos de incidencias disponibles

Cada proyecto manejará “entidades” distintas y, por lo tanto, es im-portante que éstas se plasmen en los correspondientes tipos de inciden-cias disponibles a los usuarios sin limitarse a los tipos proporcionadospor defecto.

El esquema de tipos de incidencias es la herramienta que permitedefinir el conjunto de tipos de incidencias que se podrán manejar enel contexto de un proyecto.

2.5.3 Configuración de campos

Cada tipo de incidencia estará asociado a un conjunto de campospotencialmente distinto y JIRA proporciona la posibilidad de definirel contexto de aplicación de un campo personalizado que puede serglobal o por tipo de incidencia.

Aún así, proyectos distintos podrían necesitar configuraciones dis-tintas para los campos de los tipos de incidencias que comparten:

30

2.5. Esquemas

campos obligatorios en un proyecto podrían ser opcionales en otroso, incluso, algunos campos podrían ser “innecesarios” .

El usuario podrá definir, en un esquema de configuración de cam-pos, la obligatoriedad del campo, la visibilidad del campo y las pan-tallas en las cuales el campo está disponible.

2.5.4 Configuración de pantallas

JIRA presenta al usuarios pantallas distintas en respuesta a opera-ciones de diverso tipo:

(i) Creación de incidencia.(ii) Vista de detalle de incidencia.(iii) Modificación de incidencia.(iv) Transicciones de flujos de trabajo, tales como la resolución o el

cierre de una incidencia.

Por defecto, las pantallas que JIRA ofrece son muy parecidas y,por lo tanto, los usuarios inexpertos podrían no percatarse de estafuncionalidad. JIRA sin embargo, permite que el usuario configurecada pantalla de acuerdo a sus necesidades.

El usuario puede configurar la estructura de la pantalla propor-cionada por cada operación sobre las incidencias (creación, detalle yedición) e, incluso, especificar configuraciones distintas por cada tipode incidencia utilizada en un proyecto. El usuario, además, podráescoger una configuración de pantalla por cada transición de flujo detrabajo que requiera introducción de datos por parte del usuario.

Ejemplo 2.17. Los responsables de un proyecto que utiliza el tipode incidencia auditoría quisieran asegurarse de que algunos camposde una esta incidencia no pudiera modificarse después de haber sidointroducidos y antes de que la incidencia se cierre1.

Una de las formas de conseguir este objetivo es ofrecer la posi-bilidad de introducir este dato solo en la ventanas de transición deflujo de trabajo durante determinadas transiciones. Dependiendo dela máquina de estados del flujo de trabajo, podría ser incluso impo-sible volver a la ventana de transición y, por lo tanto, modificar elcampo en cuestión.

Aún cuando fuese posible efectuar otras transiciones para volver aesta ventana, el responsable de proyecto podrá aplicar una política de

1Una incidencia cerrada no puede modificarse

31


seguridad para asegurarse que solo los usuarios autorizados puedanefectuar esta operación.

2.5.5 Flujos de trabajos disponibles

Como explicado en §2.3, los usuarios de un proyecto pueden definirlos flujos de trabajo asociados a cada tipo de incidencia que manejanen sus proyectos en un esquema de flujo de trabajo.

JIRA ofrece a sus usuarios un motor de flujos de trabajo flexible ypoderoso. La definición de flujos de trabajo personalizados permite:Describe all of

the options?

(i) Definir el ciclo de vida de las incidencias.(ii) Definir las operaciones que pueden efectuarse sobre una inci-

dencia.(iii) Establecer políticas de seguridad que protejan el ciclo de vida

de una incidencia y otorguen la posibilidad de efectuar cadatransición exclusivamente a los usuarios que tengan los permisosnecesarios.

(iv) Definir reglas de validación a evaluarse durante cada transición.(v) Definir condiciones que deben satisfacerse durante cada transi-

ción.(vi) Definir estados de incidencia asociados a cada estado del flujo

de trabajo.(vii) Asociar una ventana a cada transición.(viii) Asociar operaciones a efectuarse después de cada transición ta-

les como el lanzamiento de una notificación.

2.5.6 Notificaciones

JIRA, en respuesta a determinados eventos, envía notificaciones a losusuarios que hayan sido suscritos a cada uno de ellos.

El esquema de notificaciones establece la relación entre tipos deeventos y usuarios que recibirán la notificación. Los eventos dispo-nibles en la actualidad en el esquema de notificación son los eventosdetallados en Tabla 2.2.

La creación de relaciones entre evento e identidades es muy flexibleya que los usuarios de un proyecto pueden asignar eventos no soloa cuentas de usuarios (o grupos) de JIRA, sino a un conjunto másamplio de identidades:

(i) Asignatario de la incidencia.

32

2.5. Esquemas

Nombre DescripciónIssue created Creación de una incidencia.Issue updated Actualización de una incidencia.Issue assigned Asignación de una incidencia a un usuario.Issue resolved Resolución de una incidencia.Issue closed Cierre de una incidencia.Issue commented Creación de comentario en una incidencia.Issue comment edited Modificación de un comentario en una inci-

dencia.Issue reopened Reabertura de una incidencia.Issue deleted Borrado de una incidencia.Issue moved Migración de una incidencia a otro proyecto.Work logged on issue Trabajo registrado en una incidencia.Work started on issue Trabajo comenzado en una incidencia.Work stopped on issue Trabajo terminado en una incidencia.Issue worklog updated Actualización de registro de trabajo en una

incidencia.Issue worklog deleted Borrado de registro de trabajo en una inci-

dencia.Generic event Evento genérico.

Tabla 2.2: Eventos en el esquema de notificaciones

(ii) Reporter de una incidencia.(iii) Responsable de proyecto.(iv) Responsable de componente.(v) Usuario.(vi) Grupo.(vii) Rol de proyecto.(viii) Dirección de correo electrónico.(ix) Usuarios que estén observando la incidencia.(x) Usuario indicado en un campo personalizado de la incidencia.(xi) Grupo indicado en un campo personalizado de la incidencia.

Un usuario que desee ser avisado de inmediato cuando se produ-ce algún evento, podrá utilizar el mecanismo de las notificaciones y“subscribirse” a las fuentes de eventos que le interesan.

Los eventos genéricos proporcionan, además, la posibilidad deemitir un evento en respuesta de acciones que no están previstas enJIRA. En una transición de un flujo de trabajo personalizado, por

33


ejemplo, podrán lanzarse un evento genérico para que los usuariospuedan “interceptar” dicha acción y recibir la correspondiente notifi-cación.

Ejemplo 2.18. En un proyecto los operadores pueden resolver perono cerrar las incidencias ya que, cada una de ellas, deberá ser revisaday cerrada solo para usuarios en el rol de proyecto revisores.

Los revisores pueden utilizar el mecanismo de las notificaciones pa-ra ser avisados cada vez que una incidencia entra en el estado resueltapara minimizar los tiempos de respuesta del equipo. Estos usuariospodrán suscribirse al evento Issue resolved pidiendo que se añada surol en la lista de identidades que reciben este tipo de notificaciones.

Utilizando el rol de proyecto, además, se podrán utilizar las “cate-gorías” de usuarios del proyecto, y no de la plataforma, facilitando asíla administración de las identidades y los parámetros de configuracióna ellas relacionado en el ámbito de cada proyecto.

Ejemplo 2.19. Una organización desea poder moderar los comen-tarios de las incidencias ya que, en algunos casos, los usuarios quetienen acceso a la plataforma están fuera del control de la misma.

Para solventar este problema, los responsables de proyecto puedensolicitar la creación de un rol de proyecto para los moderadores y aña-dir esta identidad a los usuarios que reciben las notificaciones de loseventos Issue commented e Issue comment edited. Los moderadoresrecibirán las notificaciones en tiempo real y podrán así moderar todocomentario creado o modificado sin necesidad de controlar periódica-mente las incidencias modificadas.

Ejemplo 2.20. Un proyecto ha definido flujos de trabajo personali-zados para un conjunto de tipos de incidencias que contempla transi-ciones a un estado llamado auditado. Las transiciones sucesivas, hastaal cierre de las incidencias, solo pueden ser ejecutadas por usuariosen el rol responsables, previa revisión de las labores desempeñadas.Es imperativo, para garantizar la continuidad de las labores y la re-ducción de los tiempos de acción, que los usuarios de este rol puedanser notificados de inmediato cada vez que una incidencia requiera suatención.

Los usuarios del rol responsables se añadirán por lo tanto a losusuarios que reciben notificaciones de eventos genéricos (Generic e-vent) y se modificará el flujo de trabajo de manera que se lance dichoevento durante la transición al estado auditado.

34

2.5. Esquemas

2.5.7 Políticas de seguridad

El esquema de permisos es la herramienta que permite definir laspolíticas de seguridad que aplican en el contexto de un proyecto. JIRAde fine un conjunto de permisos que permiten construir políticas deseguridad con “grano muy fino” y organizar los usuarios que accedena un proyecto en todos los roles que se consideren necesarios.

Debido a la complejidad de este tema, se ha dedicado un capítuloentero del Volumen ii de esta guía (§??) a la definición de políticasde seguridad en JIRA. No obstante, es importante subrayar que losresponsables de un proyecto pueden solicitar la definición de rolesde proyectos y políticas de seguridad que les permitan proteger, deacuerdo a sus necesidades, la información almacenada en JIRA.

Los usuarios no necesitan conocer detalladamente la organizaciónde los permisos de JIRA. Sin embargo, considero oportuno que losusuarios conozcan, por lo menos a grandes rasgos, las categorías quepermisos que existen:

(i) Permisos para proteger proyecto.(ii) Permisos para proteger incidencia.(iii) Permisos para proteger votantes y observadores.(iv) Permisos para proteger comentarios.(v) Permisos para proteger ficheros adjuntos.(vi) Permisos para proteger el registro de trabajo.

Los permisos, en general, permiten proteger las acciones más comu-nes que pueden efectuarse sobre las entidades que protegen, comopor ejemplo la creación, la actualización y la eliminación. JIRA tam-bién permite proteger las transiciones de flujo de trabajo asignandopolíticas de seguridad a las transiciones del mismo.

Como usuarios, por lo tanto, no debemos extrañarnos si en de-terminadas situaciones vemos que alguna funcionalidad nos ha sidorestringida, tanto a nivel de plataforma como a nivel de proyecto.Como jefes de proyecto, debemos ser conscientes de la flexibilidadde JIRA a la hora de parametrizar nuestros proyectos, para definir eimplementar un “entorno” que satisfaga nuestros requerimientos fun-cionales, incluidos los requerimientos de seguridad.

Ejemplo 2.21. Los responsables de un proyecto tienen la responsa-bilidad de asignar las incidencias para distribuir el trabajo entre losoperadores de acuerdo a su criterio y las necesidades de la empresa.

35


Para otorgar el permiso para asignar una incidencia a un subcon-junto de usuarios, es suficiente otorgar el permiso Assign issues al rolresponsables y revocarlo a todos los demás roles de proyecto.

Ejemplo 2.22. Los responsables de proyecto y componentes quierenrevisar el trabajo desempeñado por los operadores para aprobar elcierre de las incidencias.

En este caso, será necesario otorgar el permiso Close issues a losroles a los que pertenecen los responsables y revocarlo a todos losdemás roles de proyecto. De esta forma, los operadores podrán exclu-sivamente al estado correspondiente a la resolución de una incidenciay los operadores se reservarán el privilegio de cerrarlas, cuando locrean conveniente.

Ejemplo 2.23. En el proyecto cuyos requerimientos se han descritoen el ejemplo 2.20 será necesario crear los roles de proyectos necesa-rios a definir las políticas de seguridad que se necesitan implementary proteger las transiciones de flujo de trabajo que se originan en elestado auditado asignando el permiso de efectuar las mismas exclusi-vamente a los roles correspondientes.

2.5.8 Niveles de seguridad de las incidencias

Las herramientas para definir políticas de seguridad descritas en pre-cedencia (§2.5.7), permiten crear políticas de “grano muy fino” perono permiten distinguir entre incidencias.

A veces, sin embargo, puede surgir la necesidad de restringir elacceso a incidencias concretas y sería incómodo, o inviable, crear pro-yectos distintos para poder proteger las incidencias distintas con po-líticas distintas.

Para solventar este problema y dar soporte a este escenario, JIRApermite definir esquemas de nivel de seguridad. Un esquema de estetipo define un conjunto de niveles de seguridad y el acceso a cada unode los niveles puede otorgarse a un conjunto de identidades, entre lascuales las siguientes:

(i) Reporter de la incidencia.(ii) Usuario.(iii) Grupo.(iv) Rol de proyecto.(v) Responsable de proyecto.(vi) Asignatario de la incidencia.

36

2.5. Esquemas

(vii) Usuario indicado en un campo personalizado de la incidencia.(viii) Grupo indicado en un campo personalizado de la incidencia.

Los niveles de seguridad, por lo tanto, permiten definir tantas po-líticas de seguridad como el proyecto requiera para proteger a susincidencias.

La incidencia a protegerse podrá asociarse a un nivel de seguridady la asociación podrá cambiarse siempre que sea necesario. En esemomento, el acceso estará restringido a las identidades especificadaspor la política de seguridad del nivel asignado.

La asociación de una incidencia con un nivel de seguridad podráhacerla exclusivamente un usuario con el permiso Set issue security.

Ejemplo 2.24. Un proyecto se utiliza para recibir incidencias deusuarios con múltiple niveles de servicio. Los responsables del pro-yecto requieren que se restrinja el acceso a las incidencias que conten-gan información disponible exclusivamente a los usuarios que hayancontratado el nivel de soporte correspondiente, o superior.

Una de las formas de conseguir este objetivo es el siguiente:

(i) Crear los roles de proyecto necesarios a definir las políticas deseguridad que se requieren, por ejemplo Usuarios Plata, Usua-rios Oro y Usuarios Platino.

(ii) Crear un esquema de nivel de seguridad para incidencias y crearun nivel de seguridad para cada nivel de soporte.

(iii) Otorgar el acceso a cada nivel de seguridad al rol correspon-diente (y a los superiores).

Ejemplo 2.25. Un equipo quiere compartir su proyecto con usuariosexternos para permitirles abrir incidencias en el mismo proyecto enque trabajan. Sin embargo, también se requiere que los usuariosexternos puedan ver exclusivamente las incidencias abiertas por ellosmismos y ocultar las incidencias “internas” del equipo de trabajo.

Para conseguir este objetivo se puede:

(i) Crear un rol de proyecto para los usuarios externos.(ii) Crear un esquema de nivel de seguridad para incidencias con

dos niveles de seguridad: un nivel para los usuarios de la or-ganización (Internos) y otro nivel para los usuarios externos(Externos).

37


(iii) Otorgar acceso a cada nivel de seguridad a los roles correspon-dientes.

38

3Primeros pasos

En este capítulo se hará una introducción de JIRA y de las operacio-nes básicas que un usuario puede efectuar:

(i) Acceso a la plataforma, introducción de las credenciales de usua-rio y el recupero de credenciales olvidadas.

(ii) Introducción al cuadro de mando de JIRA y de su funcionalidadbásica.

(iii) Atajos de teclado.

Para un usuario, es sorprendente darse cuenta de como la mayo-ría de la funcionalidad de JIRA esté condensada en un conjunto deventanas tan reducido sin que su compleja funcionalidad afecte nega-tivamente ni a la usabilidad, ni a la homogeneidad, ni a su coherenciacomo conjunto.

Es muy importante afianzarse con ellas, ya que en ellas los usua-rios pasarán casi la totalidad del tiempo pasado en JIRA. El gradientede aprendizaje es muy suave y en poco tiempo, y casi de forma au-tomática, los usuarios aprenderán a interactuar con la funciones másavanzadas de la herramienta.

3.1 Login: acceder a JIRA

Los usuarios interactúan con JIRA principalmente a través de su in-terfaz web. Dependiendo de las políticas de seguridad implementadaspor el administrador, el acceso a algunas secciones de la herramientaspodría ser permitido a usuarios anónimos mientras que el acceso aotras secciones (o incidencias) podría estar restringido a usuarios au-tenticados que tengan los privilegios necesarios para acceder al recursosolicitado.

39

3. Primeros pasos

Dependiendo del modo en que JIRA esté ejecutándose, además,un usuario podría crearse unas credenciales de acceso de forma auto-mática solicitándolas a través de un formulario en la aplicación misma(modo público) o podría necesitar la intervención de un administradorpara la creación manual de una cuenta (modo privado).

En Figura 3.1 puede verse la ventana de login de JIRA en modopúblico en la cual aparece el enlace Sign up que lleva a la ventanapara la creación de una cuenta de usuario cuya captura de pantallapuede verse en Figura 3.2. Si el usuario ha olvidad sus credenciales, elenlace Can’t access your acccount? puede ser utilizado para solicitarla creación de una nueva contraseña, generada por el sistema, y suenvío a través de la cuenta de correo electrónico del usuario que hasolicitado la contraseña.

Figura 3.1: Ventana de login de JIRA

A través de la ventana de login un usuario puede introducir suscredenciales y autenticarse en la plataforma. Después de la autenti-cación el usuario accederá directamente al cuadro de mando de JIRA.

3.2 Cuadro de mando

El cuadro de mando de JIRA es una ventana que cada usuario puedeconfigurar a su gusto. En el cuadro de mando pueden integrarse gad-gets OpenSocial: JIRA proporciona un conjunto de gadgets con loscuales pueden visualizarse contenidos tales como reportes, resultadosde filtros de búsquedas, gráficos así como datos provenientes de otrasaplicaciones. Las aplicaciones de la suite de productos Atlassian, talescomo JIRA, Confluence, FishEye o Bamboo, pueden publicar sus gad-gets y ser utilizados en los cuadros de mandos de otras aplicaciones.

40

3.3. Barra de las herramientas

Figura 3.2: Ventana de signup de JIRA

De esta forma usuarios que deseen agregar información provenientede muchas aplicaciones, como los jefes de proyecto, podrán concen-trarla en un único sitio donde facilitar su explotación. De la mismaforma podrán insertarse en el cuadro de mando gadgets desarrolladospor la organización e integrar así JIRA con otras aplicaciones de laempresa.

3.3 Barra de las herramientas

La barra de las herramientas es una barra visualizada en cada páginade JIRA que proporciona la utente enlaces rápidos a las páginas máscomunes de JIRA. En la parte izquierda de la barra de herramientas,ilustrada en Figura 3.3, el usuario puede acceder a los menus de JIRAque, por defecto, son los siguientes:

(i) Dashboards: proporciona acceso al cuadro de mando de sistema,a los cuadros de mandos más utilizados y a la ventana de gestiónde los mismos.

(ii) Projects: proporciona acceso rápido al último proyecto utili-zado, a los proyectos más utilizados y a la lista completa deproyectos visibles al usuario conectado.

41

3. Primeros pasos

(iii) Issues: proporciona acceso rápido a las ventanas de búsqueday creación de incidencias, a las últimas incidencias visitadas, alos filtros favoritos y a la ventana de gestión de los mismos.

Figura 3.3: Sección de menus de la barra de herramientas de JIRA

Los plugins de JIRA pueden enriquecer la barra de herramientasañadiendo menus (o entradas de menus) personalizados: en la imagenprecedente puede apreciarse por ejemplo el menu Agile, un menu pro-porcionado por un plugin de JIRA, GreenHopper. Dependiendo de laconfiguración de JIRA, por lo tanto, los menús visualizados podránvariar: los menús de primer nivel presentes por defecto y detalladosen precedencia, sin embargo, estarán siempre visibles.

En Figura 3.4 puede verse la parte derecha de la barra de herra-mientas de JIRA. Esta parte hospeda los siguientes controles:

(i) El menu del usuario.(ii) El enlace al menú Administration.(iii) El control de texto para la búsqueda simple.(iv) El botón Create issues para la creación de nuevas incidencias.

Figura 3.4: Sección de herramientas de la barra de herramientas deJIRA

3.3.1 Menú Dashboards

El menu Dashboards (Cuadros de mandos) proporciona al usuario unacceso directo a los cuadros de mando disponibles y a su herramientade gestión. Los cuadros accesibles a un usuario son el cuando demando del sistema, los cuadros de mandos personales que el mismo

42

3.3. Barra de las herramientas

usuario se haya creado y los demás cuadros de mandos compartidoscon él por otros usuarios.

El menú desplegable del menú Dashboards contiene los siguienteselementos:

(i) Un enlace al cuadro de mando de sistema.(ii) Una lista de cuadros de mando a los que se haya accedido re-

cientemente.(iii) Un enlace a la herramienta de gestión de cuadros de mandos.

En §?? se detallará el funcionamiento de las herramientas de ges-tión de los cuadros de mando.

3.3.2 Menú Projects

El menú Projects (Proyectos) proporciona la usuario un acceso directoa la ventana principal del último proyecto al que se haya accedido.

El menú desplegable del menú proyectos contiene los siguienteselementos:

(i) El proyecto corriente, es decir, es último proyecto utilizado porel usuario a través de cualquier ventana de JIRA.

(ii) Una lista de proyectos a los que se haya accedido recientemente.(iii) La lista de todos los proyectos visibles al usuario.

3.3.3 Menú Issues

El menu Issues (Incidencias) proporciona al usuario un acceso di-recto al navegador de incidencias, la herramienta que permite crearbúsquedas y filtros utilizando una interfaz web intuitiva y adapta acualquier usuario (§6 y siguientes).

El menú desplegable del menú Issues contiene normalmente lossiguientes elementos:

(i) Un enlace al navegador de incidencias.(ii) Un enlace a la ventana de creación de incidencia.(iii) Una lista de enlaces a las últimas incidencias que se hayan ma-

nejado.(iv) Un enlace a la herramienta de gestión de filtros.

En §6 y siguientes se detallarán las funciones de búsqueda y filtra-do ofrecidas por JIRA, tales como la gestión de filtros y el navegadorde incidencias (§6.2).

43

3. Primeros pasos

3.3.4 Menu Administration

Si el usuario tiene los privilegios necesarios y puede entrar en el apar-tado de administración, Administration, entonces JIRA proporcio-nará una barra de herramientas dedicada mientras que el usuariopermanezca en dicha modalidad1.

En Figura 3.5 puede verse el lado izquierdo de la barra de he-rramientas en modalidad administración, con menús de primer nivelpara acceder a las apartados de administración más utilizados:

(i) Administración de proyectos.(ii) Administración de plugins.(iii) Administración de usuarios.(iv) Administración de incidencias.(v) Administración del sistema.

En Figura 3.6 puede verse su lado derecho, muy parecido al la-do derecho de la barra de herramientas en modalidad usuario, con elenlace Exit Administration que permite salir del apartado de admi-nistración.

Figura 3.5: Barra de herramientas de JIRA — Administración — Parteizquierda

Figura 3.6: Barra de herramientas de JIRA — Administración — Partederecha

1En las versiones de JIRA precedentes a la versión 5, en lugar de proporcionaruna barra de las herramientas distinta, JIRA proporcionaba un menú de primernivel adicional en la misma, llamado Administration.

44

3.4. Atajos de teclado

3.3.5 Menu del usuario

El menu del usuario, situado en la parte superior derecha de la barrade herramientas de JIRA, proporciona un acceso rápido a la ventanade gestión del perfil del usuario. En esta sección el usuario puede,a través de una serie de cuadros de mando, gestionar su perfil y suspreferencias. El cuadro de mando del perfil del usuario proporciona,entre otras, la siguiente información:

(i) Detalles del perfil de usuario.(ii) Flujo de actividad del usuario.(iii) Proyecto con incidencias abiertas del usuario.(iv) Configuraciones personales de JIRA.

3.4 Atajos de teclado

Recientemente, JIRA ha incorporado los atajos de teclado en su inter-faz web: en lugar de poder utilizar exclusivamente el ratón, el usuariopuede ahora utilizar el teclado para interactuar con JIRA2. Algunosatajos están disponibles a nivel global y pueden por lo tanto utilizarseen cualquier ventana de JIRA; otros son específicos de algunas ven-tanas en concreto. Para acceder a una ventana de ayuda que resumelos principales atajos3, una captura de pantalla de la cual puede verseen Figura 3.7, es suficiente teclear ? o Shift+/.

3.4.1 Tecla modificadora

En algunos atajos de teclado se utiliza una tecla modificadora quedepende tanto del navegador como del sistema operativo utilizado porel cliente. La tecla modificadora, desde aquí en adelante, se indicarácon el símbolo �. En Tabla 3.1 se resume cual es la tecla modificadoraen los navegadores y los sistemas operativos más utilizados.

2Los atajos de teclado deben estar habilitado a nivel de plataforma. Si no loestuviesen, es necesario solicitar su activación al administrador de JIRA. Siempreque a nivel de sistema esté habilitada, un usuario puede personalizar el compor-tamiento de JIRA para sus sesiones activando o desactivando esta funcionalidaden su perfil de usuario.

3Los atajos de teclado, como cualquier otro elemento de la interfaz gráfica deJIRA puede extenderse a través de plugins. En este caso, la ventana de ayuda encuestión también incluye atajos de teclados definidos por Greenhopper.

45

3. Primeros pasos

Figura 3.7: Ventana de ayuda de los atajos de teclado

Tecla modificadoraNavegador Windows UNIX Mac OS XFirefox Alt + Shift Alt + Shift CtrlInternet Explorer AltSafari Ctrl Ctrl + AltChrome Alt + Shift Alt + Shift Ctrl + Alt

Tabla 3.1: Tecla modificadora por navegador y sistema operativo

46


3.4.2 Atajos globales

Los atajos de teclado globales, disponibles en cualquier ventana deJIRA, están resumidos en Tabla 3.2. La nomenclatura de los atajoses la siguiente:

(i) x, y: se pulsa la tecla x, se suelta y se pulsa la tecla y.(ii) x + y: se pulsa la tecla x y, manteniéndola pulsada, se pulsa la

tecla y.(iii) x | y: se puede pulsar la tecla x o la tecla y.

Atajos de teclado globalesAtajo Descripcióng, d Abre el cuadro de mando.g, p Abre el proyecto corriente.g, i Abe el navegador de incidencias./ Pone el cursor en el campo Quick search (Búsqueda rá-

pida).c Abre la ventana de creación de una incidencia.? Abre la ventana de ayuda de los atajos de teclado.� + d Abre el menu desplegable Dashboards.� + p Abre el menu desplegable Projects.� + i Abre el menu desplegable Issues.g, g Abre la ventana de búsqueda Administration Search.

Tabla 3.2: Atajos de teclado globales

3.4.3 Atajos de las ventanas de incidencias

Los atajos descritos a continuación (Tabla 3.3) pueden utilizarsetanto en la ventana de detalle de incidencia como en el navegador deincidencias.

3.4.4 Atajos en los formularios

Los atajos descritos a continuación (Tabla 3.4) pueden utilizarse encualquier formulario de JIRA.

47

3. Primeros pasos

Atajos de teclado — Ventanas de incidenciasAtajo Descripcióno | Enter Abre la incidencia seleccionada en el navegador de

incidencias.j Navega a la incidencia siguiente (solo si se ha llegado

a la incidencia desde el navegador de incidencias).k Navega a la incidencia precedente (solo si se ha llega-

do a la incidencia desde el navegador de incidencias).u Vuelve al navegador de incidencias (solo si se ha lle-

gado a la incidencia desde el navegador de inciden-cias).

[ Nasconde o muestra el panel izquierdo en el navega-dor de incidencias.

n Navega al siguiente elemento en la sección de activi-dad (en la pantalla de detalle de incidencia).

p Navega al precedente elemento en la sección de acti-vidad (en la pantalla de detalle de incidencia).

f Posiciona el cursor en el campo búsqueda avanzadao búsqueda simple.

Esc Quita el foco de un campo de texto (para poder uti-lizar los demás atajos de teclado).

e Abre la página Modifica incidencia.a Abre la ventana Asigna incidencia.m Abre la ventana para añadir comentarios a una inci-

dencia.l Abre la ventana Etiquetas.s Abre la ventana Share para compartir una inciden-

cia.. Abre la ventana Operaciones, desde la cual se pue-

de acceder (buscándola textualmente) y lanzar cual-quier operación aplicable a la incidencia selecciona-da.

Tabla 3.3: Atajos de teclado en las ventanas de incidencias

48


Atajos de teclado — FormulariosAtajo Descripción� + s Envía un formulario.� + ‘ Anula un formulario.Esc Quita el foco de un campo de texto (para poder utilizar

los demás atajos de teclado).u Vuelve a la ventana de detalle de la incidencia.� + r Selecciona la checkbox para recordar las credenciales del

usuario (solo en el formulario de login).

Tabla 3.4: Atajos de teclado en los formularios de JIRA

49

4Explorar un proyecto

JIRA ofrece a sus usuarios dos tipos de ventanas en las cuales seresume la información presente en la plataforma:

(i) Los cuadros de mandos.(ii) Los navegadores de proyecto.

Los cuadros de mandos, como se verá en §11, son pantallas total-mente configurables por el usuario en las cuales, a través de gadgetsOpenSocial, éste puede agregar toda la información procedente de laplataforma que necesite. Los cuadros de mandos son herramientasideales para obtener una visión global del estado de los proyectos ylas actividades en las cuales esté involucrado un usuario.

La pantalla de navegación de un proyecto, sin embrago, es unapantalla diseñada para que el usuario pueda acceder de forma rápidae intuitiva a toda la información relacionada con un proyecto, nave-gar en los detalles de cada sección e, incluso, generar reportes (másinformación acerca de este tema se detallará en §10).

En este capítulo se detallarán las características de la ventana na-vegador de proyecto y las herramientas que JIRA proporciona a losusuarios para analizar en todo detalla la información procedente delos proyectos. Téngase en cuenta que en este capítulo se encontraránmuchos conceptos que serán objeto de discusión en los capítulos si-guientes de este libro. He ha intentado poner un número suficiente dereferencias cruzadas para ayudar el lector a profundizar los conceptosque se van introduciendo en este capítulo.

4.1 Estructura

Un usuario puede acceder al navegador de proyecto seleccionando unproyecto en el menú desplegable Projects en la barra de herramien-

51

4. Explorar un proyecto

tas de JIRA. En las versiones más recientes de JIRA esta ventanaestá en realidad compuesta por un conjunto de ventanas que agreganinformación de distintos ámbito (Figura 4.1).

Figura 4.1: Navegador de proyecto.

Las ventanas que componen el navegador están organizadas conuna interfaz gráfica de “pestañas” (Figura 4.2): a través de ellas,el usuario puede acceder a la información que necesita. Las pestañaspresentes en el navegador de proyecto, y por lo tanto las ventanascorrespondientes, pueden variar ya que dependen de un conjunto de

52

4.1. Estructura

Figura 4.2: Navegador de proyecto.

factores, como por ejemplo la integración de JIRA con otros produc-tos, que se detallarán a continuación. A título de ejemplo, en Figura4.2 puede verse el conjunto de pestañas presentes en el navegador deproyecto de una instalación típica de JIRA.

Desde esta ventana, el usuario tiene acceso a toda la informaciónrelativa al proyecto y sus atributos:

(i) Información relativa al proyecto (Tabla 4.1).(ii) Información relativa a las versiones de un proyecto (Tabla 4.2).(iii) Información relativa a los componentes de un proyecto (Tabla

4.3).

4.1.1 Acceso rápido a la creación de incidencias

El navegador de proyecto, con independencia de la ventana seleccio-nada por el usuario, proporciona una barra rápida de creación de

53


Nombre DescripciónSummary Actividad reciente del proyecto y lista de incidencias

que están por caducar.Issues Resumen de las incidencias agrupadas por estado.

Resumen de las incidencias no resueltas agrupadaspor asignatario, prioridad, versión y componente.

Road Map Incidencias no resueltas para las siguientes versionesde un proyecto.

Change Log Incidencias resueltas en precedentes versiones de unproyecto.

Popular Issues Incidencias no resueltas ordenadas por popularidad.Versions Resumen de las versiones recientes.Components Resumen de los componentes.Labels Resumen de las etiquetas utilizadas en las inciden-

cias.Builds Builds de Atlassian Bamboo (disponible exclusiva-

mente si se configuró la integración entre JIRA yBamboo).

Source Resumen de los cambios recientes registrados en Fis-hEye (disponible exclusivamente si se configuró laintegración entre JIRA y FishEye).

Reviews Resumen de las revisiones recientes registrados enCrucible (disponible exclusivamente si se configuróla integración entre JIRA y Crucible).

Tabla 4.1: Navegador de proyecto — Información relativa al proyecto.

Nombre DescripciónVersion Summary Actividad reciente en una versión del proyec-

to y lista de actividades que están cerca desu caducidad.

Version Issues Incidencias asignadas a una versión del pro-yecto.

Version Popular Issues Incidencias populares asignadas a una ver-sión del proyecto.

Version Builds Builds de Atalssian Bamboo de una versióndel proyecto (disponible exclusivamente si seconfiguró la integración entre JIRA y Bam-boo).

Tabla 4.2: Navegador de proyecto — Información relativa a las versionesdel proyecto.

54

4.1. Estructura

Nombre DescripciónComponent Sum-mary

Actividad reciente sobre un componente del pro-yecto.

Component Issues Incidencias pertenecientes a un componente delproyecto.

Component RoadMap

Incidencias a resolver de un componente del pro-yecto, agrupadas en versiones del proyecto.

Component Chan-ge Log

Incidencias resueltas de un componente del pro-yecto, agrupadas en versiones del proyecto.

Component Popu-lar Issues

Incidencias populares a resolver de un componen-te del proyecto, ordenadas por popularidad (nú-mero de votos).

Tabla 4.3: Navegador de proyecto — Información relativa a loscomponentes del proyecto.

incidencias en su rincón superior derecho (Figura 4.3). A través de

Figura 4.3: Navegador de proyecto — Barra de creación de incidencias.

los controles de la barra el usuario podrá crear incidencias de todos lostipos soportados en el proyecto seleccionado. Para los tipos de inci-dencias recién utilizados se proporcionará un botón a parte1, mientrasque los demás tipos de incidencias podrán crearse accediendo al menúdesplegable Other.

4.1.2 Acceso a información adicional

Por razones de espacio y de optimización de la interfaz gráfica deJIRA, algunos paneles que componen las ventanas del navegador de

1Como es el caso de los controles Bug y Documentation en Figura 4.3.

55


proyectos visualizan, por defecto, exclusivamente la información másreciente.

Algunos de estos paneles, sin embargo, permiten acceder a la ven-tana de detalle en la cual puede encontrarse la información completa.Los paneles que exhiben este comportamiento son los paneles queproporcionan un botón identificado con el icono de un “ojo” ( ):pulsando dicho botón el usuario accederá a la ventana de detalle.

4.2 Summary

En la ventana Summary el usuario podrá acceder a información gené-rica e información sobre la actividad reciente del proyecto, incluyendoversiones e incidencias que caducan en pocos días. Un ejemplo de ven-tana de resumen puede verse en Figura 4.4.

La ventana Summary está compuesta por distintos paneles queagregan información de distinta naturaleza; en Tabla 4.4 se detallaque tipo de información está disponible en cada panel de la ventana.

Nombre DescripciónDescription Información básica sobre el proyecto.Issues: Due Incidencias que han caducado.Issues: 30 days summary Reporte gráfico de incidencias abiertas y

resueltas en los últimos 30 días.Issues: Updated recently Incidencias actualizadas recientemente.Versions: Due Versiones que han caducado.Activity Stream Flujo de actividad.

Tabla 4.4: Navegador de proyecto — Paneles de la ventana Summary.

En el extremo superior derecho de la ventana Summary, JIRAproporciona una barra de herramientas, visible en Figura 4.5, quepermite al usuario acceder de forma rápida a las siguientes funciones:

(i) Creación de reportes (véase §10).(ii) Acceso a filtros (véase §8).

Mayores detalles sobre las características de estas funciones serán de-talladas en los capítulos correspondientes.

56

4.2. Summary

Figura 4.4: Navegador de proyecto — Ventana Summary.

Figura 4.5: Navegador de proyecto — Barra de herramientas de laventana Summary.

57


4.2.1 Activity Stream

El panel Activity Stream presenta el flujo de actividad reciente en elproyecto corriente. Generalmente, el flujo de actividad será relativoa operaciones sobre incidencias de la instancia de JIRA local. Sinembargo, si el administrador ha configurado la integración de JIRAcon otras aplicaciones2, el flujo de actividad incluirá también la in-formación procedentes de éstas aplicaciones. El flujo de actividad,por lo tanto, es una herramienta cómoda a la hora de aglutinar enun único lugar la información relativa a un proyecto y procedente dedistintas fuentes.

En el panel Activity Stream el usuario tiene la posibilidad de sus-cribirse a un feed RSS para recibir la información actualizada utili-zando un lector de feeds RSS. Para suscribirse al feed, es suficienterecuperar su URL utilizando el icono del feed ( ) e insertarlo en unlector RSS. Utilizando este icono directamente desde el navegadorweb permite ver el contenido actual del feed en la ventana del mismonavegador.

4.3 Issues

La ventana Issues del navegador de proyectos (Figura 4.6) propor-ciona un reporte sobre el estado de las incidencias del proyecto selec-cionado. La ventana está dividida en paneles, detallados en Tabla4.5, en los cuales se detalla el estado de las incidencias agrupadas porestado y el estado de las incidencias no solucionadas agrupadas porvarios campos.

Los enlaces proporcionados en esta ventana permiten al usuarioacceder al navegador de incidencias (§6 y sucesivos) configurado conel filtro correspondiente. Si, por ejemplo, se selecciona el enlace co-rrespondiente al nombre de un usuario en el panel Unresolved: ByAssignee, JIRA llevará el usuario a la ventana del navegador de inci-dencias configurado para devolver las incidencias no resueltas y asig-nadas al usuario seleccionado.

4.4 Road Map

La ventana Road map del navegador de proyectos (Figura 4.7) pro-porciona información sobre las versiones del proyecto todavía no en-

2JIRA puede integrarse con otras aplicaciones de Atlassian (tales como Con-fluence, FishEye, Crucible y Bamboo) u aplicaciones de terceras partes.

58

4.4. Road Map

Nombre DescripciónStatus summary Reporte de incidencias agrupadas por

estado.Unresolved: By priority Incidencias no resueltas, agrupadas

por prioridad.Unresolved: By assignee Incidencias no resueltas, agrupadas

por usuario asignado.Unresolved: By version Incidencias no resueltas, agrupadas

por versión.Unresolved: By component Incidencias no resueltas, agrupadas

por componente.

Tabla 4.5: Navegador de proyecto — Paneles de la ventana Issues.

Figura 4.6: Navegador de proyecto — Ventana Issues.

tregadas. Esta ventana está disponible solo si en el proyecto seleccio-nado se están utilizando versiones.

En el reporte de esta ventana se resume la siguiente información:

(i) La lista de versiones todavía por entregar.(ii) La lista y el número de incidencias asignadas a cada versión.(iii) El porcentaje de trabajo finalizado y por finalizar por cada ver-

sión.

El reporte de la ventana Road map agrega todas las incidenciasasignadas a las versiones del proyecto: sin embargo, un usuario pue-de acceder al road map “personal”, es decir, el road map generado

59


Figura 4.7: Navegador de proyecto — Ventana Road map.

considerando exclusivamente las incidencias asignadas al usuario ac-tualmente conectado, utilizando el control View personal road mapen el extremo superior derecho de la ventana.

4.5 Change Log

La ventana Change log del navegador de proyectos (Figura 4.8) pro-porciona información sobre las versiones del proyecto que se han entre-gado. Esta ventana está disponible solo si en el proyecto seleccionadose están utilizando versiones.

En el reporte de esta ventana se resume la siguiente información:

(i) La lista de versiones entregadas.(ii) La lista y el número de incidencias asignadas a cada versión.

60

4.6. Popular Issues

Figura 4.8: Navegador de proyecto — Ventana Changelog.

4.6 Popular Issues

La ventana Popular issues del navegador de proyectos (Figura 4.9)proporciona información sobre las incidencias más votadas (véase§5.20) por los usuarios.

El reporte de esta ventana tiene las siguientes características:

(i) Contiene la lista de incidencias no resueltas del proyecto quetengan al menos un voto.

(ii) La lista de incidencias está ordenada por el número de votos enorden decrescente.

4.7 Versions

La ventana Versions del navegador de proyectos (Figura 4.10) pro-porciona información sobre las versiones del proyecto seleccionado.Esta ventana está disponible solo si en el proyecto seleccionado seestán utilizando versiones.

61


Figura 4.9: Navegador de proyecto — Ventana Popular issues.

Figura 4.10: Navegador de proyecto — Ventana Versions.

62

4.7. Versions

Esta ventana presenta la lista de todas las versiones del proyectoseleccionado, tanto entregadas como por entregar. Si el usuario tieneel permiso requerido, el control Manage versions en el extremo supe-rior derecho de esta ventana permite acceder a la ventana de gestiónde versiones.

Seleccionando una versión de la lista, utilizando el enlace en elnúmero de versión, la ventana Versions otorga acceso a otras ventanasque proporcionan detalles sobre la versión seleccionada. Las ventanasque presentan la información de una versión se detallan en Tabla 4.6.

Nombre DescripciónSummary Actividad reciente de la versión seleccionada y

lista de incidencias que están por caducar.Issues Resumen de las incidencias de la versión selec-

cionada agrupadas por estado. Resumen de lasincidencias de la versión seleccionada no resuel-tas agrupadas por asignatario, prioridad, versióny componente.

Popular Issues Incidencias no resueltas de la versión selecciona-da ordenadas por popularidad.

Tabla 4.6: Navegador de proyecto — Ventanas de versiones.

Las ventanas de detalle de versión son parecidas a las homóni-mas ventanas del navegador de proyecto y, por lo tanto, véanse lassecciones correspondientes de este libro para obtener mayores detallessobre la funcionalidad de las mismas. Una imagen de ejemplo de dichaventana puede verse en Figura 4.11, en la cual puede apreciarse co-mo tanto la estructura global como la estructura de los paneles que lacomponen sea parecida a la estructura de los homólogos componentesde la ventana del navegador de proyecto.

4.7.1 Builds de la versión

Si se está utilizando Atlassian Bamboo para automatizar la construc-ción de un proyecto y el administrador de JIRA ha configurado laintegración entre JIRA y Bamboo, el usuario puede obtener informa-ción relativa a los builds y los planes de builds de Bamboo relativosa una versión de un proyecto directamente en la sub-ventana Builds

63


Figura 4.11: Navegador de proyecto — Detalle de versión.

de la ventana de detalle de una versión. La información disponible esla siguiente:

(i) La lista de builds relativos a la versión seleccionada.(ii) El último estado de los build plans (planes de construcción)

relacionados a dichos builds.

Para ver los builds de una versión (Figura 4.12), es necesarioefectuar las siguientes operaciones:

(i) Acceder a la ventana de detalle de la versión del proyecto desea-da, como explicado anteriormente.

(ii) Seleccionar la pestaña Builds en la ventana de detalle de unaversión del proyecto.

(iii) Asegurarse que la opción Related builds by date esté seleccionadaen el campo View.

Para ver el último estado de los planes de construcción (Figura4.13), es necesario efectuar las siguientes operaciones:

64

4.8. Components

Figura 4.12: Navegador de proyecto — Detalle de versión — Builds

(i) Acceder a la ventana de detalle de la versión del proyecto desea-da, como explicado anteriormente.

(ii) Seleccionar la pestaña Builds en la ventana de detalle de unaversión del proyecto.

(iii) Asegurarse que la opción Latest plan status esté seleccionada enel campo View.

4.8 Components

La ventana Components del navegador de proyectos (Figura 4.14)proporciona información sobre los componentes del proyecto seleccio-nado. Esta ventana está disponible solo si en el proyecto seleccionadose están utilizando componentes.

Esta ventana presenta la lista de todos los componentes del pro-yecto seleccionado. Si el usuario tiene el permiso requerido, el controlAdd a new component en el extremo superior derecho de esta ventanapermite acceder a la ventana de creación de componente.

65


Figura 4.13: Navegador de proyecto — Detalle de versión — Build Plans

Figura 4.14: Navegador de proyecto — Ventana Components.

66

4.9. Labels

Como en el caso de la ventana de versiones, seleccionando un com-ponente de la lista, utilizando el enlace en el nombre de componente,la ventana Components otorga acceso a otras ventanas que propor-cionan detalles sobre el componente seleccionado. Las ventanas quepresentan la información de un componente se detallan en en Tabla4.7.

Nombre DescripciónSummary Actividad reciente del componente seleccionado

y lista de incidencias que están por caducar.Issues Resumen de las incidencias del componente se-

leccionado agrupadas por estado. Resumen delas incidencias del componente seleccionado noresueltas agrupadas por asignatario, prioridad,versión y componente.

Road Map Incidencias no resueltas del componente seleccio-nado para las siguientes versiones de un proyecto.

Change Log Incidencias resueltas del componente selecciona-do en precedentes versiones de un proyecto.

Popular Issues Incidencias no resueltas del componente seleccio-nado ordenadas por popularidad.

Tabla 4.7: Navegador de proyecto — Ventanas de componentes.

Las ventanas de detalle de componente son parecidas en presen-tación y funcionalidad a las homónimas ventanas del navegador deproyecto con la diferencia que las primeras presentan datos filtradospor el componente seleccionado. Por esta razón, véanse las seccionescorrespondientes de este libro para obtener mayores detalles sobre lafuncionalidad de las mismas.

4.9 Labels

La ventana Labels del navegador de proyectos (Figura 4.15) propor-ciona información sobre los componentes del proyecto seleccionado.

Esta ventana presenta la lista de etiquetas (labels, véase §5.14) uti-lizadas en las incidencias del proyecto seleccionado, ordenadas segúnel criterio especificado por el usuario en las opciones de configuraciónde la ventana. El usuario puede especificar las siguientes opcionesutilizando los controles presentes en la parte superior de la ventana:

67


Figura 4.15: Navegador de proyecto — Ventana Labels.

(i) View: Con esta opción se puede seleccionar cuales etiquetasse desean ver. Seleccionando Popular labels se visualizarán lasetiquetas populares y seleccionando All labels se visualizarántodas las etiquetas.

(ii) Field: Con esta opción se puede seleccionar cuales campos uti-lizar para determinar las etiquetas de las incidencias. Selec-cionando Labels se utilizarán los campos de tipo etiquetas yseleccionando Epic/Theme se utilizarán dichos campos para de-terminarlas.

(iii) Order : Con esta opción se puede seleccionar el orden en el quese presentarán las etiquetas. Seleccionando Alphabetically sepresentarán las etiquetas en orden alfabético y seleccionandopopularity se presentarán en orden de popularidad.

Las etiquetas visualizadas en esta ventanas son enlaces que elusuario puede utilizar para visualizar las incidencias que contienenla etiqueta seleccionada: el usuario será llevado al navegador de in-cidencias (véase §6.2) donde se ejecutará un filtro auto-generado quedevolverá como resultado las incidencias correspondientes.

4.10 Builds de Bamboo

Si la instancia de JIRA ha sido integrada con una instancia de Bam-boo, estará disponible la pestaña Builds en la cual se podrá obtener

68

4.11. Fisheye changesets: cambios en las fuentes

la información relativa a los builds de Bamboo y a sus builds planrelacionados con el proyecto seleccionado.

La presentación y la funcionalidad de esta ventana es parecidaa la análoga ventana Builds de las versiones, descrita en §4.7.1 eilustrada en Figura 4.12 y 4.13. Por esta razón, véanse las seccionescorrespondientes de este libro para obtener mayores detalles sobre lafuncionalidad de las mismas.

4.11 Fisheye changesets: cambios en las fuentes

Si la instancia de JIRA ha sido integrada con una instancia de Fisheye,estará disponible la pestaña Source, la cual ofrece un resumen de laactividad de Fisheye reciente relacionada con el proyecto seleccionado.

La ventana ofrece la siguiente información, dependiendo del tipode reporte seleccionando en la lista de reportes en la parte superiorde la ventana:

(i) Reporte de los últimos commits relacionados con el proyecto se-leccionado, seleccionando el reporte Changeset (Figura 4.16).

(ii) Reporte de las estadísticas de actividad en Fisheye, seleccionan-do el reporte Statistics (Figura 4.17).

(iii) La agregación de los dos reporte precedentes, seleccionando elreporte All.

Figura 4.16: Navegador de proyecto — Ventana Source.

La ventana con el reporte de las estadísticas (Figura 4.17), pordefecto, proporciona estadísticas por líneas de código. Sin embargo,en cada panel de la ventana es posible especificar el indicador que sedesea entre las siguientes posibilidades:

69


Figura 4.17: Navegador de proyecto — Ventana Source.

(i) LOC, o Líneas de código.(ii) Files.(iii) Commits.

70

5Manejo de incidencias

Las operaciones que los usuarios suelen efectuar más frecuentementeen JIRA están relacionadas con el manejo de las incidencias. En uncaso de uso típico de la plataforma, los usuarios se dividen princi-palmente en dos grupos: los usuarios que solicitan trabajo abriendoincidencias en el sistema y los usuarios que trabajan sobre ellas.

Los usuarios del primer grupo, usuarios en la jerga de JIRA, uti-lizan la plataforma para abrir incidencias y observar el trabajo quese vaya desempeñando sobre ellas. A estos usuarios, JIRA ofrece unaserie de herramientas que les permiten tener la visibilidad que ne-cesitan sobre las incidencias que desean observar a lo largo de todosu ciclo de vida, desde el momento de su creación hasta el momen-to en que terminan su recorrido por la máquina de estados del flujode trabajo al que están sometidas. Estas herramientas permiten, en-tre otras cosas, a) crear una incidencia rellenando un formulario querecoge los campos asociados al tipo de incidencia escogido; b) organi-zar las incidencias utilizando enlaces y etiquetas; c) buscar entre lasincidencias componiendo criterios de búsquedas flexibles y creando fil-tros reutilizables; d) observar las incidencias abiertas suscribiéndosea notificaciones o utilizando las herramientas de reporting de JIRA;e) interactuar con los operadores y con otros usuarios a través decomentarios; f ) solicitar la resolución de una incidencia a través delmecanismo de los votos.

Los usuarios del segundo grupo, desarrolladores en la jerga de JI-RA y operadores en la nomenclatura de esta guía, utilizarán la plata-forma para trabajar sobre las incidencias que los usuarios han abierto.A esta categoría de usuarios JIRA ofrece una serie de herramientasespecíficas que permiten, entre otras cosas, a) trabajar sobre una in-cidencia moviéndola a través de la red de estados definida en su flujode trabajo; b) organizar las incidencias a través de los mecanismos de

71

5. Manejo de incidencias

los enlaces y de las etiquetas; c) proteger las incidencias estableciendopolíticas de seguridad; d) mantener constancia del trabajo realizadoa través del log de trabajo.

JIRA no obliga el administrador de un proyecto a marcar confi-nes muy rígidos entre una categoría de usuarios y la otra. Al revés,simplemente otorgándole los privilegios requeridos, cualquier usuariopuede utilizar cualquier herramientas que JIRA ofrezca. Esta flexibi-lidad a nivel de las políticas de seguridad se traduce por lo tanto enflexibilidad a la hora de perfilar las responsabilidades de cada catego-ría de usuarios que se desea introducir en un determinado proyecto.

Un jefe de proyecto, por ejemplo, puede ejercer al mismo tiempolas funciones de usuario y operador. Por un lado observará y organi-zará el progresar de las labores a través de búsquedas, filtros, flujosde actividades y las herramientas de reporting de JIRA; por el otrolado, participará activamente en las labores del equipo creando nue-vas incidencias, asignando las incidencias existentes a los miembrosdel equipo para repartir eficazmente el trabajo e, incluso, trabajandosobre alguna de ellas, tal vez de un tipo pensado explícitamente porsu rol.

La experiencia con otras herramientas que brillan por flexibilidadpodría hacer sospechar a muchos usuarios que la riqueza de funciona-lidad de una plataforma como JIRA tenga repercusiones negativas enotros aspectos no menos importantes para la eficacia y la eficienciadel trabajo tales como la facilidad de utilización o el tiempo de apren-dizaje requerido para convertirse en un usuario competente. Sorpren-dentemente, en el caso de JIRA esto no sucede y este logro, sin duda,ha sido uno de sus más importantes selling points.

Detrás de este logro ha habido una decisión de diseño fundamen-tal. En lugar de trasladar al usuario, a través del interfaz de JIRA1,las complejidades y la heterogeneidad de posibles escenarios distintosprocedentes de su elevada flexibilidad, se tomó la decisión de a) ho-mogeneizar el interfaz; b) reducir al mínimo el número de ventanas dela plataforma; c) trasladar la flexibilidad de la plataforma al interfazutilizando ventanas que se rellenan dinámicamente.

El trabajo sobre una incidencia, por ejemplo, se efectúa en una úni-ca ventana, con independencia de cualquier privilegio y rol otorgado alusuario conectado. La ventana en cuestión, descrita detalladamenteen las secciones siguientes de éste capítulo, es modular y logra la “ho-

1Así como a cualquier otro nivel en que tiene lugar una interacción entre JIRAy un sistema externo, incluso un ser humano.

72

5.1. Creación de una incidencia

mogeneización” de los perfiles de usuarios poblando automáticamentesus paneles con los controles habilitados de acuerdo a los privilegiosotorgados al usuario conectado.

La “segmentación” de los usuarios en roles de proyecto, cuya res-ponsabilidad es de los administradores en el ámbito de cada proyec-to, no se repercute en la forma en que los usuarios interactúan conla herramienta: éstos no deberán preocuparse de aprender a utilizarherramientas distintas o específicas para desempeñar las labores quese les encomienden en el contexto de cada proyecto.

En un caso de uso típico, por ejemplo, los usuarios tendrán los pri-vilegios necesarios a crear incidencias en un proyecto pero no podrántrabajar sobre ellas y cambiarlas de estado. Los operadores podrántrabajar sobre las incidencias a ellos asignadas y moverlas a travésde un conjunto de estados en su flujo de trabajo. Los supervisorespodrán asignar (o re-asignar) las tareas a los operadores, revisarlasy cerrarlas e, incluso, borrarlas del sistema. Todas estas operacionesse efectuarán en la misma ventana, utilizando además controles fun-cionalmente muy similares. En el caso en que un usuario adquieraprivilegios distintos en el contexto de otro proyecto, éste no requeriráaprender a utilizar herramientas distintas ya que, funcionalmente, noapreciará diferencias sustanciales en el interfaz de la herramienta.

5.1 Creación de una incidencia

El primer paso durante la utilización de JIRA es el proceso de creaciónde una incidencia. Los usuarios con este privilegio (Create Issues) enun proyecto podrán acceder a la ventana de creación de incidencias yrellenar los detalles requeridos por el tipo de incidencia que se deseacrear.

JIRA proporciona dos accesos a la ventana de creación de inci-dencias:

(i) El primer acceso, ilustrado en Figura 5.1, es el botón de creaciónde incidencias que está siempre presente en el extremo derechode la barra de herramientas de JIRA, como explicado en §3.3.

(ii) El segundo acceso, presente en la parte superior de la ventanadel navegador de proyecto, es la barra de creación de incidencias,descrita en §4.1.1 e ilustrada en Figura 5.2.

JIRA 5 unificó el comportamiento de ambos controles y, ahora,todos llevan a una única ventana de creación de incidencia, visible

73


Figura 5.1: Botón de creación de incidencia

Figura 5.2: Navegador de proyecto — Barra de creación de incidencias.

en Figura 5.3. La única diferencia funcional que queda entre losdos controles de creación de incidencia es que la barra de creaciónde incidencias en el navegador de proyecto proporciona una serie debotones de acceso rápido para seleccionar los tipos de incidencia quehayan sido utilizados más recientemente: en el caso ilustrado en figu-ra, por ejemplo, pueden verse los botones Bug y Documentation paracrear una incidencia del tipo correspondiente. A la derecha de estosbotones JIRA proporciona el botón Other que despliega un menú conlos demás tipos de incidencias aceptables en el proyecto corriente.

La ventana de creación de incidencia es una form que recoge todoslos campos de una incidencia que el usuario puede rellenar durantesu creación. El número y el tipo de campos presentes en esta ventanason configurados por el administrador en el contexto de cada proyectopor cada tipo de incidencia admisible. Los primeros pasos a cumplirdurante la creación de una incidencia será, por lo tanto, los siguientes:

(i) La elección del proyecto en el cual la incidencia debe crearse,seleccionando el proyecto deseado en el menú desplegable delcampo Project.

(ii) La elección del tipo de incidencia a crear, seleccionando el tipodeseado en el menú desplegable del campo Issue Type.

Una vez escogido estos datos, la ventana de creación de incidencia se

74


Figura 5.3: Ventana de creación de incidencia

75


actualizará automáticamente para reflejar la configuración de camposdel tipo de incidencia escogido en el contexto del proyecto selecciona-do. Por esta razón, los usuarios podrían ver ventanas con un distintoconjunto de campos para el mismo tipo de incidencia en proyectosdistintos.

En las versiones de JIRA anteriores a la versión 5, la ventanade creación de incidencia proporcionaba todos los campos previstospor la configuración de campos del tipo de incidencia seleccionada.Esta ventana podía contener muchos campos opcionales, algunos delos cuales raras veces utilizados por los usuarios, y su composiciónno podía modificarse. Desde la introducción de JIRA 5 los usuariospueden personalizar la configuración de campos de esta ventana aña-diendo los campos que utilizan más a menudo y ocultando los camposque raramente utilizan. La única limitación, obviamente, es ningúncampo obligatorios para un tipo de incidencia no puede ocultarse.La configuración de la ventana se efectúa utilizando el formulario deconfiguración al que se accede utilizando el botón Configure Fields enla esquina superior izquierda de la misma e ilustrado en Figura 5.4.El campo Show Fields puede asumir los siguientes valores:

Figura 5.4: Ventana de creación de incidencia — Configuración decampos

(i) All, si la ventana visualizará todos los campos.(ii) Custom, si la ventana visualizará solo los campos escogidos por

el usuario.

76


En el segundo caso, el usuario podrá decidir cuales campos visualizary cuales campos ocultar utilizando los controles de tipo check-box queaparecen a la izquierda del nombre de cada campo previsto por el tipode incidencia actualmente seleccionado: deseleccionando el check-boxde un campo, se ocultará el campo en la ventana.

Cuando el usuario termine de rellenar el formulario de creación ypulse el botón Create JIRA creará la incidencia y llevará el usuario ala ventana de detalle de incidencia (§2.2, Figura 2.4 e §5.2).

Si, por el otro lado, el usuario necesita crear más de una inciden-cia, desde JIRA 5 puede optar para crearlas de forma seguida sin salirde la ventana de creación de incidencia. Esta versión de JIRA incluyeun control adicional de tipo check-box, llamado Create another, que,si seleccionado, instruye JIRA a no cerrar la ventana después de laconfirmación de creación de incidencia (como explicado en el párra-fo anterior) sino vaciarla para que el usuario pueda seguir creandoincidencias de forma más rápida.

5.1.1 Citación de otros usuarios y envío de mail

JIRA 5 permite la citación de otros usuarios de la plataforma en loscampos Description y Comment. La citación de usuario está ligada aotra funcionalidad nueva, la posibilidad de compartir incidencias connuevos usuarios, que se detallará en §5.4.

Es posible citar un usuario en un campo de texto que lo permitapueden introduciendo su nombre en una de las siguientes formas:

(i) @nombre.(ii) [~nombre].

Cuando el usuario comienza a teclear estos caracteres, JIRA sugerirála lista de usuarios que satisfagan los criterios introducidos, comoilustrado en Figura 5.5. Seleccionando un usuario de la lista desugerencias completará automáticamente el texto que el usuario estáintroduciendo. Si un usuario está siendo citado durante la creaciónde una incidencia2, JIRA le enviará un correo electrónico.

Véase §5.4 para obtener más informaciones sobre esta funcionali-dad.

2Así como ocurre durante las demás operaciones sobre una incidencia.

77


Figura 5.5: Citación de otro usuario

5.2 Ventana de detalle de incidencia

La ventana de detalle de la incidencia es una de las ventanas másutilizadas por los usuarios. Los usuarios utilizan esta ventana paraobservar el trabajo que se va desempeñando sobre ella y los operadoresutilizan esta ventana para toda labor que efectúen sobre la inciden-cia. La ventana está compuesta por paneles, cada uno del los cualesagrupa información de distinta naturaleza. En Figura 5.6 volvemos areproducir Figura 2.4.

En la parte superior de la ventana, en la sección Detalles, los usua-rios pueden ver tanto la información básica sobre una incidencia, tipo,prioridad, estado y resolución, como todos los campos disponibles altipo de incidencia y contexto seleccionado.

El la columna derecha, en las secciones People y Dates, se enseñanla información relativa a los usuarios que están relacionados con laincidencia: repoter, asignatario, votos y watches. En el panel TimeTracking, por otro lado, puede verse un resumen gráfico del trabajo adesempeñar y desempeñado, de acuerdo a la estimación introducidapor los usuarios y el trabajo registrado por los operadores.

En la parte central de la ventana pueden verse paneles que contieneinformación adicional de la incidencia, tales como su descripción y losenlaces entre incidencias.

La parte inferior de la ventana está organizada en pestañas a travésde las cuales se puede acceder a la demás información relacionada conla incidencia: comentarios, work log, actividad, etc.

Algunos plugins de JIRA enriquecen las ventanas de la plataformay, dependiendo de cada instalación, es posible que el contenido varíe.En la ilustración, por ejemplo, puede verse la pestaña Source queproporciona información que proviene de Atlassian FishEye.

78

5.3. Operaciones disponibles

Figura 5.6: Ventana de detalle de incidencia

5.3 Operaciones disponibles

En la ventana de detalle de incidencia (Figura 5.6), debajo del título,hay una barra de botones. Como explicado en precedencia (§2.2),las operaciones que un usuario puede efectuar sobre una incidencia,de acuerdo a los permisos que tiene en el proyecto, son accesibles através de dichos botones.

Las operaciones se dividen en dos categorías:

(i) Operaciones comunes a toda incidencia.(ii) Operaciones del flujo de trabajo de un tipo de incidencia.

Las operaciones comunes son las operaciones que un usuario de JIRApuede efectuar sobre cualquier incidencia y son, básicamente, opera-ciones de actualización de los campos de la incidencia (Edit, Com-ment, Attach files, etc.) y operaciones de “organización” de las inci-dencias (Clone, Move, Delete, etc.). En Figura 5.7 pueden verse losbotones correspondientes a las operaciones comunes más utilizadas yel botón More Actions que despliega un menú con todas las demásoperaciones disponibles para una incidencia.

79


Figura 5.7: Menú de acciones

La segunda categoría de operaciones desciende del flujo de trabajode cada tipo de incidencia y de las operaciones de workflow (transicio-nes) que se puedan invocar en el estado corriente de una incidencia.En el flujo de trabajo estándar de JIRA, para una incidencia en esta-do Open, solo pueden ejecutarse las transiciones Start progress paraempezar a trabajar sobre la incidencia, Resolve para resolver de in-mediato una incidencia sin abrirla (probablemente para no aceptarla)y Close. En Figura 5.7 pueden verse los botones que correspondena algunas de estas transiciones estándar.

Sin embargo, los administradores de proyecto pueden crear flujosde trabajos personalizados y asignarlos a determinados tipos de inci-dencias. En Figura 5.6, por ejemplo, pueden verse los botones Backto Todo y Back to In Progress asociados a las correspondientes transi-ciones en un flujo de trabajo personalizado asociado a las incidenciasdel tipo Bug de ese proyecto.

80

5.4. Compartir una incidencia por correo electrónico

5.4 Compartir una incidencia por correo electrónico

Un usuario tiene dos opciones para enviar a otro usuario de la plata-forma el enlace a una incidencia por mail3:

(i) Citando el destinatario en un campo que soporte las citaciones,como los campos descripción y resumen.

(ii) Compartiendo la incidencia.

5.4.1 Citar un usuario

El mecanismo de las citaciones, que se detalló en §5.1.1, permiteenviar un correo electrónico al buzón de un usuario cada vez queéste sea citado en un campo de tipo texto que soporte las citaciones(como descripción y resumen) durante una operación la creación o lamodificación de una incidencia o de un comentario a una incidencia.

Para citar un usuario, es necesario efectuar las operaciones detalla-das en §5.1.1 durante una cualquiera de las operaciones mencionadascon anterioridad.

5.4.2 Compartir una incidencia

Una incidencia puede ser compartida con otros usuarios de la pla-taforma: al acto de compartir, se puede introducir una nota que,conjuntamente a la dirección de la incidencia compartida, se remitirápor correo electrónico a los destinatarios.

Para compartir una incidencia con otros usuarios, es necesarioefectuar las siguientes operaciones:

(i) Seleccionar la incidencia que se quiere compartir y entrar en suventana de detalle.

(ii) Pulsar el botón Share4: aparecerá el formulario para compartirla incidencia (Figura 5.8). Alternativamente, puede utilizarseel atajo de teclado ‘s’.

(iii) Añadir los usuarios con los cuales se quiere compartir la inciden-cia tecleando sus nombres o sus direcciones de correo electrónicoen el campo de texto User name or email.

3Con independencia del mecanismo de las notificaciones.4Este botón está disponible solo si un servidor de envío de correo SMTP ha

sido configurado por el administrador de JIRA.

81


(iv) Eliminar usuarios con los cuales no se quiere compartir la in-cidencia utilizando el control identificar con el icono “basura”( ).

(v) Introducir la nota que se desea enviar a los usuarios en el campode texto Note.

(vi) Pulsar el botón Share para comparir la incidencia.

Figura 5.8: Compartir una incidencia.

5.5 Adjuntar ficheros o capturas de pantallas a una in-cidencia

Con independencia de la exhaustividad de los campos asociados conun tipo de incidencia, a veces se presenta la necesidad de proporcionardatos añadidos relacionados con la incidencia. A menudo dichos datosestán contenidos en ficheros y, en la mayoría de los casos, no seríapráctico ni viable transcribir su contenido en un campo dedicado.

Muy a menudo, de hecho, los usuarios desean adjuntar una capturade pantalla, para ofrecer a los operadores un feedback visual. En otrasocasiones, podrían ser los operadores quienes soliciten a los usuariosque han abierto una incidencia de adjuntar ficheros, los cuales pue-den ser de cualquier naturaleza, como formularios, documentaciónadicional o ficheros de log de una aplicación.

82

5.5. Adjuntar ficheros o capturas de pantallas a una incidencia

Si el formato del fichero adjunto es un formato reconocido porJIRA podrá verse una vista previa del fichero directamente en laventana de detalle de incidencias sin la necesidad de descargarlo pre-viamente para abrirlo con una aplicación local.

La posibilidad de adjuntar ficheros está subordinada a que el admi-nistrador de JIRA haya habilitado está funcionalidad en la plataforma(a nivel global) (§??) y que el usuario posea los privilegios necesarios(Create attachments). Si estas condiciones están satisfechas, el usua-rio podrá utilizar la funcionalidad Attach files y Attach screenshot.Por defecto, además, no es posible editar incidencias cerradas y, porlo tanto, tampoco es posible añadir ficheros adjuntos a incidencias enéste estado. Si se desea editar una incidencia cerrada, es necesariosolicitar esta funcionalidad al administrador de JIRA.

Para adjuntar un fichero es necesario efectuar las siguientes ope-raciones:

(i) Abrir la incidencia en la cual se desea adjuntar el fichero.(ii) Pulsar el botón Attach files en el menu More actions (o utilizar

el formulario de acciones accesible con el atajo de teclado ‘.’) yaparecerá la ventana ilustrada en Figura 5.9.

Figura 5.9: Ventana para adjuntar ficheros a una incidencia

(iii) Seleccionar los ficheros que se desean adjuntar5 utilizando la5El tamaño máximo del fichero adjunto es establecido por el administrador

de JIRA y, por defecto, es de 10 MB.

83


ventana de selección de ficheros que aparece pulsando el botónChoose File. Dependiendo del navegador que se esté utilizando,podría ser necesario repetir esta operación por cada fichero quese desea adjuntar. El nombre de los ficheros adjuntos no puedecontener ninguno de los caracteres detallados en Tabla 5.1.

Caracteres no permitidos\ / " % : $ ? *

Tabla 5.1: Nombre de ficheros adjuntos — Caracteres no permitidos

(iv) Si se desea no adjuntar un fichero seleccionado por error, essuficiente deseleccionar el control de tipo check-box que aparecea la izquierda de sun nombre.

(v) Opcionalmente, insertar un comentario para ofrecer una des-cripción al fichero adjunto rellenando el campo de texto Com-ment. Se puede establecer un nivel de seguridad para el co-mentario y restringir su visibilidad a un único rol de proyectoescogiendo el rol deseados en el menú desplegable que se encuen-tra debajo del campo Comment. En Figura 5.9 puede verse elmenú de selección del nivel de seguridad del comentario con lostres roles de proyecto que, por defecto, adquiere un proyecto enJIRA.

(vi) Pulsar el botón Attach para finalizar la operación y adjuntar losficheros seleccionados.

Después de haber adjunto los ficheros a la incidencia seleccionada,JIRA enseñará una vista previa en la ventana de detalle de la inciden-cia, siempre que el administrador haya habilitado esta funcionalidadde JIRA (§??) y siempre que le formato del fichero sea uno de losformatos de imagen reconocido por JIRA6, como ilustrado en Figura5.10.

Las vistas previas también pueden verse “en galería”, a un tamañomayor, y de esta forma poder acceder rápidamente a los ficheros sinnecesidad de descargarlos en el ordenador local, sobre todo cuandoel tamaño de los ficheros adjuntos es grande. Para acceder a la vistade galería es suficiente hacer click sobre la vista previa de cualquierfichero; en la vista de galería es posible navegar entre los ficheros

6Tales como: GIF, JPG, PNG, ZIP, etc.

84

5.6. Gestionar los ficheros adjuntos

Figura 5.10: Vista previa de los ficheros adjuntos a una incidencia

adjuntos, cuando haya más que uno, a través de los controles queaparecerán en pantalla, como ilustrado en Figura 5.11.

Figura 5.11: Vista de galería de los ficheros adjuntos a una incidencia

5.6 Gestionar los ficheros adjuntos

El menu desplegable a la derecha de la sección de fichero adjuntos,ilustrado en Figura 5.12, permite gestionar los ficheros adjuntos yefectuar las siguientes operaciones:

(i) Ordenar los ficheros adjuntos por nombre y fechas.(ii) Bajarse todos los ficheros adjuntos en un archivo comprimido

de tipo ZIP.(iii) Acceder a la ventana de gestión de ficheros adjuntos en la cual

es posible eliminar los ficheros que no se desean.

85


Figura 5.12: Menu de operaciones sobre ficheros adjuntos a unaincidencia

En las siguientes secciones se detallará la funcionalidad de cadaoperación mencionada.

5.6.1 Ordenar los ficheros adjuntos

Para ordenar la lista de ficheros adjuntos de acuerdo a los criteriosdeseados es necesario efectuar las siguientes operaciones:

(i) Abrir el menú desplegable de gestión de los ficheros adjuntos.(ii) Escoger el criterio de ordenación deseado: a) Sort By Name pa-

ra ordenar por nombre; b) Sort By Date para ordenar por fecha;c) Ascending para ordenar de forma ascendente; d) Descendingpara ordenar de forma descendente.

Téngase en cuenta que el criterio de ordenación así establecidoserá aplicado a todas las incidencias abiertas de aquí en adelanta asícomo a cualquier vista donde se gestionen ficheros adjuntos, como lasgalerías.

5.6.2 Acceder al contenido de adjuntos de tipo ZIP

Si un fichero adjunto es un fichero de tipo ZIP (como los ficherosJAR), JIRA proporcionará en su interfaz un explorador a través delcual es posible examinar los contenidos del archivo comprimido sinnecesidad de bajarlo y descomprimirlo en el cliente, como ilustradoen Figura 5.13.

Esta funcionalidad estará disponible solo si el administrador hahabilitado la función de gestión de ficheros ZIP de JIRA (§??).

86


Figura 5.13: Vista previa de un fichero adjunto de tipo ZIP o JAR

5.6.3 Eliminar ficheros adjuntos

Para eliminar un fichero adjunto de una incidencia es necesario efec-tuar las siguientes operaciones:

(i) Acceder a la ventana de gestión de ficheros adjuntos (Figura5.14) utilizando el enlace Manage attachments (Gestiona fiche-ros adjuntos) en el menú de gestión de los ficheros adjuntos (§5.6y Figura 5.12).

(ii) Eliminar los ficheros adjuntos utilizando el icono “papelera” ( )a la extrema derecha del registro correspondiente al fichero aeliminar.

Figura 5.14: Ventana de gestión de ficheros adjuntos

5.6.4 Bajar todos los adjuntos en un archivo ZIP

Si una incidencia tiene más que un fichero adjunto y el usuario deseabajárselos todos, JIRA ofrece la posibilidad de bajarse todos los ar-chivos comprimidos en un único archivo ZIP en lugar de obligar elusuario a bajárselos de uno en uno.

Para bajarse todos los ficheros adjuntos de una incidencia comoarchivo ZIP es necesario abrir el menú de gestión de los ficheros ad-juntos (§5.6 y Figura 5.12) y seleccionar el elemento Download All.

87


5.6.5 Adjuntar una captura de pantalla

Attach screenshot (Adjuntar captura de pantalla) es una versión “op-timizada” de la funcionalidad Attach files pensada para adjuntar cap-turas de pantallas a una incidencia. La ventana para adjuntar cap-turas de pantalla permite al usuario generar una captura de pantallay subirla a JIRA utilizando un applet Java sin necesidad de grabarficheros en el cliente para subirlos manualmente.

Para adjuntar una captura de pantalla es necesario seleccionarla operación Attach screenshot en el menú desplegable More actions.La primera vez que se utiliza esta funcionalidad, dependiendo de laspreferencias del navegador del usuario, podría aparecer una ventanade confirmación para la ejecución del applet Java que JIRA utiliza enel ordenador del cliente, como ilustrado en Figura 5.15.

Figura 5.15: Ventana de confirmación para ejecutar un applet Java

Después de haber confirmado que se desea ejecutar el applet pa-ra adjuntar capturas de pantalla, aparecerá la pantalla ilustrada enFigura 5.16.

Utilizando el botón Paste es posible pegar en la ventana la cap-tura de pantalla para sucesivamente adjuntarla a la incidencia. En elcampo File name es posible especificar el nombre del fichero adjunto;los nombres válidos no deberán contener los siguientes caracteres: /,\, \", %, :, $, ? y *. Los demás campos de la ventana tienen lamisma funcionalidad que se explicó anteriormente en la ventana paraadjuntar ficheros.

88


Figura 5.16: Ventana para adjuntar capturas de pantalla

El procedimiento para copiar en memoria una captura de la pan-talla del cliente depende del sistema operativo utilizado:

(i) En Microsoft Windows puede utilizarse la combinación deteclas Alt + Print screen para capturar la ventana seleccio-nada o la combinación Ctrl + Alt + Print screen para cap-turar la pantalla entera.

(ii) En Mac OS X puede utilizarse la combinación de teclas Ctrl +Apple + Shift + 4 para capturar la ventana corriente o Ctrl+ Apple + Shift + 3 para capturar la pantalla entera.

Para descubrir como capturar pantallas en otros sistemas operativos,véase su documentación oficial.

89


5.7 Comentarios

Los comentarios de una incidencia son una herramienta muy útil a lahora de añadir información sobre una incidencia o como herramientade colaboración entre usuarios. Los comentarios pueden verse en lapestaña Comments de la sección Activity de la ventana de detalle deuna incidencia.

Para añadir un comentario as una incidencia es necesario seleccio-nar el botón Comment en la barra de operaciones en la ventana dedetalle de la incidencia a comentar o el botón Comment que apreceen el rincón inferior izquierdo de la misma ventana. En la mismaventana de detalle de incidencia aparecerá el formulario para añadirel comentario, ilustrado en Figura 5.17.

Figura 5.17: Formulario de creación de un comentario

Un usuario necesita poseer el permiso Add comments para poderañadir un comentario a una incidencia. Debido a que los comentariosson “hijos” de una incidencia, el usuario debe también poseer el per-miso Browse project para poder acceder al proyecto y a la incidencia.

Los comentarios, así como toda la información almacenada por JI-RA, pueden ser protegido para que solo los usuarios autorizado puedanverlos. Dependiendo de como el administrador haya configurado lavisibilidad de comentarios, podrán escogerse roles de proyecto y gru-pos durante el establecimiento de la política de seguridad que protegea un comentario, utilizando el menú desplegable que aparece debajodel formulario e identificable con el icono de un candado.

En los comentarios puede insertarse texto formateado e utilizar elwiki markup (§??).

En la interfaz web de JIRA, los comentarios pueden colapsarse yexpanderse utilizando los correspondientes iconos a la izquierda delcomentario. En Figura 5.18 puede verse un ejemplo de comentariocolapsado (arriba) y expandido (abajo).

90

5.7. Comentarios

Figura 5.18: Comentarios colapsados y expandidos

Posicionando el ratón encima de un comentario, aparecerán unosiconos a la izquierda del comentario con las cuales los usuarios que po-sean los permisos requeridos pueden operar sobre un comentario. EnFigura 5.19 pueden verse los iconos correspondientes a las operacionesde creación de enlace, modificación y borrado de comentario.

Figura 5.19: Iconos para operar sobre un comentario

5.7.1 Modificar un comentario

A veces es necesario modificar un comentario existente si, por ejem-plo, es necesario corregir la información introducida o moderar uncomentario que no cumple con las políticas de la empresa. Tambiénes posible modificar la política de seguridad de un permiso y modificarel valor del campo Viewable by.

El permiso requerido para modificar un comentario propio es elpermiso Edit own comments y para modificar cualquier comentariose requiere el permiso Edit all comments.

Para modificar un comentario es necesario utilizar el control demodificación de comentario indicado con el icono de un lápiz a la de-recha del comentario. Seleccionando esta operación el usuario seráenviado a una ventana parecida a la ventana de creación de comen-tario para que pueda aportar las modificaciones deseadas.

91


5.7.2 Eliminar un comentario

Un comentario también puede ser eliminado por un usuario que poseael permiso requerido: para eliminar un comentario propio es necesariotener el permiso Delete own comments y para eliminar un comentariode otro usuario es necesario tener el permiso Delete all comments.

Para eliminar un comentario es necesario utilizar el icono de eli-minación de comentario, identificado con una papelera, a la derechadel comentario a borrar.

5.7.3 Crear un enlace a un comentario

Muchas veces los comentarios contienen información de interés in-troducida por otros usuarios. Los operadores, por ejemplo, puedenutilizar los comentarios para colaborar con los demás usuario e com-partir, por ejemplo, instrucciones para solucionar una incidencia.

Por esta razón es útil poder disponer de un mecanismo para “en-lazar” directamente a un comentario para poder almacenar una refe-rencia a él y compartirla con otros usuarios a través del correo electró-nico, en una página web o con cualquier otro medio de comunicaciónelectrónica.

JIRA soporta la creación de permalinks hacia los comentarios uti-lizando el icono de “enlace” que se encuentra a la derecha del comen-tario seleccionado. Después de haber pulsado el comentario, la páginase recargará y, si la página de detalle de la incidencia es más grandede la pantalla del usuario, la página se posicionará a la altura del co-mentario seleccionado. El URL que aparece en la barra de direccionesdel navegador es el permalink generado por JIRA y puede copiarse ecompartirse con otros usuarios.

5.8 Campos de texto formateado

En JIRA el “rendering” de los campos es efectuado por los “rende-rers”. JIRA proporciona renderers por todos los tipos de campos quepueden aparecer en sus páginas: sin embargo, renderers adicionalespueden ser instalados por plugins y el administrador puede asociarun renderer específico a un campo en una configuración de campos.

Las recientes versiones de JIRA proporcionan el wiki-style rende-rer que permite formatear campos de texto libre (como los comenta-rios) con efectos sofisticados utilizando una “notación” heredada deAtlassian Confluence. Los campos para los cuales el administrador ha

92

5.8. Campos de texto formateado

configurado el wiki-style renderer pueden reconocerse por unos iconosadicionales que pueden verse en Figura 5.20.


El icono que representa una pantalla azul es la función de vistaprevia que permite visualizar el campo de texto formateado, y verlos efectos aplicados a través de la notación wiki, antes de grabar lasmodificaciones. El icono amarillo con un punto de interrogación pro-porciona una ventana de ayuda sobre la notación “wiki”. En Figura5.21 puede verse la función de vista previa aplicada al texto insertadoen el campo de Figura 5.20.


5.8.1 Macros

El wiki-style renderer permite formatear un campo de texto con efec-tos sofisticados tales como:

(i) Efectos tipográficos tales como fuente itálica, negrita, etc.(ii) Creación de títulos de múltiple niveles.

93


(iii) Creación de listas, listas numeradas, tablas y citaciones.(iv) Visualización de imágenes.(v) Preparación rápida de fragmentos de código.

JIRA, por defecto, proporciona las macros ilustradas en el Cuadro5.2.

Wiki-style renderer — MacroMacro Efectoanchor Crea un anchor en un punto específico de la página.code Formatea un fragmento de código. La macro formatea

Java, JavaScript, ActionScript, XML, HTML y SQL.quote Formatea una citación.noformat Crea una sección dentro de la cual el formateo wiki no

se aplica.panel Crea un panel.color Cambia el color del texto.loremipsum Inserta párrafos de prueba.html Inyecta fragmentos de HTML.

Tabla 5.2: Macro del wiki-style renderer

5.8.2 Sintaxis de las macros

La sintaxis para utilizar las macros del wiki-style renderer es la si-guiente:

{macro}...{macro}

Algunas macros, como la macro panel aceptan parámetros opcionalesque se especificarán de la siguiente forma:

{macro:attr0=valor|attr1=valor|...}...{macro}

5.8.3 Macro code

La macro code permite formatear fragmentos de código de forma fácilen un campo de texto de JIRA. El texto:

94

5.9. Sub-tareas

{code:title=Example.java}// Commentpublic String getFoo(){

return foo;}{code}

produce el resultado de Figura 5.22.

Figura 5.22: Fragmento de código formateado con la macro code

Por defecto la macro code asume que el lenguaje de programacióndel fragmento sea Java. Sin embargo, es posible utilizar otros len-guajes (JavaScript, ActionScript, XML, HTML y SQL). El siguientefragmento:

{code:xml}<element>

<child attribute="value"/></element>{code}

produce el resultado de Figura 5.23.

Figura 5.23: Fragmento de XML formateado con la macro code

5.9 Sub-tareas

En su sentido más amplio, la “incidencias” de JIRA puede representaruna “tarea” asignada a un usuario y sujeta a un flujo de trabajo deter-minado. En muchos casos de usos es útil poder subdividir una tarea

95


en sub-tareas, cada una de las cuales puede ser gestionada indepen-dientemente de la demás. Dividir una tareas en sub-tareas permitetener una visión más completa del estado de avance de una incidenciay, además, permite paralelizar los trabajos requeridos para solucionaruna tarea ya que cada sub-tarea puede asignarse a usuarios distintos.

Las sub-tareas, de todos modos, tienen algunas limitaciones. Lassub-tareas, antes que todo, pertenecerán al mismo proyecto de la inci-dencia “padre”. Los tipos de incidencia de las sub-tareas son distintosde los tipos de incidencia de incidencias de primer nivel. En JIRApueden crearse también tipos de incidencias para sub-tareas; sin em-bargo el nivel de flexibilidad de la configuración es menor y se reduce,básicamente, a asignar un nombre y un icono a cada tipo de sub-tareacreado. Las sub-tareas no pueden tener sub-tareas: el “árbol” de in-cidencias de un proyecto como mucho tiene profundidad 2. Si unasub-tarea necesita tener sub-tareas, se puede “promover” la sub-tareaa tarea de primer nivel; para mantener una relación entre distintasincidencias podrá utilizarse un mecanismo alternativo, el mecanismode los enlaces.

Esta funcionalidad estará disponible en JIRA solo si el adminis-trador ha habilitado las sub-tareas (§??).

5.9.1 Crear sub-tareas

Para crear una sub-tarea, el usuario necesita el permiso Create issue.Para crear una sub-tarea en una incidencia de JIRA es necesario en-trar en la ventana de detalle de la incidencia y seleccionar la operaciónCreate sub-task en el menú More actions: el usuario podrá seleccionarel tipo de sub-tarea en la ventana de creación de sub-tareas que seilustra en Figura 5.24. El tipo de sub-tarea seleccionado por defectoes el tipo de sub-tarea estándar de JIRA, Sub-task pero, como expli-cado anteriormente, la lista puede de tipos de sub-tareas puede serconfigurada por el administrador.

Figura 5.24: Ventana de creación de sub-tarea

96

5.9. Sub-tareas

Después de haber seleccionado el tipo de tarea, el usuario tendráque completar el formulario en la ventana de creación de incidencia(§5.1): los campos de una sub-tarea son los campos de una incidenciaestándar de JIRA, exceptuando el nivel de seguridad que siempre sehereda de la incidencia padre. Después de haber creado la sub-tarea,el usuario será llevado a la ventana de detalle de incidencia. En elcaso de las sub-tareas, la ventana de detalle es la misma que en elcaso de las incidencias y puede verse un exemplo en Figura 5.25.

Figura 5.25: Ventana de detalle de sub-tarea

Puede notarse que la incidencia es efectivamente una sub-tarea yaque encima del nombre de la incidencia puede verse el nombre delproyecto y el nombre de la incidencia padre:

JIRA Guide / JRADG-1 I think I found a bug / JRAGD-2

Utilizando esos enlaces y pulsando el nombre de la incidencia padre(JRADG-1) el usuario puede ir a la ventana de detalle de esta incidenciay comprobar que las sub-tareas que ésta contiene pueden verse en laventana de detalle. En Figura 5.26 puede verse el panel Sub-tasks queaparece en la ventana de detalle cuando una incidencia tiene algunasub-tarea.

Figura 5.26: Lista de sub-tareas de una incidencia

97


5.9.2 Gestión de sub-tareas

Las sub-tareas no difieren mucho de las incidencias de primer nively el usuario podrá trabajar con ellas de la misma manera en quetrabaja con cualquier otra incidencia. Las diferencias más relevantes,de hecho, están a nivel de interfaz de usuario.

Como visto en la sección precedente, en la ventana de detalle deincidencia existe un panel dedicado a las sub-tareas de una incidencia,el panel Sub-tasks. A través de este panel es posible filtrar las sub-tareas, ordenarlas y efectuar muchas de las operaciones que puedenefectuarse a través de la ventana de detalle de incidencia. El panelSub-tasks tiene dos vistas con las cuales pueden visualizarse todas lassub-tareas o solo las sub-tareas abiertas (no completadas). Cuando seposiciona el ratón encima de una sub-tarea, aparecen unos controlesadicionales, ilustrados en (Figura 5.27).

Figura 5.27: Operaciones de una sub-tarea

Los controles a forma de “flecha” permiten ordenar las sub-tareas,moviéndolas arriba y abajo, según los criterios establecidos por elusuario. El segundo control, identificado con el icono de un “engra-naje”, despliega el menú de acciones (que puede verse en Figura 5.28)que contiene las operaciones que es posible efectuar sobre una sub-tarea. Nótese que el menú de acciones contiene prácticamente todaslas operaciones disponibles sobre una incidencia, tanto las operaciones“comunes” como las operaciones de flujo de trabajo.

En el panel Sub-tasks pueden verse las barras de progreso del traba-jo sobre una incidencia se ilustra de forma gráfica el tiempo estimadopara la resolución de una incidencia y el trabajo desempeñado hastael momento.

A través del control identificado con el icono “+” puede crearse rá-pidamente una sub-tarea a la incidencia seleccionada. Seleccionandoese control, aparecerá la form de creación de sub-tarea directamenteen el panel Sub-tasks, como ilustrado en Figura 5.29

98

5.9. Sub-tareas

Figura 5.28: Menu de operaciones de una sub-tarea

Figura 5.29: Formulario de creación de sub-tarea en el panel Sub-tasks

99


5.9.3 Convertir una incidencia en sub-tarea

A veces es deseable modificar la organización de las incidencias “aposteriori”. Un jefe de proyecto, por ejemplo, podría querer “agregar”un conjunto de incidencias de primer nivel como sub-tareas de otraincidencia con el objetivo de facilitar el seguimiento de unas labores.En otras ocasiones, un jefe de proyecto quisiera “subdividir” el trabajode una incidencia en sub-tareas para agilizar su resolución y asignarmúltiples “unidades de trabajo” a muchos miembros del equipo a lavez.

JIRA permite convertir una incidencia de primer nivel a sub-tarea(y viceversa). Ya que, como explicado, las sub-tareas no pueden tenersub-tareas, no es posible convertir a sub-tarea una incidencia quetenga sub-tareas.

Para convertir una tarea de primer nivel en sub-tarea, es necesarioefectuar las siguientes operaciones:

(i) Seleccionar la incidencia a convertir.(ii) Seleccionar la operación Convert to sub-task del menú More

actions.(iii) En la form de conversión ilustrada en Figura 5.30 seleccionar la

tarea a la que pertenecerá la incidencia después de convertirseen sub-tarea.

Figura 5.30: Formulario de conversión de incidencia a sub-tarea

(iv) Seleccionar el tipo de incidencia de la sub-tarea.(v) En el caso en que el estado de la tarea a convertir no fuese

permitido por el tipo de sub-tarea escogida, aparecerá un for-mulario para escoger el estado de la incidencia después de laconversión. En el caso no fuese necesario hacer esta conversión,la ventana no aparecerá.

100

5.9. Sub-tareas

(vi) En el caso en que el tipo de sub-tarea escogido requiriese cam-pos adicionales, el usuario podrá introducirlos en el formularioilustrado en Figura 5.31. En el caso no fuese necesario añadirninguna información adicional, la ventana presentará un men-saje informativo.

Figura 5.31: Formulario de conversión de campos para la conversión asub-tarea

(vii) Al final del proceso, se visualizará la ventana de confirmaciónilustrada en Figura 5.32. Pulsando el botón Finish se llevaráa cabo el proceso de conversión al final del cual aparecerá laventana de detalle de la incidencia.

Figura 5.32: Formulario de confirmación de conversión de incidencia asub-tarea

5.9.4 Convertir una sub-tarea en incidencia

En ciertas ocasiones puede ser deseable hacer la conversión inversa ytransformar una sub-tarea en una incidencia de primer nivel. Los pa-sos necesarios a efectuar la transformación y las ventanas propuestasal usuario son las mismas que se han visto durante la conversión deuna incidencia de primer nivel en sub-tarea (§5.9.3). En resumen, lasoperaciones a efectuar son las siguientes:

(i) Seleccionar la sub-tarea a convertir.(ii) Seleccionar la operación Convert to issue del menú More ac-

tions.

101


(iii) Seleccionar el tipo de incidencia.(iv) En el caso en que el estado de la sub-tarea a convertir no fue-

se permitido por el tipo de incidencia escogida, aparecerá unformulario para escoger el estado de la incidencia después de laconversión. En el caso no fuese necesario hacer esta conversión,la ventana no aparecerá.

(v) En el caso en que el tipo de incidencia escogido requiriese cam-pos adicionales, el usuario podrá introducirlos en el formularioparecido a la ventana ilustrada en Figura 5.31. En el caso nofuese necesario añadir ninguna información adicional, la venta-na presentará un mensaje informativo.

(vi) Al final del proceso, se visualizará una ventana de confirmaciónparecida a la ilustrada en Figura 5.32. Pulsando el botón Fi-nish se llevará a cabo el proceso de conversión al final del cualaparecerá la ventana de detalle de la incidencia.

5.10 Duplicar una incidencia

En ciertas ocasiones puede ser útil poder crear una incidencia co-piando una incidencia existente y evitar así volver a rellenar muchoscampos cuyo valor coincide en ambas incidencias: si, por ejemplo,se necesita crear una incidencia “muy parecida” a una incidencia yaregistrada en JIRA, puede clonarse dicha incidencia para obteneruna copia exacta (con las excepciones detalladas más adelante) de laincidencia y de sus campos y cambiar solo la información que nece-sita modificarse. Durante la copia de una incidencia la informaciónrelativa al trabajo desempeñado sobre la incidencia “original” (timetracking, comentarios, etc.) no se copiarán. Los campos copiados sonlos siguientes:

(i) Título.(ii) Descripción.(iii) Usuarios al que se asignó la incidencia.(iv) Entorno.(v) Prioridad.(vi) Tipo de incidencia.(vii) Seguridad.(viii) Usuario que ha reportado la incidencia.(ix) Componentes.(x) Versiones afectadas.

102

5.10. Duplicar una incidencia

(xi) Resolución para versiones.(xii) Enlaces de incidencia.(xiii) Ficheros adjuntos(xiv) Proyecto.

Los campos copiados podrán, obviamente, modificarse después dehaberse creado la copia. En el caso del campo proyecto, por ejemplo,podrá moverse la incidencia duplicada a otro proyecto.

En algunos casos de uso, puede ser útil dejar constancia de la ope-ración de copia utilizando un link (enlace) entre la incidencia originaly su copia.

Para duplicar una incidencia es necesario efectuar las siguientesoperaciones:

(i) Seleccionar la incidencia a duplicarse.(ii) Selecciona la operación Clone del menú More actions.(iii) En la ventana siguiente puede modificarse el título de la inci-

dencia. Por defecto, JIRA añade un prefijo (§??) al título de laincidencia original.

(iv) Si la incidencia contiene enlaces a otras incidencias es posibleelegir si duplicar los enlaces o no.

(v) Si la incidencia contiene sub-tareas es posible elegir si duplicarlas sub-tareas o no.

(vi) Si la incidencia contiene ficheros adjuntos es posible elegir siincluir estos ficheros en la incidencia duplicada.

(vii) Finalizar la duplicación de la incidencia pulsando el botón Crea-te.

5.10.1 Crear un enlace a una incidencia duplicada

Puede ser deseable mantener constancia de las operaciones de du-plicación de incidencia y para conseguir este objetivo JIRA permitecrear de forma automática un enlace entre las dos incidencias. Pordefecto esta funcionalidad está inhabilitada y solo el administradorpuede activarla.

Para activar la creación automática de enlaces durante la dupli-cación de incidencias el administrador debe impostar la propiedadjira.clone.linktype.name en el fichero de configuración de JIRA,jira-application.properties con el nombre del enlace a crear.Por defecto el nombre es Cloners, como puede verse en el fragmentode código 5.1.

103


Código 5.1 Nombre por defecto del enlace automático a incidenciasduplicadasjira.clone.linktype.name = Cloners

El tipo de enlace configurado debe existir y, por defecto, el enlacede tipo Cloners no existe en JIRA. Para habilitar esta funcionalidadel administrador deberá por lo tanto crear el enlace de tipo Clonerso crear otro enlace y configurar adecuadamente la propiedad en cues-tión.

5.10.2 Prefijo del título de las incidencias duplicadas

Cuando se duplica una incidencia JIRA añade automáticamente unprefijo al título de la incidencia duplicada y, por defecto, el prefijoutilizado es CLONE -. El prefijo utilizado puede elegirse modificandola propiedad jira.clone.prefix en el fichero de configuración de JI-RA, jira-application.properties, como ilustrado en el fragmentode código 5.2.

Código 5.2 Prefijo del título de las incidencias duplicadasjira.clone.prefix = CLONE -

5.10.3 Duplicación de incidencias y sub-tareas

El proceso de duplicación de incidencias maneja de forma distintalas sub-tareas dependiendo del “contexto” en el que las sub-tareasaparecen. Si se está duplicando una sub-tarea, el procedimiento deduplicación será idéntico al proceso de duplicación de cualquier inci-dencia. Si se está duplicando una incidencia que contiene sub-tareas,las sub-tareas podrán duplicarse también pero el prefijo del título seaplicará solo a la incidencia padre.

5.11 Enlaces entre incidencias

JIRA proporciona algunos mecanismos para establecer una “relación”entre incidencias. Los enlaces son, probablemente, el más flexible deestos mecanismos. Esta funcionalidad es habilitada y configurada porel administrador de JIRA. El administrador puede definir los tipos de

104

5.11. Enlaces entre incidencias

enlaces que se requieren y los usuarios que posean el permiso Linkissues pueden escoger un tipo de enlace y establecer una relaciónentre dos incidencias.

Los enlaces son relaciones bidireccionales7 que indicaremos con lanotación α−→. Por su naturaleza bidireccional, establecer una relaciónα entre dos incidencias x y y:

xα−→ y (5.1)

o la correspondiente inversa α−1 entre y y x:

xα−1

←− y (5.2)

otorga el mismo resultado: JIRA indicará la existencia de la relaciónα en la ventana de detalle de x, y la existencia de la relación α−1 enla ventana de detalle de y. Cuando el administrador crea un enlacenuevo, entonces, es necesario definir tanto la descripción para α quepara la relación inversa, α−1.

Desde o hacia una incidencia pueden crearse tantos enlaces comosean necesarios. El interfaz de JIRA, en la ventana de detalle de inci-dencia, agregará los enlaces del mismo tipo y dirección para facilitarla lectura y la organización de los enlaces entre incidencias.

Relaciones muy comúnmente utilizadas son, por ejemplo, la rela-ciones de duplicidad y dependencia. La relación de duplicidad, porejemplo, puede ser definida por el administrador como x duplica y y yes duplicada por x. El administrador podrá definir, a través de la con-sola de administración de JIRA, todos los tipos de enlaces requeridospor los proyectos gestionados por la plataforma.

Para establecer una relación entre dos incidencias es necesarioefectuar las siguientes operaciones:

(i) Seleccionar una incidencia. La incidencia, como veremos, puedeser tanto la incidencia donde se origina la relación o la incidenciadonde termina la relación. En la notación x

α−→ y x es laincidencia donde “origina” y y la incidencia donde “termina” larelación.

(ii) Seleccionar la operación Link del menú More actions y apare-cerá la ventana de creación de enlace que puede verse en Figura5.33.

7Que pueden navegarse en ambos sentidos.

105


Figura 5.33: Formulario de creación de un enlace entre incidencias

(iii) En la ventana de creación elegir el tipo de enlace que se deseaestablecer. En la combo (Figura 5.34) podrá elegirse tanto unarelación que “origina” como una relación que “termina” en laincidencia seleccionada. En Figura 5.34 pueden verse, por ejem-plo, las relaciones de dependencia, duplicación y relación y lascorrespondientes relaciones inversas.

Figura 5.34: Formulario de creación de un enlace entre incidencias

(iv) En el campo Issues se pueden escoger las incidencias con lascuales hay que establecer la relación. Las incidencias puedenseleccionarse empezando a teclear el código o el título de la in-cidencia y JIRA propondrá una lista de incidencias, generadadinámicamente, que satisfacen el criterio de búsqueda de acuer-do al texto escogido por el usuario (Figura 5.35).

(v) Las incidencias pueden buscarse también utilizando un filtro debúsqueda que el usuario haya definido (véase §??) en el buscador

106

5.11. Enlaces entre incidencias

Figura 5.35: Búsqueda de una incidencia por código o título

de incidencias que aparece seleccionado el control + a la dere-cha de la combo Issues (Figura 5.36). Si se desean seleccionarmúltiples incidencias, se puede utilizar el botón Select multipleissues y seleccionar las incidencias deseadas utilizando los checkbox que aparecen al lado de cada incidencia.

Figura 5.36: Búsqueda de una incidencia utilizando un filtro

(vi) Puede insertarse un comentario al enlace creado insertando un

107


texto en el control Comment.(vii) Puede escogerse que tipo de visibilidad tendrá el enlace esco-

giendo un role de proyecto en el control Viewable by (véase§??).

(viii) Crear el enlace seleccionando el botón Link.

Después de haber creado el enlace podrán verse los detalles de losenlaces a los que pertenece la incidencia seleccionada en el panel IssueLinks de la ventana de detalles de incidencia. Un enlace de ejemplopuede verse en Figura 5.37.

Figura 5.37: Detalle de un enlace entre incidencias

Como en otros paneles de JIRA, en el rincón superior derechopueden verse controles adicionales. En este caso está el control degestión de enlaces, identificado con el icono de un “engranaje” y elcontrol para añadir un enlace, identificado con un icono con el símbulo+.

5.11.1 Gestionar los enlaces entre incidencias

El control de gestión de enlaces, identificado con un engranaje, llevaa la ventana de gestión de enlaces. En esta ventana, ilustrada enFigura 5.38, pueden organizarse los enlaces, ordenándolos utilizandolos controles identificados con “flechas” y eliminar enlaces, utilizandoel control de eliminación, identificado con el icono de “basura”.

Figura 5.38: Ventana de gestión de enlaces entre incidencias

108

5.12. Planificar las incidencias

5.12 Planificar las incidencias

JIRA permite planificar las incidencias que creamos dentro de losproyectos incluyendo la fecha de resolución (Due date). La fecha deresolución es una “estimación” de la fecha en la que una incidenciadebería cerrarse y, por defecto, es un campo opcional en los tipos deincidencia y relativas configuraciones de campos de una instalaciónestándar de JIRA.

La fecha de resolución puede utilizarse, por ejemplo, para priorizarla resolución de las incidencias que estén próximas a la fecha límite.Creando filtros (§??) es posible, por ejemplo, crear reportes en elcuadro de mando de JIRA de un jefe de equipo y obtener una imagendel estado de resolución de las incidencias de un proyecto. De lamisma forma, es posible utilizar este campo para enviar notificaciones(§??) cuando una incidencia supera la fecha límite sin estar resueltay ser avisado inmediatamente cuando este evento ocurre.

Esta funcionalidad de JIRA está siempre habilitada y, para modi-ficar el valor de este campo, un usuario debe tener el permiso Scheduleissues.

Un usuario puede modificar el campo Due date en el momentode la creación de una incidencia o, posteriormente, modificando unaincidencia existente.

5.12.1 Filtrar incidencias utilizando la fecha de resolu-ción

Las herramientas de búsqueda y filtrado de incidencia de JIRA sonpoderosas y permiten realizar búsquedas complejas utilizando cual-quier campo de una incidencia, incluidos los campos personalizadoscreados por los administradores de acuerdo a las necesidades de cadaproyecto.

El campo fecha de resolución es un campo estándar de las in-cidencias y es posible realizar búsquedas simples o avanzadas. Eneste capítulo se detallará el mecanismo de búsqueda simple. Las bús-quedas avanzadas aprovechan del lenguaje de query de JIRA que sedetallará en ??.

La sección relativa al filtrado por fecha de resolución del navega-dor de incidencias puede verse en Figura 5.39. Debido a la naturalezadel valor almacenado en este campo, JIRA permite realizar dos ti-pos de búsquedas de forma fácil a través de una interfaz de usuarioespecializada:

109


Figura 5.39: Sección de filtrado por fecha de resolución en el navegadorde incidencias

(i) Búsquedas por valores exactos, utilizando los campos Due aftery Due before.

(ii) Búsquedas por intervalos temporales relativos a la fecha busca-da, utilizando los campos From, To y el formulario de búsquedapor valores relativos disponible utilizando el icono “calendario”a la derecha de estos campos.

En las búsquedas por valores exactos se utiliza un valor “absoluto”para filtrar las incidencias; llamando t0 y t1 los valores introducidospor el usuario y x el valor del campo fecha de resolución de unaincidencia, pueden realizarse las siguientes operaciones a través delinterfaz de usuario de JIRA:

(i) Buscar las incidencias que satisfagan x = t0.(ii) Buscar las incidencias que satisfagan x ≤ t0.(iii) Buscar las incidencias que satisfagan x ≥ t0.(iv) Buscar las incidencias que satisfagan t0 ≤ x ≤ t1.

Los campos Due after y Due before se poblarán con los valores t0y t1 de acuerdo con la búsqueda que se está deseando realizar. Pararealizar la búsqueda (ii), por ejemplo, habrá que poner el valor t0 enel campo Due before; para realizar la búsqueda (iv), habrá que ponerel valor t0 en el campo Due after y el valor t1 en el campo Due before.

La fecha puede especificarse utilizando los formatos descritos en?? o utilizando los controles “calendarios” cuyos iconos pueden versea la derecha de los campos Due after y Due before. En Figura 5.40puede verse como filtar las incidencias con x ≤ t0 cuando la fecha deresolución es el 10 de Enero de 2011.

110

5.12. Planificar las incidencias

Figura 5.40: Ejemplo de filtrado por fecha de resolución en el navegadorde incidencias

Las búsquedas por intervalos temporales relativos a la fecha actualpermiten efectuar búsquedas de los siguientes tipos:

(i) Buscar las incidencias que hayan sobrepasado la fecha límite.(ii) Buscar las incidencias que hayan sobrepasado la fecha límite por

un número de días n ≥ t0.(iii) Buscar las incidencias que habrán sobrepasado la fecha límite

dentro de n días8.(iv) Buscar las incidencias cuya fecha límite está en el intervalo [t+

t0, t+ t1] donde t es la fecha al momento de la búsqueda y t0 yt1 son dos parámetros especificados por el usuario.

El formulario de búsqueda (Figura 5.39) contiene dos campos:From y To. Todas las búsquedas por intervalos temporales relativospueden realizarse poblando adecuadamente estos campos. Sin embar-go, el usuario puede componer más fácilmente el formulario utilizandola ventana de selección (Figura 5.41) a la que se accede seleccionan-do el icono identificado con un “calendario” a la derecha de dichoscampos. La ventana de selección permite poblar el formulario con losvalores adecuados al tipo de búsqueda que se desea realizar.

8Es posible especificar si se desea recuperar también las incidencias que hayanya sobrepasado la fecha límite al momento de la búsqueda

111


Figura 5.41: Formulario para la creación de un criterio de búsqueda porfecha de resolución con intervalos temporales relativos.

La búsqueda de tipo (i) se obtiene utilizando los valores9:{From = ∅To = 0

(5.3)

La búsqueda de tipo (ii) se obtiene utilizando los valores:{From = ∅To = −nd

(5.4)

La búsqueda de tipo (iii) se obtiene utilizando los valores:{From = 0To = nd

(5.5)

Si se desea encontrar también las incidencias que hayan sobrepasadola fecha límite en el momento de la búsqueda, se utilizarán los valores:{

From = ∅To = nd

(5.6)

9Con el símbulo ∅ se entiende que el campo se queda vacío.

112

5.13. Proteger una incidencia

La búsqueda de tipo (iv) se obtiene utilizando los valores:{From = t0

To = t1(5.7)

donde t0 y t1 pueden utilizar la notación ±xw ydwh zm donde windica el número de semanas, d el número de días, h el número dehoras y m el número de minutos. −1w 2d indicará, por ejemplo, unasemana y dos días en el pasado, ya que está prefijado con el signo −.

5.13 Proteger una incidencia

Los roles de proyecto y los esquemas de permisos permiten al adminis-trador de definir políticas de seguridad con una resolución muy fina.Sin embargo, en algunos casos de uso, no es suficiente otorgar el per-miso para ver las incidencias de un proyecto (Browse projects) a unconjunto de roles ya que podría necesitarse proteger un subconjuntode las incidencias existentes para que sean visibles solo a un gruporestringido de usuarios.

Los niveles de seguridad de las incidencias permiten subdividirlas incidencias en “grupos” cada uno de los cuales puede tener unapolítica de seguridad distinta y, por lo tanto, ser visible a grupos deusuarios diferentes. Sin esta funcionalidad, la única opción viable paraobtener un resultado parecido sería la creación de múltiples proyectoscon usuarios y roles de proyectos distintos. Sin embargo, la gestión demúltiples proyectos sería más complicada y se duplicarían de formainnecesaria las herramientas que el jefe de proyecto utilizaría paramonitorizar las labores sobre los proyectos tales como filtros, cuadrosde mandos y reportes.

Cuando una incidencia está protegida con un nivel de seguridad,la incidencia será invisible a los usuarios no autorizados a través decualquier herramienta proporcionada por JIRA, incluyendo reportes,búsquedas, filtros, notificaciones, etc.

5.13.1 Caso de uso: segmentación de usuarios

Un caso de uso típico de los niveles de seguridad de las incidenciases la segmentación de los usuarios de un proyecto de JIRA. El mis-mo proyecto, por ejemplo, podría estar recogiendo incidencias porusuarios, “clientes” en este caso, que hayan contratado soportes condistintos niveles de servicio. En este caso de uso podría ser deseable

113


establecer una “segmentación” de clientes de manera que los clientesque han contratado un nivel de servicio más elevado tengan accesoa información restringida a usuarios con soporte de nivel más bajo.En la segmentación de ejemplo ilustrada en Figura 5.42, los usua-rios con el nivel de soporte Silver-level support podrán acceder a unsub-conjunto de la “información” gestionada en el proyecto JIRA yno podrán ver la información reservada a los niveles superiores. Los

Figura 5.42: Segmentación de usuarios con niveles de seguridad deincidencia

usuarios con el nivel de soporte inmediatamente superior, Gold-levelsupport, podrán acceder a la información disponible al nivel Silvery a un conjunto de información adicional. Los usuarios con el nivelPlatinum podrán acceder a la información disponible a los usuariosde los niveles inferiores y a un conjunto de información adicional.

Este tipo de segmentación no solo permite crear “vistas” diferen-tes del mismo proyecto para usuarios distintos sino que puede ser deayuda a la hora de planificar el trabajo sobre las incidencias. El jefede proyecto y los operadores asignados al proyecto pueden utilizar lasegmentación para priorizar las labores sobre las incidencias. La for-ma más sencilla consiste en planificar la resolución de las incidenciade forma manual: el jefe de equipo utilizará la segmentación y la prio-ridad de las incidencias para asignarlas a los operadores de acuerdoa las necesidades del proyecto, de los clientes y de la importancia delas incidencias.

Otro enfoque, más apto a proyectos con un grande número de in-cidencias y operadores, es la implementación de una segmentación deoperadores. La segmentación de operadores permite crear grupos deoperadores “dedicados”: para ofrecer un nivel de servicio más elevadoa clientes con soporte más alto se pueden asignar más recursos10 algrupo de operadores dedicados al nivel de seguridad más elevado.

10La asignación de una cantidad de recursos más elevada podría traducirse en

114

5.13. Proteger una incidencia

5.13.2 Caso de uso: proteger información confidencial

Otro caso de uso para los niveles de seguridad de las incidencias es laprotección de información confidencial de un proyecto.

Para un usuario de JIRA, un proyecto no es “solo” un sitio dondereportar incidencias y observar el trabajo desempeñado sobre ella.Uno de los valores añadidos más importantes de la plataforma JIRAes el hecho de que se proporciona un espacio donde los usuarios puedencolaborar y donde se favorece la interacción directa con otros usuariosde la plataforma.

Un proyecto de JIRA es el lugar ideal donde una empresa, o unaunidad organizativa de una empresa, puede concentrar toda la in-formación relativa a las labores dentro del marco de una iniciativa.La consolidación de la información en una sola plataforma facilitarála explotación de la información histórica y la gestión de las laboresdiarias de los equipos.

En ciertas circunstancias, sin embargo, una organización quisie-ra utilizar JIRA para almacenar y tener constancia de informaciónconfidencial relativa a un proyecto garantizando, al mismo tiempo,que el acceso a dicha información estuviera restringido a los usuariosautorizados.

Los niveles de seguridad de las incidencias permiten crear las po-líticas de seguridad necesarias a proteger un conjunto de incidenciasy otorgar el acceso a ellas solo a un grupo de usuarios selectos.

5.13.3 Proteger una incidencia

La definición de los niveles de seguridad disponibles en un proyectoes una responsabilidad del administrador de JIRA. Los usuarios deun proyecto que tengan el permiso Set issue security podrán escogerel nivel de seguridad de una incidencia al momento de su creación o,posteriormente, al momento de su modificación.

Es importante subrayar que un usuario puede escoger como nivelde seguridad de una incidencia solo un nivel del cual él mismo seamiembro. De esta forma se garantiza que no pueda asociarse unaincidencia con un nivel de seguridad para el cual no exista ningúnmiembro activo y, por lo tanto, “perder” esa incidencia ya que resul-taría inaccesible para todo usuario del proyecto.

un número de operadores más elevados e, incluso, en un horario “extendido” detrabajo sobre las incidencias.

115


Para seleccionar el nivel de seguridad de una incidencia es ne-cesario modificar el valor del campo Security level. En Figura 5.43puede verse el menú desplegable del campo Security level en la ven-tana de modificación de una incidencia. En este caso solo existen dos

Figura 5.43: Modificar el nivel de seguridad de una incidencia

opciones:

(i) None: Seleccionando esta opción no se aplicará ningún nivelde seguridad a la incidencia que, por lo tanto, estará visible atodos los usuarios que tenga el permiso Browse projects.

(ii) Silver: Seleccionando esta opción se aplicará el nivel de segu-ridad Silver a la incidencia. La incidencia estará visible a todoslos usuarios autorizados por este nivel de seguridad.

Al proyecto al que pertenece la incidencia ilustrada, JIRA Guide,se ha asignado un esquema de nivel de seguridad de incidencias quecontiene los tres niveles que se introdujeron en §5.13.1:

(i) Platinum.(ii) Gold.(iii) Silver.

Sin embargo, en Figura 5.43, solo se puede seleccionar el valor Silveren el campo Security level ya que el usuario conectado solo tieneacceso a incidencias en este nivel de seguridad.

Después de haber confirmado el nivel de seguridad de la inciden-cia podrá verse reflejado el nuevo valor en la ventana de detalle deincidencias (Figura 5.44).

116

5.14. Poner etiquetas a una incidencias

Figura 5.44: Nivel de seguridad de una incidencia en la ventana dedetalle

Un usuario que no tenga acceso a este nivel de seguridad no podráver las incidencias asociadas. Para ilustrar esta características sehan asociados todas las incidencias del proyecto al nivel de seguridadSilver. Un usuario “básico” que no tenga acceso a ningún nivel deseguridad no verá ninguna actividad en el proyecto, como ilustradoen Figura 5.45.


5.14 Poner etiquetas a una incidencias

Las etiquetas (labels) son un tipo de campo introducido recientementeen JIRA que permite al usuario agregar un conjunto de “etiquetas’libres” a las incidencias. Las incidencias, por defecto, llevan un campode este tipo denominado Label y el administrador de JIRA puede crearcampos personalizados adicionales de este tipo.

117


Un ejemplo de etiquetas, “AJAX” y “JQuery”, pueden verse enFigura 5.46. Las etiquetas de JIRA son muy parecidas a las etiquetas


que pueden verse en un gran número de aplicaciones de distintos tiposcomo las etiquetas que pueden adjuntarse a un blog post. Los usuarioscon permiso a modificar una incidencia (Edit issues) pueden añadiretiquetas a una incidencia y este mecanismo es ideal para organizarlas incidencia de una forma más “informal”.

En JIRA, los mecanismos alternativos utilizado para organizar in-cidencias son los componentes y las versiones. Sin embargo, ningunode estos dos mecanismos se prestan a que los usuarios puedan or-ganizar las incidencia de forma de acuerdo a los criterios que ellosmismos establezcan: ambos son una característica de un entero pro-yecto y solo los administradores y los usuarios que tengan los permisosadecuados (como los jefes de proyecto) podrán manejar versiones ycomponentes. Por otro lado, cualquier usuario que pueda modificaruna incidencia puede asignar etiquetas a la misma y, por lo tanto,agrupar incidencias utilizando “palabras claves”.

Las etiquetas, como cualquier otro campo, permiten efectuar bús-quedas y filtros utilizando el valor de este campo. Pulsando unaetiqueta en una incidencia de JIRA, además, el usuario será llevadoal navegador de incidencias donde se seleccionarán automáticamentetodas las incidencias que tengan la etiqueta que se haya seleccionado.

Las etiquetas pueden crearse durante el proceso de creación deuna incidencia, durante el proceso de modificación de una incidenciao utilizando el formulario de gestión de etiquetas de una incidencia.Para añadir una etiqueta a una incidencia utilizando el formulario degestión de etiquetas es necesario efectuar las siguientes operaciones:

(i) Seleccionar la incidencia que se desea etiquetar yendo a su ven-tana de detalle.

118

5.14. Poner etiquetas a una incidencias

(ii) Seleccionar el control para gestionar etiquetas, identificado conel icono de un “lápiz”, a la derecha del campo Labels en el panelDetails.

(iii) En el formulario que aparecerá (Figura 5.47), teclear las etique-tas que se desean añadir. Mientras se esté tecleando una eti-queta, JIRA propondrá al usuario las etiquetas existentes quecoincidan con las letras tecleadas.

Figura 5.47: Formulario de creación de una etiqueta en una incidencia

(iv) Seleccionar la checkbox Send update notification si se desea queJIRA envíe la notificación de modificación de incidencia a losusuarios.

(v) Confirmar la modificación pulsando el botón Update.

5.14.1 Eliminar una etiqueta

El procedimiento de para eliminar una etiqueta de una incidencia essimilar al procedimiento de creación. Una etiqueta puede eliminarsedurante la modificación de una incidencia o utilizando el formulariode gestión de etiquetas de una incidencia. Para remover una etiquetade una incidencia utilizando el formulario de gestión de etiquetas esnecesario efectuar las siguientes operaciones:

(i) Seleccionar la incidencia que se desea etiquetar yendo a su ven-tana de detalle.

(ii) Seleccionar el control para gestionar etiquetas, identificado conel icono de un “lápiz”, a la derecha del campo Labels en el panelDetails.

(iii) En el formulario que aparecerá (Figura 5.47), eliminar las eti-quetas que se desean borrar seleccionando con el ratón el controlde eliminación de etiqueta, identificado con el icono ×, a la de-recha de la etiqueta a borrar.

119


(iv) Seleccionar la checkbox Send update notification si se desea queJIRA envíe la notificación de modificación de incidencia a losusuarios.

(v) Confirmar la modificación pulsando el botón Update.

5.15 Trabajar sobre una incidencia

JIRA permite mantener un control de horario (time tracking) paracada incidencia a través del cual es posible:

(i) Registrar el tiempo estimado para resolver una incidencia.(ii) Obtener una estimación del tiempo restante para resolver una

incidencia.(iii) Registrar el tiempo trabajado en una incidencia con una des-

cripción del trabajo desempeñado.(iv) Si una incidencia tiene sub-tareas, además, es posible ver los

tiempos agregados.

Esta información puede utilizarse para generar reportes y controlarlos niveles de servicios que se proporcionan a los usuarios.

El administrador puede habilitar la funcionalidad de time trac-king a nivel de plataforma. Cuando esta funcionalidad es disponible,la ventana de detalle de incidencia mostrará un panel, Time tracking,donde se presentará esta información de forma gráfica, como ilustradoen Figura 5.48. La primera barra, la barra azul con la etiqueta Es-

Figura 5.48: Panel Time tracking de una incidencia

timated, indica el tiempo estimado para resolver una incidencia: estevalor es el valor del campo Original estimate y puede establecersedurante la creación de una incidencia. Este campo puede modificarseposteriormente pero antes de que un usuario registre trabajo sobre la

120

5.15. Trabajar sobre una incidencia

incidencia. Si un usuario ha registrado trabajo en una incidencia, elcampo que podrá modificarse será el campo Remaining estimate.

La segunda barra, la barra naranja con la etiqueta Remaining,indica el tiempo restante estimado para resolver la incidencia. Es-te valor, tr es el valor del campo Remaining estimate y satisface lacondición

tr = to − tw (5.8)

donde to es la estimación original (Original estimate) menos el trabajotw trabajado por los operadores. En el caso en que se decida agregar lainformación de las sub-tareas, cada uno de los valores indicados seránla suma de los respectivos valores en el conjunto Λ de las sub-tareas:

Tr = To − TwTr =

∑λ∈Λ

tr(λ)

To =∑λ∈Λ

to(λ)

Tw =∑λ∈Λ

tw(λ)

(5.9)

La incidencia cuyo panel Time tracking puede verse en Figura 5.48tenía To = 4 d y Tw = 1 d y, por lo tanto, un valor Tr = 3 d.

La tercera barra, la barra verde con la etiqueta Logged, indica eltiempo tw (o Tw) que los operadores han registrado como “trabaja-do” sobre esta incidencia. JIRA mantendrá un registro histórico deltrabajo registrado por los operadores en la plataforma en la pestañaWork log del panel Activity cuya captura de pantalla puede verse enFigura 5.49.

Figura 5.49: Pestaña Work log del panel Activity de una incidencia

121


5.15.1 Hacer una estimación del trabajo requerido

La primera acción que normalmente efectúan los operadores, o el jefede proyecto que asigna la incidencia, es hacer una estimación deltiempo necesario para solucionar la incidencia. Esta estimación seregistra en el campo Original estimate (Figura 5.50) y puede asumirvalores del tipo xw yd wh zm donde x, y, w y z son, respectivamente,el número de semanas, días, horas y minutos.

Figura 5.50: Campos para la estimación del trabajo requerido de unaincidencia

Dependiendo de la versión de JIRA y de la configuración queel administrador haya establecido, la funcionalidad de time trackingpodría funcionar en modalidad legacy o no. En la modalidad legacy,el campo Original estimate puede modificarse exclusivamente antesde que un operador registre en la butaca el primer parte de actividad.Después de que un operador haya registrado trabajo, aparecerá elcampo Remaining estimate en lugar del campo Original estimate ysolo podrá modificarse el valor de este campo.

En las nuevas versiones de JIRA, sin embargo, se ha introducidouna nueva funcionalidad y ambos campos Original estimate y Remai-ning estimate pueden modificarse después de que el trabajo sobre unaincidencia haya empezado. Para mantener el comportamiento de lasantiguas versiones de JIRA el administrador puede configurar el timetracking para funcionar en modalidad legacy en la cual el comporta-miento de la plataforma emulará el comportamiento de las versionesantiguas de JIRA.

Los campos Original estimate y Remaining estimate están por de-fecto accesibles en la ventana de modificación de la incidencia. Sinembargo estos campos, así como cualquier otro campo de JIRA, puedehacerse disponible en otras pantallas también de acuerdo a las confi-guraciones que haya establecido el administrador a nivel de esquemade pantallas por tipo de incidencia y de pantallas de transiciones deflujo de trabajo.

122


5.15.2 Registrar trabajo sobre una incidencia

JIRA permite registrar en el log de actividad de una incidencia ella cantidad de trabajo desempeñado por los operadores con una des-cripción de las actividades realizadas. El log de actividad es una he-rramienta importante para todos los usuarios de la plataforma: jefesde equipo, operadores y usuarios. Los jefes de equipo podrán, entreotras cosas, observar el trabajo del equipo y mantener un históricode actividades para saber exactamente que actividades han manteni-do ocupado un operador en cada momento y cuales incidencias hangenerado más trabajo. Los operadores dispondrán de la historia detoda actividad llevada a cabo que podrán consultar en cualquier mo-mento en caso de duda, revisión o reapertura de una incidencia. Losoperadores se beneficiarán de esta información para detectar las acti-vidades que han resultado más problemáticas durante las resoluciónde las incidencias y será una información valiosa a la hora de estimar yplanificar trabajos futuros. Los usuarios, por otra parte, podrán uti-lizar esta información para observar los trabajos que se desempeñansobre una incidencia mientras esperan su resolución.

Los operadores pueden registrar el trabajo que van desempeñandoa través del campo denominado Log work. El campo Log work, enrealidad, es un conjunto de campos que permiten:

(i) Registrar el trabajo.(ii) Efectuar opcionalmente un ajuste sobre la estimación de trabajo

restante.(iii) Adjuntar una descripción del trabajo desempeñado.

Por defecto, el campo es accesible a través de la operación Logwork en la ventana de detalle de una incidencia. El campo Log work,como cualquier campo de JIRA, puede añadirse a cualquier pantallade acuerdo a las necesidades del proyecto y es una solicitud comúndisponer de este campo en una ventana de transición de flujo de tra-bajo, especialmente en las transiciones que implican un “trabajo”,como las transiciones de resolución y cierre de incidencia.

Para registrar trabajo desde la ventana de detalle de incidencia esnecesario efectuar las siguientes operaciones:

(i) Seleccionar la incidencia deseada.(ii) Seleccionar la operación Log work en el menú More actions.(iii) Rellenar el formulario Log work presentado al usuario e ilustrado

en Figura 5.51.

123


Figura 5.51: Formulario de registro de trabajo

(iv) Introducir en el campo Time spent la cantidad de trabajo desem-peñada. La cantidad de tiempo puede introducirse en el formatoxw yd wh zm detallado en precedencia (§??).Añadir sec-

ción sobreel formatode interva-los de tiem-po

(v) En el campo Date started introducir la fecha en la que se comen-zó la unidad de trabajo a registrar. La fecha puede seleccionarseutilizando el control “calendario” al que se puede acceder selec-cionando el control, identificado con el icono “calendario”, a laderecha del campo.

Añadir sec-ción sobreel control“calenda-rio”

(vi) El campo Remaining estimate puede utilizarse para efectuar unajuste de la estimación del tiempo restante hasta la resoluciónde la incidencia. En este campo puede seleccionarse una de lassiguientes opciones:• Adjust automatically, para que el tiempo restante se calculecon tr = to − tw.

124


• Leave estimate unset11, para no introducir ninguna esti-mación.

• Use existing estimate of. . . 12, para que el valor tr no se mo-difique después de la introducción del registro de trabajocorriente.

• Set to. . . , para modificar manualmente la estimación detiempo restante tr. El formato del valor introducido es elformato xw yd wh zm detallado en precedencia (§??).

• Reduce by. . . , para reducir manualmente la estimación detiempo restante tr de la cantidad especificada. El formatodel valor introducido es el formato xw yd wh zm detalladoen precedencia (§??).

(vii) Introducir opcionalmente la descripción del trabajo realizado enel campo Work description.

(viii) Utilizar opcionalmente el control Viewable by, identificado conel icono “candado”, para establecer una política de seguridadsobre el registro de trabajo y decidir que usuarios, grupos oroles de proyecto pueden acceder a él.

(ix) Confirmar la operación pulsando el botón Log.

Después de haber creado el registro de trabajo el usuario volveráa la ventana de detalle de incidencia en la cual aparecerá el registrorecién creado (en el panel Activity) y las estimaciones del panel Timetracking se habrán actualizado de acuerdo a la información introdu-cida.

En Figura 5.52 puede verse un registro de trabajo y a la derechadel registro se aprecian los controles que aparecen cuando el ratón seencuentra encima del mismo. Los controles son similares a los demáscontroles de gestión de otras “entidades” gestionadas por JIRA y elfuncionamiento de cada uno de ellos se explorará en las siguientessecciones.

5.15.3 Registrar trabajo durante una transición de es-tado en el flujo de trabajo

Como explicado en precedencia, el administrador puede añadir elcampo Log work en cualquier pantalla de acuerdo a las necesidades

11Este campo es disponible solo si la incidencia no tiene todavía ninguna esti-mación de tiempo necesario para la resolución.

12Este campo es disponible solo si la incidencia tiene una estimación de tiemponecesario para la resolución.

125


Figura 5.52: Registro de trabajo con controles de gestión

de los proyectos. Es común añadir este campo en las pantallas detransición de estado hacia el estado Resuelta y Cerrada del flujo detrabajo de las incidencias: de esta forma los usuarios podrán resolveruna incidencia y registrar el trabajo efectuado en una única operación.En Figura 5.53 puede verse una ventana de resolución de incidenciacon el campo Log work habilitado.

Figura 5.53: Formulario de registro de trabajo en una ventana deresolución de incidencia

Cuando se utiliza el campo Log work en una ventana de transi-ción de estado de flujo de trabajo, el comportamiento de los camposComment y Viewable by. . . dependen de como el administrador haya

126


configurado la funcionalidad de time tracking. Por defecto, JIRA co-piará el contenido del campo Comment en la descripción del registrode trabajo y protegerá el registro con la política seleccionada en elcontrol Viewable by. . . .

Sin embargo el administrador puede inhabilitar esta funcionalidady, por lo tanto:

(i) El registro podría ser visible a cualquier usuario que pueda verla incidencia.

(ii) La descripción del registro de trabajo podría estar vacía.

Ambos problemas pueden solucionarse “a posteriori” modificando elregistro de trabajo creado durante la transición. Sin embargo es acon-sejable solicitar al administrador la habilitación de la funcionalidadde copia de comentarios en el registro de trabajo para reducir el nú-mero de operaciones que el usuario tiene que efectuar y, por lo tanto,reducir los errores que potencialmente pudieran ocurrir durante lacreación de registros de trabajo.

5.15.4 Crear un enlace a un registro de trabajo

JIRA permite crear enlaces permanentes (permalink) a un registro detrabajo. El control identificado con un icono parecido a ⊂⊃ (§5.15.2)se utiliza para crear un enlace permanente tal y como se detalló en§??. Añadir sec-

ciones sobrepermalinks5.15.5 Modificar un registro de trabajo

Un registro de trabajo puede ser modificado después de su creaciónutilizando el control de modificación, identificado con un icono “lápiz”(§5.15.2), del registro de trabajo a modificar. Un usuario necesitael permiso Edit own work log para modificar un registro de trabajocreado por él mismo y necesita el permiso Edit all work logs paramodificar los registros de los demás usuarios.

Seleccionando el control de modificación de registro de trabajoaparecerá la ventana de modificación. La ventana de modificación esuna ventana parecida a la ventana Log work descrita en §5.15.2 y lasinstrucciones para modificar el registro son parecidas a las instruccio-nes de creación de registros detalladas en la sección citada. Téngaseen cuenta que en la ventana de modificación no aparecerá la opciónReduce by. . . del control Remaining estimate y, por lo tanto, se podráajustar la estimación utilizando exclusivamente los demás controles.

127


Después de haber confirmado la modificación de un registro detrabajo el usuario será llevado a la ventana de detalle de la incidenciadonde estarán reflejadas las modificaciones aportadas al registro, par-ticularmente en las estimaciones de la sección Time tracking. Parafacilitar su identificación, los registros de trabajo modificados seránmarcados con la etiqueta edited, como el registro ilustrado en Figura5.54.

Figura 5.54: Registro de trabajo modificado

5.15.6 Eliminar un registro de trabajo

Un registro de trabajo puede ser eliminado después de su creaciónutilizando el control de eliminación, identificado con un icono “basu-ra” (§5.15.2), del registro de trabajo a eliminar. Un usuario necesitael permiso Delete own work log para eliminar un registro de trabajocreado por él mismo y necesita el permiso Delete all work logs paraeliminar los registros de los demás usuarios.

Seleccionando el control de eliminación de registro de trabajo, apa-recerá la ventana de eliminación ilustrada en Figura 5.55. Esta venta-na es muy parecida a la ventana de creación de registro cuya funcio-nalidad se detalló en §5.15.2. Durante la eliminación de un registrode trabajo se dará la opción al usuario de ajustar la estimación detrabajo restante tr con un subconjunto de las opciones detalladas en§5.15.2 y las siguientes opciones adicionales:

(i) Auto adjust: esta opción “compensa” la estimación tr aumen-tando su valor con el valor tw del registro de trabajo a borrar.El valor resultante, tr + tw, será el mismo valor que tenía trantes de crear el registro de trabajo.

(ii) Increase estimated time remaining by. . . : esta opción permiteaumentar tr con un valor introducido por el usuario. La can-tidad de tiempo puede introducirse en el formato xw yd wh zmdetallado en precedencia (§??).

128

5.16. Mover una incidencia

Figura 5.55: Ventana de eliminación de registro de trabajo

Después de haber eliminado un registro de trabajo el usuario serállevado a la ventana de detalle de la incidencia donde estarán re-flejadas las modificaciones aportadas al registro, particularmente enlas estimaciones de la sección Time tracking. El registro de trabajoeliminado desaparecerá de la sección Work log del panel activity yel único rastro que quedará del registro en la plataforma serán lascorrespondientes entradas en el registro histórico (§??) de JIRA. Añadir sec-

ción sobre elregistro his-tórico5.16 Mover una incidencia

JIRA llava “migración” la operación a través de la cual se cambia elproyecto al que pertenece una incidencia y/o su tipo de incidencia.

Después de una reestructuración de proyectos puede ser conve-niente mover incidencias de un proyecto a otro. Un proyecto que haido creciendo con el tiempo, por ejemplo, podría partirse en múltiplesproyectos, cada uno de los cuales con su conjunto distinto de usuariosy operadores, y las incidencias existentes podrían distribuirse entrelos nuevos proyectos de acuerdo a los criterios establecidos durante lacreación de dichos proyectos.

En otras situaciones, un proyecto podría detectar la necesidad decrear un nuevo tipo de incidencia y solicitar la creación y la configu-ración de dicho tipo (configuración de campos, flujo de trabajo, etc.).Podría darse la necesidad, entonces, de “mover” (convertir), las inci-dencias que mientras tanto se hayan ido creando en el nuevo tipo deincidencia.

129


Una incidencia no puede “simplemente” moverse de un proyectoa otro o cambiarse de tipo: cada proyecto puede tener un conjuntode esquemas de configuración diferentes y algunos de estos esquemaspodrían incluso ser incompatibles el uno con el otro. El conjunto detipos de incidencias de un proyecto, por ejemplo, podría no incluirtodos los tipos contemplados en otro proyecto y, por lo tanto, unaincidencia de un tipo que no exista en otro proyecto solo podrá “mo-verse” efectuando una conversión a otro tipo. Aún cuando el mismotipo de incidencia exista en ambos proyectos, el esquema de camposasociado en un proyecto podría ser distinto, e incompatible, con elesquema de campos asociado en el otro proyecto. Dos campos con elmismo nombre podrían ser campos de tipo distinto y, una vez más,su valor debería convertirse cuando la incidencia se mueva. En otroescenario un esquema de campos podría prever como campo opcionalun campo que en el esquema de campos del proyecto de destino seconsidera requerido: como consecuencia, cuando se mueva una inci-dencia habrá que rellenar los campos requeridos que estén vacíos yentonces inválidos en el esquema de destino.

Otra fuente de incompatibilidades entre configuraciones de proyec-tos distintos son los estados personalizados de las incidencias. JIRApermite definir estados personalizados y utilizarlos en los flujos detrabajo asociados a un conjunto de tipos de incidencias en un pro-yecto. Una incidencia de una proyecto podría tener un estado que noestá contemplado en el flujo de trabajo asociado al tipo de inciden-cia correspondiente en el proyecto de destino. En este caso tambiénse requerirá intervención del usuario para escoger un nuevo estado aasociar a la incidencia que se está moviendo.

Para facilitar estas labores, JIRA proporciona un asistente queayuda el operador a llevar a cabo la labor de migración de incidenciasy encargándose de detectar posibles incompatibilidades que podríansurgir a raíz de la migración y proponiendo posibles soluciones.

Para mover una incidencia el usuario necesita el permiso Moveissues en el proyecto de origen y, ya que desde el punto de vista deéste la operación que se está efectuando es una creación, el permisoCreate issues en el proyecto de destino.

Para mover una incidencia es necesario efectuar las siguientes ope-raciones:

(i) Seleccionar la incidencia que se desea mover.(ii) Seleccionar la operación Move en el menú More actions.

130

5.16. Mover una incidencia

(iii) El usuario será llevado en la primera ventana del asistente parala migración de incidencia, cuya captura de pantalla puede verseen Figura 5.56. En esta ventana el usuario puede escoger el

Figura 5.56: Asistente de migración de incidencias — Paso 1

proyecto de destino y el tipo de incidencia en el proyecto dedestino.

(iv) Si el estado de la incidencia a mover no es un estado válido parael tipo de incidencia seleccionado en el proyecto de destino elusuario será llevado a la segunda ventana del asistente (Figu-ra 5.57) en la cual podrá seleccionar el nuevo estado para laincidencia.


(v) Si el asistente detecta que algunos campos de la incidencia en elproyecto de destino tengan que ser actualizados por el usuario,el usuario será llevado a la tercera ventana del asistente (Figura5.58).

(vi) Cuando todos los datos estén correctamente rellenados, el asis-tente presentará la ventana de confirmación (Figura 5.59) en la

131



cual se presentará un resumen de las operaciones que se llevarána cabo.


(vii) Confirmar la operación pulsando el botón Move.

Después de haber confirmado la operación, JIRA moverá la in-cidencia al proyecto de destino aplicando todos los cambios especi-ficados por el usuario en el asistente de migración y el usuario serállevado a la ventana de detalle de la incidencia.

5.17 Modificar múltiples incidencias a la vez

En ciertas circunstancias es deseable efectuar una operación sobre ungrupo de incidencias: eliminación, migración de un proyecto a otro otransición de flujo de trabajo son operaciones que, a menudo, puedenefectuarse sobre muchas incidencias a la vez y la posibilidad de hacerloreduce el trabajo de los usuarios y la posibilidad de cometer erroresa lo largo del proceso.

132

5.17. Modificar múltiples incidencias a la vez

JIRA permite efectuar operaciones bulk (operaciones masivas) so-bre el resultado de una búsqueda y las operaciones permitidas son lasoperaciones que más comúnmente se necesitan:

(i) Transiciones de flujo de trabajo.(ii) Eliminaciones.(iii) Migraciones.(iv) Modificaciones.

Las operaciones masivas de transición de flujo de trabajo permi-ten, por ejemplo, resolver un conjunto de búsquedas: si, por ejemplo,se efectúa una labor por la cual un grupo de incidencias resulta re-suelto o, por otro lado, se toma la decisión de no resolver un conjuntode incidencias, se puede efectuar la transición de flujo de trabajo co-rrespondiente (hacia el estado resuelto o no resuelto) con una únicaoperación.

Las operaciones masivas de eliminación ymigración permiten, porejemplo, de eliminar o migrar a otro proyecto, en una sola operación,un grupo de incidencias. Si se decide, por ejemplo, crear proyectosadicionales para distribuir a distintos equipos (y usuarios) las inci-dencias de un proyecto existente, esta funcionalidad permitirá a losjefes de proyecto de filtrar las incidencias con los criterios escogidosy moverlas a los proyectos que correspondan a dicho criterio con unasola operación.

De la misma forma, la operación masiva de modificación permiteaplicar la misma modificación a un grupo de incidencias. En el casoen que se sustituya un operador, por ejemplo, todas las incidenciasa él asociadas podrán asociarse al nuevo operador de forma masiva.En otra situación, por ejemplo, un proyecto podría decidir modificarlas incidencias asociadas a una versión determinada a otra versión:es el caso en que, por necesidades de calendario, se decide entregaruna release de un producto dejando abiertas algunas incidencias queno se pueden entregar a tiempo: con un filtrado será posible escogerlas incidencias no resueltas de la versión a entregar y asociarlas, enuna sola operación, a otra versión futura.

Para efectuar una operación masiva un usuario necesita tener elpermiso Bulk change. El permiso Bulk change es un permiso global deJIRA (§??) el administrador podrá otorgarlo a los grupos de usuarios Atar a glo-

bal.permission.seleccionados. Debido a que los permisos de proyecto se comprobarándurante una operación masiva, el usuario que efectúe una operaciónmasiva necesitará también el permiso “correspondiente” a la opera-

133


ción efectuada (como detallado en las secciones anteriores): en el casode una operación masiva de migración, por ejemplo, el usuario debe-rá tener el permiso global Bulk move y el permiso de proyecto Moveissues.

5.17.1 Inhabilitar las notificaciones durante una opera-ción masiva

Durante una operación masiva, el usuario que tenga el permiso deadministrador o administrador de proyecto en todos los proyectos alos cuales pertenecen las incidencias modificadas podrá seleccionar laopción Send mail for this update (Figura 5.60): de esta forma lasoperaciones que se ejecuten no enviarán correos de notificación a losusuarios suscritos.

Figura 5.60: Inhabilitar las notificaciones durante una operación masiva

Es aconsejable inhabilitar el envío de notificaciones en las situa-ciones en las cuales dicha notificación no sea “informativa”: si, porejemplo, se están migrando incidencias a un nuevo proyecto es proba-blemente innecesario enviar los correspondientes correos de notifica-ción a los usuarios13 ya que, verosímilmente, los usuarios estarán alcorriente de la migración.

5.17.2 Efectuar una operación masiva

Para efectuar una operación masiva es necesario efectuar las siguientesoperaciones:

(i) Efectuar una búsqueda en el Navegador de incidencias pare re-cuperar el grupo de incidencia sobre las cuales efectuar la ope-ración masiva.

(ii) Seleccionar la operación Bulk change en el menú Tools. Estaoperación estará disponible exclusivamente a los usuarios quetengan los permisos requeridos (§5.17). En dicha opción, si el

13El número de correos recibidos por usuario sería igual al número de inciden-cias modificadas

134


Figura 5.61: Operación Bulk change en el menú Tools

navegador de incidencias devuelve más de una página de resul-tados (Figura 5.61 izquierda), seleccionar si la operación masivadebería efectuarse sobre las incidencias en la página de resul-tados corriente o en todas las incidencias recuperadas. Si labúsqueda devuelve más de 1000 resultados, solo se podrán se-leccionar las primeras 1000 incidencias devueltas (Figura 5.61derecha).

(iii) En la pantalla siguiente, la pantalla de selección de incidencias,el usuario podrá escoger las incidencias sobre las cuales efectuarla operación masiva (Figura 5.62). Si el filtro utilizado no es lo

Figura 5.62: Selección de las incidencias sobre las cuales efectuar laoperación masiva

suficientemente “fino”, el usuario podrá escoger las incidenciasuna por una seleccionando el check-box a la izquierda de cadaincidencia. Si el usuario desea seleccionar todas las incidencias,podrá hacerlo utlizando el check-box en la cabecera de la tablade resultados.

(iv) En la pantalla siguiente elegir el tipo de operación masiva a

135


efectuar (Figura 5.63).

Figura 5.63: Selección del tipo de operación masiva

Las demás operaciones a efectuar dependerán del tipo de opera-ción masiva escogido, tal y como se detalla en las siguientes secciones.

5.17.3 Operación masiva de eliminación

Si la operación masiva seleccionada en §5.17.2 es una operación deeliminación, los últimos pasos del asistente serán decidir si enviarun correo de notificación (§5.17.1) y la confirmación de la operación(Figura 5.64). Después de la confirmación, JIRA eliminará todas las

Figura 5.64: Confirmación de una eliminación masiva

incidencias seleccionadas.

136


5.17.4 Operación masiva de migración

Si la operación masiva seleccionada en §5.17.2 es una operación demigración, los siguientes pasos del asistente serán similares a los pasosdetallados en 5.16, a los cuales se hace referencia, y con las diferenciasdetalladas a continuación.

La operación masiva de migración, como detallado en 5.16, sedivide en las siguientes sub-operaciones:

(i) Selección de incidencias.(ii) Selección de proyecto de destino y de tipo de incidencia para

incidencias de primer nivel y sub-tareas.(iii) Selección de estado de destino para estados que no existan en

los flujos de trabajo de los tipos de incidencias seleccionados enel proyecto de destino.

(iv) Selección de valores para campos obligatorios y campos inváli-dos.

(v) Confirmación de la operación.

La selección de incidencias (i) a mover durante una operaciónmasiva tiene que tener en cuenta de la relación padre-hijo entre inci-dencias de primer nivel y sub-tareas. Por esta razón, si se seleccionauna incidencias de primer nivel y algunas de sus sub-tareas duranteuna operación masiva de migración y se opta para efectuar una mi-gración de proyecto, las sub-tareas se moverán siempre en el proyectoespecificado para la incidencia padre y la única transformación que sepropondrá al usuario será la elección de un tipo de incidencia para lassub-tareas. JIRA avisará el usuario proponiendo una alerta parecidaa la ilustrada en Figura 5.65.

Figura 5.65: Aviso de exclusión de sub-tareas durante una migraciónmasiva

El primer paso del asistente de migración masiva es la seleccióndel proyecto de destino y del tipo de incidencia final (ii) para cadagrupo de incidencias que compartan los valores (proyecto de origen,tipo de incidencia) como ilustrado en Figura 5.66: para cada uno de

137


Figura 5.66: Selección de proyecto y tipo de incidencia de destino enuna migración masiva

estos grupos JIRA pedirá al usuario de escoger las nuevas “coordena-das”. Como en el caso de la operación de migración de una inciden-cia (§5.16), la operación de migración masiva puede utilizarse para“mover” incidencias dentro del mismo proyecto y efectuar un cambiode tipo de incidencia. La transformación de tipo de incidencia soloaplicará a las incidencias de primer nivel y las sub-tareas serán ex-cluidas automáticamente durante el proceso de transformación. JIRAtambién permite escoger un “destino” común para todos los gruposutilizando el control Use the above project and issue type pair for allother combinations que puede verse en Figura 5.66.

En el caso en que se esté moviendo un grupo de incidencias consub-tareas a otro proyecto, el asistente de migración podrá solicitar alusuario de escoger el tipo de sub-tarea de destino para las sub-tareasque serán migradas automáticamente con las incidencias de primernivel (Figura 5.67).

Figura 5.67: Selección de tipo de sub-tarea de destino en una migraciónmasiva

El siguiente paso, (iii), es la elección del estado de destino. Como

138


explicado en 5.16, JIRA solicitará al usuario de elegir el nuevo estadopara las incidencias que tengan un estado que no exista en el flujo detrabajo asociado al tipo de incidencia de destino en el contexto delproyecto de destino. Si los estados de todas las incidencias existen enel proyecto de destino, JIRA no propondrá al usuario está ventanadel asistente de migración.

Sucesivamente, JIRA propondrá al usuario de asignar un valor alos campos cuyo valor no sea válido de acuerdo a la configuración decampos para el tipo de incidencia de destino escogido (Figura 5.68).Para cumplir con los requerimientos de las configuraciones de campos

Figura 5.68: Actualización de campos de una incidencia en unamigración masiva

que aplican después de la migración, el usuario deberá actualizar loscampos inválidos con un nuevo valor y rellenar los campos obliga-torios que no tengan un valor asociado. Los valores escogidos seránutilizados para toda incidencia en el grupo de incidencias que se estámigrando de forma masiva. Para los siguientes tipos de campos, JI-RA proporcionará un menú desplegable con el cual el usuario podráescoger uno de los posibles valores válidos para el campo en cuestión:

(i) Componente.(ii) Versión afectada.(iii) Versión de resolución. check names

(iv) Campos personalizados de tipo Version-picker.

Es importante subrayar que, en los campos de tipo versión, será po-sible escoger exclusivamente versiones que todavía no se hayan ar-chivado. En el caso se necesitase utilizar estos valores será necesario add index

des-archivar la versión requerida, efectuar la migración masiva de in-cidencias y volver a archivar la versión.

139


Como ejemplo, en Figura 5.68 pueden verse los menús desplegablesproporcionados al usuarios para actualizar los valores de los camposVersión de resolución y Componentes.

En algunos casos, para el mismo campo, algunas incidencias ten-drán un valor válido y otras tendrán un valor inválido. El caso másfrecuente se da cuando un campo de una incidencia es opcional enla configuración de salida y obligatorio en la configuración de destinoya que podrán existir incidencias que tengan este campo vacío e inci-dencias con este campo valorizado. En estos casos, el usuario podrádecidir si actualizar todas las incidencias con el nuevo valor o man-tener el valor antiguo en las incidencias que lo tengan válido: paramantener los valores antiguos válidos para un campo es necesario se-leccionar el check-box Retain que aparece en la última columna en laventana de actualización de campos de Figura 5.68. Este campo es-tará inhabilitado por los campos de tipo (i)-(iv) ya que estos camposrequieren una relación explícita.

Después de haber completado el asistente de migración, JIRA pro-porcionará una ventana de confirmación en la que se resumen todaslas “transformaciones” que se efectuarán durante la migración de lasincidencias. Por cada grupo de incidencias con el mismo (proyecto,tipo de incidencia), JIRA detallará la siguiente información (cuandoaplique):

(i) Issue targets: proyecto y tipo de incidencia de destino.(ii) Workflow: flujo de trabajo de destino y nuevo estado final de

destino.(iii) Updated fields: nuevos valores para los campos actualizados.(iv) Removed fields: campos eliminados porque no válidos en la con-

figuración de campos de destino.

En Figura 5.69 puede verse una ventana de confirmación de ejem-plo donde se pueden apreciar las secciones (i), (iii) para las incidenciasa mover al tipo Bug y Sub-task del proyecto CC.

Después de haber confirmado la operación JIRA migrará todas lasincidencias seleccionadas efectuando las transformaciones especifica-das en el asistente de migración.

5.17.5 Operación masiva de modificación

La operación de modificación masiva permite modificar un conjuntode campos de un grupo de incidencias a la vez. Esta operación es

140


Figura 5.69: Ventana de confirmación de una migración masiva

141


útil en muchos casos de usos en los cuales el mismo campo necesiteuna actualización en muchas incidencias a la vez: cambio de usuarioasignado a una incidencia, cambio de un campo de tipo versión deuna incidencia, cambio de componentes, etc. Los campos que puedenactualizarse durante una operación masiva de este tipo pueden verseen Tabla 5.3.

Campos actualizables en una modificación masivaCampo CondiciónVersión afectada Proyecto con versiones.

Permiso Edit Issue.Campo visible en toda configuración asociadaal campo.

Usuario asignado Permiso Assign issue.Campo visible en toda configuración asociadaal campo.

Comentario Permiso Comment issue.Campo visible en toda configuración asociadaal campo.

Componentes Proyecto con componentes.Campo visible en toda configuración asociadaal campo.Permiso Edit issue.

Fecha límite Campo visible en toda configuración asociadaal campo.Permiso Edit issue.Permiso Schedule issue.

Versión de resolución Proyecto con versiones.Campo visible en toda configuración asociadaal campo.Permiso Edit issue.

Tipo de incidencia Permiso Edit issue.Prioridad Campo visible en toda configuración asociada

al campo.Permiso Edit issue.

Reporter Campo visible en toda configuración asociadaal campo.Permiso Edit issue.Permiso Modify reporter .

Continúa en la siguiente página

142


Campos actualizables en una modificación masivaCampo CondiciónNivel de seguridad Campo visible en toda configuración asociada

al campo.Todos los proyectos con el mismo esquema deseguridad de incidencias.

Campo personalizado Campo personalizado existe oTodas las incidencias son del mismo tipo conun campo personalizado oTodas las incidencias son del mismo proyectocon un campo personalizado de proyecto.

Tabla 5.3: Campos estándar de una incidencia

Un requerimiento adicional que es necesario cumplir si se estánmodificando incidencias cerradas será que el flujo de trabajo de lasincidencias que se desea modificar permita la modificación de inci-dencias cerradas.

Los siguientes campos no podrán modificarse con una operaciónmasiva:

(i) Ficheros adjuntos.(ii) Título.(iii) Descripción.(iv) Entorno.(v) Proyecto14.(vi) Resolución15. add reference

to bulk.work-flow.transition

Después de haber seleccionado las incidencias para una operaciónde modificación masiva, como explicado en §5.17.2, las operaciones arealizar en el asistente de migración son las siguientes:

(i) Selección de los campos a modificar y modificación de su valor.(ii) Revisión de los cambios y confirmación de la operación.

14Un grupo de incidencias pueden moverse de un proyecto a otro con unaoperación masiva de migración como detallado en §5.17.4.

15Puede efectuarse una transición de flujo de trabajo para un grupo de inciden-cias con una operación masiva de transición de flujo de trabajo como detalladoen §??

143


La selección de campos a modificar (i) se efectúa en la ventana demodificación de campos del asistente de migración ilustrada en Figura5.70. En esta ventana JIRA propondrá la usuario la lista de camposque se pueden modificar en el grupo de incidencias seleccionadas. Elusuario puede seleccionar los campos a modificar utilizando el check-box en la columna izquierda y escoger el nuevo valor utilizando loscontroles de edición en la columna derecha. Dependiendo del tipo decampo escogido JIRA proporcionará el editor correspondiente. En laventana de Figura 5.70, por ejemplo, puede verse un menú desplegablepara escoger el nivel de seguridad de las incidencias, un campo detexto libre para el campo Comentario y un campo de selección deusuarios para el campo Reporter. Para las operaciones masivas demodificación puede utilizarse el control descrito en §5.17.1 y visibleen figura para decidir si enviar una notificación de modificación a losusuarios.

Después de haber modificado todos los campos que se desean mo-dificar y pulsado el botón Next JIRA llevará el usuario a la ventanade confirmación donde puede verse un resumen de las modificacionesque se efectuarán. En Figura 5.71 puede verse un ejemplo de venta-na de modificación masiva en la cual se detalla la actualización delcampo Nivel de seguridad de las incidencias al valor Silver.

Pulsar el botón Confirm se confirmará la operación y JIRA apli-cará las modificaciones elegidas a todas las incidencias seleccionadas.

5.18 Registro histórico de cambios de una incidencia

Muchas de las operaciones efectuadas por los usuarios de JIRA segraban en el registro histórico de cambios. Algunas de las operacionesque generan una entrada en el registro histórico de cambios de unaincidencias son:

(i) Modificación de un campo.(ii) Subida de un fichero adjunto.(iii) Creación de un enlace entre incidencias.(iv) Eliminación de un comentario.(v) Eliminación de un registro de trabajo.(vi) Eliminación de un enlace entre incidencias.

Para cada uno de los eventos que han desencadenado la grabaciónde un registro de cambios JIRA almacena la siguiente información:

(i) El usuario que ha realizado el cambio.

144

5.18. Registro histórico de cambios de una incidencia

Figura 5.70: Ventana de modificación de campos en una operación demodificación masiva

145


Figura 5.71: Ventana de modificación de campos en una operación demodificación masiva

(ii) La hora en la que se ha realizado el cambio.(iii) Si el cambio es la modificación de un campo, los valores del

campo antes y después de la modificación.

El registro de cambios puede consultarse en la pestaña History delpanel Activity en la ventana de detalle de la incidencia cuyo registro sedesea consultar. El registro no se pueden manipular y es informaciónde sola lectura. En Figura 5.72 se ilustra una sección del registro decambios de una incidencia de ejemplo.


146

5.19. Integración de JIRA con otras aplicaciones

5.19 Integración de JIRA con otras aplicaciones

Uno de los objetivos de JIRA es convertirse en el “centro de gravedad”de las actividades que orbitan alrededor de las actividades del procesode desarrollo y de mantenimiento. Por esta razón, la plataforma ofrecemúltiples herramientas que pueden utilizarse a la hora de efectuaractividades tales como a) la integración de aplicaciones externas, b) laextensión de la plataforma, c) la utilización de la plataforma comofuente de datos.

En el caso se estén utilizando otros productos de Atlassian, sinembargo, la integración entre ellos es garantizada out-of-the-box y elmecanismo se conoce por el nombre de application links16. Un en-lace entre aplicaciones, establecido por el administrador de sistemas,establece una relación de confianza entre las dos aplicaciones relacio-nadas entre sí, lo cual permite a cada una de ellas de utilizar datosprocedente de la otra. JIRA, así como otros productos de Atlassian,integran en su interfaz de usuario muchas funcionalidades construidasencima de este mecanismo tales como las pestañas Source de la venta-na de detalle de una incidencia, que presenta información procedentede FishEye.

En las siguientes secciones se detallarán las funcionalidades opcio-nales de este tipo ofrecidas por JIRA en el ámbito de la gestión delas incidencias:

(i) Creación de enlaces entre incidencias en instancias de JIRA dis-tintas.

(ii) Creación de enlaces entre incidencias y páginas de Confluence.(iii) Creación de enlaces entre incidencias y recursos identificados

por URL.(iv) Obtención de información sobre revisiones de Crucible.(v) Obtención de información sobre changesets de FishEye.(vi) Obtención de información sobre builds de Bamboo.

5.19.1 Crear enlaces a incidencias en otras instancias deJIRA

Si el administrador de JIRA ha creado por lo menos un enlace aotra instancia de JIRA, los usuarios podrán establecer enlaces entreincidencias en diferentes sistemas.

16Llamados enlaces entre aplicaciones en la presente guía.

147


Para establecer un enlace con una incidencia en otra instancia deJIRA es necesario efectuar las siguientes operaciones:

(i) Utilizar el procedimiento detallado en §5.11 para acceder a laventana de creación de enlace entre incidencias.

(ii) Seleccionar el botón17 Remote JIRA issue en la ventana de crea-ción de enlaces ente incidencias.

(iii) Opcionalmente18, efectuar el procedimiento de login en la ins-tancia remota de JIRA hacía la cual se desea establecer un en-lace entre incidencias.

(iv) Si el administrador ha configurado múltiples enlaces de aplica-ción, será necesario seleccionar la instancia de JIRA remota quese desea utilizar en el menú desplegable Server.

(v) Seleccionar el tipo de enlace a establecer en el menú desplegableThis issue.

(vi) Introducir el identificador de la incidencia que se desea enla-zar19.

(vii) Seleccionar el check box Create reciprocal link si se desea crearel enlace inverso en la instancia remota de JIRA.

(viii) Utilizar los demás pasos del procedimiento detallado en §5.11para terminar la configuración del enlace.

Es importante tener en cuenta que, durante la creación de unenlace entre incidencias en distintos sistemas, cada instancia de JIRAtendrá potencialmente dos conjuntos de permisos distintos para elusuario que está efectuando la operación. Es posible, por lo tanto, quela operación de creación de enlace pueda no terminar con éxito debidoa una limitación de permisos del usuario en cuestión. Los enlacesentre aplicaciones, además, también tienen una dirección: es posiblepor lo tanto, que no se pueda crear el enlace inverso en determinadascircunstancias, de acuerdo a como el administrador de JIRA hayaconfigurado dicho enlace. En todo caso, el usuario será avisado delproblema con un mensaje de error coherente.

17Dicho control solo estará disponible si el administrador de JIRA ha estable-cido por lo menos un enlace con una instancia remota de JIRA.

18Este paso será necesario solo si el administrador de JIRA ha configurado elenlace entre las aplicaciones con autenticación de tipo OAuth.

19Durante la creación de enlaces entre incidencias en distintas instancias deJIRA el campo no soporta el completamento automático de los identificadores.Es necesario, por lo tanto, conocer exactamente el identificador de la incidencia aenlazar.

148


5.19.2 Enlaces a páginas de Confluence

Como explicado en §5.19.1, JIRA puede integrarse con otros produc-tos de Atlassian y actuar como hub, agregando y manejando informa-ción procedente de distintas fuentes. Confluence, el enterprise wiki deAtlassian, se utiliza a menudo para documentar un producto, inclusopara detallar de forma más extensa la información relacionada conuna incidencia. Es deseable, por lo tanto, que pueda enlazarse unaincidencia con una página de Confluence (y vice versa). Esta funcio-nalidad estará disponible solo si el administrador ha establecido unenlace de aplicaciones entre JIRA y por lo menos una instancia deConfluence.

Para enlazar una incidencia a una página de Confluence es nece-sario efectuar las siguientes operaciones:


(ii) Seleccionar el botón20 Confluence Page en la ventana de crea-ción de enlaces ente incidencias.

(iii) Si el administrador ha configurado múltiples enlaces de aplica-ción a instancias de Confluence, será necesario seleccionar lainstancia de Confluence remota que se desea utilizar en el menúdesplegable Server.

(iv) Especificar la página de Confluence que se desea enlazar comoexplicado a continuación.

(v) Utilizar los demás pasos del procedimiento detallado en §5.11para terminar la configuración del enlace.

Para especificar la página de Confluence que se desea enlazar, esnecesario utilizar uno de los siguientes métodos:

(i) Introducir el URL21 de la página a enlazar en el campo PageURL.

(ii) Buscar la página a enlazar utilizando la ventana de búsquedaque aparece pulsando el enlace Search for a page. Los camposSearch pueden utilizarse para filtrar los resultados de búsquedautilizando los criterios especificados.

20Dicho control solo estará disponible si el administrador de JIRA ha estable-cido por lo menos un enlace con una instancia Confluence.

21El URL tiene que ser calificado: http://conf-server/display/etc/etc.

149


Es importante tener en cuenta que, durante la creación de unenlace entre incidencias en distintos sistemas, la instancia de JIRA yla instancia de Confluence tendrán potencialmente dos conjuntos depermisos distintos para el usuario que está efectuando la operación.Es posible, por lo tanto, que la operación de creación de enlace puedano terminar con éxito debido a una limitación de permisos del usuarioen cuestión. En todo caso, el usuario será avisado del problema conun mensaje de error coherente.

5.19.3 Enlaces a páginas web

El último tipo de contenido que JIRA permite enlazar a una inciden-cia es un contenido genérico identificado simplemente por un URL.De esta forma los usuarios podrán enlazar una incidencia a cualquiertipo de recurso accesible utilizando un URL, tales como a) páginasweb relacionadas con la incidencia en cuestión, b) archivos de confi-guración, c) documentación de APIs.

Para enlazar una incidencia a un recurso identificado por una URLes necesario efectuar las siguientes operaciones:


(ii) Seleccionar el botón Web link.(iii) Introducir el URL del recurso a enlazar.(iv) Introducir la descripción del enlace establecido en el campo Link

text.(v) Utilizar los demás pasos del procedimiento detallado en §5.11

para terminar la configuración del enlace.

5.19.4 Revisiones de Crucible

En la ventana de detalle de una incidencias es posible obtener infor-mación relativa a sus revisiones de Crucible y, por lo tanto:

(i) Examinar el mensaje de commit.(ii) Examinar la lista de files en el commit.(iii) Examinar las diferencias y la historia de cada file.(iv) Acceder a cada file.(v) Crear una revisión de Crucible.(vi) Ver el estado de una revisión de Crucible.

150


Para ver las revisiones de una incidencia es necesario efectuar lassiguientes operaciones:

(i) Acceder a la ventana de detalle de la incidencia en cuestión.(ii) Seleccionar la pestaña Reviews en el panel Activity.

En la pestaña Reviews aparecerá la información relativa a las revi-siones de Crucible de la incidencia seleccionada, como ilustrado enFigura 5.73.

Figura 5.73: Incidencia — Revisión de Crucible

5.19.5 Changesets de FishEye

En la ventana de detalle de la incidencia es posible obtener informa-ción relativa a los changesets de FishEye, en el caso en que se estéutilizando un sistema de versionado de código fuente visible a FishEyey, por lo tanto:

(i) Examinar el mensaje de commit.(ii) Examinar la lista de files en el commit.(iii) Examinar las diferencias y la historia de cada file.(iv) Acceder a cada file.(v) Crear una revisión de Crucible.(vi) Ver el estado de una revisión de Crucible.

Las incidencias se relacionan con las incidencias buscando en elmensaje de commit el identificador de la incidencia. La expresiónregular con la cual se efectúa esta búsqueda es la siguiente:

151


(^|[^a-zA-Z0-9-])

Para que se relacionen correctamente incidencias e commits es nece-sario, por lo tanto, asegurarse que:

(i) El mensaje de commit comience con el código de la incidencia.(ii) Si no es así, que el carácter que precede y el carácter que sigue el

código de la incidencia no sea una letra (mayúscula o minúscula)entre a y z, un número entre 0 y 9 o un guión (-).

Para ver los changesets de FisyEye de una incidencia es necesarioefectuar las siguientes operaciones:

(i) Acceder a la ventana de detalle de la incidencia en cuestión.(ii) Seleccionar la pestaña Source en el panel Activity.

En la pestaña Source aparecerá la información relativa a los chan-gesets de FishEye de la incidencia seleccionada, como ilustrado enFigura 5.74.

Figura 5.74: Incidencia — Changesets de FishEye

152

5.20. Observar y votar una incidencia

5.19.6 Builds de Bamboo

En la ventana de detalle de la incidencia es posible obtener infor-mación relativa a los builds de Bamboo, en el caso en que se estéutilizando el sistema de construcción e integración continua Bambooy, por lo tanto:

(i) Examinar el nombre del build y del plano de build.(ii) Examinar la fecha de última ejecución del plan de build.(iii) Examinar información relativa al build, tal como builds relacio-

nados, estado del build y duración del build.(iv) Examinar las etiquetas del build.(v) Examinar los enlaces a artefactos del build.

Para ver los builds de Bamboo de una incidencia es necesarioefectuar las siguientes operaciones:

(i) Acceder a la ventana de detalle de la incidencia en cuestión.(ii) Seleccionar la pestaña Builds en el panel Activity.

En la pestaña Builds aparecerá la información relativa a los buidlsde Bamboo de la incidencia seleccionada, como ilustrado en Figura5.75.

5.20 Observar y votar una incidencia

Uno de los mecanismos proporcionado por JIRA para facilitar la co-municación y la colaboración entre usuarios es el mecanismo de losvotos y de los watch (vigilancia).

Los votos permiten a los usuarios dar una “preferencia” a unaincidencia para comunicar a los operadores su “interés” a que la inci-dencia se solucione y los operadores, por otra parte, pueden utilizaresta información para priorizar la resolución de las incidencias.

Los watch permiten a los usuarios suscribirse a las notificacionesde actualización de la incidencia. Cada vez que la incidencia seamodificada, siempre el proyecto esté configurado con un esquema denotificación, los usuarios recibirán los correos electrónicos generadospor los eventos de modificación de la incidencia “vigilada”.

El número de usuarios que han votado y que están vigilando unaincidencia puede verse en el panel People (Personas) en la ventana dedetalle de la incidencia, como ilustrado en Figura 5.76. La incidencia

153


Figura 5.75: Incidencia — Builds de Bamboo

Figura 5.76: Panel de Personas en la ventana de detalles de incidencias

154

5.20. Observar y votar una incidencia

ilustrada ha sido votada por un usuario y está siendo vigilada por unusuario.

Cuando se está visualizando una incidencia que no se ha votado,el enlace que indica el número de votos tendrá la etiqueta Vote; posi-cionando el ratón encima de este enlace un icono verde con el símbolo"+" se solapará al icono con el pulgar levantado y pulsando el enlaceel usuario podrá votar instantaneamente a la incidencia seleccionada.Por otra parte, cuando se está visualizando una incidencia qua ya seha votado, el enlace que indice el número de votos tendrá la etiquetaVoted; posicionando el ratón encima de este enlace un icono rojo conel símbolo "−" se solapará al icono con el pulgar levantado y pulsan-do el enlace el usuario podrá eliminar instantaneamente el voto a laincidencia seleccionada. El mismo mecanismo se utiliza para obser-var o dejar de observar a una incidencia: en este caso se seleccionaráel enlace Watching para comenzar o dejar de observar la incidenciaseleccionada. En Figura 5.77, en la imagen a la izquierda puede verseel enlace Vote seleccionado en una incidencia que no se ha votado yen la imagen a la derecha puede verse el enlace Voted seleccionado enuna incidencia que se ha votado.

Figura 5.77: Panel de Personas en la ventana de detalles de incidencias

Un usuario con el permiso necesario para ver la lista de usuariosque han votado y/o vigilado una incidencia, el permiso View votersand watchers, puede utilizar el enlace que indica el número de usuariosque han votado o observado una incidencia para acceder a la ventanade gestión de Voters (votantes) y Watchers (observadores), ilustradaen Figura 5.78. En esta ventana de gestión el usuario podrá ver lalista de usuarios que han expresado su voto o que se han suscrito alas notificaciones.

Un usuario que tenga el permiso Manage watcher list podrá uti-lizar la ventana de gestión de Watchers para modificar la lista deusuarios que están observando la incidencia, añadiendo o eliminando

155


Figura 5.78: Ventana de gestión de Watchers de una incidencia

usuarios de la lista de suscritos.

156

6Buscar y filtrar incidencias

JIRA proporciona herramientas para la búsqueda y el filtrado de in-cidencias poderosas y fácil de utilizar. Las dos herramientas de bús-queda proporcionadas por la plataforma son la búsqueda rápida y elnavegador de incidencias. La búsqueda rápida permite efectuar bús-quedas rápidas tecleando el criterio de búsqueda en un control que seencuentra en el rincón superior derecho de la barra de herramientas deJIRA (Figura 6.19). El navegador de incidencias es una herramientaorientada a la creación de búsquedas complejas a través de una inter-faz gráfica (interfaz de búsqueda simple) u, opcionalmente, utilizandoel lenguaje de query de JIRA (interfaz de búsqueda avanzada).

La interfaz web de la búsqueda simple del Navegador de inciden-cias permite a un usuario utilizar criterios de búsqueda que tenganen cuenta de los campos estándar proporcionados por JIRA y de loscampos personalizados creado por el usuario.

El único límite del navegador de incidencias, en cuanto a construc-ción de criterios de búsqueda, es el hecho que cuando se construyencriterios “múltiples” utilizando los distintos controles de la interfazdel navegador de incidencias, la query resultante es la proposición ló-gica que concatena todos los criterios con el operador ∧ (and). Si,por ejemplo, se selecciona para el estado s el valor Open (Abierta) ypara la resolución r el valor Won’t fix (No se resolverá) en la interfazdel navegador, la query resultante será

(s = Open) ∧ (r = Won′t fix) (6.1)

que, probablemente, no es la query deseada y devolverá casi siempreningún registro. Si el usuario desease ejecutar la query

(s = Open) ∨ (r = Won′t fix) (6.2)

157

6. Buscar y filtrar incidencias

no podrá utilizar la interfaz de búsqueda simple y deberá recurrir ala interfaz de búsqueda avanzada (§7), en la cual el usuario puedeconstruir queries de cualquier complejidad utilizando el lenguaje dequery de JIRA. No obstante, en la mayoría de los casos se podráutilizar la interfaz de la búsqueda simple para construir fácilmentelos varios criterios que componen la búsqueda y utilizar la interfaz debúsqueda avanzada para cambiar solo los operadores lógicos que losrelacionan, como explicado en §6.1.7.

Las queries creadas por los usuarios podrán grabarse en filtros(§??) que podrán utilizarse para repetir la búsqueda y como fuentede datos para otros componentes como gadgets del cuadro de mandos,reportes y otros plugins.

Para acceder al navegador de incidencias es necesario pulsar el en-lace Issues de la barra de herramientas de JIRA. Por defecto, el na-vegador de incidencias se abre en la última búsqueda o filtro utilizadoen la sesión de usuario corriente: para efectuar una nueva búsquedaes necesario seleccionar la pestaña New en la barra a la izquierda dela página.

6.1 Búsquedas simples

El navegador de incidencias permite definir criterios de búsqueda deforma sencilla utilizando una intuitiva interfaz gráfica. La parte iz-quierda de la ventana ofrece un conjunto de controles que, depen-diendo del tipo de campos asociados, permiten escoger o introducirlos valores con los cuales se desea filtrar las incidencias. Los controlesestán organizados en paneles que dividen los controles en “catego-rias” formadas por controles “afines”. Los paneles disponibles en elnavegador de incidencias son los siguientes:

(i) Panel principal de búsqueda.(ii) Components/Versions.(iii) Issue attributes.(iv) Dates and times.(v) Work ratio.(vi) Custom fields.

Como regla general, JIRA construirá una query construyendo unaproposición que relaciona los criterios generados por cada panel conel operador lógico ∧ (and). Si el usuario rellena campos de búsquedaen un conjunto de paneles, llamando {pi, i ∈ [0, n]} el conjunto de

158

6.1. Búsquedas simples

“fragmentos” de query generados por cada panel, la query resultanteejecutada por JIRA será:

p0 ∧ p1 ∧ · · · ∧ pn (6.3)

En general, múltiples controles dentro del mismo panel también ge-nerarán fragmentos relacionados con el operador ∧ aunque existenexcepciones que se detallarán más adelante en la descripción de cadapanel. En el caso de los controles que permiten selección múltiplede los elementos de una lista, como el control Status, JIRA generaráun fragmento de query de tipo in: si {si, i ∈ [0, n]} son los estadosseleccionados, JIRA creará el fragmento de query correspondiente alcriterio:

s ∈ {si, i ∈ [0, n]} (6.4)Este criterio, conceptualmente, equivale a la siguiente proposición:

(s = s0) ∨ (s = s1) ∨ · · · ∨ (s = sn) (6.5)

6.1.1 Panel principal de búsqueda

El panel principal de búsqueda (i), ilustrado en Figura 6.1 (izquier-da), ofrece como funcionalidad el filtrado de incidencias por proyecto,por tipo de incidencia y por palabra clave en algunos campos están-dar detallados a continuación. En el control Query el usuario puedeintroducir texto libre que JIRA buscará en los campos seleccionados através de los controles de tipo check-box que están debajo del controlQuery:

(i) Título.(ii) Descripción.(iii) Comentarios.(iv) Entornos.

La selección de múltiples campos de búsqueda {ci, i ∈ [0, n]} durantela búsqueda de una cadena x se traduce en una query del tipo:

x ∈ {ci, i ∈ [0, n]} = (c0 = x) ∨ (c1 = x) ∨ · · · ∨ (cn = x) (6.6)

y, por lo tanto, JIRA devolverá las incidencias en las cuales almenosuno de los campos seleccionados satisfaga el filtro de búsqueda.

Los controles Project y Issue type permiten seleccionar el proyec-to y el tipo de incidencias que se desean filtrar. Estos dos com-ponentes permiten efectuar selecciones múltiples (que indicaremos

159


Figura 6.1: Paneles de búsqueda del navegador de incidencias — 1

{pi, i ∈ [0, n]} y {ti, i ∈ [0,m]}) entre los valores propuestos y loscriterios generados serán respectivamente

p ∈ {pi, i ∈ [0, n]} = (p = p0) ∨ · · · ∨ (p = pn) (6.7)

yt ∈ {ti, i ∈ [0,m]} = (t = t0) ∨ · · · ∨ (t = tm) (6.8)

Esto significa que JIRA devolverá las incidencias que pertenezcan auno de los proyectos seleccionados1 y cuyo tipo sea uno de los tiposescogidos2.

1Debido a que una incidencia solo puede pertenecer a un proyecto, no tendríasentido una búsqueda que ha la intersección de múltiples proyectos.

2Una incidencia sólo puede ser de un tipo.

160


Cuando se utilizan los tres controles de este panel a la vez, loscriterios generados por cada control se juntarán en una preposiciónutilizando el operador lógico ∧ (and):

x ∈ {ci, i ∈ [0, n]} ∧ p ∈ {pi, i ∈ [0, k]} ∧ t ∈ {ti, i ∈ [0,m]} =((c0 = x) ∨ · · · ∨ (cn = x)) ∧ ((p = p0) ∨ · · · ∨ (p = pk))

∧ ((t = t0) ∨ · · · ∨ (t = tm)) (6.9)

Esto es, JIRA devolverá las incidencias que cumplan los criterios debúsqueda establecidos en cada control del panel a la vez.

Es importante subrayar que, dependiendo de la selección corrienteen los controles Project y Issue type, otros paneles del navegador debúsqueda podrían necesitar ser recargados para que los datos en elloscontenidos reflejen los datos relativos a los proyectos y a los tipos deincidencias seleccionados. JIRA informará el usuario que es necesariorecargar el navegador de búsqueda utilizando un mensaje parecido alilustrado en Figura 6.2. Pulsando el enlace Refresch search en el

Figura 6.2: Navegador de incidencias — Aviso de refresco

mensaje el navegador de incidencias actualizará sus paneles de bús-queda para reflejar los valores relativos a la nueva selección.

6.1.2 Panel de búsqueda por componentes y versiones

El panel de búsqueda Components/Versions (ii), ilustrado en Figura6.3 (izquierda), permite efectuar búsquedas por componentes y ver-siones. El panel proporciona un conjunto de controles, Fix for, Com-ponents y Affects versions, que permiten efectuar búsquedas filtrandopor lo campos asociados a los controles. Los controles mencionados

161


Figura 6.3: Paneles de búsqueda del navegador de incidencias — 2

aparecerán cuando se esté efectuando una búsqueda en proyectos queposean información asociada a los campos en cuestión: si un proyec-to está asociado con un esquema de configuración de campos que noprevé la utilización de los campos de versión para ningún tipo de inci-dencias, los controles correspondientes no aparecerán en el navegadorde incidencias.

Los controles Fix for y Affects versions permiten filtrar las inci-dencias utilizando las versiones especificadas en la lista y los siguientesvalores:

(i) Any: Cualquier valor.(ii) No version: Incidencias que no especifiquen ningún valor para

este campo.(iii) Unreleased version: Incidencias cuyo campo especifique una ver-

sión que no haya sido entregada.

El control Components permiten filtrar las incidencias utilizandolos componentes especificados en la lista y los siguientes valores:

(i) Any: Cualquier valor.(ii) No components: Incidencias que no estén asociadas a ningún

componente.

Los controles en este panel son controles que permiten seleccionarmúltiples entradas de la lista de opciones propuestas: en este casotambién, el criterio de búsqueda generado será un criterio de tipo in

162


y JIRA devolverá las incidencias cuyo campo contenga uno de losvalores escogidos en la lista.

6.1.3 Panel de búsqueda por atributos de incidencia

El panel de búsqueda por atributos de incidencias (iii), ilustrado enFigura 6.1 (centro), contiene controles que permiten filtrar las inci-dencias utilizando los siguientes campos:

(i) Reporter : usuario que ha reportado la incidencia.(ii) Assignee: usuario asignado a la incidencia.(iii) Status: estado de la incidencia.(iv) Resolutions: resolución de la incidencia.(v) Priorities: prioridad de la incidencia.(vi) Labels: etiquetas de la incidencia.

Los campos Reporter y Assignee tienen un funcionamiento muysimilar y permiten filtrar las incidencias utilizando uno de los criteriosproporcionados en el menú desplegable del control (Figura 6.4):

(i) Any user : Cualquier usuario.(ii) No reporter/Unassigned: La incidencia no está asociada a nin-

gún reporter o no está asignada a ningún usuario.(iii) Current user : El usuario que está efectuando la búsqueda.(iv) Specify user : El usuario especificado.(v) Specify group: El grupo especificado.

Figura 6.4: Navegador de incidencias — Campos Reporter y Assignee

Si se selecciona la opción Specify user o Specify group, el usuario po-drá especificar el usuario o el grupo con el cual filtrar introduciéndoloen el campo de selección de usuario o grupo debajo del control, co-mo ilustrado en Figura 6.5. Los campos de selección de usuariosy grupos de JIRA son campos de textos que, según el usuario va

163


Figura 6.5: Navegador de incidencias — Campos Reporter y Assignee

tecleando el nombre de la entidad, van sugiriendo al operador los po-sibles nombres que satisfagan el texto insertado hasta el momento.Add section

to user pickerfields Si se prefiere, se puede escoger un usuario (o un grupo) utilizando

la ventana de selección de usuarios (o de grupos) a la cual se accedepulsando el control identificado con el icono “hombre” a la derechadel campo de selección de usuario.

Los controles Status, Resolutions y Priorities son controles conselección múltiple que recogen todos los estados, resoluciones y prio-ridades definidos en el conjunto de proyectos y tipos de incidenciaseleccionados. El criterio de búsqueda generado por estos controlesserá un criterio de tipo in y JIRA devolverá las incidencias cuyo cam-po contenga uno de los valores escogidos en la lista.

El control Labels es un campo de texto libre que permite filtrarlas incidencias especificando las etiquetas a buscar. Un método alter-nativo y más rápido para buscar las incidencias que compartan unaetiqueta con una incidencia que se está observando en la ventana dedetalle ha sido descrito en §5.14.

6.1.4 Panel de búsqueda por fechas

El panel de búsqueda por fechas (iv), ilustrado en Figura 6.1 (dere-cha), permite filtrar las incidencias utilizando un grupo de controlesasociados a los correspondientes campos de tipo fecha:

(i) Fecha de creación.(ii) Fecha de última actualización.(iii) Fecha límite de resolución.(iv) Fecha de resolución.

Los controles de este panel están divididos en cuatro grupos, unopor cada uno de los tipos de fecha, y en cada grupo se encuentra:

164


(i) Un control, llamado “. . . After”, que acepta una fecha absoluta.(ii) Un control, llamado “. . . Before”, que acepta una fecha absolu-

ta.(iii) Un control, llamado From, que acepta una fecha relativa.(iv) Un control, llamado To, que acepta una fecha relativa.

El principio de funcionamiento de cada grupo de controles es idén-tico al funcionamiento del grupo Fecha límite de resolución, cuyo fun-cionamiento se detalló en §5.12.1 y que se resume a continuación. Update §5.12.1

to reflect theexistence of thischapter

Los controles del tipo “. . . After” y “. . . Before” aceptan fechasabsolutas y pueden utilizarse para efectuar búsquedas por valores exac-tos; llamando t0 y t1 los valores introducidos por el usuario, xa elcampo “. . . After”, xb el campo “. . . Before” y x el valor del cam-po asociado al grupo de controles en cuestión, pueden realizarse lassiguientes búsquedas:

(i) Buscar las incidencias que satisfagan x = t0, poniendo:

xa = xb = t0 (6.10)

(ii) Buscar las incidencias que satisfagan x ≤ t0, poniendo:

xb = t0 (6.11)

(iii) Buscar las incidencias que satisfagan x ≥ t0, poniendo:

xa = t0 (6.12)

(iv) Buscar las incidencias que satisfagan t0 ≤ x ≤ t1, poniendo:{xa = t0

xb = t1

Los controles From y To permiten hacer búsquedas por intervalostemporales relativos a la fecha actual. Las búsquedas que se pue-den efectuar son las mismas detalladas en los elementos de la listaprecedente con la diferencia que los tiempos t0 y t1 se expresan concantidades relativas al instante en el que se efectúa la búsqueda. Elformato aceptado en los campos de tipo fecha relativa es ±xw yd whzm donde x, y, w y z son, respectivamente, el número de semanas,días, horas y minutos. El signo del campo indica si la cantidad de Add section

about therelative timeformat.

tiempo indicada es relativa a un instante en el futuro o en el pasado:

165


un campo con el tiempo positivo (con el signo +) indicará un instan-te en el futuro y un campo con el tiempo negativo (con el signo −)indicará un instante en el pasado.

En cada grupo de controles de tipo fecha podrán utilizarse unosasistentes para rellenar el valor de dichos campos, tanto para los cam-pos con fechas absolutas como para los campos con fechas relativas:los asistente se podrán abrir utilizando el control identificado con elicono “calendario” a la derecha del campo que se desea modificar.Los asistentes para campos de tipo fecha absoluta son controles detipo calendario que permiten introducir una fecha seleccionándola enun calendario (Figura 5.40). Los asistentes para campos de tipo fe-cha relativa son ventanas que ofrecen varias opciones intuitivas pararellenar los campos From y To utilizando opciones tales como:

(i) Fecha anterior al instante especificado.(ii) Fecha posterior al instante especificado.(iii) Fecha en el intervalo especificado.

En Figura 5.41 puede verse la ventana del asistente para el grupode controles Fecha límite de resolución y en Figura 6.6 la ventanapara el grupo de controles Fecha de creación. Los asistente de los

Figura 6.6: Formulario para la creación de un criterio de búsqueda porfecha de creación con intervalos temporales relativos.

166


demás grupos de controles son similares a los asistentes ilustrados yel principio de funcionamiento es idéntico al detallado en esta sección.

6.1.5 Panel de búsqueda por porcentaje de trabajo rea-lizado

El panel de búsqueda por porcentaje de trabajo realizado (v), ilustra-do en Figura 6.3 (derecha), permite filtrar las incidencias utilizandocomo criterio el porcentaje de trabajo realizado:

w = wrwt· 100 (6.13)

donde wr es el trabajo realizado y wt es el trabajo estimado total. Eneste panel pueden utilizarse dos controles, Min y Max, para realizarlas siguientes búsquedas:

(i) Búsqueda de incidencias con porcentaje de trabajo realizadow = w0, poniendo:

wmin = wmax = w (6.14)

(ii) Búsqueda de incidencias con porcentaje de trabajo realizadow ≤ w0, poniendo:

wmax = w (6.15)

(iii) Búsqueda de incidencias con porcentaje de trabajo realizadow ≥ w0, poniendo:

wmin = w (6.16)

(iv) Búsqueda de incidencias con porcentaje de trabajo realizadow0 ≤ w ≤ w1, poniendo: {

wmin = w0

wmax = w1

6.1.6 Panel de búsqueda por campos personalizados

El panel de búsqueda por campos personalizados (v), ilustrado enFigura 6.3 (derecha), permite filtrar las incidencias utilizando loscampos personalizados que el administrador haya configurado en elcontexto de un proyecto.

Los controles relativos a los campos personalizados aparecerán eneste panel solo después de haber seleccionado un contexto válido: un

167


proyecto, en el caso de campos personalizados de proyecto o un tipode incidencia, en el caso de campos personalizados de un tipo deincidencia.

El tipo de control que aparezca, así como su funcionamiento, de-penderá del tipo de campo personalizado que se haya escogido.add documenta-

tion about JI-RA field types

6.1.7 Modificar manualmente una query simple

Como explicado en §6 y succesivas, el navegador de incidencias esuna herramienta muy útil a la hora de construir búsquedas utilizan-do todos los criterios disponibles a través de una interfaz gráfica deusuario. De esta forma cualquier usuario, incluso los usuarios queno tengan ninguna familiaridad con los lenguajes de query, podránefectuar las búsquedas que necesiten.

Sin embargo, las consultas de tipo simple producidas por el na-vegador de incidencias están sujetas a algunas limitaciones (§6) y,en ciertas ocasiones, podría ser necesario deber utilizar una búsquedaavanzada. En las búsquedas avanzadas el usuario utilizará el lenguajede query de JIRA y, por lo tanto, no estará sujeto a las restriccionesimpuestas por el interfaz gráfico de búsqueda simple del navegadorde incidencias. Las búsquedas avanzadas se describirán en detalle en§7.

Aun así, sobre todo en casos simples (como la necesidad de cam-biar algún operador lógico), el usuario podrá beneficiarse del interfazgráfico de búsqueda simple para construir el “esqueleto” de la consultay pasar al interfaz gráfico de búsqueda avanzada para modificar ma-nualmente la query generada. Cuando se pasa al interfaz de búsquedaavanzada después de haber creado una consulta, JIRA recordará laconsulta ejecutada y poblará esta ventana con el texto de la queryen el lenguaje de query de JIRA. De esta forma, entonces, el usuariopodrá analizar la query generada y aportar las modificaciones nece-sarias reduciendo el tiempo necesario para construir la consulta y loserrores que puedan producirse a lo largo del proceso.

Ejemplo 6.1. Una búsqueda que no puede hacerse a través del in-terfaz de búsqueda simple es la siguiente: filtrar las incidencias quehan sido creadas en la última semana o cuya fecha de finalizaciónhaya pasado desde hace más de 15 días. Esta búsqueda contiene doscriterios:

(i) Cc = (fecha de creación ≤ 7 d)(ii) Cd = (fecha de finalización ≥ 15 d)

168


juntados con el operador lógico ∨ (or): Cc ∨ Cd. A pesar de nopoderse expresar la consulta Cc∨Cd con el interfaz gráfica, el usuariopodrá beneficiarse de la interfaz de búsqueda simple para crear loscriterios Cc y Cd utilizando los asistentes y juntarlos posteriormentecon el operador ∨ utilizando el lenguaje de query de JIRA. Comoexplicado en §6, los criterios generados por cada panel (o a vecesincluso entre controles del mismo panel) deben satisfacerse al mismotiempo, es decir, serán juntados con el operador lógico ∧ (and) y laquery resultante sería:

fecha de creación ≤ 7 d︸︷︷︸Cc

y︸︷︷︸∧

fecha de finalización ≥ 15 d︸︷︷︸Cd

(6.17)

La modificación que hay que aplicar a la query precedente para obte-ner la query que se necesita es simplemente el operador lógico ∨ queles relaciona:

fecha de creación ≤ 7 d︸︷︷︸Cc

o︸︷︷︸∨

fecha de finalización ≥ 15 d︸︷︷︸Cd

(6.18)

es decir, simplemente sustituir ∧ con ∨. Para modelar la query 6.17 elusuario pondrá entonces los datos siguientes en el interfaz de búsquedasimple: {

tc(from) = −7 dtd(to) = −15 d

(6.19)

como se ilustra en Figura 6.7. Para modificar la query y obtenerla query 6.18 el usuario podrá efectuar la búsqueda3 y pasar a lainterfaz de búsqueda avanzada pulsando el enlace correspondiente.En Figura 6.8 puede verse la query creada en los pasos precedentesexpresada en el lenguaje de query de JIRA. En el texto de la querypuede verse claramente el operador ∧ generado por el interfaz debúsqueda simple:

due ≤ −15 d︸︷︷︸Cd

and︸︷︷︸∧

created ≥ −7 d︸︷︷︸Cc

(6.20)

El usuario podrá modificar la query para obtener la consulta 6.18sustituyendo and con or, como ilustrado en Figura 6.9. El interfaz

3Es necesario efectuar la búsqueda para que JIRA “recuerde” la consulta y sepueda pasar a la interfaz de búsqueda avanzada sin perdida de datos.

169


Figura 6.7: Criterio de búsqueda de ejemplo.

Figura 6.8: Criterio de búsqueda de ejemplo en el interfaz de búsquedaavanzada.

170


Figura 6.9: Modificación del criterio de búsqueda de ejemplo en elinterfaz de búsqueda avanzada.

de búsqueda avanzado, como puede apreciarse en figura, ayuda eloperador en la tarea de creación de queries sugiriendo en un menúdesplegable las palabras claves y los campos estándar de JIRA.

Es importante subrayar que una query modificada manualmentepuede ser imposible de “expresarse” a través del interfaz gráfico debúsqueda simple y, por lo tanto, si se vuelve a esta interfaz despuésde haber modificado manualmente una query JIRA podrá informarel usuario de este problema con un mensaje parecido al ilustrado enFigura 6.10.

Figura 6.10: Modificación del criterio de búsqueda de ejemplo en elinterfaz de búsqueda avanzada.

En §7.9 se proporciona información adicional sobre las situacionesen las cuales no es posible regresar al interfaz de búsqueda simpledesde el interfaz de búsqueda avanzada.

171


6.2 El navegador de incidencias

El navegador de incidencias es la ventana en la que JIRA devuelve losresultados de las búsquedas efectuadas a través de filtros, búsquedasrápidas y búsquedas avanzadas. Una captura de pantalla de ejemplodel navegador de incidencias puede verse en Figura 6.11.

Figura 6.11: Navegador de incidencias.

La incidencia actualmente seleccionada será indicada con un trián-gulo negro (I) a la extrema izquierda de los registros cuyo color defondo, además, será distinto del color de los demás (Figura 6.11). Elusuario podrá utilizar los atajos de teclado (§§3.4—3.4.3) para moverla selección a otros registros: el usuario podrá por ejemplo utilizar latecla j para mover la selección hacia abajo, la tecla k para mover laselección hacia arriba y la tecla o para ir a la ventana de detalle dela incidencia seleccionada.

6.2.1 Crear un enlace permanente a una búsqueda

JIRA permite crear un permalink a la página de resultados de unabúsqueda: los resultados de la búsqueda corriente, por ejemplo, po-drán así ser compartidos con usuarios “externos” a través de un enlaceque podrá enviarse por correo o utilizarse en otras páginas web. Pa-ra crear un permalink a la búsqueda corriente es necesario utilizar

172

6.2. El navegador de incidencias

el control identificado con un icono parecido a ⊂⊃ y proceder comoexplicado en §??. Añadir sec-

ciones sobrepermalinks

6.2.2 Herramientas en el navegador de incidencias

En la ventana del navegador de incidencias, sin embargo, el usuariono puede solo examinar los resultados de la búsqueda o navegar ala ventana de detalle de la incidencia seleccionada: el usuario puedetambién efectuar operaciones sobre el conjunto de resultados o sobrecada una de las incidencias.

El usuario puede escoger las operaciones disponibles sobre cada in-cidencias seleccionando el menú Actions, parecido al menú de accionesde la ventana de detalle de incidencia e identificado con el icono deun “engranaje”, que aparece a la derecha de una incidencia cuando elusuario la selecciona con el ratón (Figura 6.12). En el menú Actionsel usuario podrá efectuar las operaciones detalladas en Tabla 6.1:es importante subrayar que las lista de operaciones disponibles en elmenú Actions se construye dinámicamente dependiendo de paráme-tros tales como los permisos del usuario, la habilitación de algunascaracterísticas de JIRA y los flujos de trabajos asociados a cada tipode incidencia.

El menú Views (Figura 6.13, derecha), identificado con el icono“ojo” en la esquina superior izquierda del navegador de incidencias,permite operar sobre el conjunto de resultados devueltos por la bús-queda. Las operaciones disponibles en este menú se han resumido enTabla 6.2.

El menú Tools del navegador de incidencias (Figura 6.13, izquier-da) permite efectuar operaciones masivas, como explicado en §5.17,y para configurar las columnas utilizadas en el navegador de inciden-cias4, como explicado en §??.

6.2.3 Ordenar los resultados

El navegador de incidencias permite ordenar los resultados de unabúsqueda por el valor de uno de los campos (las columnas) visualiza-dos5.

4Las columnas configuradas en el navegador de incidencias se utilizan paravisualizar los resultados de búsqueda y para exportar o transformar los resultadosen algunas operaciones del menú Views, como explicado en Tabla 6.2

5No todos los campos pueden utilizarse para ordenar las búsquedas: los cam-pos de tipo fichero (como las imágenes) o los campos de “agregación” (cuyo nom-bre empieza por Σ) no son campos que pueden ordenarse.

173


Figura 6.12: Menú Actions de una incidencia en el navegador deincidencias.

Figura 6.13: Menú Actions y Tools del navegador de incidencias.

174

6.2. El navegador de incidencias

Acciones en el menú ActionsAcción DescripciónStart progress Comenzar a trabajar sobre una incidencia po-

niendo su estado a In progress (En progreso).Resolve issue Resolver una incidencia poniendo su estado a Re-

solved (Resuelta).Close issue Cerrar una incidencia poniendo su estado a Clo-

sed (Cerrada).Reopen issue Volver a abrir una incidencia poniendo su estado

a Reopened.Edit Modificar una incidencia.Assign Asignar una incidencia.Assign to me Asignar una incidencia a sí mismo.Comment Añadir un comentario a la incidencia.Log work Registrar trabajo sobre la incidencia.Attach file Añadir un fichero adjunto a la incidencia.Attach screenshot Añadir una captura de pantalla a la incidencia.Voters Consultar la lista de usuarios que han votado la

incidencia.Add vote Votar la incidencia.Watch issue Observar la incidencia.Stop watching Dejar de observar la incidencia.Watchers Consultar la lista de usuarios que están obser-

vando la incidencia.Create sub-task Crear una sub-tarea en la incidencia.Convert to issue Convertir en incidencia.Convert to sub-task Convertir en sub-tarea.Move Mover la incidencia.Link Crear un enlace a la incidencia.Clone Clonar la incidencia.Labels Modificar las etiquetas de la incidencia.Delete Borrar la incidencia.

Tabla 6.1: Acciones en el menú Actions en el navegador de incidencias.

175


Acciones en el menú ViewsAcción DescripciónPrintable Visualiza los resultados en una página con los

campos actualmente configurados.Full content Visualiza los resultados en una página inclu-

yendo todos los datos estándar de las inci-dencias.

XML Visualiza los resultados en XML. Véase §9.3.RSS (Issues) Un feed RSS v. 2.0 con las incidencias. Véase

§9.2RSS (Comments) Un feed RSS v. 2.0 con los comentarios a las

incidencias. Véase §9.2Word Exporta las incidencias en un documento Mi-

crosoft Word. Véase §9.4Excel (All fields) Exporta los campos estándar de las inciden-

cias en un documento Microsoft Excel. Véase§9.5

Excel (Current fields) Exporta los campos actualmente configura-dos de las incidencias en un documento Mi-crosoft Excel. Véase §9.5.

Charts Genera un gráfico con los resultados de labúsqueda. Véase §9.6.

On dashboard Visualiza los resultados en un gadget en elcuadro de mandos. Véase §9.6.1.

Tabla 6.2: Acciones en el menú Actions en el navegador de incidencias.

Para ordenar los resultados de una búsqueda es suficiente pulsarel nombre del campo en la cabecera de la tabla de resultados. Laprimera vez que se utiliza un campo para ordenar los datos de unaconsulta, el ordenamiento será ascendente y se visualizará una flechahacia arriba (↑) a la derecha del nombre del campo. Para invertir elcriterio de ordenamiento es suficiente pulsar una segunda vez sobre elmismo campo: los datos se cargarán con el ordenamiento descendientey se visualizará una flecha hacia abajo (↓) a la derecha del nombredel campo.

En Figura 6.11, por ejemplo, puede verse la ventana del navega-dor de incidencias con los datos ordenados de forma descendiente porel campo Key (Clave).

176

6.3. Configurar el navegador de incidencias

6.2.4 Visualizar las incidencia

Desde la ventana del navegador de incidencias, el usuario puede acce-der a los datos de una incidencia seleccionándola y navegando hastala ventana de detalle de la incidencia seleccionada. Cuando se accedea esta ventana a través del navegador de incidencias, JIRA informaráel usuario visualizando unos controles adicionales en la esquina supe-rior derecha de la ventana de detalle, como ilustrado en Figura 6.14.Los controles adicionales desempeñan las siguientes funciones:

Figura 6.14: Ventana de detalle de la incidencia con controles debúsqueda.

(i) Avisan el usuario que existe una búsqueda en curso.(ii) Informan el usuario que se está visualizando la incidencia i-

ésima de un conjunto de n resultados (8 de 9 en la ventana deejemplo).

(iii) Permiten navegar a las demás incidencias utilizando los contro-les de navegación identificados con triángulos hacia arriba (N)y hacia abajo (H).

Si el usuario decidiera o necesitara volver al navegador de inciden-cias, podrá hacerlo seleccionando el enlace Return to search (Vuelvea la búsqueda) en los controles de navegación.

6.3 Configurar el navegador de incidencias

El usuario puede personalizar el navegador de incidencias (§6.2) es-pecificando:

(i) Las columnas visualizadas.(ii) El número de líneas de resultados visualizadas.(iii) La visibilidad de la columna de acciones de las incidencias.

Como explicado en §6.2, las columnas visualizadas en el nave-gador de incidencias afectan también el comportamiento de algunasoperaciones del menú Views (§6.2) utilizadas para generar una repre-sentación alternativa de los resultados de una búsqueda. Por otro

177


lado, como explicado en §5.17, una de las opciones de selección deincidencias durante una operación de modificación masiva es la selec-ción de una página de resultados. Por estas razones, estos parámetrosde configuración no sirven solo para personalizar la “estética” de laventana de resultados sino que tienen repercusiones en la usabilidadde la herramienta y en las operaciones que se pueden efectuar.

La configuración del navegador de incidencia se determina nave-gando una jerarquía de configuraciones, ilustradas en Figura 6.15: laconfiguración que queda establecida es la primera configuración queJIRA encuentra a partir del nivel más bajo de la jerarquía. Por lo tan-

Figura 6.15: Jerarquía de configuración del navegador de incidencias.

to, si un usuario ha establecido una configuración personalizada en superfil de usuario, la misma tendrá precedencia sobre la configuraciónde sistema y será la configuración utilizada por JIRA. Si el usuario,por el contrario, no ha establecido una configuración personalizada,JIRA utilizará la configuración de sistema.

6.3.1 Configurar las columnas visualizadas

En el perfil de cada usuario, JIRA permite definir y almacenar la con-figuración de columnas del navegador de incidencias. El navegador deincidencias de un usuario que no haya establecido dicha configuraciónutilizará la configuración por defecto establecida por los administra-dores de JIRA.

Para modificar el conjunto de columnas visualizadas en esta ven-tana, es necesario acceder a la ventana de configuración de camposdel navegador de incidencias (Figura 6.16) seleccionando la opera-ción Configure columns en el menú Tools. En esta ventana el usuariopodrá modificar el conjunto de campos visualizados añadiendo, eli-minando, reordenando y ocultando los campos disponibles:

(i) Para reordenar los campos de la ventana utilizar los controlesidentificados con flechas (hacia la derecha→ y hacia la izquierda←) para mover el campo en la dirección especificada.

178

6.3. Configurar el navegador de incidencias

Figura 6.16: Ventana de configuración de campos del navegador deincidencias.

(ii) Para eliminar un campo de la ventana seleccionar el control deeliminación identificado con el icono “basura”.

(iii) Para añadir un campo a la ventana, seleccionar el campo en elmenú desplegable Add new column (Añadir nueva columna) ypulsar el botón Add (Añadir).

(iv) Para ocultar la columna de acciones, utilizar el botón Hide ‘Ac-tions’ menu. (Oculta el menú ‘Acciones’).

(v) Para volver a la configuración por defecto, utilizar el botón Res-tore defaults (Restablece valores originales).

La ventana de configuración de campos del navegador también esaccesible desde la ventana del perfil del usuario, a través del enlaceView navigator columns, ilustrado en Figura 6.18.

La configuración de columnas del navegador de incidencias se al-macena en el perfil de usuario de forma que cada usuario puede per-sonalizar las columnas utilizadas por defecto en esta ventana.

Para modificar la configuración de columnas, pueden repetirse lospasos detallados en precedencias y ajustar la configuración del proprioperfil a las nuevas necesidades.

Un usuario también puede decir eliminar la configuración de co-lumnas de su perfil y, en este caso, el navegador de incidencias volveráa utilizar la configuración por defecto establecida por el administra-dor de la plataforma. Para eliminar la configuración de columnas

179


personalizada es necesario seleccionar la operación Restore defaultsilustrada en Figura 6.17.

Figura 6.17: Ventana de configuración de campos del navegador deincidencias — Establecer configuración por defecto.

6.3.2 Configurar el número de líneas visualizadas

El número de líneas de resultados devueltas por el navegador de inci-dencias es un parámetro de configuración del perfil de cada usuario.Para modificar este parámetro es necesario efectuar las siguientes ope-raciones:

(i) Acceder al perfil del usuario seleccionando el enlace con el nom-bre del usuario en la barra de herramientas de JIRA.

(ii) Seleccionar el icono de modificación, identificado con el icono“lápiz”, en el panel Preferences (Preferencias), como ilustradoen Figura 6.18.

(iii) Modificar el parámetro Page size (Tamaño de página) que, pordefecto, tiene el valor 50.

(iv) Confirmar la modificación utilizando el botón Update.

180

6.4. Búsquedas de texto

Figura 6.18: Panel Preferences del perfil de usuario.

6.4 Búsquedas de texto

JIRA ofrece funciones avanzadas pensadas para la búsqueda eficaz detexto:

(i) Búsquedas “aproximadas”, utilizando “comodines” (§6.4.2).(ii) Búsquedas fuzzy (§6.4.3).(iii) Búsquedas por proximidad (§6.4.4).(iv) Búsquedas con palabras de distinta importancia (§6.4.5).(v) Operadores booleanos y de agrupación para la construcción de

consultas complejas (§6.4.6).

Para aclarar la importancia de estas funcionalidades, tomaremoscomo ejemplo las búsquedas “aproximadas”. Para algunos tipos decampos, una búsqueda “aproximada” podría ser de escasa utilidad oincluso carecer de sentido. En el caso de otros campos, como los cam-pos de tipo fecha, aunque el formato del campo esté bien especificadoy no puedan introducirse valores arbitrarios, una búsqueda “aproxi-mada” puede ayudar el usuario a acotar el conjunto de incidencias afiltrar: para este tipo de campo JIRA ofrece, como visto en §6.1.4, laposibilidad de buscar fechas relativas.

En los campos de texto los usuarios pueden introducir texto librey, por lo tanto, es difícil, sino imposible, asegurarse que se utilice un“diccionario” de términos acotado; aún con esta restricción, limitar labúsqueda de texto a términos exactos podría dificultar las operacionesde filtrado y un usuario podría enfrentarse a problemas a la hora deencontrar las incidencias que está buscando.

181


Si un usuario quisiera filtrar las incidencias utilizando como cri-terio un campo de texto y deseara buscar la palabra factura, porejemplo, si la búsqueda se limitara a encontrar palabras idénticas, elusuario no encontraría eventuales “variaciones” de la palabra facturacomo los plurales. En otros idiomas, además, las palabras se decli-nan y, por lo tanto, una búsqueda exacta se revelaría insuficiente yel usuario debería construir criterios que tomasen en cuenta todas lasposibles “variaciones” que se puedan dar.

Este ejemplo demuestra que es necesario disponer de herramientasque garanticen cierto nivel de flexibilidad y, sobre todo, confianza ala hora de certificar que las incidencias que se han filtrado sean todaslas que cumplan los criterios que el usuario ha establecido.

6.4.1 Estructuras de las consultas

Antes de describir las funcionalidades de búsqueda de texto avanzadases importante familiarizarse con la estructura y los términos utilizadospara describir una query de JIRA.

JIRA subdivide las palabras que forman una consulta en dos ca-tegorías: términos y operadores. Los términos son las “palabras” queel usuario desea buscar y, a su vez, se subdividen en términos únicosy frases. Los términos únicos son conjuntos de una palabra comopor ejemplo documento o implantación mientras que las frases sonconjuntos ordenados de palabras, como por ejemplo documento deimplantación. Para agrupar términos y formar una frase es necesarioutilizar las comillas dobles (") para delimitar la misma: la búsqueda"documento de implantación" está compuesta por una frase de trespalabras mientras que la búsqueda documento de implantación esuna búsqueda con tres términos. JIRA trata una frase como un con-junto indivisible de palabras que tiene que aparecer, con las palabrasen el orden especificado y sin interrupción, en el campo que se es-tá filtrando. Las dos búsquedas anteriores, por lo tanto, devolveránconjuntos distintos de resultados siendo la segunda (documento deimplantación), una búsqueda menos “filtrante” que la primera ya quedevolverá la unión de los resultados de las tres palabras buscadas deforma independiente.

La función de los operadores, por otro lado, es la de “juntar” múl-tiples términos en un criterio de búsqueda más complejo. Los ope-radores más comúnmente utilizados son, por ejemplo, los operadoresbooleanos and (∧) y or (∨).

182


El lenguaje de las consultas de texto contiene, como se verá enlas siguientes secciones, unos caracteres especiales que necesitarán ser“escapados” para poderse utilizar en un término con su significadoliteral. Los caracteres especiales están detallados en Tabla 6.3. Para

+ - && || ! ( ) {} [ ] ˆ ˜ * ? \

Tabla 6.3: Caracteres especiales en las búsquedas de texto.

utilizar los caracteres especiales en una consulta es necesario prefijar-los con el carácter de escape \.

Ejemplo 6.2. Para buscar el texto (x + y) + z, por ejemplo, seránecesario ejecutar la consulta:

$x\+y$\+z

En la consulta precedente, se ha utilizado el carácter \ para “escapar”,prefijándolo a ellos, los tres caracteres reservados que aparecían en laconsulta: (, ) y +.

Algunas palabras son consideradas especiales y serán ignoradasen las búsquedas. Las palabras especiales dependen del lenguaje deindicización de JIRA y, por lo tanto, no es posible ofrecer una listaexhaustiva en todos los idioma en los que JIRA está disponible. Comoreferencia, en Tabla 6.4 se detallan los términos especiales de JIRAen inglés.

Términos especialesa and are as at be butby for if in into is itno not of on or s sucht that the their then there thesethey this to was will with

Tabla 6.4: Términos especiales en las búsquedas de texto.

183


6.4.2 Búsquedas aproximadas

JIRA permite utilizar los siguientes “comodines” para modificar elsignificado de los términos en los cuales se utilizan:

(i) ?: para indicar un carácter cualquiera.(ii) *: para indicar un grupo de caracteres cualquiera.

La búsqueda de la palabra factur*, por lo tanto, devolverá tantoresultados de la palabra factura como resultados de las palabrasfacturas, facturación, etc.

La búsqueda de la palabra factur?, por otro lado, devolverá losresultados de la palabra factura pero no los resultados correspon-dientes a facturas o facturación.

La única limitación de estos dos comodines es que no se puedenutilizar como comienzo de palabra. Las búsquedas *ras, por ejemplo,será una búsqueda inválida.

6.4.3 Búsquedas fuzzy

Las búsquedas fuzzy permiten buscar términos que se “parezcan” alos términos especificados en situaciones en las cuales la utilizaciónde comodines (§6.4.2) para efectuar una búsqueda aproximada nogarantizarían un buen resultado. Las búsquedas fuzzy solo puedenutilizarse por términos únicos y no por frases (§6.4.1).

Un usuario podría, por ejemplo, estar buscando una palabra que“se parece” a otra pero, no sabiendo exactamente como se escribe estapalabra, teme que la utilización de comodines podría resultar en unfiltrado ineficaz de las incidencias en el sistema.

Para efectuar una búsqueda fuzzy con un término es necesarioutilizar el modificador ˜ al final del término único que se desea modi-ficar. Para buscar de forma fuzzy utilizando el término factura, porejemplo, un usuario deberá utilizar el término modificado factura˜.

6.4.4 Búsquedas por proximidad

Las búsquedas por proximidad permiten efectuar búsquedas con fra-ses cuyas palabras no deben distar más de la cantidad de palabrasespecificadas.

Este tipo de búsqueda es útil para refinar una búsqueda por frasecuando no se tiene la certidumbre que la frase sea “exacta” y puedadarse que la misma contenga palabras adicionales. De esta forma un

184


usuario puede seguir utilizando frases, un criterio más filtrante queun criterio por términos únicos, asegurándose que las palabras no es-tén demasiados “apartadas” corriendo el riesgo de obtener resultadosdiversos de los esperados.

Para efectuar una búsqueda por proximidad un usuario necesitaañadir el sufijo ˜n donde n es la distancia máxima entre las palabrasde la misma frase. Para buscar el conjunto de palabras documentode implantación asegurándose que no disten más de 5 palabras, elusuario utilizará el término "documento de implantación"˜5.

6.4.5 Búsqueda por importancia

JIRA “categoriza” los resultados de una búsqueda con un valor deimportancia relativa medido de acuerdo a los términos encontrados.Por defecto el nivel de importancia de un término de una búsquedade texto es 1.

El usuario puede modificar el nivel de importancia de un término,tanto único como frase, utilizando el modificador ˆn donde n es elnivel de importancia que se quiere asignar al término. El nivel deimportancia debe ser un número positivo: los números n ∈]0, 1[ dis-minuyen el nivel de importancia de un término mientras que los nú-meros n ∈]1,∞[ aumentan el nivel de importancia de un término. Labúsqueda

documento implantación^4

por ejemplo, asignará un valor cuatro veces superior al término im-plantación relativamente al término documento.

6.4.6 Operadores

Los operadores permiten combinar términos para construir consultasmás complejas. Los operadores booleanos soportados por JIRA sonlos siguientes:

(i) AND o &&.(ii) OR o ||.(iii) NOT o !.(iv) +.(v) -.

Nótese que un operador debe escribirse en mayúsculas, de lo contrarioJIRA lo interpretará como término (§6.4).

185


El operador AND es un operador binario que relaciona dos términos,como en el criterio x AND y. Este operador indica a JIRA que ambostérminos, x y y, deben encontrarse en la incidencia. Para hacer unaanalogía con los conjuntos, el operador AND (∧) hace una intersección:si X es el conjunto de resultados del término x y Y el del término y,los resultados de x ∧ y serán x ∩ y.

El operador OR es un operador binario que indica a JIRA de devol-ver resultados que contengan o un término o el otro. Para hacer unaanalogía con los conjuntos, el operador OR (∨) hace una intersección:si X es el conjunto de resultados del término x y Y el del término y,los resultados de x ∨ y serán x ∪ y.

El operador NOT es un operador binario que indica a JIRA dedevolver los resultados que contengan el término especificado por elprimer operando y que no contenga el término especificado por elsegundo operando. Para hacer una analogía con los conjuntos, eloperador NOT (¬) hace una diferencia entre conjuntos. Si X es elconjunto de resultados del término x y Y es el conjunto de resultadosdel término y, el conjunto de resultados de la consulta x¬y será X\Y .

El operador + es un operador unario que indica a JIRA que untérmino de una consulta es un término requerido y debe encontrarseen los resultados. A pesar de ser un operador unario, este operador notiene efecto si utilizado en una consulta con un solo término ya que,en ambos casos, el conjunto de resultados coincidiría. En la consulta:

documento +implantación

los resultados deberán contener la palabra implantación y podráncontener la palabra documento.

El operador - es un operador unario que indica a JIRA que untérmino de una consulta es un término excluido de la consulta y nodebe encontrarse en los resultados. En la consulta:

"documento de implantación" -borrador

los resultados deberán contener la frase documento de implantacióny no podrán contener la palabra borrador.

Los criterios de búsqueda pueden agruparse para formar consul-tas de complejidad superior y los caracteres de agrupación son lasparéntesis. Existe una limitación por la cual una consulta no puedecomenzar con un carácter de agrupación. La consulta

documento AND (explotación OR implantación)

186

6.5. Búsquedas rápidas

devolverá resultados que contengan la palabra documento y contenganuna de las palabras explotación o implantación.

6.5 Búsquedas rápidas

El control de búsqueda rápida, ilustrado en Figura 6.19, está situadoen la barra de herramientas de JIRA y, por lo tanto, está disponibleen cualquier ventana de la aplicación. Este control permite efectuar

Figura 6.19: Control de búsqueda rápida.

búsquedas tecleando el “criterio” directamente en el campo de texto:por defecto, JIRA efectuará una búsqueda con “texto libre” buscandoel texto en los campos descriptivos de las incidencias: título, descrip-ción y comentarios. El control de búsqueda rápida también reco-noce algunos términos que permite efectuar rápidamente búsquedas“inteligentes” tales como búsqueda por usuario asignado o reporter,búsquedas con fechas, búsquedas por estado, etc.

La búsqueda rápida, aunque no permita filtrar las incidencias concriterios complejos como los que se pueden construir el navegadorde incidencias, es una herramienta puede resultar muy poderosa alusuario que aprenda como utilizarla. Los resultados de las búsquedasrápidas se visualizarán además, como cualquier otra búsqueda, en elnavegador de incidencias: todas las funciones proporcionadas en estaherramienta estarán por lo tanto a disposición del usuario.

Cuando JIRA detecta una query inteligente, el usuario será avisa-do en la ventana de resultados por un mensaje parecido al ilustradoen Figura 6.20. Si la intención del usuario era efectuar una búsqueda

Figura 6.20: Aviso de activación de búsqueda inteligente.

de texto libre, se podrá utilizar el enlace Run search without smart

187


query para volver a efectuar la búsqueda inhabilitando las queriesinteligentes6.

La búsqueda rápida es una funcionalidad compatible con el con-trol de búsqueda de navegadores basados en Mozilla: una instanciade JIRA podrá por lo tanto integrarse en los motores de búsquedagestionados por el navegador y el usuario podrá efectuar búsquedasrápidas en las instancias de JIRA registradas directamente desde elnavegador. De la misma forma en que los usuarios pueden iniciar unanavegación utilizando otros motores de búsqueda (tales como Goo-gle), se podrá efectuar una búsqueda en JIRA sin ni siquiera accederpreviamente a la misma y obtener los resultados accediendo directa-mente al navegador de incidencias. En sección §6.5.14 se detallarácomo configurar esta funcionalidad en los navegadores compatibles.

En las siguientes secciones se detallarán las “búsquedas inteligen-tes” que JIRA es capaz de reconocer.

6.5.1 Navegar a una incidencia

Uno de los casos de usos más comunes para la búsqueda simple es lanavegación hacia una incidencia utilizando su código. La búsquedarápida proporciona el camino más rápido hacia la ventana de deta-lle de una incidencia ya que, tecleando en el control un código deincidencia, JIRA llevará el usuario a la ventana de detalle correspon-diente. Si, por ejemplo, un usuario quiere navegar hacia la incidenciaJRAGD-1, es suficiente teclear este código en el control de búsquedarápida para que JIRA lleve directamente el usuario a la ventana dedetalle sin pasar por una ventana de resultados de búsqueda interme-dia.

Si, además, el usuario está buscando una incidencia en el mismoproyecto en el que está trabajando, se podrá omitir la clave de pro-yecto y teclear solo el número de incidencia: JIRA asumirá que seestá buscando la incidencia en el mismo proyecto y llevará el usuarioal detalle de la incidencia.

6.5.2 Incidencias asignadas a uno mismo

Para encontrar incidencias asignadas a uno mismo se puede utilizarla palabra clave my en el criterio de búsqueda utilizando los demástérminos inteligentes proporcionados por JIRA. Si, por ejemplo, un

6Las queries inteligentes se inhabilitarán solo durante la búsqueda por la quese ha utilizado este enlace.

188


usuario quisiera encontrar las incidencias asignadas a si mismo que nose han resuelto en la fecha límite (§6.5.5), podrá teclear my overduey JIRA devolverá las incidencias requeridas. Si el usuario quisiera en-contrar sus incidencias abiertas (§6.5.7) en el proyecto JRAGD (§6.5.4)podrá teclear my open JRAGD.

6.5.3 Incidencias por reporter

Si se quisieran filtar las incidencias utilizando el nombre del usuarioque ha reportado la incidencia7 podrá utilizarse la cadena r: seguidade:

(i) me: si se están buscando las incidencias abiertas por uno mismo.(ii) none: si se están buscando las incidencias sin reporter.(iii) nombre: si se están buscando las incidencias abiertas por un

usuario específico.

Si, por ejemplo, un usuario quisiera buscar las incidencias abiertaspor enrico podrá utilizar r:enrico.

6.5.4 Incidencias en un proyecto

Para filtrar las incidencias de un proyecto es posible especificar elcódigo o el nombre del mismo en el criterio de búsqueda. Si se quierenbuscar las incidencias del proyecto JRAGD se podrá utilizar esta claveen el criterio de búsqueda rápida para que JIRA acote el filtrado enel contexto del proyecto especificado.

6.5.5 Incidencias atrasadas

Para buscar las incidencias “atrasadas”, es decir las incidencias cuyafecha de resolución ha pasado la fecha límite especificada en el cam-po Due date, se puede utilizar el término overdue en el criterio debúsqueda, como ilustrado en el ejemplo de §6.5.2.

6.5.6 Incidencias por fecha

Los prefijos created:, updated: y due: pueden utilizarse para bus-car las incidencias cuya fecha de creación, última actualización o ven-cimiento sea la especificada. El formato de fecha que puede utilizarse

7Esta funcionalidad está incluida en JIRA v. 4.3 y superiores

189


con este tipo de búsqueda inteligente es exclusivamente una fecha re-lativa (§??) o un intervalo de fechas relativas, utilizando la notaciónadd section

x,y donde x y y respetan el formato detallado en §?? y no contienenningún espacio.

Para facilitar la búsqueda, JIRA también entiende los siguientesmnemónicos:

(i) yesterday(ii) today(iii) tomorrow

Para buscar incidencias creadas en la última semana puede uti-lizarse por ejemplo la búsqueda created:-1w. Para buscar inciden-cias actualizadas en los últimos dos días puede utilizarse la búsquedaupdated:-2d,-1d.

6.5.7 Incidencias por estado

Para buscar incidencias de un particular estado puede utilizarse elnombre del estado como término de búsqueda, como ilustrado en elejemplo my open JRAGD de §6.5.2 que devuelve las incidencias abier-tas (open) asignadas a uno mismo en el proyecto JRAGD.

Los estados reconocidos serán exclusivamente los estados del flujode trabajo estándar de JIRA.

6.5.8 Incidencias por resolución

El nombre de una resolución (§??) puede utilizarse para filtrar lasincidencias como en la busqueda my incomplete, para buscar inci-dencias en el estado Incomplete, o en la búsqueda r:me duplicate,para buscar las incidencias duplicadas reportadas por uno mismo.

6.5.9 Incidencias por prioridad

Las incidencias pueden buscarse utilizando el nombre de la prioridad:para buscar una incidencia con prioridad blocker, por ejemplo, se pue-de utilizar el término blocker como criterio de búsqueda inteligente.

6.5.10 Incidencias por tipo

El tipo de incidencia puede utilizarse como término de búsqueda inte-ligente: para buscar incidencias del tipo bug o task pueden utilizarse

190


los términos bug o task en el criterio de búsqueda. JIRA, en algunoscasos, interpretará también los plurales y podrán efectuarse búsque-das tales como my open bugs para encontrar las incidencias abiertas(open, §6.5.7) de tipo bug asignadas a uno mismo (my, §6.5.2).

6.5.11 Incidencias por versión

El prefijo v: puede utilizarse para especificar la versión a la que es-tán asociadas las incidencias que se están buscando. JIRA devolverálas incidencias cuya versión sea igual a la que se especifique o quecomience con la cadena especificada siempre que el primer carácterdespués de ésta sea un espacio.

Si en un proyecto, por ejemplo, se han definido las versiones 1.0,1.0 Standard y 1.0.1 y se utiliza el término v:1.0 en una búsquedarápida, JIRA devolverá las incidencias asociadas a las versiones 1.0 y1.0 standalone. No se devolverán las incidencias asociadas a la versión1.0.1 ya que el primer carácter después de la cadena especificada (1.0)no es un espacio sino un punto (.).

6.5.12 Incidencias por versión de resolución

Las incidencias pueden filtrarse por el campo Fix version utilizandoel término ff: y especificando un número de versión. El mecanismode búsqueda es parecido al detallado en §6.5.11.

6.5.13 Incidencias por componente

El prefijo c: puede utilizarse para buscar las incidencias asociadas alcomponente buscado. Este prefijo permite especificar una palabra (sinespacios) y JIRA devolverá las incidencias asociada a componentescuyo nombre contenga la palabra especificada.

6.5.14 Integración con navegadores

La integración de JIRA con el control de búsqueda de los navegado-res es una forma muy cómoda de poder “registrar” cualquier instanciade JIRA como motor de búsqueda y poder efectuar una búsqueda deforma rápida, sin siquiera conectarse previamente a la plataforma yacceder a sus herramientas de búsqueda. En lugar de utilizar estasúltimas, el usuario podrá teclear la búsqueda directamente en el con-trol de búsqueda del navegador que, normalmente, está situado justoa la derecha de la barra de navegación. El navegador, después de que

191


el usuario haya confirmado la búsqueda, contactará con JIRA paraenviarle la query introducida por el usuario que será llevado directa-mente a la página de resultados del navegador de incidencias.

La funcionalidad de búsqueda rápida de JIRA puede integrarsesolo con algunos navegadores que deben cumplir una de las siguientescondiciones:

(i) Soportar el estándar OpenSearch.(ii) Ser un navegador derivado de Mozilla.

El estándar OpenSearch [26], la opción aconsejada para integraresta funcionalidad, es un estándar que se creó para la publicación deresultados de búsqueda y proporcionarlos en una “forma” que facili-tara la agregación y la sindicación de los mismos. El descubrimientode las funcionalidades, la registración y la utilización de un motorde búsqueda que, como JIRA, soporte este estándar es automáticay, por lo tanto, es una operación muy sencilla a completarse inclusopara usuarios no expertos.there can only

be one open-search descrip-tor per domain.

Los navegadores más conocidos que hoy en día soportan este es-tándar son:

(i) Mozilla Firefox v. 2 y superiores.(ii) Microsoft Internet Explorer v. 7 y superiores.(iii) Google Chrome.

Para añadir una instancia de JIRA a los motores de búsquedaconfigurados de un navegador soportado, es suficiente navegar a cual-quier página de la plataforma. El navegador, una vez que se acceda ala plataforma, accederá al descriptor OpenSearch proporcionado porJIRA y el usuario podrá añadir la instancia corriente en la configu-ración del navegador. En Figura 6.21 puede verse un ejemplo conMozilla Firefox: utilizando el menú desplegable a la izquierda del con-trol de búsqueda (identificado, en las versiones recientes de Firefox,con el logo del motor de búsqueda actualmente utilizado), apareceráuna entrada de menú que permitirá añadir a JIRA entre los motoresconfigurados.

Una vez registrado el motor, el usuario podrá comenzar a teclearsus búsquedas y enviarlas directamente a JIRA. En Figura6.22 pue-de verse el resultado de la búsqueda my open bugs efectuada desdeel control de búsqueda de Firefox.

El soporte del estándar OpenSocial permite la integración de JIRAcon cualquier aplicación que soporte este estándar. Aunque el caso

192


Figura 6.21: Registración de un motor de búsqueda OpenSearch.

Figura 6.22: Ejemplo de búsqueda desde el control de búsqueda delnavegador.

193


más común será la integración con un navegador el usuario podráintegrar JIRA como motor de búsqueda en cualquier aplicación olenguaje de programación que soporte el estándar [27] directamenteo a través de una librería, tales como: Alfresco, Drupal, Lucene,MediaWiki, WordPress, etc. Véase [27] para obtener informaciónacerca de los clientes soportados.

Otra opción de integración para navegadores que deriven de Mo-zilla es la creación de un bookmark personalizado que apunte a ladirección8:

http://your.jira/secure/QuickSearch.jspa?searchString=%s

El usuario podrá escoger una keyword (palabra clave) para el book-mark que, por ejemplo, podría ser el mnemónico j. Para efectuar unabúsqueda en JIRA será suficiente teclear la palabra clave escogida se-guida del criterio deseado: para repetir la búsqueda del ejemplo deFigura 6.22 el usuario deberá teclear j my open bugs.

8Sustituir your.jira con la dirección de la instancia de JIRA a integrar.

194

7Búsquedas avanzadas

La búsqueda avanzada es la herramienta de búsqueda más comple-ta proporcionada por JIRA. Para utilizar este tipo de búsqueda, adiferencia de los demás tipos de búsquedas ofrecidos por JIRA (bús-queda simple, descrita en §6.1, y búsqueda rápida, descrita en §6.5),es necesario conocer y emplear el JIRA query language (lenguaje dequery de JIRA, o JQL). El JQL es un lenguaje que se asemeja alSQL, aunque con notables diferencias y limitaciones: a continuaciónse detallarán las más importantes desde el punto de visto del usuario.

En primer lugar, el JQL permite efectuar búsquedas (la operaciónanáloga al comando SELECT del SQL) pero no permite modificar losdatos: de hecho, ni siquiera existe el comando SELECT sino que seasume implícitamente que el comando JQL sea una selección.

En segundo lugar, el JQL aísla el usuario del modelo de datossubyacente de JIRA: sencillamente, no existe el concepto de tabla (niconceptos a ella relacionados, tales como el join) y solo se manejancampos en un “espacio de nombres global”.

En tercer lugar, no se puede utilizar un campo como “valor” enuna comparación con otro campo: criterios válidos (y comunes) enSQL no podrán implementarse con ninguna herramienta de búsquedaproporcionada por JIRA, ni siquiera con el JQL. Si, por ejemplo, unusuario quisiera efectuar la búsqueda:

asignatario = reporter (7.1)

o la búsqueda:

fecha de creación = fecha de actualización (7.2)

no habrá forma de ejecutarla a través de las herramientas de JIRAya que, por ejemplo, la consulta:

195

7. Búsquedas avanzadas

assignee = reporter

será interpretada por JIRA como la búsqueda de las incidencias cuyoasignatario se llame, literalmente, reporter.

Las búsquedas avanzadas se efectúan en el navegador de inciden-cias (§6.2), seleccionando en enlace Advanced para pasar de la mo-dalidad simple a la modalidad avanzada, cuya captura de pantallapuede verse en Figura 7.1. El usuario podrá teclear la consulta

Figura 7.1: Ventana de búsqueda avanzada.

JQL en el cuadro de texto, pulsar el botón Search y los resultados sevisualizarán, como para cualquier otra búsqueda, en el navegador deincidencias donde se podrán utilizar sus herramientas para manipularlos datos.

7.1 Estructura de una query JQL

La query JQL básica está compuesta por los siguientes elementos:

assignee︸︷︷︸campo

=︸︷︷︸operador

enrico︸︷︷︸valor

(7.3)

El campo es el identificador del campo a buscar: en este caso el campoassignee, es decir, el usuario al que está asignada la incidencia.

El operador representa el tipo de “filtrado” que se desea efectuarsobre el campo y devuelve un valor booleano : en este caso se deseanbuscar valores iguales al valor proporcionado.

El valor es el parámetro requerido por algunos operadores paracompletar el filtrado: en este caso, tratándose del operador binariode igualidad, enrico es el valor que tiene que asumir el campo parasatisfacer nuestro criterio de búsqueda. En lugar de un valor, algunoscampos soportan la comparación con el resultado de una función

Múltiples proposiciones pueden juntarse, utilizando operadores boo-leanos, para construir proposiciones complejas.

196

7.2. Caracteres reservados

7.2 Caracteres reservados

El lenguaje JQL tiene los caracteres reservados detallados en Tabla7.1. Para utilizar caracteres reservados en las consultas JQL habrá

" " + . , ; ? | */ % ˆ $ # @ [ ]

Tabla 7.1: Caracteres JQL reservados.

que “protegerles” utilizando comillas o comillas dobles.Nótese que, en el caso de búsquedas de texto habrá que tener en

cuenta una lista adicional de caracteres reservados que ha sido deta-llada en §6.4.1. Este tipo de búsqueda, cuando se utilizan consultasJQL, aplicarán a los siguientes campos:

(i) Título.(ii) Descripción.(iii) Entorno.(iv) Comentarios.(v) Campos personalizados que utilicen el buscador de texto libre

(§??), tales como:a) Campo de texto libre.b) Campo de texto.c) Campo de texto de sola lectura.

7.3 Palabras reservadas

El lenguaje JQL tiene también palabras reservadas que, para poderseutilizar en una consulta, deberán ser “protegidas” con comillas. En§B.3 se detallará la lista completa de palabras reservadas de estelenguaje.

7.4 Campos

En esta sección se introducirán los campos más comúnmente utiliza-dos en las consultas. Por razones de espacio y organización de estelibro, se ha dedicado una apéndice (§B) como referencia exhaustivasobre los campos JQL.

197


En Tabla 7.2 puede verse la lista de campos que pueden utilizarseen una query JQL.

Descripción Nombre

Versión afectada affectedVersionAsignatario assigneeCategoría categoryComentario commentComponente componentFecha de creación createdDescripción descriptionFecha de vencimiento dueEntorno environmentFiltro filterVersión de resolución fixVersionClave de incidencia issueKeyNivel de seguridad levelEstimación original originalEstimatePadre parentPrioridad priorityProyecto projectEstimación restante remainingEstimateReporter reporterResolución resolutionFecha de resolución resolvedEstado statusTítulo summaryTexto textTipo de incidencia issueTypeTiempo trabajado timeSpentFecha de actualización updatedUsuario que ha votado voterNúmero de votos votesUsuario que observa watcherPorcentaje de trabajo workRatio

Tabla 7.2: Campos JQL.

7.5 Palabras claves

Las palabras claves son términos reservados JQL que se dividen enlas siguientes categorías:

198

7.5. Palabras claves

(i) Conectivas o operadores lógicos, como por ejemplo los opera-dores para conectar múltiples proposiciones en una proposiciónmás compleja: AND (∧) y OR (∨).

(ii) Operadores de ordenamiento.

7.5.1 Palabra clave and

El operador lógico and (∧) permite unir dos proposiciones lógicas (doscriterios de búsqueda)X y Y en una proposición más compleja, X∧Y ,que será verdadera cuando ambos componentes sean verdaderos.

Ejemplo 7.1. Para buscar las incidencias de tipo bug asignadas aun usuario llamado enrico es necesario juntar las proposiciones:

(i) la incidencia es de tipo bug(ii) la incidencia está asignada al usuario denominado enrico

con el operador and:

type = Bug and assignee = enrico

Ejemplo 7.2. Para buscar las incidencias abiertas, urgentes y asig-nadas a enrico es necesario juntar las proposiciones

(i) la incidencias está abierta.(ii) la prioridad de la incidencia es urgente.(iii) la incidencia está asignada al usuario denominado enrico

con el operador and:

status = open and priority = urgent and assignee = enrico

7.5.2 Palabra clave or

El operador logico or (∨) permite unir dos proposiciones lógicas (doscriterios de búsqueda) X y Y en una proposición más compleja, X ∨Y , que será verdadera cuando al menos uno de los componentes seaverdadero.

Ejemplo 7.3. Para buscar las incidencias vencidas o las incidenciasque no especifican una fecha de vencimiento es necesario juntar lasproposiciones

199


(i) La incidencia ha vencido.(ii) La incidencia no tiene fecha de vencimiento.

con el operador or:

duedate < now() or duedate is empty

7.5.3 Palabra clave not

El operador not (¬) invierte la función de verdad de la proposición:si X es una proposición y ¬X es la proposición negada, ¬X seráverdadera cuando X sea falsa y viceversa.

Ejemplo 7.4. Para buscar las incidencias abiertas, urgentes y queno estén asignadas a enrico es necesario juntar las proposiciones

(i) La incidencias está abierta.(ii) La prioridad de la incidencia es urgente.(iii) La incidencia no está asignada al usuario denominado enrico.

y ejecutar, pues, la consulta:

status = open and priority = urgent and not assignee = enrico

7.5.4 Palabra clave empty

La palabra clave empty se utiliza en una query JQL como valor paraindicar que el campo no tiene un valor asignado. Esta palabra clavesolo puede utilizarse con campos (§B.1.3) que soportan los operadoresis (§7.6.11) e is not (§7.6.12). Véase también §7.5.5.

Ejemplo 7.5. En el ejemplo 7.3 se utilizó el operador is y la palabraclave empty para expresar el criterio la incidencia no tiene fecha devencimiento:

duedate is empty

200

7.6. Operadores

7.5.5 Palabra clave null

El operador null tiene una funcionalidad muy parecida al operadorempty: se utiliza en una query JQL como valor para indicar que elcampo no tiene un valor asignado. Esta palabra clave solo puede uti-lizarse con campos (§B.1.3) que soportan los operadores is (§7.6.11)e is not (§7.6.12). Véase también §7.5.4.

Ejemplo 7.6. En el ejemplo 7.5 se puede intercambiar el operadorempty con el operador null y expresar el mismo criterio de búsqueda:

duedate is null

7.5.6 Palabra clave order by

El operador order by permite especificar el campo con el cual se or-denarán los resultados. Por defecto este operador devolverá los datosen órden ascendente pero su comportamiento puede modificarse indi-cando explícitamente el órden deseado utilizando las palabras clavesasc y desc si se desea, respetivamente, ordenamiento ascendente odescendiente.

Ejemplo 7.7. Si se desean ordenar los resultados de la consulta des-crita en el ejemplo 7.3 en orden descendente utilizando el campo fechade creación deberá utilizarse la consulta:

duedate < now() or duedate is empty order by created

7.6 Operadores

Los operadores pueden pensarse como funciones que devuelven unvalor booleano y aceptan como “parámetros” un campo y su valor (ouna función). Los operadores definen los criterios de filtrado que elusuario puede hacer sobre los campos y son los siguientes:

(i) El campo es igual a (=): equals.(ii) El campo es distinto de ( 6=): not equals.(iii) El campo es mayor que (>): greater than.(iv) El campo es mayor o igual que (≥): greater than equals.(v) El campo es menor que (<): less than.

201


(vi) El campo es menor o igual que (≤): less than equals.(vii) El campo está en (∈): in.(viii) El campo no está en (/∈): not in.(ix) El campo contiene (3): contains.(x) El campo no contiene (63): does not contain.(xi) El operador es (≡): is.(xii) El operador no es (6≡): is not.

7.6.1 Operador equals

El operador equals (=) se utiliza cuando el valor de un campo tie-ne que coincidir con el valor especificado. Este operador no puedeutilizarse con campos de tipo texto (véase §7.6.9).

Ejemplo 7.8. En el ejemplo 7.1 se utilizó el operador = dos vecesen la consulta:

type = Bug and assignee = enrico

Nótese que en ambas proposiciones este operador se ha utilizado concampos que no son textuales aunque, intuitivamente, se podría pensarque lo fuesen.

7.6.2 Operador not equals

El operador not equals (6=) se utiliza cuando el valor de un campotiene que ser distinto que el valor especificado. Este campo puedeindicarse también como !=. Este operador no puede utilizarse concampos de tipo texto (véase §7.6.10).

Una proposición que utilice el operador 6= equivale a la negaciónde la misma proposición en la que 6= se haya sustituido con el operador=:

(campo != valor) = (not campo = valor)

Hay que subrayar también el hecho que, contrariamente a lo quesugiere la intuición, la proposición campo != valor será falsa cuandoel campo sea vacío (∅), es decir, no tenga ningún valor asignado. Si,por lo tanto, se están buscando las incidencias cuyo campo c satisfagael criterio c 6= v, incluso cuando el campo c esté vacío, habrá queutilizar la proposición (c 6= v) ∨ (c = ∅):

campo != valor or campo is empty

202

7.6. Operadores

Ejemplo 7.9. Para encontrar todas las incidencias asignadas a unusuario distinto del usuario enrico será necesario utilizar la proposi-ción:

assignee != enrico

o la proposición:

not assignee = enrico

Ejemplo 7.10. Para encontrar todas las incidencias que no esténasignadas al usuario enrico será necesario utilizar la proposición:

assignee != enrico or assignee is empty

Ejemplo 7.11. Para encontrar todas las incidencias que no hayansido reportadas por el usuario corriente, es decir, el usuario que estáefectuando la búsqueda, será necesario utilizar la proposición:

reporter != currentUser()

7.6.3 Operador greater than

El operador greater than (>) se utiliza cuando el valor de un campotiene que ser estrictamente mayor que el valor especificado1.

Ejemplo 7.12. Para encontrar todas las incidencias no soluciona-das que no hayan vencido todavía será necesario utilizar la siguienteproposición:

duedate > now() and resolution is empty

Ejemplo 7.13. Para encontrar todas las incidencias cuya prioridadsea mayor que normal será necesario utilizar la siguiente proposición:

1Debido a su naturaleza, el campo con el que se utiliza este operador tieneque tener un tipo de valor para el cual exista una relación de órden tales como lasfechas. Los campos de tipo texto, a pesar de que este tipo de campo suele poderseordenar, no pueden ser comparados utilizando este operador. Véase §B.1.3 paracomprobar cuales operadores están soportados por cada campo.

203


priority > normal

7.6.4 Operador greater than equals

El operador greater than equals (≥) se utiliza cuando el valor deun campo tiene que ser mayor o igual que el valor especificado2.

Ejemplo 7.14. Para encontrar todas las incidencias que venzan apartir del día 31 de Diciembre de 2008 incluido será necesario utilizarla siguiente proposición:

duedate >= "2008/12/31"

Ejemplo 7.15. Para encontrar todas las incidencias que hayan si-do creadas en los últimos 7 días será necesario utilizar la siguienteproposición:

created >= "-7d"

7.6.5 Operador less than

El operador less than (<) se utiliza cuando el valor de un campotiene que ser menor que el valor especificado3.

Ejemplo 7.16. Para encontrar todas las incidencias que hayan sidovotadas menos que 4 será necesario utilizar la siguiente proposición:

votes <= 4

2Véase nota al pié 1.3Véase nota al pié 1.

204

7.6. Operadores

7.6.6 Operador less than equals

El operador less than (<) se utiliza cuando el valor de un campotiene que ser menor o igual que el valor especificado4.

Ejemplo 7.17. Para encontrar todas las incidencias que hayan si-do actualizadas en las últimas 4 semanas será necesario utilizar lasiguiente proposición:

updated <= "-4w"

7.6.7 Operador in

El operador in (∈) se utiliza cuando el valor de un campo tiene quepertenecer al conjunto de elementos especificados que se indicará conla notación (x, . . . , z). Como ya hemos subrayado en otra sección(§6.1), la proposición:

s ∈ {si, i ∈ [0, n]} (7.4)

es equivalente a la siguiente proposición:

(s = s0) ∨ (s = s1) ∨ · · · ∨ (s = sn) (7.5)

Por lo tanto, el operador in permite escribir proposiciones más com-pactas y fáciles de entender.

Ejemplo 7.18. Para encontrar todas las incidencias que hayan sidoabiertas o por enrico o por lourdes, será necesario utilizar la siguienteproposición:

assignee in (enrico,lourdes)

Ejemplo 7.19. Para encontrar todas las incidencias que afecten a laversión 3 o a la versión 4 será necesario utilizar la siguiente proposi-ción:

affectedVersion in ("3", "4")

4Véase nota al pié 1.

205


7.6.8 Operador not in

El operador not in (/∈) se utiliza cuando el valor de un campo notiene que pertenecer al conjunto de elementos especificados.

Negando las proposiciones 7.4 y 7.5 se obtiene:

(s /∈ {si, i ∈ [0, n]}) = ((s 6= s0) ∧ (s 6= s1) ∧ · · · ∧ (s 6= sn)) (7.6)

es decir, que el operador not in puede utilizarse para sustituir unconjunto de proposiciones, relacionadas con el operador and, que com-prueban que el campo no asuma ninguno de los valores especificados,uno a la vez. Esto significa que, por ejemplo, la consulta JQL:

assignee not in (enrico,lourdes)

es equivalente a la consulta:

assignee != enrico and assignee != lourdes

El operador not in, como el operador in, permite “simplificar” al-gunas consultas y escribirlas con una notación más compacta y másfácil de entender.

Es importante subrayar que este operador tiene el mismo com-portamiento del operador not equals (véase §7.6.2) cuando comparacampos vacíos: si un campo c es vacío, c ∈ {ci, i ∈ [0, n]} será siemprefalsa y, por lo tanto, las incidencias correspondientes no aparecerán enlos resultados. Si se desea incluir las incidencias con el campo c vacío,será necesario añadirlas explicitamente en la consulta: c /∈ C ∨ c = ∅.

Ejemplo 7.20. Para encontrar todas las incidencias cuyo usuarioasignado no sea ni enrico ni lourdes será necesario utilizar la siguienteproposición:

assignee not in (enrico,lourdes) or assignee is empty

7.6.9 Operador contains

El operador contains (3), un operador que se puede utilizar exclusi-vamente con campos de tipo texto, se utiliza para comprobar que uncampo tenga el valor especificado o un valor que se le “parezca”.

Cuando se utiliza contains, o ˜ para efectuar búsquedas de texto,pueden utilizarse todas las funcionalidades descritas en §6.4, inclusolas búsquedas fuzzy. Véanse las secciones citadas para obtener mayorinformación sobre la funcionalidad de este operador.

206

7.6. Operadores

Ejemplo 7.21. Para encontrar todas las incidencias cuyo título con-tenga la frase “problema de pantalla” será necesario utilizar la siguien-te proposición:

summary ~ "problema de pantalla"

Ejemplo 7.22. Para encontrar todas las incidencias cuyo título con-tenga el término bug o los términos “parecidos” con una búsquedafuzzy, será necesario utilizar la siguiente proposición:

summary ~ bug

Ejemplo 7.23. Para encontrar todas las incidencias cuyo título con-tenga una palabra que comience con win, será necesario utilizar lasiguiente proposición:

summary ~ "win*"

7.6.10 Operador does not contain

El operador does not contain ( 63), o !˜, es el operador “inverso” deloperador contains (§7.6.9): si un campo c satisface la proposiciónc 3 v, entonces no satisfará la proposición c 63 v, y vice versa.

Este operador tiene el mismo principio de funcionamiento y estásujeto a las mismas limitaciones del operador contains (véase §7.6.9para mayor información).

Ejemplo 7.24. Para encontrar todas las incidencias que no satisfa-cen el criterio del ejemplo 7.22, es decir, cuyo título no contenga eltérmino bug o términos “parecidos”, será necesario utilizar la siguienteproposición:

summary !~ bug

207


7.6.11 Operador is

Como explicado en las secciones dedicadas a otros varios operado-res, el valor vacío (∅) es un valor “especial” para un campo y lasproposiciones que involucran campos vacíos no siempre devuelven elresultado esperado. Simplificando, se puede pensar que, cuando uncampo c está vacío, c = ∅, este campo no es “comparable” con ningúnvalor no nulo ya que dicha proposición devolverá siempre no.

El operador is, y su inverso is not (§7.6.12), sirve exclusivamentepara comprobar este particular estado: el operador is comprueba siun campo está vacío, con el valor empty o null.

Ejemplo 7.25. Para encontrar todas las incidencias que tengan fechade vencimiento vacía será necesario utilizar una de las dos siguientesproposiciones:

duedate is nullduedate is empty

7.6.12 Operador is not

El operador is not, inverso del operador is (§7.6.11), comprueba queun campo no esté vacío, comparándolo con el valor empty o null.

Ejemplo 7.26. Para encontrar todas las incidencias que tengan asig-nada una fecha de vencimiento (véase ejemplo 7.25) será necesarioutilizar una de las dos siguientes proposiciones:

duedate is not nullduedate is not empty

7.7 Órden de evaluación

Cuando se compone una consulta JQL, así como cuando se componenproposiciones lógicas, con operadores booleanos, el órden en el que seejecutan las evaluaciones es importante. JIRA, por defecto, evalúa lasproposiciones de una en una de izquierda a derecha. Si se considerala consulta:

status = resolved and project = myproject or assignee = enrico

208

7.8. Auto-finalización de las consultas

llamado s el estado, p el proyecto y a el asignatario, JIRA la evaluaráde la siguiente forma:

(s = s0) ∧ (p = p0 ∨ a = a0) (7.7)

y devolverá las incidencias resueltas, que pertenezcan al proyecto p0o que hayan sido asignadas al usuario a0.

Si lo que se desea es buscar las incidencias resueltas del proyectop0 o las incidencias asignadas a a0 será necesario modificar la querypara establecer el órden en que se evalúen las proposiciones. Así comose detalló para otros tipos de búsqueda, en las búsquedas avanzadasse utilizarán las paréntesis para agrupar las sentencias. La query encuestión, por lo tanto, será:

(status = resolved and project = myproject) orassignee = enrico

Las paréntesis también permiten utilizar el operador not paranegar una proposición compuesta por otras proposiciones (utilizandoa = ¬a):

(a ∧ b) = a ∨ b (7.8)

y obtener una consulta más compacta. La consulta:

not (status = resolved and assignee = enrico)

equivale a la consulta:

status != resolved or assignee != enrico)

7.8 Auto-finalización de las consultas

La interfaz gráfica de búsquedas avanzadas de JIRA ofrece la fun-cionalidad de auto-finalización de las consultas: mientras el usuariova tecleando la consulta JQL, JIRA va sugiriendo como sería posible“completar” la consulta, tanto en lo que concierne los operadores, lasfunciones y las palabras claves, como en lo que concierne los valoresde los campos. La tecnología de auto-finalización determina de for-ma “inteligente” y de acuerdo a los datos introducidos por el usuarioaquellos fragmentos de consulta que, probablemente, el usuario irá ateclear.

Si, por ejemplo, un usuario desea teclear la consulta:

assignee = enrico

209


y comienza a teclearla en el navegador de incidencias, en cuanto hayateclado el carácter a, JIRA sugerirá al usuario los dos campos cuyonombre comienza por “a”, es decir, affectedVersion y assignee,como ilustrado en Figura 7.2. El usuario, entonces, podrá seleccio-

Figura 7.2: Auto-finalización de un campo en una consulta JQL.

nar de la forma más cómoda (con el teclado o con el ratón) el campodeseado. Después de haber seleccionado el campo, el usuario teclearáun espacio y JIRA sugerirá los operadores que pueden utilizarse conel campo en cuestión, como ilustrado en Figura 7.3. Después de

Figura 7.3: Auto-finalización de un operador en una consulta JQL.

haber seleccionado el operador y haber tecleado otro espacio, JIRAsugerirá al usuario una posible lista de valores para el campo y eloperador que se han introducidos. En Figura ?? pueden verse losusuarios sugeridos por JIRA después de que el usuario teclease unae: el nombre o la dirección de correo electrónico de los usuarios queaparecen en el menú desplegable de sugerencia comienzan todos conla letra e.

El auto-finalización inteligente de consultas JQL es una herra-mienta poderosa que facilita mucho la labor de los usuarios a la hora

210


Figura 7.4: Auto-finalización de un valor en una consulta JQL.

de crearse una query JQL. A menudo no será siquiera necesario re-cordar perfectamente los nombres de los campos, de los operadoreso de las funciones que JIRA pone a disposición: será la herramientamisma quién facilitará al usuario los posibles términos a introducir y,por lo tanto, permitirá la creación de consultas de una forma rápiday con errores mínimos.

Cuando se está tecleando una consulta, además, JIRA informaal usuario si la consulta que aparece en pantalla es válida o no. EnFigura 7.3, por ejemplo, puede verse una señal de aviso, identifica-da por un triángulo amarillo con un punto exclamativo ( ), encimadel control en el cual se escriben las consultas JQL. En este caso laconsulta es inválida, todavía, ya que falta por introducir tanto unoperador como un valor. En Figura 7.4, sin embargo, puede verseque JIRA informa el usuario que la consulta es válida con un círculoverde y un “tick” ( ).

La funcionalidad de auto-finalización puede ser inhabilitada por eladministrador de JIRA a nivel global. Si la instancia de JIRA que seestá utilizando no proporciona esta funcionalidad, será necesario so-licitar a los administradores de la plataforma que habiliten la misma.El usuario que lo desee, además, puede inhabilitar la auto-finalizacióndurante la composición de una consulta en el navegador de incidenciautilizando el check-box Auto-complete debajo del campo de texto enque se teclea la consulta, ilustrado en Figura 7.5.

El mecanismo de auto-finalización ofrece una lista de opciones enlas siguientes situaciones:

(i) Tecleando un espacio al principio de una consulta.(ii) Tecleando algún carácter.(iii) Tecleando un espacio después del nombre de un campo.(iv) Tecleando un espacio después de un campo y un operador.

211


Figura 7.5: Formulario de creación de consultas JQL.

(v) Teclando algún carácter después de un campo y un operador.

El conjunto de resultados propuestos por JIRA será compuesto porlos primeros 15 elementos que pueden completar el fragmento de con-sulta.

Si se teclea un espacio al principio de una consulta, (i), JIRAsugerirá los campos y los operadores con los cuales se puede comen-zar la misma. En Figura 7.6, por ejemplo, puede verse la lista de

Figura 7.6: Auto-finalización de un campo en una consulta JQL.

sugerencias con algunos campos y el operador not.

212


Si se teclea algún carácter al principio de una consulta, (ii), JIRApropondrá la lista de campos cuyo nombre comienza con los caracte-res introducidos. En Figura 7.7 puede verse la lista de sugerenciascuando el usuario introduce como primer carácter la letra d.

Figura 7.7: Auto-finalización en consultas JQL — Selección de campos.

Cuando el usuario teclea un espacio después del nombre de uncampo, (iii), JIRA propondrá la lista de operadores que pueden uti-lizarse con el mismo. En Figura 7.8 puede verse como, cuando elusuario teclea un espacio después del campo due, aparece la lista desugerencias que contiene los operadores soportados por dicho campo.

Figura 7.8: Auto-finalización en consultas JQL — Selección deoperadores.

Después de haber seleccionado el campo y el operador y tecleandoun espacio, (iv), JIRA proporcionará la lista de valores o funcionesque pueden completar la consulta introducida hasta ahora. En Figu-

213


ra 7.9 puede verse como, cuando el usuario teclea un espacio despuésdel campo due y del operador >, aparece la lista de sugerencias quecontiene las funciones soportados por la combinación de campo y ope-rador introducida. Según el usuario vaya tecleando otros caracteres,

Figura 7.9: Auto-finalización en consultas JQL — Selección de valores yfunciones.

(v), JIRA filtraría la lista de resultados para enseñar exclusivamentelos resultados que comiencen con los caracteres que el usuario estátecleando.

7.9 Modificar una búsqueda avanzada con la interfaz debúsqueda simple

Como subrayado múltiples veces a lo largo de §6, la interfaz de bús-queda simple no permite construir todas las consultas que puedenexpresarse con el lenguaje JQL. En §6.1.7 se ilustró como utilizarla interfaz de búsqueda avanzada para modificar algunas consultassimples, en casos muy sencillos.

Después de haber aportado una modificación que no puede im-plementarse en la interfaz de búsqueda simple, no es posible volvera ésta interfaz y JIRA avisará el usuario con un mensaje. Los casosen que no es posible volver a la interfaz de búsqueda simple son lossiguientes:

(i) La consulta contiene el operador or (∨).(ii) La consulta contiene el operador not (¬).(iii) La consulta contiene el operador empty (∅).(iv) La consulta contiene un operador de comparación: !=, is, is

not, <, <=, > o >=.

214

7.9. Modificar una búsqueda avanzada con la interfaz de búsqueda simple

(v) La consulta contiene un campo relacionado con un proyecto perono incluye explícitamente un criterio sobre el proyecto (véaseEjemplo 7.27).

Ejemplo 7.27. Una consulta JQL contiene un criterio que filtra lasincidencias por el campo fixVersion:

fixVersion = 1.0

De acuerdo al elemento (iv) de la lista de excepciones detallada en§7.9, la consulta no podrá expresarse a través de la interfaz de búsque-da simple, ya que no contiene explicitamente un criterio que utilice elcampo project.

Sin embargo si el usuario ha introducido la siguiente consulta JQL:

fixVersion = 1.0 and project = JRAGD

podrá volver a la interfaz de búsqueda simple ya que ésta cumple conlos requerimientos de dicho elemento.

215

8Grabar una búsqueda en un filtro

JIRA permite grabar una búsqueda para poder almacenarla y utili-zarla cuando sea necesario sin necesidad de volver a introducirla, yasea en la interfaz de búsqueda simple o en la interfaz de búsquedaavanzada.

La funcionalidad de los filtros va más allá del simple “almacena-miento”. Los filtros son “objetos” sofisticados de JIRA que pueden:

(i) Utilizarse de forma sencilla, a través del interfaz web de usuariosde JIRA.

(ii) Buscarse.(iii) Compartirse con otros usuarios.(iv) Protegerse, a través de políticas de seguridad.(v) Modificarse y clonarse, para crear nuevos filtros.

La importancia de los filtros reside, además, en su capacidad deactuar como fuente de datos para otros “objetos” de JIRA. Los fil-tros, en este sentido, “representan” el conjunto de resultados de unabúsqueda y pueden utilizarse para:

(i) Visualizar los resultados en el navegador de incidencias. Losusuarios podrán utilizar las herramientas de esta ventana paraactuar sobre los resultados como en el caso de, por ejemplo, unaexportación a otro formato (§9).

(ii) Visualizar los resultados en un reporte.(iii) Utilizar los resultados en un gadget del cuadro de mandos.(iv) Recibir notificaciones sobre los resultados del filtro.

Ejemplo 8.1. En un proyecto en el cual se definen acuerdos de nivelde servicio es necesario establecer la prioridad, organizar la asignación

217

8. Grabar una búsqueda en un filtro

y determinar el orden de resolución de las incidencias, con el fin derespetar los niveles de servicios establecidos.

En este caso de uso los responsables de proyecto pueden definirun conjunto de filtro, de acuerdo a los parámetros que considerenoportunos, que devuelvan el estado de las incidencias en cada nivel deservicio y, utilizando estos datos, vayan estableciendo las prioridadesdel trabajo.

Si, por ejemplo, se están utilizando los siguientes 3 niveles deservicio:

(i) Platinum: tempo de respuesta máximo de 1 hora.(ii) Gold: tempo de respuesta máximo de 4 horas.(iii) Silver : tempo de respuesta máximo de 8 hora.

se podrán crear filtros que devuelvan las incidencias en cada nivel queno se hayan comenzado a investigar después de un tiempo αt, donde elparámetro α podrá ajustarse de acuerdo a la experiencia acumulada yal flujo de trabajo que vaya entrando. En el caso α = .5, dichos filtrosdevolverán las incidencias que todavía estén sin comenzar después de:

(i) Platinum: 30 minutos.(ii) Gold: 2 horas.(iii) Silver : 4 horas.

Los resultados de los filtros podrán utilizarse para crear notifica-ciones o reportes en cuadros de mandos personalizados y permitir alos responsables de proyecto de tener una imagen del estado del ser-vicio actualizada en tiempo real y de ser avisados tempestivamenteen el caso en que empiecen a observarse síntomas de retraso en las la-bores desempeñadas por los miembros del equipo para tomar cuantoantes medidas vueltas a mitigar el riesgo que se está corriendo.

En el ejemplo 8.4 se verá que mecanismos pueden utilizarse paracomunicarse tempestivamente con los operadores.

8.1 Organización de los filtros

Los filtros son objetos que, por defecto, “pertenecen” al usuario queles ha creado y, por lo tanto, están visibles exclusivamente en sussesiones de trabajo.

Muchas búsquedas, sin embargo, pueden cubrir las necesidadesde muchos usuarios. Los resultados de una búsqueda, por ejemplo,puede proporcionar “indicadores” que pueden utilizarse en cuadros de

218

8.2. Creación de un filtro

mandos de muchos perfiles de usuarios tales como jefes de equipo, decomponente o, incluso, clientes que utilicen JIRA como herramientade “comunicación” con otros equipos. Por esta razón, los filtros pue-den protegerse con políticas de seguridad que permiten compartirlescon un selecto conjunto de identidades. Todo usuario que tenga per-miso para acceder a un filtro, podrá disponer de él para ejecutarlo yobtener los resultados de la búsqueda o para utilizarlo como fuentede datos.

Los filtros pueden también ser objeto de búsquedas: los usuarios,a través de un buscador, podrán examinar los filtros existentes1 ycomprobar si existe un filtro que satisface sus necesidades.

Los filtros utilizados frecuentemente por un usuario pueden sermarcados como filtros favoritos. De esta forma, el usuario podráacceder a ellos de forma más fácil y rápida ya que JIRA destacarálos favoritos en todos los controles que permiten acceder a los filtrostal como, por ejemplo, el menú Issues de la barra de herramientas deJIRA, como ilustrado en Figura 8.1.

8.2 Creación de un filtro

Para crear un filtro es necesario crear la búsqueda que se desea gra-bar; el usuario podrá grabar una búsqueda creada con cualquiera delas herramientas proporcionadas por JIRA, como explicado en los ca-pítulos §6 y §7. Cuando el usuario ha creado una consulta, en laspestañas New o Edit del panel izquierdo de la ventana del navegadorde incidencias, JIRA proporcionará al usuario la posibilidad de grabarla consulta corriente en un filtro. En Figura 8.2 puede ver el controlde creación de filtros (el enlace Save it as a filter) en dos detallesdel panel izquierdo del navegador de incidencia. En la figura a laizquierda puede verse el control en la pestaña Summary del panel,mientras que en la figura a la derecha puede verse el mismo controlen la pestaña Edit. En ambos casos el control, así como otras opera-ciones, estará en la sección Operations del panel, junto a las demásoperaciones que, en cada caso, puedan efectuarse en ese momento.

Para crear un filtro, es necesario efectuar las siguientes operacio-nes:

(i) Seleccionar el enlace Save it as a filter. El usuario será llevadoa la ventana de creación de filtro.

1Un usuario, incluso a través del buscador de filtros, podrá tener acceso ex-clusivamente al conjunto de filtros para los cuales tiene los permisos necesarios.

219


Figura 8.1: Filtros favoritos en la barra de herramientas de JIRA.

Figura 8.2: Creación de filtros.

220

8.2. Creación de un filtro

(ii) En la ventana de creación de filtros, visible en Figura 8.3,el usuario podrá establecer el nombre y la descripción del filtrotecleándolos, respectivamente, en el control Name y Descriptiondel formulario.

Figura 8.3: Ventana de creación de filtros.

(iii) Por defecto, un filtro creado por uno mismo es un filtro favori-to (§8.1), como puede verse por el control identificado con unicono “estrella amarilla” ( ) en el formulario de creación de fil-tro. Para crear el filtro sin añadirlo a la lista de los favoritos,deseleccionar este control con un click del botón izquierdo delratón: éste control actúa como un “interruptor”, el mismo sevolverá “gris” ( ) y el filtro se excluirá de los favoritos.

(iv) En el control Shares se detallan las listas de identidades con lascuales se compartirá el filtro. Por defecto, un filtro se compartecon las identidades especificadas en el perfil de usuario. Si no seha especificado ninguna preferencia, se utilizará la preferenciaglobal, configurada por el administrador. Por defecto, un filtroes privado y no se comparte con nadie.

(v) Opcionalmente, y siempre que el usuario posea el permiso Crea-te shared object, se pueden añadir las identidades con las cualesse desea compartir el filtro utilizando el control Add Shares delformulario. Véase §8.8 para obtener mayores detalles sobre co-mo compartir filtros con otros usuarios.

221


8.3 Sumario de un filtro

Cuando se ha seleccionado un filtro, en la barra de búsqueda delnavegador de incidencias aparece la pestaña Summary. En esta partede la ventana se ofrece un resumen de las características de un filtroasí como las operaciones disponibles que el usuario conectado puedeefectuar.

En Figura 8.4 puede verse el sumario de un filtro de un usuario.En la parte superior de la ventana, en la sección summary, se resume

Figura 8.4: Sumario de un filtro.

la siguiente información:

(i) Nombre del filtro.(ii) Estado del flag favorito.(iii) Criterio de búsqueda del filtro.

El estado del flag favorito será indicado con un control identificadocon el icono “estrella amarilla” ( ) o “estrella gris” ( ) si el filtro es,respectivamente, un filtro favorito o no. El control podrá utilizarsepara cambiar este flag y añadir o remover el filtro seleccionado de lalista de favoritos del usuario conectado.

El criterio de búsqueda del filtro será resumido de forma distintadependiendo de si el criterio de búsqueda es un criterio simple (§6) oavanzado (§7). Si la búsqueda es una búsqueda simple, se proporcio-nará la lista de los campos de búsqueda seleccionados por el creadordel filtro así como el valor seleccionado. Por otro lado, en el caso

222

8.4. Gestión de filtros

en que la búsqueda fuese avanzada, se proporcionará el texto de laconsulta en el lenguaje de query de JIRA.

En la sección Operations de la ventana de sumario JIRA ofrecerála lista de operaciones que el usuario puede efectuar sobre el filtro.Las operaciones disponibles dependerán de varios factores tales comoel autor del filtro y los privilegios del usuarios conectado.

Ejemplo 8.2. En la imagen de Figura 8.4 puede apreciarse comoel filtro se llame Unresolved issues y sea un filtro favorito del usuario(indicado por el icono ).

La búsqueda del filtro es una búsqueda simple que específica loscriterios project y status y los resultados se devuelven ordenados porprioriy (prioridad) descendiente.

8.4 Gestión de filtros

La ventana de gestión de filtros permite ver, organizar y configurartanto los filtros propios como los filtros compartidos por otros usua-rios. Para acceder a esta ventana es necesario seleccionar la operaciónManage filters en el menú Issues en la barra de herramientas de JIRA(Figura 8.5).

Figura 8.5: Menú Issues — Operación Manage filters.

223


Esta ventana está compuesta por las siguientes pestañas:

(i) Favorite: en esta pestaña el usuario tiene acceso directo a susfiltros favoritos (Figura 8.6).

Figura 8.6: Ventana de gestión de filtros — Pestaña Favorite.

(ii) My: en esta pestaña el usuario tiene acceso directo a sus filtros.(iii) Popular : en esta pestaña, similar a la pestaña precedente, el

usuario tiene acceso a los filtros populares, es decir, los filtrosque muchos usuarios han marcados como favoritos. En estapestaña JIRA propondrá al usuario los 20 filtros más popularesentre los filtros al que el usuario tenga acceso.

(iv) Search: en esta pestaña, similar a la pestaña precedente, elusuario puede efectuar búsquedas de filtros (Figura8.7).

Figura 8.7: Ventana de gestión de filtros — Pestaña Search.

En esta ventana un usuario podrá:

(i) Buscar filtros.(ii) Añadir o remover filtros de la lista de favoritos.(iii) Modificar y actualizar los filtros creados por él mismo.

224

8.5. Eliminar un filtro de la lista de favoritos

8.5 Eliminar un filtro de la lista de favoritos

El usuario puede modificar la lista de filtros favoritos añadiendo nue-vos filtros o eliminando los filtros que ya no le interesan.

Para eliminar un filtro de la lista de favoritos es necesario efectuarlas siguientes operaciones:

(i) Localizar el filtro a eliminar de la lista de favoritos. El filtropuede buscarse a través del buscador de filtros (§??) o nave-gando a la pestaña Favorite de la ventana de gestión de filtros,ilustrada en Figura 8.6.

(ii) Eliminar el filtro de la lista seleccionando el control identificadocon un icono “estrella amarilla” ( ). Después de la eliminaciónel control se volverá gris ( ) y se mostrará un aviso de elimi-nación a través del cual, en el caso la eliminación hubiera sidoaccidental, se podría anular la operación. En Figura 8.8 pue-de verse el aviso de eliminación y el control de anulación de laoperación, el enlace Undo.

Figura 8.8: Aviso de eliminación de filtro favorito.

8.6 Añadir un filtro a la lista de favoritos

Todos los filtros creados por un usuario, por defecto y siempre queno se haya explícitamente modificado esta opción (§8.2), son filtrosfavoritos. Para añadir un filtro existente a la lista de filtros favoritoses necesario efectuar las siguientes operaciones:

(i) Localizar el filtro a eliminar de la lista de favoritos. El filtropuede buscarse a través del buscador de filtros (§??) o nave-gando a la pestaña Favorite de la ventana de gestión de filtros,ilustrada en Figura 8.6.

225


(ii) Añadir el filtro a la lista de filtros favoritos utilizando el controlidentificado con un icono “estrella gris” ( ). Después de haberañadido el filtro el control se volverá amarillo ( ).

8.7 Modificación de los atributos de un filtro

Durante la creación de un filtro se establecen los siguiente algunosatributos del filtro:

(i) Nombre.(ii) Descripción.(iii) Favorito.(iv) Identidades con los cuales se comparte.

El usuario al que pertenezca el filtro puede modificar estos atri-butos en cualquier momento efectuando las siguientes operaciones:

(i) Localizar el filtro a modificar. El filtro puede buscarse a travésdel buscador de filtros (§??) o accediendo a la pestaña My en laventana de gestión de filtros (§8.4) en la cual se enumeran losfiltros creados por el usuario conectado.

(ii) Seleccionar la operación Edit en la columna Operations paraacceder a la ventana de modificación de filtros que puede verseen Figura 8.9.

Figura 8.9: Ventana de modificación de un filtro.

226

8.8. Compartir un filtro con otros usuarios

(iii) En la ventana de modificación pueden introducirse los nuevosvalores para los atributos que se desean modificar. Si se deseanmodificar las identidades con las cuales se quiere compartir elfiltro es necesario seguir las instrucciones detalladas en §8.8.

(iv) Seleccionar el botón Save para confirmar la operación.

8.8 Compartir un filtro con otros usuarios

Un filtro es una entidad que puede compartirse con otros usuariospara favorecer la creación y la explotación de fuentes de datos quepuedan ser de utilidad general, por ejemplo para proporcionar datosa utilizarse en la generación de reportes.

Compartir filtros con otros usuarios también permite “separar” losusuarios que explotan la información de los usuarios que organizan lainformación y puede ser beneficioso en algunos casos de uso, como losilustrados en los ejemplos de esta sección.

Sin embargo, la compartición de una entidad genera un acopla-miento entre proveedores y consumidores de la información. Esteacoplamiento debe gestionarse adecuadamente como una dependen-cia y solo a través de coordinación es posible garantizar que eventua-les modificaciones se hagan con el conocimiento y, eventualmente, elacuerdo de los usuarios.

Los filtros pueden compartirse al momento de la creación (§8.2)o posteriormente, modificando un filtro existente. En ambos casos,tanto el procedimiento como la interfaz gráfica utilizada para efectuaresta operación son los mismos.

Para poder compartir un filtro es necesario tener el permiso Createshared object. Si el usuario no dispone de este permiso en las ventanasde creación y modificación de filtro no serán visibles los controles paracompartir el filtro.

Para modificar las identidades con las cuales se desea compartirel filtro es necesario efectuar las siguientes operaciones:

(i) Si se desea compartir el filtro durante su creación, pasad direc-tamente a (iii).

(ii) Localizar el filtro a compartir. El filtro puede buscarse a travésdel buscador de filtros (§??) o accediendo a la pestaña My en laventana de gestión de filtros (§8.4) en la cual se enumeran losfiltros creados por el usuario conectado.

(iii) En la ventana de modificación del filtro pueden añadirse lasidentidades con las cuales se desea compartir el filtro y elimi-

227


narse las identidades con las cuales no se desea seguir compar-tiendo el mismo. En Figura 8.10 pueden verse los controlesShares y Add Shares que deben utilizarse para llevar a caboesta configuración.

Figura 8.10: Controles para la modificación de las identidades con lascuales se comparte un filtro.

(iv) El control Shares detalla las identidades con las cuales se estácompartiendo un filtro. Para eliminar una identidad con la cualya no se desea seguir compartiendo el filtro corriente es necesarioutilizar el control identificado con el icono “basura” ( ).

(v) El control Add Shares contiene una serie de menú a través delos cuales puede seleccionarse la identidad a añadir a la listade usuarios que comparten el filtro. En el primer menú puedeseleccionarse el tipo de identidad:a) Everyone, para grabar un filtro público que pueda ser uti-

liado por cualquier usuario de JIRA.b) Group, para compartir el filtro con un grupo de usuarios.c) Project, para compartir el filtro con un rol de proyecto.

Si se desea añadir un grupo, habrá que seleccionar el elemen-to group en el control y JIRA propondrá, como ilustrado enFigura 8.11, la lista de grupos disponibles en otro control.

Figura 8.11: Compartir un filtro con un grupo de usuarios.

Si se selecciona añadir un rol de proyecto, habrá que seleccionarel elemento Project en el control y JIRA propondrá, como ilus-trado en Figura 8.12, la lista de proyectos disponibles y, paracada proyecto que se seleccione, un control con la lista de rolesdisponibles en el mismo.

228

8.8. Compartir un filtro con otros usuarios

Figura 8.12: Compartir un filtro con un rol de proyecto.

Para añadir la identidad seleccionada, pulsar el control Add,identificado con el icono “más” ( ) y repetir este paso hastaque se hayan añadido todas las identidades con las cuales sedesea compartir el filtro.

Ejemplo 8.3. En el ejemplo 8.1 se ha visto como los filtros puedenser fuentes de datos útiles a la hora de obtener la información que senecesita, de forma sencilla y actualizada en tiempo real.

Compartir filtros permite reutilizar los filtros existentes y, además,centralizar su gestión de forma que, si más que un proyecto está sujetoa las mismas políticas de servicio, no sea necesario modificar los filtrosde todos los proyectos sino, simplemente, el único filtro que todos losusuarios están compartiendo.

En el caso que estamos ilustrando, por ejemplo, el filtro en cues-tión podría ser utilizado poo el responsable de cualquier proyectosimplemente utilizando oportunamente la proposición

project = projectsLeadByUser

en el criterio de búsqueda utilizado por el filtro. De esta forma, elfiltro devolverá solo las incidencias que estén cumpliendo los criteriosilustrados en el ejemplo 8.1 en los proyectos gestionados por el usuarioque está utilizando el filtro.

Ejemplo 8.4. Los responsables del proyecto ilustrado en el ejemplo8.1, en que se ofrece soporte de 3 niveles y cada uno con tiemposde respuesta distintos, debe ser capaz de comunicar constantementecon sus operadores para que las incidencias de nivel más crítico sevayan solucionando con antelación sin dejar que sean los operadoresorganicen el trabajo según su albedrío.

Una de las formas de solucionar este problema, complementaria alos mecanismo estándar de JIRA tales como asignación y prioridadde incidencias, es proporcionar a los usuario un conjunto de filtros queles proporcione los datos que cumplan los criterios que se hayan esta-blecido a nivel de dirección de proyecto. De esta forma, en lugar de

229


dejar a los operadores la responsabilidad de examinar las incidenciasa ellos asignadas y determinar el orden de ejecución de las labores, sepodrá utilizar un filtro que les devuelva esta información.

Una ventaja adicional que deriva de la centralización en la gestiónde la información es que, en cada momento se decida modificar los pa-rámetros utilizados para establecer el orden de trabajo, será suficientemodificar los relativos filtros ya que los usuarios que los compartan,de forma inmediata, dispondrán de los datos actualizados.

Ejemplo 8.5. Con referencia al ejemplo 8.4, los campos que por de-fecto componen las incidencias de JIRA podrían resultar insuficientesa organizar la información requerida por los usuarios de forma efi-ciente.

El campo prioridad, a menudo utilizado para organizar el ordende trabajo sobre las incidencias, se compone de un número finito,normalmente reducido, de niveles. Utilizar este campo para ordenarlas incidencias, así como cualquier campo que adquiera un conjuntode valores de tamaño reducido, puede resultar ineficaz a los fines quenos proponemos.

Una solución comúnmente utilizada es la creación de campos per-sonalizados (§??) que puedan ordenarse (tales como los campos nu-méricos, véase §B.1.3) y utilizarlos como parámetros para establecerel orden de trabajo sobre las incidencias.

8.9 Buscar un filtro

Debido a que los filtros son una funcionalidad muy comúnmente uti-lizada por los usuarios de JIRA, no es inusual que en una instalaciónde la herramienta el número de filtros guardados sea elevado y que,por lo tanto, el número de filtros visibles a un usuario, tantos propioscomo compartidos por otros, sea grande.

Como descrito en precedencia, el usuario puede acceder rápida-mente a algunas categorías de filtros, los filtros favoritos, los filtrospropios y los filtros populares, utilizando respectivamente las pestañasFavorite, My y Popular de la ventana de gestión de filtros (§8.4).

Sin embargo si el usuario necesita encontrar un filtro que no estéen ninguna una de estas ventanas será necesario efectuar una búsque-da. Para facilitar esta tarea al usuario, JIRA ofrece el formulario debúsqueda de filtros, ilustrado en Figura 8.13, al que se puede accedera través de la pestaña Search de la ventana de gestión de filtros.

230

8.9. Buscar un filtro

Figura 8.13: Ventana de búsqueda de filtros.

A través del formulario de búsqueda, el usuario podrá acotar elconjunto de filtros examinados utilizando los siguientes parámetros:

(i) Nombre y descripción.(ii) Autor.(iii) Identidades con las que se comparte.

Para buscar un filtro es necesario efectuar las siguientes operacio-nes:

(i) Acceder a la ventana de gestión de filtros, seleccionando la ope-ración Manage filters en el menú Issues en la barra de herra-mientas de JIRA.

(ii) Acceder a la ventana de búsqueda de filtros seleccionando lapestaña Search en la ventana de gestión de filtros.

(iii) Si se desea efectuar una búsqueda de texto en el nombre o enla descripción del filtro, introducir el criterio de búsqueda en elcontrol Search.

(iv) Si se desea buscar entre los filtros creados por un usuario, intro-ducir el nombre del usuario en el campo Author. Alternativa-mente, seleccionar el usuario utilizando la ventana de selecciónde usuarios a la que se puede acceder a través del control iden-tificado por el icono ( ) situado a la derecha del control Author.

(v) Si se desea buscar entre los filtros que están compartidos conuna identidad, seleccionar la identidad deseada en el controlShared with. El funcionamiento de este control es parecido aldel control Add shares que ha sido detallado en §8.8.

(vi) Para confirmar la búsqueda, seleccionar el botón Search.

Los resultados de búsqueda serán visualizados en la parte inferiorde la ventana, como ilustrado en Figura 8.14. Los resultados podrán

231


Figura 8.14: Resultados de búsqueda de filtros.

ordenarse por los valores contenidos en algunas columnas, tales comoName y Author, seleccionando el título de la columna en la cabecerade la tabla de resultados.

Seleccionando el nombre de un filtro en la lista de resultados,JIRA establecerá el filtro seleccionado como filtro corriente y llevaráel usuario directamente a la ventana de resultados de la búsquedaasociada al filtro.

8.10 Copiar un filtro existente

Como explicado en §8.1, la funcionalidad de compartición de filtrospermite centralizar la gestión de estas fuentes de datos y separar losusuarios que explotan la información de los usuarios que organizan lainformación. Esta funcionalidad también genera acoplamiento entreproveedores, quienes definen un filtro compartido, y consumidores,quienes utilizan el filtro.

En determinadas circunstancias, por lo tanto, los usuarios podríanpreferir no tener que depender de un filtro que está fuera de su control:de esta forma no correrán los “riesgos” relacionados con la dependen-cia con entidades de este tipo. El creador, por ejemplo, podría dejarde compartir un filtro o, incluso, eliminarlo. El creador podría tam-bién modificar el criterio de búsqueda de un filtro y, por lo tanto,quiénes estén utilizando esa fuente de datos podrían estar recibiendodatos que no corresponden a la búsqueda que están esperando.

Para minimizar el trabajo del usuario en las situaciones en las cua-les no es deseable acoplarse a un filtro compartido JIRA proporcionala posibilidad de clonar un filtro existente: de esta forma, el usuariopodrá crear una “copia” de un filtro y grabarlo en un filtro nuevo.

232

8.11. Modificación de un filtro

La misma técnica puede utilizarse también cuando quiere crearseun filtro nuevo “comenzando” con los criterios grabados en otro filtro,incluso del mismo usuario que está efectuando la copia.

Para copiar un filtro, es necesario efectuar las siguientes operacio-nes:

(i) Localizar y seleccionar el filtro que se desea copiar.(ii) Seleccionar la pestaña Summary del panel de búsqueda.(iii) Si el filtro es un filtro compartido por otro usuario, la lista

de operaciones disponibles será reducida y parecida a la listailustrada en Figura 8.15 (izquierda). Para copiar el filtro deotro usuario es necesario seleccionar la operación Create newfilter from current.

Figura 8.15: Resultados de búsqueda de filtros.

(iv) Si el filtro es un filtro propio, la lista de operaciones será pareci-da a la lista ilustrada en Figura 8.15 (derecha). Para copiar unfiltro propio es necesario seleccionar la operación Save as newfilter.

Después de haber copiado el filtro se procederá como durante lacreación de un filtro cualquiera. Las instrucciones para configurar unnuevo filtro están detalladas en §8.2.

8.11 Modificación de un filtro

Un usuario no podrá modificar filtros que no le pertenezcan: en estecaso la única operación permitida será la copia (§8.10) y la modifi-

233


cación de la misma. El autor de un filtro, por el otro lado, puedemodificar el criterio de búsqueda asociado al mismo en cualquier mo-mento. Sin embargo, por las razones explicadas en precedencia, esaconsejable que un usuario que esté compartiendo un filtro con otrosusuarios no modifique un filtro sin haberlo comunicado a los usuariosque lo pueden estar utilizando.

Para modificar el criterio de búsqueda de un filtro es necesarioefectuar las siguientes operaciones:

(i) Localizar y seleccionar el filtro que se desea copiar.(ii) Seleccionar la pestaña Edit del panel de búsqueda.(iii) Modificar el criterio de búsqueda en el navegador de incidencias

así como explicado en los Capítulos §6 y §7, dependiendo deltipo de búsqueda que se desee utilizar.

(iv) Si se utiliza la interfaz de búsqueda avanzada para modificarel criterio de búsqueda, como ilustrado en Figura 8.16, lasoperaciones disponibles serán visibles en la sección Operationsde la pestaña Edit, en el lado izquierdo de la página. JIRA

Figura 8.16: Modificación del criterio de búsqueda de un filtros.

informará al usuario de que existen modificaciones al filtro singrabar a través del mensaje Filter modified since loading quepuede apreciarse en el lado izquierdo de la ventana.

(v) Si se utiliza la interfaz de búsqueda simple para modificar el cri-terio de búsqueda, como ilustrado en Figura 8.17, las operacio-nes disponibles no serán visibles en la pestaña Edit y solo seránaccesibles en la pestaña Summary. JIRA informará al usuariode que existen modificaciones al filtro sin grabar a través delmensaje Filter modified since loading que puede apreciarse enel lado izquierdo de la ventana.

234

8.12. Configurar el orden de columnas de un filtro

Figura 8.17: Modificación del criterio de búsqueda de un filtros.

(vi) Para grabar las modificaciones en el filtro, seleccionar la opera-ción Save changes to filter. Para grabar las modificaciones en unnuevo filtro y mantener el filtro original inalterado, seleccionarla operación Save as new filter.

8.12 Configurar el orden de columnas de un filtro

Como explicado en los capítulos dedicados a las tecnologías de bús-quedas ofrecidas por JIRA (§??), las columnas visualizadas para losresultados de búsqueda visualizados en el navegador de incidenciasdependerán de las configuraciones que se hayan establecido tanto anivel de perfil de usuario como a nivel de sistema.

La configuración del navegador de incidencia se determina nave-gando una jerarquía de configuraciones, ilustradas en Figura 8.18: laconfiguración que queda establecida es la primera configuración queJIRA encuentra a partir del nivel más bajo de la jerarquía.

Figura 8.18: Jerarquía de configuración del navegador de incidencias.

Sin embargo, los filtros añaden un elemento a esta jerarquía y JI-RA ofrece la posibilidad de “ignorar” las configuraciones mencionadasy asociar a un filtro una configuración de columnas; la jerarquía deconfiguraciones que JIRA analiza en este caso es la jerarquía ilustra-da en Figura 8.19. De esta forma, si un filtro está asociado a unaconfiguración de columnas personalizada, ésta tendrá la precedenciacon respeto a las demás configuraciones y será la configuración que

235


Figura 8.19: Jerarquía de configuración del navegador de incidencias —Filtros.

quede establecida cuando JIRA visualice los resultados de búsquedade un filtro.

Por la naturaleza misma de los filtros y por el hecho de ser en-tidades que pueden compartirse entre usuarios, el autor de un filtropodría querer proporcionar a los usuarios que utilicen sus resulta-dos tanto el criterio de búsqueda como la configuración de columnasdevueltas. Si esto no fuera posible, usuarios con configuraciones dis-tintas que estuvieran utilizando el mismo filtro acabarían viendo losmismos resultados pero, potencialmente, distintas columnas. Depen-diendo de la naturaleza de la búsqueda asociada al filtro, este hechopodría perjudicar el usuario y su comprensión de los datos devueltos.

Ejemplo 8.6. El conjunto de columnas utilizadas por defecto en laconfiguración por defecto del navegador de incidencias de JIRA noincluye ninguna columna relacionada con el trabajo sobre las inci-dencias, como por ejemplo tiempo trabajado y porcentaje de trabajocompletado. Si un usuario deseara compartir un filtro cuyo criterio debúsqueda esté filtrando por columnas de este tipo, será aconsejableconfigurar el mismo de manera que dichas columnas aparezcan en losresultados; de esta forma, los usuarios que utilicen los datos que pro-ceden del filtro podrán ver los datos que el creador del filtro consideró“importantes” y que, por esa razón, utilizó en el criterio de búsquedadel mismo.

Para establecer la configuración de columnas asociada a un filtroes necesario efectuar las siguientes operaciones:

(i) Acceder a la ventana de configuración del orden de columnasdel filtro que se desea modificar. Se puede acceder a la ventanade configuración del orden de columnas de un filtro tanto des-de la ventana de gestión de filtros como desde el navegador deincidencia, cuando un filtro está seleccionado. Desde le venta-

236

8.12. Configurar el orden de columnas de un filtro

na de gestión de filtro, se puede utilizar la operación Columns(Figura 8.20) del filtro que se desea modificar.

Figura 8.20: Ventana de gestión de filtros - Operaciones.

Desde la ventana del navegador de incidencias, cuando el filtroa modificar está seleccionado, se puede utilizar la operación Setfilter’s columns order del menú Tools (Figura 8.21).

Figura 8.21: Navegador de incidencias - Configuración de columnas deun filtro.

(ii) En la ventana de configuración de columnas se puede configurarel orden de columnas del filtro de la misma forma en que se con-figura el orden de columnas del navegador de incidencias. Véase§6.3.1 para obtener mayores detalles sobre el procedimiento deconfiguración.

8.12.1 Modificar la configuración de columnas de un fil-tro

La configuración de columnas de un filtro puedemodificarse utilizandoel procedimiento detallado a continuación:

237


(i) Acceder a la ventana de configuración del orden de columnas delfiltro que se desea modificar siguiendo las instrucciones detalla-das en el la sección precedente (§8.12) teniendo en cuenta que,cuando un filtro ya está asociado a una configuración de colum-nas, la operación que aparece en el menú Tools del navegadorde incidencias será Edit filter’s column order, como ilustrado enFigura 8.22.

Figura 8.22: Navegador de incidencias — Menú Tools — Modificaciónde la configuración de columnas de un filtro.

(ii) Seguir las instrucciones detalladas en la sección precedente (§8.12)para modificar la configuración de columnas del filtro.

8.12.2 Eliminar la configuración de columnas de un fil-tro

La configuración de columnas de un filtro puede eliminarse para quelos resultados devueltos por un filtro vuelvan a mostrarse con la con-figuración de columnas establecida a nivel de perfil de usuario o, ensu defecto, a nivel de plataforma.

Para eliminar la configuración de columnas de un filtro es necesarioefectuar las siguientes operaciones:

(i) Acceder a la ventana de configuración del orden de columnas delfiltro que se desea modificar siguiendo las instrucciones detalla-das en el la sección precedente (§8.12) teniendo en cuenta que,cuando un filtro ya está asociado a una configuración de colum-nas, la operación que aparece en el menú Tools del navegadorde incidencias será Edit filter’s column order, como ilustrado enFigura 8.22.

238

8.13. Utilizar la configuración de columnas por defecto

(ii) Seleccionar la operación Remove filter’s column order (Figura8.23) para eliminar la configuración de columnas asociada alfiltro.

Figura 8.23: Navegador de incidencias — Eliminar configuración decolumnas de un filtro.

8.13 Utilizar la configuración de columnas por defecto

En las secciones precedentes hemos visto como JIRA proporciona unagrande flexibilidad a la hora de configurar las columnas a utilizar-se en el navegador de incidencias. En determinadas situaciones, noobstante, un usuario quisiera utilizar una configuración de columnasdistintas a la establecida en el filtro. Esta situación cobra mayor im-portancia en el caso en que se esté utilizando un filtro compartido porotro usuario y, por lo tanto, no pueda modificarse su configuración deorden de columnas.

Para utilizar la configuración de columnas del usuario, determina-da con el procedimiento detallado en §8.12, puede utilizarse la ope-ración Use your default column order del menú Tools del navegadorde incidencias, como ilustrado en Figura 8.24 izquierda. Si se deseavolver a utilizar la configuración de columnas especificada por el filtrocorriente, será suficiente utilizar la operación Use filter’s column orderdel menú Tools (Figura 8.24 derecha) para que JIRA presente los re-sultados del filtro corriente en el navegador de incidencias utilizandodicha configuración.

239


Figura 8.24: Navegador de incidencias — Selección de la configuraciónde columnas.

8.14 Configuración de columnas y exportación de datos

A lo largo de este capítulo se han ilustrado las funciones que ofreceJIRA para compartir filtros entre usuarios y personalizar, incluso, lascolumnas que JIRA visualice cuando ofrezca los resultados al usuario.Sin embargo, la configuración del orden de columnas no afecta sóloa los resultados visualizados en la ventana del navegador de inciden-cias: como se verá en el siguiente capítulo, JIRA permite exportarlos resultados de búsquedas en múltiples formatos para permitir alusuario de explotar los datos más fácilmente. Como se verá, la confi-guración de columnas afectará la operación de exportación de datosya que, en determinadas circunstancias, ésta determinará cuales seránlas columnas exportadas.

240

9Explotar los resultados de búsqueda

En los capítulos precedentes se ha visto como los filtros permitengrabar criterios de búsquedas para, entre otras cosas, utilizarlos comofuente de datos en objetos como los gadgets.

Sin embargo, los resultados de una búsqueda o de un filtro puedenexplotarse tanto dentro JIRA, como por ejemplo para generar reporteso gráficos en el cuadro de mandos, como fuera de JIRA. JIRA, a travésdel navegador de incidencias, permite exportar los resultados de unabúsqueda a muchos formatos de uso común, entre los cuales:

(i) XML.(ii) Microsoft Word.(iii) Microsoft Excel.(iv) Correo electrónico.

9.1 Suscribirse a un filtro

JIRA permite a los usuarios suscribirse a un filtro y recibir perió-dicamente, de forma automática, los resultados de los filtro a travésde un correo electrónico. El usuario podrá especificar la periodicidadcon la cual JIRA volverá a ejecutar el filtro y también si el usuariodesea recibir un correo incluso cuando el filtro no devuelve ningúnresultado.

Con esta funcionalidad, el usuario podrá observar la evoluciónde un conjunto de incidencias sin la necesidad de acceder a JIRAy, en algunos casos, emplear este mecanismo como una herramientade “notificación”: el lugar de controlar activamente el estado y laevolución de las incidencias a observar, JIRA “avisará” al usuarioenviándole los resultados.

241

9. Explotar los resultados de búsqueda

Ejemplo 9.1. Un proyecto debe garantizar un conjunto de acuerdosde nivel de servicio (ANS) y, para controlar más fácilmente el estadodel trabajo, el jefe de proyecto prepara un conjunto de filtros, unopara cada nivel de servicio a controlar, que devuelve la lista de inci-dencias que han pasado la fecha límite de resolución y están todavíasin resolver. Un fragmento de criterio de búsqueda que devuelve lasincidencias no resueltas que hayan sido creadas en los últimos n díases el siguiente:

... resolution = unresolved and created <= -nd ...

Mientras se respeten los acuerdos de nivel de servicio, los filtros encuestión no devolverán ningún resultado. Un usuario que se suscribaa ellos podrá elegir no recibir ningún correo hasta que los mismosdevuelvan algún resultado y, de esta forma, ser avisado en el momentoen que no se están respetando los acuerdos.

Para suscribirse a un filtro es necesario efectuar las siguientes ope-raciones:

(i) Localizar el filtro al que se desea subscribirse en la ventana degestión de filtros, siguiendo las instrucciones detalladas en §8.4.

(ii) Seleccionar la operación Subscribe en la columna Suscriptionsdel filtro al que se desea suscribirse, como ilustrado en Figura9.1.

Figura 9.1: Suscripción a filtro.

(iii) Rellenar el formulario de suscripción que JIRA presentará eilustrado en Figura 9.2 como detallado a continuación.

(iv) Seleccionar en el campo Recipients las identidades que recibiránlas notificaciones. Este campo permite seleccionar a uno mis-mo, escogiendo la opción Personal subscription, o a un grupocualquiera de los grupos de usuarios de la plataforma.

242

9.1. Suscribirse a un filtro

Figura 9.2: Formulario de suscripción a un filtro.

(v) Seleccionar el checkbox Email zero results si se desea recibir unanotificación incluso cuando el filtro no devuelve ningún resulta-do. Por defecto, este checkbox no está seleccionado.

(vi) Seleccionar la periodicidad con la cual se desea recibir las no-tificaciones escogiendo una de las opciones del campo Schedule.Las opciones disponibles están detalladas en §9.1.1.

(vii) Pulsar el botón Subscribe para suscribirse al filtro.

9.1.1 Periodicidad

La frecuencia que un usuario puede escoger cuando se suscribe a unfiltro es una de las siguientes:

(i) Daily: el usuario recibirá las notificaciones todos los días.(ii) Days per week: el usuario recibirá las notificaciones los días de

la semana que haya escogido.(iii) Days per month: el usuario recibirá las notificaciones los días

del mes que haya escogido.(iv) Advanced: el usuario recibirá las notificaciones como determi-

nado por la expresión de tipo cron que se haya introducido.

Seleccionando la opción Daily (i), el usuario recibirá las notifi-caciones todos los días a un intervalo prefijado, seleccionado con elcampo Interval, y a una hora prefijada, seleccionada con los camposat. Por defecto, el intervalo entre una notificación y otra son 24 ho-ras (once). Los valores que puede asumir el campo Interval estánresumidos en Tabla 9.1.

243


Intervalos24 horas3 horas2 horas1 hora30 minutos15 minutos

Tabla 9.1: Tipos de campos JQL.

Si el usuario selecciona recibir más que una notificación a lo largodel día y escoge por lo tanto un intervalo distinto del intervalo 24horas, JIRA proporcionará al usuario la posibilidad de seleccionar lafranja horaria dentro de la cual el usuario desea recibir las notifica-ciones. La franja horaria [t0, t1] se seleccionará especificando la horade comienzo t0 en el campo from y la hora de fin t1 en el campo to delformulario de suscripción ilustrado en Figura 9.3. De esta forma, se

Figura 9.3: Formulario de suscripción a un filtro — Selección de franjahoraria.

podrá evitar de recibir notificaciones inútilmente en horarios en loscuales el usuario no está interesado a ellas.

Seleccionando la opción Days per week (ii), el usuario recibirá lasnotificaciones con la frecuencia y en los días de la semana escogidos.En el formulario de Figura 9.4 el usuario podrá seleccionar los díasde las semanas en los cuales desea recibir las notificaciones marcando

244


los checkbox correspondientes a cada uno de ellos. Como en el caso

Figura 9.4: Formulario de suscripción a un filtro — Selección de días dela semana.

(i), el interval podrá asumir los valores especificados en Tabla 9.1y, cuando aplique, especificar la franja horaria en la cual recibir lasnotificaciones como explicado anteriormente.

Seleccionando la opción Days per month (iii), el usuario recibirálas notificaciones en el día del mes y el ha hora escogida. En elformulario de Figura 9.5 el usuario podrá seleccionar el día del mesen el cual desea recibir las notificaciones de dos formas:

(i) Especificando el ordinal del día.(ii) Especificando el día de la semana y el ordinal de la semana del

mes.

Como en los casos precedentes, el momento en que se desea recibir lanotificación se escogerá utilizando los controles at.

Si la periodicidad con la cual el usuario desea recibir las notifica-ciones no encaja con ninguna de las opciones descritas en precedencia,éste puede utilizar la modalidad avanzada seleccionando Advanced enel control Schedule. En esta modalidad, el usuario podrá especificar

245


Figura 9.5: Formulario de suscripción a un filtro — Selección de días delmes.

una expresión de tipo cron en el campo Cron expression, ilustradoen Figura 9.6. cron es un planificador de procesos utilizado en los

Figura 9.6: Formulario de suscripción a un filtro — Expresión cron.

sistemas operativos UNIX y UNIX-like cuya sintaxis de los ficherosde configuración, muy conocida, puede ser utilizada por los usuariosde JIRA para definir suscripciones avanzadas.

La sintaxis de los ficheros de configuración de cron es la siguiente:

•︸︷︷︸segundos

•︸︷︷︸minutos

•︸︷︷︸horas

•︸︷︷︸día del mes

•︸︷︷︸mes

•︸︷︷︸día de la semana

•︸︷︷︸año

(9.1)

246


Los campos, separados por espacios, pueden asumir los valores espe-cificados en Tabla 9.2 teniendo los caracteres especiales el significadodetallado en Tabla 9.3.

Campo Valores Caracteres especialesSegundos [0, 59] , - * /Minutos [0, 59] , - * /Horas [0, 23] , - * /Día del mes [1, 31] , - * / ? L WMes [1, 12] o [Jan, Dec] , - * /Día de la semana [1, 7] o [Sun, Sat] , - * / ? L #Año [1970, 2099] , - * /

Tabla 9.2: Valores de los campos de una expresión cron de JIRA.

Carácter especial Significado* Todos los posibles valores., Lista de valores.- Intervalo de valores./ Incremento sobre un valor.? Ningún valor.L Último posible valor.W Día de la semana (de lunes a viernes).# n-esima ocurrencia de un día de la semana.

Tabla 9.3: Significado de los caracteres especiales de una expresión cronde JIRA.

Ejemplo 9.2. Para recibir una notificación cualquier día de la sema-na a las 10.00 de la mañana se puede utilizar la expresión:

0 0 10 ? * *

Ejemplo 9.3. Para recibir una notificación cualquier día de la se-mana, cada minuto entre las 10.00 y las 11.00 se puede utilizar laexpresión:

0 * 10 * * ?

247


9.1.2 Cualquier valor

El carácter * se utiliza para asignar cualquier valor válido a un cam-po1:

. . * . . . .

En este caso, se está asignando al campo hora cualquier valor válido,es decir, todos los valores del intervalo [0, 23].

El carácter ?, sin embargo, se utiliza cuando se necesita especificarun valor a uno de los campos días del mes o día de la semana peroninguno al otro2:

. . . ? . * .

En este caso, se está asignando cualquier al campo día del mes ycualquier valor al campo día de la semana.

9.1.3 Listas de valores

El carácter , se utiliza para separar valores y asignar listas de valoresa un campo3:

. . 9,12 . . . .

En este caso, se están asignando al campo hora los valores 9 y 12.

Ejemplo 9.4. Para recibir una notificación cualquier día de la se-mana, cada minuto entre las 10.00 y las 11.00 y entre las 12.00 y las13.00 se puede utilizar la expresión:

0 * 10,12 * * ?

Ejemplo 9.5. Para recibir una notificación cualquier Miércoles deMarzo, a las 10.00 y a las 10.30, se puede utilizar la expresión:

0 0,30 10 ? 3 4

Alternativamente, para que sea más fácil de leer, se puede utilizar laexpresión:

1 El carácter . se utiliza para marcar la posición de un campo cuyo valor nose está ignorando.

2Véase nota 1.3Véase nota 1.

248


0 0,30 10 ? Mar Wed

9.1.4 Intervalo de valores

El carácter - se utiliza para separar dos valores y asignar un intervalode valores a un campo4:

. . 9-12 . . . .

En este caso, se están asignando al campo hora el intervalo de valo-res entre 9 y 12 y, por lo tanto, el campo asumirá todos los valorescomprendidos entre los extremos del mismo.

Ejemplo 9.6. Para recibir una notificación cualquier día de la sema-na, cada hora entre las 9.00 y las 18.00, se puede utilizar la expresión:

0 0 9-18 * * ?

Ejemplo 9.7. Para recibir una notificación cualquier día de la se-mana, cada media hora entre las 9.00 y las 18.00, se puede utilizar laexpresión:

0 0,30 9-18 * * ?

Ejemplo 9.8. Para recibir una notificación cualquier día de la sema-na entre Lunes y Viernes, cada media hora entre las 9.00 y las 18.00,se puede utilizar la expresión:

0 0,30 9-18 ? * 2-6

4Véase nota 1.

249


9.1.5 Incremento de un valor

El carácter / se utiliza para especificar un incremento a un valor deun campo, el valor inicial, y asignar al mismo todos los valores quese obtienen sumando el incremento al valor inicial5:

. . 0/2 . . . .

En este caso, se está asignando al campo hora cualquier valor válidoobtenido añadiendo el incremento 2 al valor inicial 0, es decir, losvalores {0, 2, 4, . . . , 22}.

Ejemplo 9.9. Para recibir una notificación cualquier día de la sema-na, cada 10 minutos, se puede utilizar la expresión:

0 0/10 * * * ?

Ejemplo 9.10. Para recibir una notificación cualquier día de la se-mana, cada 5 minutos entre las 9.00 y las 18.00, se puede utilizar laexpresión:

0 0/5 9-17 * * ?

9.1.6 Último valor

El carácter L se utiliza para asignar a un campo el último posiblevalor válido y puede utilizarse, adicionalmente, con los formatos es-pecificados6 en Tabla 9.4.

Formato Significado w m

L Último posible valor. • •xL Último día x del mes. •LW Último día laborable del mes. •

Tabla 9.4: Significado de los caracteres especiales de una expresión cronde JIRA.

5Véase nota 1.6En Tabla 9.4 los símbolos w y m identifican, respetivamente, los campos día

de la semana y día del mes.

250


El formato básico con el que se puede utilizar este carácter especiales7:

. . . L . . .

En este caso, se está asignando al campo día del mes el último va-lor válido. Dependiendo del mes corriente, por lo tanto, este campoasumirá uno de los valores en el conjunto {28, 29, 30, 31}.

Este carácter especial se puede utilizar con el campo día de lasemana con el formato xL, donde x es un valor válido para el campo:en este caso significará el último día x del mes.

Este carácter especial también se puede utilizar con el campo díadel mes en el formato LW: en este caso significará el último día (entrelunes y viernes) del mes.

Ejemplo 9.11. Para recibir una notificación el último día del mes,a las 10.00 de la mañana, se puede utilizar la expresión:

0 0 10 L * ?

Ejemplo 9.12. Para recibir una notificación el último día laborable(entre Lunes y Viernes) del mes, a las 10.00 de la mañana, se puedeutilizar la expresión:

0 0 10 LW * ?

Ejemplo 9.13. Para recibir una notificación el último Viernes delmes, a las 10.00 de la mañana, se puede utilizar la expresión:

0 0 10 ? * 6L

9.1.7 Ocurrencias

El carácter # se utiliza para especificar la n-esima ocurrencia de unvalor del campo día de la semana8:

. . . . . 6#2 .

7Véase nota 1.8Véase nota 1.

251


En este caso, se está asignando al campo día de la semana la segundaocurrencia del valor 6, de decir, el segundo Viernes del mes.

Ejemplo 9.14. Para recibir una notificación el segundo Viernes delmes, a las 10.00 de la mañana, se puede utilizar la expresión:

0 0 10 ? * 6#2

9.2 Recibir resultados de búsqueda en un feed RSS

JIRA permite recibir los resultados de una búsqueda a través de unfeed RSS v. 2.0 y la búsqueda a la que está asociado un feed RSSpuede ser una búsqueda grabada como filtro o una búsqueda de reciéncreación y visualizada en el navegador de incidencias. Como detalladoen §6.2, los feeds pueden devolver datos de incidencia o comentarios.

Para limitar el número de resultados devueltos en el feed RSS, JI-RA prevé la utilización de un parámetro de solicitud HTTP, tempMax,a través del cual el usuario puede escoger el tamaño de la página deresultados.

Para suscribirse a un feed RSS asociado a una búsqueda, es nece-sario efectuar las siguientes operaciones:

(i) Utilizar el navegador de incidencias como detallado en éste ca-pítulo para construir la consulta deseada.

(ii) Seleccionar la operación deseada en el menú Views (§6.2.2): RSS(Issues) si se desea un feed que devuelva los datos de las inci-dencias o RSS (Comments) si se desea un feed que devuelva loscomentarios de las incidencias.

(iii) Copiar el enlace del feed RSS de la barra de navegación del na-vegador. Algunos navegadores, como ilustrado en Figura 9.7,pueden visualizar el feed RSS y facilitar herramientas adiciona-les tales como un lector de feed RSS.

(iv) Opcionalmente, modificar el valor del parámetro de solicitudHTTP tempMax. El valor de este parámetro determina el nú-mero máximo de resultados devueltos en el feed RSS y, pordefecto, su valor es 1000.

El URL del feed RSS podrá utilizarse con un lector de feeds; loslectores de feeds RSS permiten examinar fácilmente la informacióncontenida en los feeds y notificar el usuario cuando la información

252

9.2. Recibir resultados de búsqueda en un feed RSS

Figura 9.7: Feed RSS de JIRA visualizado en el navegador Apple Safari.

devuelta varía. Algunos clientes de correo electrónico muy difundi-dos tales como Apple Mail o Mozilla Thunderbird integran en susfunciones la capacidad de recibir feeds RSS.

Si el feed RSS devuelto por JIRA está vacío, comprobar que elusuario tiene los permisos necesarios para acceder a dicha informa-ción. Para autenticar el usuario que accede a JIRA utilizando un feedRSS, véase §9.2.1.

9.2.1 Autenticar el usuario de un feed RSS

La información publicada a través de un feed RSS podría ser informa-ción confidencial y, por lo tanto, el usuario deberá autenticarse parapoder acceder a los datos solicitados. Para acceder a la informaciónconfidencial el usuario puede utilizar una de las siguientes técnicas:

(i) Utilizar los parámetros de solicitud HTTP os_username y os_-password para enviar sus credenciales a JIRA.

(ii) Utilizar el parámetro de solicitud HTTP os_authType con elvalor basic para utilizar el protocolo de autenticación HTTP

253


básico.

El problema de ambos métodos es que las credenciales del usuarioviajarán en claro a través de la red y serán entonces susceptibles de serinterceptadas por usuarios maliciosos. Es importante notar que, detodos modos, esto no es un problema limitado a los feeds RSS sino quees un problema común a toda la plataforma cuando se está utilizandoel protocolo HTTP, como explicado en el capítulo de instalación. Pa-ra obtener mayor información acerca de los problemas de seguridadque existen utilizando JIRA a través del protocolo HTTP así comoinstrucciones para utilizar JIRA a través del protocolo HTTPS, véase§??.

9.3 Recibir resultados de búsqueda en XML

JIRA permite recibir los resultados de una búsqueda en formato XML.El formato XML es un formato ideal para proporcionar los resultadosde búsqueda a otra herramienta que efectúe un post-procesamientode los datos. Muchos plugins utilizan este formato para procesar lainformación recibida y formatearla en el cuadro de mandos de JIRAu de otra aplicación: la macro JIRA Issue de Atlassian Confluence,por ejemplo, utiliza este formato para recibir y utilizar informaciónque proviene de JIRA en las páginas de Confluence. Este formatopuede utilizarse si se está utilizando un lector de feeds RSS v. 0.9.29.

Uno de los caminos de integración con JIRA, por lo menos en loque concierne los casos de uso en los cuales JIRA sea simplementeuna fuente de datos, es utilizar este formato para el intercambio deinformación. Uno de los objetivos que llevó a la definición del for-mato XML era la necesidad de definir un formato de documento quefuera fácil de leer y procesar de forma mecanizada: la mayoría de loslenguajes de programación y de los frameworks de uso común, hoyen día, proporcionan las herramientas necesarias para leer y generarflujos de datos en formato XML. Integrar JIRA como fuente de datosen una plataforma que sea capaz de “entender” el formato XML esfácil, aunque fuera de los objetivos de este documento.

La utilización del XML que se hace en JIRA no está pensada parael uso por parte de un ser humano. No obstante, estas instruccionesson necesarias para determinar el URL a través del cual JIRA publi-cará los resultados de una búsqueda y poder así proporcionar dichadirección a la aplicación que la utilice.

9Si está utilizando RSS v. 2.0, véase §9.2

254

9.4. Exportar resultados de búsqueda a Microsoft Word

Para obtener los resultados de una búsqueda en formato XML esnecesario efectuar las siguientes operaciones:


(ii) Seleccionar la operación XML en el menú Views (§6.2.2).(iii) Copiar el enlace que aparece en la barra de navegación del na-

vegador.(iv) Opcionalmente, modificar el valor del parámetro de solicitud

HTTP tempMax. El valor de este parámetro determina el nú-mero máximo de resultados devueltos en el documento XML y,por defecto, su valor es 1000.

(v) Opcionalmente, configurar los campos que serán devueltos en eldocumento XML siguiendo las instrucciones detalladas a conti-nuación (§9.3.1). Por defecto, JIRA devolverá todos los camposen el documento generado.

9.3.1 Selección de campos devueltos en el documento

JIRA, por defecto, devolverá todos los campos en el documento XMLgenerado. Para facilitar la explotación de la información contenidaen el documento XML devuelto y reducir el tamaño del documen-to recibido, el usuario puede especificar cuales campos incluir en eldocumento utilizando el parámetro de solicitud HTTP field. Elparámetro field puede asumir un conjunto de valores detallados acontinuación y, para incluir múltiples campos, será suficiente incluiren el URL del documento XML el parámetro field tantas veces comosea necesario:

...&field=campo1&field=campo2&...

Los posibles campos que puedan incluirse en el documento XML,los correspondientes valores del parámetro field y ejemplos de frag-mentos de documento XML generados pueden encontrarse en §A.

9.4 Exportar resultados de búsqueda a Microsoft Word

JIRA permite exportar los resultados de búsqueda a un documento deMicrosoft Word. Esta funcionalidad es útil cuando el usuario necesiteincluir resultados de búsquedas en un documento, por ejemplo pararedactar un informe de seguimiento o de estado del arte.

255


Para exportar los resultados a un documento de Microsoft Wordes necesario efectuar las siguientes operaciones:


(ii) Seleccionar la operación Word en el menú Views (§6.2.2).(iii) JIRA generará un file Microsoft Word y, dependiendo del nave-

gador y del sistema operativo utilizado, se abrirá en el navegadoro será descargado a una carpeta local.

En Figura 9.8 puede verse un ejemplo de documento MicrosoftWord generado a partir de una búsqueda en JIRA.

Figura 9.8: Ejemplo de documento Microsoft Word generado de unabúsqueda en JIRA.

Es importante subrayar que, durante la exportación de resultadosde búsqueda a Microsoft Word, JIRA exportará todos los campos dela incidencia, con independencia de la configuración de campos activadurante la exportación.

9.5 Exportar resultados de búsqueda a Microsoft Excel

Poder exportar los resultados de una búsqueda a Microsoft Exceles una funcionalidad útil para los usuarios que necesitan recoger losdatos de una búsqueda para tratarlos “a posteriori”: creación de re-portes, filtrados de datos, agregaciones, gráficos son solo algunas delas operaciones que pueden hacerse con Microsoft Excel sobre un con-junto de datos.

256

9.6. Visualizar los resultados en un gráfico

Para exportar los resultados a un documento de Microsoft Exceles necesario efectuar las siguientes operaciones:


(ii) Seleccionar la operación Excel (All fields) o Excel (Current fields)en el menú Views (§6.2.2): la primera operación permite expor-tar todos los campos de las incidencias encontradas y la segundapermite exportar solo los campos configurados en el navegadorde incidencias (véanse §?? y §8.12).

(iii) JIRA generará un file Microsoft Excel y, dependiendo del nave-gador y del sistema operativo utilizado, se abrirá en el navegadoro será descargado a una carpeta local.

En Figura 9.9 puede verse un documento Microsoft Excel gene-rado a partir de una búsqueda en JIRA.

Figura 9.9: Ejemplo de documento Microsoft Excel generado de unabúsqueda en JIRA.

9.6 Visualizar los resultados en un gráfico

El navegador de incidencias de JIRA permite ver rápidamente losresultados de una búsqueda en uno de los tipos de gráficos disponibles,detallados a continuación. El usuario que haya generado un gráficotendrá además la posibilidad de grabar el gráfico en un gadget delcuadro de mandos de forma muy sencilla.

257


Los tipos de gráficos que JIRA ofrece incluyen, entre otros:

(i) Average age. Gráfico de la edad media de una incidencia sinresolver (Figura 9.13).

(ii) Created vs. resolved issues. Gráfico de la diferencia entre in-cidencias creadas y resueltas. El gráfico, que opcionalmentepuede ser cumulativo, dibujará areas rojas cuando la diferenciaes positiva y verde cuando la diferencia es negativa (Figura9.16).

(iii) Resolution time. Gráfico de barra del tiempo10 de resoluciónmedio de las incidencias (Figura 9.12).

(iv) Pie chart. Gráfico de torta de las incidencias agrupadas porcualquier tipo de estadística (asignatario, estado, prioridad, etc.)(Figura 9.12).

(v) Recently created. Gráfico de barra cuya parte verde son las in-cidencias resueltas y cuya parte roja son las incidencias creadasy no resueltas (Figura 9.12).

(vi) Time since. Gráfico de barra que relaciona fechas con el númerode incidencias que tenían un campo de tipo fecha, seleccionadopor el usuario, igual a la fecha en gráfico (Figura 9.15).

Para visualizar los resultados de una búsqueda en un gráfico, esnecesario efectuar las siguientes operaciones:

(i) En la ventana de resultados del navegador de incidencias, selec-cionar la operación Charts en el menú Views debajo de la barrade herramientas, como ilustrado en Figura 9.17.

(ii) Seleccionar el gráfico que se desea visualizar en la ventana deselección presentada por JIRA.

(iii) Si se desea modificar los parámetros de configuración del gráficoseleccionado, pulsar el control identificado con un “engranaje”ilustrado en Figura 9.18, personalizar los parámetros del grá-fico y pulsar el botón Save.

9.6.1 Visualizar los resultados de búsqueda en el cuadrode mandos

Los gráficos generados con los resultados de búsqueda del navegadorde incidencias y descritos en la sección precedente pueden añadirsecomo gadget en el cuadro de mando de JIRA. De esta forma, no

10El tiempo de resolución medio se mide en días.

258


Figura 9.10: Gráfico Agerage age.

Figura 9.11: Gráfico Created vs. resolved.

259


Figura 9.12: Gráfico Created vs. resolved.

Figura 9.13: Gráfico Pie chart.

260


Figura 9.14: Gráfico Recently created.

Figura 9.15: Gráfico Time since.

261


Figura 9.16: Navegador de incidencias — Tipos de gráfico.

Figura 9.17: Navegador de incidencias — Ver como gráfico.

262


Figura 9.18: Navegador de incidencias — Personaliza gráfico.

será necesario regenerar el gráfico cada vez que los resultados de unabúsqueda se actualicen ya que el gadget estará siempre disponible, yactualizado automáticamente con los datos actuales, en el cuadro demando de un usuario.

Para añadir un gráfico generado con los resultados de una búsque-da es necesario efectuar las siguientes operaciones:

(i) Generar el gráfico siguiendo las instrucciones detalladas en §9.6.(ii) Pulsar el botón Save to dashboard en la ventana de configuración

del gráfico.(iii) Seleccionar el cuadro de mando en que se desea añadir el gadget

en el campo Select dashboard de la ventana de selección del cua-dro de mando que aparece a continuación (Figura 9.19). En elcaso en que el usuario no tenga ningún cuadro de mando y estéutilizando el cuadro de mando del sistema, JIRA creará auto-máticamente un nuevo cuadro de mando y avisará el usuariocon el aviso ilustrado en Figura 9.20.

(iv) En el campo Filter name seleccionar el nombre del filtro aso-ciado a la búsqueda corriente que JIRA creará conjuntamenteal gadget del cuadro de mando.

263


Figura 9.19: Grabación de gráfico en el cuadro de mando — Selecciónde cuadro de mando.

Figura 9.20: Grabación de gráfico en el cuadro de mando — Creaciónautomática de un cuadro de mando.

(v) Pulsar el botón Save.

JIRA creará un filtro y un gadget que será añadido al cuadro demando indicado por el usuario. Si el usuario lo necesita, el gadgeten cuestión podrá ser posicionado y configurado utilizando las herra-mientas del cuadro de mando.

264

10Generar reportes

La información almacenada en un sistema es valiosa si puede ser ex-plotada. Una herramienta como JIRA va almacenando continuamenteinformación de interés para una organización y es fundamental poderconsultarla de forma eficiente cuando sea necesario.

En los capítulos precedentes se ha detallado como la funcionalidadde búsqueda de JIRA proporciona una herramienta sofisticada parapoder extraer del sistema la información que se necesita. Se vio,además, como los resultados de búsquedas pueden compartirse conotros usuarios, ser utilizadas para la exportación a otros formatos oser utilizados para la generación de gráficos. En este capítulo se veráotra herramienta para la explotación de datos que JIRA ofrece a sususuarios: los reportes.

JIRA ofrece un conjunto de reportes que ofrecen varios tipos deestadísticas a sus usuarios, tales como carga de trabajo o tiempos deresolución. Tipos de reportes adicionales pueden integrarse en JIRAcomo plugins: una organización puede comprobar si el reporte quese está buscando existe en el “ecosistema” de JIRA [28] [29] y, en sudefecto, un nuevo plugin puede ser fácilmente desarrollado utilizandoel Atlassian SDK [30].

En Tabla 10.1 se enumeran los reportes integrados y distribuidoscon JIRA y a continuación se detallarán las características de cadauno de ellos así como las operaciones necesarias para generarlos.

Todos los reportes son accesibles a través del menú Reports queaparece en el cuadro de mando de un proyecto, indicado en Figura10.1. Como puede verse en Figura 10.2, el menú Reports es unmenú desplegable en el cual se encuentra una entrada por cada unode los tipos de reportes soportados por la plataforma: tanto para losreportes que JIRA proporciona por defecto como para los reportesadicionales instalados a través de plugins.

265

10. Generar reportes

Figura 10.1: Cuadro de manos de un proyecto — Menú Reports.

Figura 10.2: Cuadro de manos de un proyecto — Menú Reportsdesplegado.

266

10.1. Workload pie chart

Nombre DescripciónWorkload piechart

Carga de trabajo media de los usuarios asignadosa las incidencias de un proyecto o devueltas porun filtro.

User workload Carga de trabajo de un usuario y tiempo estima-do para la finalización de los trabajos.

Version workload Trabajo a finalizar, para usuarios y para inciden-cias, antes de que finalice una versión.

Version time trac-king

Tiempo estimado para la finalización de los tra-bajos de una versión, calculado utilizando regis-tros de trabajos y estimaciones de tiempo de tra-bajo requerido de las incidencias.

Single level groupby

Resultados de un filtro, agrupados por un campoa elección del usuario.

Created vs. resol-ved issues

Número de incidencias creadas contra número deincidencias resueltas en un intervalo de tiempoespecificado.

Resolution time Tiempo medio de resolución de las incidencias.Pie chart Resultados de un filtro o de un proyecto, agrupa-

dos por un campo a elección del usuario, en ungráfico de torta.

Average age Edad media de las incidencias (en días).Recently createdissues

Frecuencia de creación de las incidencias.

Time since issues Número de incidencias que tienen un campo detipo fecha, escogido por el usuario, igual a la fe-cha indicada.

Tabla 10.1: Reportes integrados en JIRA.

10.1 Workload pie chart

El reporte workload pie chart resume la carga de trabajo (relativa)de los usuarios asignados a un grupo de incidencias; el grupo de in-cidencias sobre el cual se efectúa el cálculo puede ser el conjunto deincidencias de un entero proyecto o las incidencias devueltas por unfiltro escogido por el usuario.

Para poder utilizar este reporte es necesario que:

(i) El administrador de JIRA haya habilitado la funcionalidad detime tracking.

(ii) Esté instalado el plugin JIRA Charting Plugin [31].

267


Para generar un reporte de este tipo es necesario efectuar las si-guientes operaciones:

(i) Acceder al cuadro de mando del proyecto que se desea navegar.(ii) Seleccionar el reporte en el menú Reports en el cuadro de mando

del proyecto.(iii) En la ventana de configuración del reporte (Figura 10.3), selec-

cionar el proyecto o el filtro que proporciona los datos al mismoseleccionando el enlace Select filter or project. . . a la derechadel campo Project or saved filter. Aparecerá la ventana de se-

Figura 10.3: Workload pie chart — Configuración.

lección de proyecto o filtro (Figura 10.4) en la cual el usuariopodrá escoger o buscar entidades de ambos tipos.

Figura 10.4: Ventana de selección de proyecto o filtro.

(iv) Seleccionar el campo utilizado para agregar los datos en el grá-fico de torta utilizando el menú desplegable del campo Statistictype. Por defecto el campo seleccionado es Assignee.

268

10.1. Workload pie chart

(v) Seleccionar la estimación de tiempo a utilizar en el menú desple-gable del campo Time field to report on. El menú devuelve loscampos de estimación de tiempo de JIRA, es decir: estimacióncorriente, estimación original y tiempo trabajado.

(vi) Seleccionar el botón Next para generar el reporte.

Un ejemplo de reporte de este tipo, generado agregando datosdel campo Assignee, está ilustrado en Figura 10.5. En la parte

Figura 10.5: Report Workload pie chart.

superior del reporte puede verse el gráfico de tipo torta que ilustra elporcentaje de trabajo asignado a cada usuario. En la parte inferiordel reporte puede verse la tabla con los mismos datos reportados enforma numérica: en la segunda columna de la tabla está el númerode horas asignadas a cada usuario (calculadas utilizando el campo

269


indicado durante la configuración del reporte) y la carga de trabajorelativa de cada uno de ellos, calculada como el porcentaje de horasasignadas a cada usuario sobre el total.

10.2 User workload

El reporte User workload resume la carga de trabajo de un usuario yel tiempo estimado para la finalización de los trabajos pendientes.

Para poder utilizar este reporte es necesario que el administradorde JIRA haya habilitado la funcionalidad de time tracking.



del proyecto.(iii) En la ventana de configuración del reporte (Figura 10.6), se-

leccionar el usuario del que se desea obtener el reporte introdu-ciendo su nombre en el campo User o buscándolo a través delbuscador de usuarios al que se accede seleccionando el controlidentificado por el icono ( ) situado a la derecha del mismocampo.

Figura 10.6: User workload — Configuración.

(iv) Seleccionar el botón Next para generar el reporte.

Un ejemplo de reporte de este tipo, generado para el usuario enri-co, está ilustrado en Figura 10.7. En el reporte puede verse la tablaque agrega por proyecto (primera columna) la carga de trabajo delusuario seleccionado generada por las incidencias que tiene en cada

270

10.3. Version workload

Figura 10.7: Report User workload.

uno de los proyectos indicados (segunda columna); en la última co-lumna de la tabla, Workload, puede verse la carga de trabajo totalen cada proyecto y en el último registro de la tabla pueden verse lostotales de los datos detallados.

10.3 Version workload

El reporte Version workload resume el trabajo a finalizar, para usua-rios y para incidencias, antes de que finalice una versión de un pro-yecto.




del proyecto.(iii) Configurar el reporte en la ventana de configuración del repor-

te (Figura 10.8) siguiendo las instrucciones que se detallan acontinuación.

(iv) Seleccionar en el menú desplegable del campo Version la versióndel proyecto para la cual se desea generar el reporte.

(v) Seleccionar en el menú desplegable del campo Display unesti-mated issues si se desea incluir en el reporte las incidencias paralas cuales no exista una estimación de tiempo restante para lafinalización.

(vi) Seleccionar en el menú desplegable del campo Sub-task inclusionqué tipo de sub-tareas se desean incluir en el reporte:

271


Figura 10.8: Version workload — Configuración.

a) Seleccionar el valor Only including sub-tasks with the se-lected version para incluir en el reporte las sub-tareas quetengan la misma versión de la incidencia que las contiene.

b) Seleccionar el valor Also include sub-tasks without a ver-sion set para incluir en el reporte las sub-tareas que ten-gan la misma versión de la incidencia que las contiene ylas sub-tareas que tengan el campo versión vacío.

c) Seleccionar el valor Include all sub-tasks para incluir todaslas sub-tareas en el reporte.

(vii) Seleccionar el botón Next para generar el reporte.

Un ejemplo de reporte de este tipo está ilustrado en Figura 10.9.En la parte superior del reporte, Summary, puede verse la carga de

Figura 10.9: Report Versión workload.

272

10.4. Time tracking

trabajo que queda por efectuar desglosada por usuario y tipo de inci-dencia. En la parte inferior del reporte, Individual estimates, puedeverse el detalle de los trabajos pendientes, organizados por usuariosy tipo de tarea.

10.4 Time tracking

El reporte Time tracking resume el tiempo estimado para la finali-zación de los trabajos de una versión, calculado tanto utilizando laestimación inicial como los registros de trabajos de las incidencias. Elreporte también indicará si una incidencia se finalizará a tiempo o enretraso, respeto a la estimación original.




del proyecto.(iii) Configurar el reporte en la ventana de configuración del reporte

(Figura 10.10) siguiendo las instrucciones que se detallan acontinuación.

Figura 10.10: Time tracking — Configuración.

(iv) Seleccionar en el menú desplegable del campo Fix version laversión del proyecto para la cual se desea generar el reporte:

273


el reporte incluirá las incidencias cuyo campo Fix versión seaigual a la versión indicada.

(v) Seleccionar en el menú desplegable del campo Sorting el criteriocon el cual se ordenarán las incidencias en el reporte utilizandoel valor del campo estimación de tiempo restante:a) Seleccionar Least completed issues first para ordenar las

incidencias con estimación de tiempo restante descendien-te.

b) Seleccionar Most completed issues first para ordenar lasincidencias con estimación de tiempo restante ascendiente.

(vi) Seleccionar en el menú desplegable del campo Issues cuales in-cidencias incluir en el reporte:a) Seleccionar All para incluir todas las incidencias de la ver-

sión elegida.b) Seleccionar Incomplete issues only para excluir del reporte

las incidencias completadas y las incidencias que tengan laestimación de tiempo vacía.

(vii) Seleccionar en el menú desplegable del campo Sub-task inclusionqué tipo de sub-tareas se desean incluir en el reporte:a) Seleccionar el valor Only including sub-tasks with the se-

lected version para incluir en el reporte las sub-tareas quetengan la misma versión de la incidencia que las contiene.

b) Seleccionar el valor Also include sub-tasks without a ver-sion set para incluir en el reporte las sub-tareas que ten-gan la misma versión de la incidencia que las contiene ylas sub-tareas que tengan el campo versión vacío.

c) Seleccionar el valor Include all sub-tasks para incluir todaslas sub-tareas en el reporte.

(viii) Seleccionar el botón Next para generar el reporte.

Un ejemplo de reporte de este tipo está ilustrado en Figura 10.11.En el reporte puede verse la tabla con el detalle de los datos extraídos;en las últimas columnas dicha tabla se presentan los datos de loscuatros campos utilizados para el seguimiento de tiempo del proyecto:

(i) Original estimate: la estimación original tf del tiempo necesariopara finalizar la incidencia.

(ii) Estimated time remaining: la estimación actual ta del tiemponecesario para finalizar la incidencia.

274

10.4. Time tracking

Figura 10.11: Report Time tracking.

(iii) Time spent: la cantidad de tiempo ts trabajado en la incidencia.(iv) Accuracy: la exactitud de la estimación original comparada con

la estimación actual calculada como

at = tf − (ts + ta) (10.1)

Si at es at < 0, la incidencia está en retraso con la estimación,mientras que si at ≥ 0 la incidencia está respetando la estima-ción inicial.

Si las sub-tareas están habilitadas en la plataforma, cada una delas columnas (i)-(iv) llevará un valor adicional, indicado con la letra∑

en la cabecera de la columna, que indicará los valores “agregados”para las incidencias con sub-tareas. Si una incidencia b tiene un con-junto de n sub-tareas {bi : i ∈ [1, n], i ∈ N}, el valor agregado paraun campo x cualquiera de los campos indicados en precedencia será:

x(b) =n∑1x(bi) (10.2)

El último registro del reporte es la agregación de los datos de todaslas incidencias incluidas en el mismo.

En la parte superior del reporte JIRA proporciona una represen-tación gráfica del estado de progreso y exactitud de las estimaciones

275


Figura 10.12: Report Time tracking — Barras de resumen.

para la versión seleccionada (Figura 10.12). El gráfico de barrastiene las siguientes carácterísticas:

(i) La barra de progreso ilustra la cantidad de trabajo llevado acabo, en color verde, y la cantidad de trabajo que falta porejecutar en las incidencias todavía abiertas, en color naranja.La relación entre la longitud de un segmento coloreado y lalongitud total de la barra representa el porcentaje de trabajocompletado o por completar.

(ii) La barra de “exactitud” (Accuracy) ilustra la exactitud de lasestimaciones: en el caso ilustrado la exactitud es negativa y esoindica un retraso de los trabajos estimado en el 14% del tiempototal.

(iii) La relación entre longitud de la barra de accuracy con respeto ala longitud de la barra de progreso también indica si el trabajoestá completándose a tiempo, en adelanto o en retraso. Si lalongitud de la barra de accuracy es más corta de la barra dela barra de progreso, como en Figura 10.12, el trabajo va enretraso. Si la longitud es la misma, el trabajo está completán-dose de acuerdo a las estimaciones. Si la longitud de la barra deaccuracy es más grande de la longitud de la barra de progreso,el trabajo está completándose en adelanto.

10.5 Single level group by

El reporte Single level group by permite organizar los resultados debúsqueda de un filtro agrupándolos por un campo escogido por elusuario.

Ejemplo 10.1. El jefe de proyecto desea organizar por asignatario lasincidencias abiertas para un componente de un proyecto y planificadaspara solucionarse en una versión del proyecto. Para generar estereporte, el jefe de proyecto podrá crear un filtro que devuelva lasincidencias buscadas:

project=... and component=... and version=... and status=open

276

10.6. Created vs. resolved issues

Para agrupar los resultados del filtro por asignatario, el usuariopodrá configurar un reporte de tipo Single level group by para queutilice el filtro en cuestión y agrupe las incidencias utilizando el campoAssignee.





Figura 10.13: Single level group by — Configuración.

(iv) Seleccionar el filtro a utilizarse como fuente de datos del re-porte utilizando la ventana de selección de filtros que apareceseleccionando el enlace Select filter. . . en el campo Filter.

(v) Seleccionar en el menú desplegable del campo Statistic type elcampo de las incidencias a utilizarse para agregar los datos.


Un ejemplo de reporte de este tipo, configurado agregando lasincidencias por el campo Assignee, está ilustrado en Figura 10.14.En el filtro pueden verse las incidencias devueltas por el filtro asociadoal reporte agregadas por asignatario.

10.6 Created vs. resolved issues

El reporte Created vs. resolved issues resume la diferencia entre elnúmero de incidencias creadas y resueltas, procedentes de un filtro o

277


Figura 10.14: Report Single level group by.

de un proyecto, en un intervalo temporal escogido por el usuario.Para generar un reporte de este tipo es necesario efectuar las si-

guientes operaciones:




(iv) Seleccionar el filtro o el proyecto asociado al reporte utilizandola ventana de selección de filtros y proyectos a la que se acce-de utilizando el enlace Select filter or project. . . en el campoProject or saved filter.

(v) Seleccionar en el menú desplegable del campo Period el intervalotemporal utilizado para la visualización del reporte. Los valoresdisponibles para este campo están resumidos en Tabla 10.2.

(vi) Seleccionar en el campo Days previously el número de días nde datos a tener en cuenta para la generación del gráfico. Elreporte utilizará los datos procedentes de las incidencias creadas

278

10.6. Created vs. resolved issues

Figura 10.15: Created vs. resolved — Configuración.

Nombre DescripciónHourly Intervalo de una hora.Daily Intervalo de un día.Weekly Intervalo de una semana.Monthly Intervalo de un mes.Quarterly Intervalo de 3 meses.Yearly Intervalo de un año.

Tabla 10.2: Reporte — Intervalos temporales.

o modificadas en el intervalo temporal [t0 − n, t0] siendo t0 lafecha actual de generación del gráfico.

(vii) Seleccionar en el menú desplegable del campo Cumulative to-tals? si los datos del reporte deben ser cumulativos o invididua-les.

(viii) Seleccionar en el menú desplegable del campo Display versions?si y para que tipo de versiones deben enseñare las fechas deliberación en el gráfico.

(ix) Seleccionar el botón Next para generar el reporte.

Un ejemplo de reporte de este tipo, generado utilizando los pará-metros: {

Period = DailyDays previously = 30

(10.3)

279


está ilustrado en Figura 10.16 y 10.17.

Figura 10.16: Report Created vs. Resolved — Gráfico.

Las areas verdes del gráfico representan los intervalos de tiempoen los cuales el número de incidencias resueltas ir, ha sido mayor queel número de incidencias creadas ic:ir > ic. Las areas rojas, al revés,representan los intervalos de tiempo en los cuales ir < ic.

El mismo conjunto de datos se ha utilizado para generar el si-guiente reporte, utilizando los siguientes parámetros:{

Period = WeeklyDays previously = 30

(10.4)

Como puede verse en Figura 10.18, los datos diarios del gráficoprecedente se han agregados en datos semanales. La curva resultantees la curva generada sumando los datos diarios a lo largo de los díasde cada semana. Puede verse como la curva de Figura 10.18 es más“suave” de la curva de Figura 10.16 por efecto de la operación de

280

10.7. Resolution time

Figura 10.17: Report Created vs. Resolved — Tabla de datos.

suma y que las areas coloreadas en el primer gráfico se reflejan en lasareas coloreadas en el mismo color en el segundo gráfico.

10.7 Resolution time

El reporte Resolution time resume el tiempo medio que se ha reque-rido para resolver las incidencias, calculado en intervalos de longitudespecificada por el usuario. El conjunto de incidencias analizadas eneste tipo de reporte puede proceder tanto de un filtro como de unentero proyecto.





281


Figura 10.18: Report Created vs. Resolved — Gráfico.

Figura 10.19: Resolution time — Configuración.

282

10.8. Pie chart



(vi) Seleccionar en el campo Days previously el número de días nde datos a tener en cuenta para la generación del gráfico. Elreporte utilizará los datos procedentes de las incidencias creadaso modificadas en el intervalo temporal [t0 − n, t0] siendo t0 lafecha actual de generación del gráfico.




(10.5)

está ilustrado en Figura 10.20 y 10.21.En el gráfico de barras del reporte puede verse el tiempo medio de

resolución, calculado sobre el intervalo especificado, representado porla altura y de las barras. En la tabla de datos pueden apreciarse losmismos datos en forma numérica: la tabla tiene 30 registros, comoespecificado en el parámetro Days previously y la media del tiempode resolución se ha calculado en base diaria, como especificado en elparámetro Period.

10.8 Pie chart

El reporte Pie chart es un reporte similar al reporte Single level groupby (§10.5): este reporte permite agrupar un conjunto de incidenciaspor un campo escogido por el usuario y enseñar el resultado de laagrupación de forma “gráfica” en un gráfico de torta.

Ejemplo 10.2. Como en el Ejemplo 10.1, el jefe de proyecto deseaorganizar por asignatario las incidencias abiertas para un componentede un proyecto y planificadas para solucionarse en una versión delproyecto. En este caso, sin embargo, el jefe de proyecto quiere ilustrarlos resultados en un gráfico de tarta.

283


Figura 10.20: Report Resolution time — Gráfico.

Para agrupar los resultados del filtro por asignatario, el usuariopodrá configurar un reporte de tipo Pie chart para que utilice el filtroen cuestión y agrupe las incidencias utilizando el campo Assignee.





(iv) Seleccionar el filtro o el proyecto a utilizarse como fuente dedatos del reporte utilizando la ventana de selección de filtrosy proyectos que aparece seleccionando el enlace Select filter orproject. . . en el campo Project or saved filter.

284

10.8. Pie chart

Figura 10.21: Report Resolution time — Tabla de datos.

Figura 10.22: Pie chart — Configuración.

285


(v) Seleccionar en el menú desplegable del campo Statistic type elcampo con el cual agregar los datos.


Un ejemplo de reporte de este tipo, configurado agregando lasincidencias por el campo Assignee, está ilustrado en Figura 10.23 y10.24.

Figura 10.23: Report Pie chart — Gráfico.

Figura 10.24: Report Pie chart — Tabla de datos.

Como puede observarse, el gráfico de torta ilustra el porcentajede incidencias que componen cada uno de los conjuntos obtenidosagregando las incidencias por el campo especificado. En la tabla dedatos, se detallan de forma numérica los datos ilustrados en el gráfico.

286

10.9. Average age

10.9 Average age

El reporte Average age resume la edad media (medida en días) de lasincidencias no resueltas en cada instante de tiempo con la frecuenciaescogida por el usuario.





Figura 10.25: Average age — Configuración.



(vi) Seleccionar en el campo Days previously el número de días nde datos a tener en cuenta para la generación del gráfico. Elreporte utilizará los datos procedentes de las incidencias creadaso modificadas en el intervalo temporal [t0 − n, t0] siendo t0 lafecha actual de generación del gráfico.


287




(10.6)


Figura 10.26: Report Average age — Gráfico.

En el gráfico del reporte puede verse una barra por cada intervaloespecificado por el usuario cuya altura indica la edad media de lasincidencias abiertas y no resueltas en ese intervalo de tiempo. En latabla de datos del reporte pueden verse los mismos datos en formanumérica.

10.10 Recently created issues

El reporte Recently created issues resume la frecuencia con la cual seestán creando nuevas incidencias. La frecuencia se calcula sobre el

288

10.10. Recently created issues

Figura 10.27: Report Average age — Tabla de datos.

conjunto de incidencias devueltas por un filtro o un proyecto y unintervalo de tiempo escogido por el usuario.







(vi) Seleccionar en el campo Days previously el número de días nde datos a tener en cuenta para la generación del gráfico. El

289


Figura 10.28: Recently created issues — Configuración.

reporte utilizará los datos procedentes de las incidencias creadaso modificadas en el intervalo temporal [t0 − n, t0] siendo t0 lafecha actual de generación del gráfico.




(10.7)

está ilustrado en Figura 10.29 y 10.30.En el gráfico del reporte puede verse una barra por cada intervalo

especificado por el usuario cuya altura indica el número de incidenciasabiertas en el intervalo de tiempo correspondiente. La longitud delsegmento de barra coloreado en verde indica el porcentaje de inciden-cias que se han resuelto y el segmento coloreado en rojo el porcentajede incidencias que todavía quedan por resolver. En la tabla de datosdel reporte pueden verse los mismos datos en forma numérica.

10.11 Time Since Issues Report

El reporte Time since issues resume el número de incidencias cuyocampo de tipo fecha escogido por el usuario es igual a la fecha indica-da. En conjunto de incidencias analizado en el reporte puede procederde un filtro o de un proyecto escogido por el usuario.


(i) Acceder al cuadro de mando del proyecto que se desea navegar.

290

10.11. Time Since Issues Report

Figura 10.29: Report Recently created issues — Gráfico.

(ii) Seleccionar el reporte en el menú Reports en el cuadro de mandodel proyecto.

(iii) Configurar el reporte en la ventana de configuración del reporte(Figura 10.31) siguiendo las instrucciones que se detallan acontinuación.


(v) Seleccionar en el menú desplegable del campo Date field el cam-po de tipo fecha de las incidencias a utilizar en el reporte.

(vi) Seleccionar en el menú desplegable del campo Period el intervalotemporal utilizado para la visualización del reporte. Los valoresdisponibles para este campo están resumidos en Tabla 10.2.

(vii) Seleccionar en el campo Days previously el número de días nde datos a tener en cuenta para la generación del gráfico. El

291


Figura 10.30: Report Recently created issues — Tabla de datos.

Figura 10.31: Time since issues — Configuración.

292

10.11. Time Since Issues Report

reporte utilizará los datos procedentes de las incidencias creadaso modificadas en el intervalo temporal [t0 − n, t0] siendo t0 lafecha actual de generación del gráfico.

(viii) Seleccionar en el menú desplegable del campo Cumulative to-tals? si los totales deben ser cumulativos o individuales.

(ix) Seleccionar el botón Next para generar el reporte.



(10.8)


Figura 10.32: Report Time since issues — Gráfico.

En el gráfico del reporte puede verse una barra por cada intervaloespecificado por el usuario cuya altura indica el número de incidenciascuyo campo especificado es igual a la fecha del intervalo correspon-diente. En la tabla de datos del reporte pueden verse los mismosdatos en forma numérica.

293


Figura 10.33: Report Time since issues — Tabla de datos.

10.12 Caché de los navegadores

Dependiendo de la configuración de la caché del navegador que se estáutilizando, puede suceder que las páginas de los reportes visualicendatos no actualizados. Es importante, por lo tanto, configurar lacaché de forma que compruebe de forma automática si existe unaversión actualizada para una página presente en la caché.

294

11Gestionar los cuadros de mandos

El cuadro de mandos de JIRA es la primera ventana a la que llega elusuario después del login. Dependiendo de la configuración del cuadrode mando por defecto de JIRA, los contenidos de esta ventana puedencambiar.

Para muchos usuarios y en muchos casos de uso, los cuadros demandos adquieren una importancia relevante en una aplicación co-mo JIRA. En los capítulos precedentes nos hemos focalizado en lainteracción entre usuarios y JIRA en el contexto de un proyecto. Ennavegador de proyecto, por ejemplo, puede considerarse el “cuadro demandos” de un proyecto y desde esa ventana el usuario puede accedera cualquier función e información relacionada con el mismo.

Sin embargo, algunos roles de usuarios pueden estár involucradosen un amplio conjunto de proyectos: las herramientas específicas deproyecto, o incluso los filtros, pueden resultar lentas y engorrosas ala hora de recuperar, agregar y analizar la información procedente devarios proyectos.

Los cuadros de mandos proporcionan una solución a esta necesi-dad: el usuario puede utilizar los gadgets para recuperar y presentarla información que necesitan en una única ventana. La fuente de datosutilizada por los gadgets para recuperar la información que presentansuelen ser filtros: de esta forma el usuario puede definir de forma sen-cilla la búsqueda de los datos que le interesan (como explicado en §6 yposteriores), grabarla para reutilizarla y compartirla con otros usua-rios e utilizar los gadgets para agregar y visualizar esta informaciónen ventanas dedicadas.

Un usuario podrá definir tantos cuadros de mandos como necesitee, incluso, compartirlos con otros usuarios. Los cuadros de mandos,por lo tanto, son ventanas de reporting flexible y fácil de utilizar quepueden considerarse también activos de la plataforma: los jefes de

295

11. Gestionar los cuadros de mandos

proyectos de proyectos distintos podrán, por ejemplo, compartir uncuadro de mando que defina la “estructura” de la información quenecesitan. La flexibilidad de los filtros hará que cada usuario queutilice un cuadro de mandos vea una versión personalizada de losdatos que le interesan.

En este Capítulo se detallará el procedimiento de gestión de loscuadros de mandos. En el siguiente Capítulo se detallará el procedi-miento de personalización de los cuadros de mandos.

11.1 Contenedores de gadgets OpenSocial

Como explicado en la introducción de este capítulo, la característicaprincipal de esta ventana o, para ser más precisos, de este tipo deventanas, es su extrema flexibilidad. Un cuadro de mandos es uncontenedor de “gadgets” OpenSocial en el cual el usuario puede añadirgadgets compatibles con los cuales diseñar su ventana.

OpenSocial es un conjunto de APIs1 que en un principio fue pro-mocionado por Google y otras empresas con el fin de poder compartirinformación entre distintas aplicaciones utilizando “componentes”, losgadgets, que se pudieran añadir fácilmente en la capa de presentación.Atlassian, después de haber comenzado a utilizar esta tecnología enJIRA, ha extendido su utilización a sus demás productos proporcio-nando al usuario una forma efectiva y sencilla de poder personalizar,de acuerdo a sus necesidades y a sus gustos, las ventanas de las apli-caciones. En Figura 11.1 puede verse un cuadro de mandos vacío.El usuario podrá ir añadiendo los gadgets que desea, conectándoloscuando sea necesario a las fuentes de datos que requieran, y confi-gurar el aspecto de la ventana moviendo los gadgets en la posicióndeseada arrastrándolo simplemente con el ratón (Figura 11.2).

Como explicado a continuación, la utilización de una tecnologíaestándar para la personalización de los cuadros de mandos permite alusuario integrar información procedente de otras aplicaciones, siem-pre que el gadget utilizado cumpla los requerimientos del estándarOpenSocial. De esta forma, los cuadros de mandos de JIRA puedenconvertirse en cuadros de mandos globales en los cuales los usuariospueden agregar cómodamente la información procedente de las apli-caciones que utilizan.

1Application Programming Interfaces (Interfaces de Programación de Aplica-ción).

296

11.1. Contenedores de gadgets OpenSocial

Figura 11.1: Cuadro de mandos vacío.

Figura 11.2: Cuadro de mandos — Disponer un gadget.

297


11.2 Gestión de los cuadros de mandos

Los cuadros de mandos son entidades que, a la par que otras entidadesde JIRA tales como los filtros, pueden:

(i) Crearse.(ii) Compartirse.(iii) Buscarse.(iv) Marcarse como favoritos.

Los usuarios pueden utilizar la ventana de gestión de cuadros de man-dos para gestionar los cuadros de mandos que desea utilizar, tantospropios como creados por otros usuarios. De esta forma, cada usuariopodrá utilizar tantos cuadros de mandos como necesite para mantenerla información organizada con los criterios deseados.

Para acceder a la ventana de gestión de cuadros de mandos seselecciona la operación Manage dashboards del menú Dashboards enla barra de herramientas de JIRA (Figura 11.3).

Figura 11.3: Menú Dashboards.

La ventana de gestión está compuesta por distintas sub-ventanas,accesibles a través de las pestañas que pueden verse a la izquierda deFigura 11.4 y detalladas a continuación:

Figura 11.4: Ventana de gestión de cuadros de mandos.

298

11.2. Gestión de los cuadros de mandos

(i) Favorite: Ventana de gestión de cuadros de mandos favoritos,cuya funcionalidad está detallada en 11.2.1.

(ii) My: Ventana de gestión de cuadros de mandos del usuario co-nectado. Las operaciones disponibles en esta ventana están de-talladas en las secciones siguientes.

(iii) Popular : Ventana de gestión de cuadros de mandos populares.Esta ventana propone la lista de los cuadros de mandos máspopulares, de acuerdo al número de usuarios que los añade a sulista de favoritos.

(iv) Search: Ventana de búsqueda de cuadros de mandos, cuya fun-cionalidad está detalladas en 11.3.

11.2.1 Gestión de cuadros de mandos favoritos

La ventana que por defecto se presenta al usuario es la ventana degestión de cuadros de mandos favoritos (Figura 11.4). Los cuadrosde mandos, a la par que otras entidades tales como los filtros, puedenmarcarse como favoritos. Los cuadros de mandos favoritos se propo-nen al usuario como pestañas en el lado izquierdo de cualquier cuadrode mando que se esté utilizando, como puede verse en Figura 11.5.De esta forma, los usuarios podrán acceder a los cuadros de mandos

Figura 11.5: Ventana de gestión de cuadros de mandos.

que más utilicen de forma rápida y desde cualquier otro cuadro demando.

Como puede observarse en Figura 11.4, los cuadros de mandosfavoritos están señalados con un control identificados con un icono“estrella amarilla” ( ). Seleccionando este control se puede quitar uncuadro de mando de la lista de favoritos. JIRA avisará el usuario

299


que la operación de eliminación de un cuadro de mando de la lista defavoritos se ha completado con éxito con un mensaje parecido al quese ilustra en Figura 11.6. Si se desea anular la operación de elimina-

Figura 11.6: Confirmación de eliminación de un cuadro de mandos de lalista de favoritos.

ción del cuadro de mandos de la lista de favoritos, es posible hacerloutilizando el enlace Undo disponible en el mensaje de confirmación(Figura 11.6).

De forma análoga, es posible añadir un cuadro de mandos a lalista de favoritos utilizando el control “estrella”. Por eso, es necesario“encontrar” el cuadro de mando que se desea agregar a la lista defavoritos2 y seleccionar el control identificado con un icono “estrellagris” ( ). Después de que el cuadro de mandos se haya marcado comofavorito, el control se volverá amarillo ( ) y el cuadro de mando podrágestionarse de la ventana de gestión Favorite.

11.2.2 Ordenar los cuadros de mandos favoritos

Por cada uno de los cuadros de mandos favoritos JIRA presenta unapestaña en la parte izquierda de la ventana de cuadros de mandoscon la cual el usuario puede acceder rápidamente al cuadro deseado.En la ventana de gestión de cuadros de mandos favoritos el usuariopuede ordenar los elementos de la lista de forma que las pestañascorrespondientes aparezcan en el órden deseado.

Para ordenar los elementos de la lista, el usuario puede utilizarlos controles que aparecen en cada elemento de la lista, descritos enTabla 11.1.

11.2.3 Creación de un cuadro de mandos

Los usuarios, a parte de utilizar el cuadro de mandos del sistemaproporcionado por la plataforma y que no pueden ser modificadossino por el administrador de JIRA, pueden crear cuadros de mandosadicionales que pueden configurarse a placer.

2En las siguientes secciones se detallarán varios mecanismos proporcionadospor JIRA para encontrar un cuadro de mando.

300


Control DescripciónMover a la primera posición.Mover hacia arriba.Mover hacia abajo.Mover a la última posición.

Tabla 11.1: Controles para el ordenamiento de los elementos de la lista.

Un cuadro de mandos puede crearse:

(i) Copiando un cuadro de mandos existente, como explicado en§11.2.4.

(ii) Creando un cuadro de mandos nuevo, como explicado a conti-nuación.

Independientemente de como se haya creado el cuadro de mandos, elusuario podrá modificarlo de acuerdo a sus necesidades eliminandogadgets que no se necesiten (si el cuadro de mandos ha sido copiado)y añadiendo los que se requieran.

Para crear un cuadro de mandos es necesario efectuar las siguientesoperaciones:

(i) Utilizar el comando Create new dashboard en la esquina superiorderecha de cualquier ventana de gestión de cuadros de mandos(Figura 11.7). JIRA presentará al usuario el formulario de

Figura 11.7: Control de creación de cuadros de mandos.

creación de cuadros de mandos, ilustrado en Figura 11.8.(ii) Establecer el nombre del cuadro de mandos en el control Name.(iii) Establecer la descripción del cuadro de mandos en el control

Description.(iv) Decidir que cuadro de mandos existente puede utilizar comoma-

queta seleccionando un cuadro de mandos del menú desplegabledel control Start from.

(v) Añadir el cuadro de mandos a la lista de favoritos utilizandoel control Favorite, identificado con el icono “estrella amarilla”( ), como explicado en §11.2.1.

301


Figura 11.8: Formulario de creación de cuadros de mandos.

(vi) Compartir el cuadro de mandos añadiendo las identidades conlas cuales se desea compartirlo utilizando el control Add shares,como detallado a continuación.

(vii) Si se desea compartir el cuadro de mandos con cualquier usuariode la plataforma, seleccionar la identidad Everyone en el menúdesplegable del control Add shares y añadiéndola a la lista deidentidades compartidas pulsando el control Add, identificadocon el icono (+).

(viii) Si se desea compartir el cuadro de mandos con un grupo deusuarios, seleccionar la identidad Group en el menú desplegabledel control Add shares. En el menú desplegable que aparecerá ala derecha del menú de identidades, seleccionar el grupo deseadoy añadirlo a la lista de identidades compartidas pulsando elcontrol Add.

(ix) Si se desea compartir el cuadro de mandos con usuarios quepertenezcan a un rol de un proyecto, seleccionar la identidadProject en el menú desplegable del control Add shares. En losmenús desplegables que aparecerán a la derecha del menú deidentidades, seleccionar el proyecto y el rol de proyecto deseado,y añadirlo a la lista de identidades compartidas pulsando elcontrol Add.

(x) Confirmar la creación del cuadro de mandos seleccionando el

302


botón Add en el formulario de creación de cuadros de mandos.

11.2.4 Copiar un cuadro de mandos

En determinadas circunstancias es deseable crear un nuevo cuadro demandos utilizando un cuadro de mandos existente como “maqueta”inicial a la cual aportar las modificaciones que se necesitan. En §11.2.3se ha visto que en el procedimiento estándar de creación de cuadrosde mandos se puede utilizar el control Start from para seleccionar elcuadro de mandos que se desea utilizar como maqueta.

Sin embargo, existe otra opción que permite copiar un cuadrode mandos. En las listas de cuadros de mandos presentadas en lasventanas de gestión, se puede utilizar la operación Copy para co-piar el cuadro de mandos elegido, como ilustrado en Figura 11.9.Seleccionando esta operación, el usuario será llevado a la ventana de

Figura 11.9: Ventana de gestión de cuadros de mandos — OperaciónCopy

creación de cuadro de mandos y el campo Start from del formula-rio de creación será valorizado con el cuadro escogido. El usuariopodrá seguir configurando el nuevo cuadro de mando siguiendo lasinstrucciones detalladas en §11.2.3.

11.2.5 Modificar un cuadro de mandos

Todos los parámetros establecidos al acto de la creación de un cua-dro de mandos pueden modificarse a posteriori utilizando la ventanade modificación de cuadro de mandos. Para acceder a la ventana demodificación es necesario seleccionar la operación Edit del cuadro demandos a modificar en una de las ventanas de gestión, como ilustra-do en Figura 11.10. Seleccionando esta operación, el usuario serállevado al formulario de modificación de cuadro de mandos, ilustrada

303


Figura 11.10: Ventana de gestión de cuadros de mandos — OperaciónEdit

en Figura 11.11, cuya funcionalidad es idéntica a la del formulariode creación. A través de este formulario, siguiendo las instrucciones

Figura 11.11: Ventana de modificación de cuadros de mandos

detalladas en §11.2.3, el usuario podrá modificar el cuadro de mandosseleccionado de acuerdo a sus necesidades.

11.2.6 Eliminar un cuadro de mandos

Un cuadro de mandos puede ser eliminado por el usuario que lo hacreado utilizando la operación Delete en una de las ventanas de ges-tión de cuadros de mandos, como ilustrado en Figura 11.12. Despuésde haber seleccionado esta operación, JIRA pedirá confirmación alusuario con una ventana parecida a la ilustrada en Figura 11.13.Después de haber confirmado la operación, JIRA procederá a la eli-minación del cuadro seleccionado.

304

11.3. Búsqueda de cuadro de mandos

Figura 11.12: Ventana de gestión de cuadros de mandos — OperaciónDelete

Figura 11.13: Ventana de confirmación de eliminación de cuadro demandos

11.3 Búsqueda de cuadro de mandos

La ventana de búsqueda de cuadro de mandos, ilustrada en Figu-ra 11.14, permite buscar entre los cuadros de mandos los que quecumplan los criterios establecidos por el usuario:

(i) Texto libre en nombre y descripción.(ii) Autor.(iii) Tipo de identidad con la cual el cuadro de mando está compar-

tido.

Para buscar un cuadro de mandos es necesario efectuar las siguien-tes operaciones:

(i) Si se desea utilizar un criterio de búsqueda de texto libre en elnombre o en la descripción del cuadro de mando, introducir eltexto a buscar en el campo Search.

(ii) Si se desea restringir la búsqueda a los cuadros de mandos de unusuario, introducir el nombre del usuario en el control Author

305


Figura 11.14: Ventana de búsqueda de cuadro de mandos

o elegir el usuario en la ventana de selección de usuarios queaparece seleccionando el control identificado por el icono ( ).

(iii) Si se desea restringir la búsqueda a los cuadros de mandos quese han compartido con una determinada “identidad”, utilícenseel control Shared with para seleccionar la identidad deseada. Elfuncionamiento de este control es parecido al del control Addshares descrito en §11.2.3.

(iv) Efectuar la búsqueda seleccionando el botón Search en el for-mulario de búsqueda.

Los resultados serán presentado en una lista de cuadros de mandosdebajo del formulario de búsqueda, como ilustrado en Figura 11.15.Los cuadros de mandos en la lista de resultados podrán añadirse a la

Figura 11.15: Ventana de búsqueda de cuadro de mandos — Resultados

306

11.3. Búsqueda de cuadro de mandos

lista de favoritos utilizando el procedimiento descrito en §11.2.1.

307

12Personalizar el cuadro de mandos

En el Capítulo precedente se ha visto como JIRA permite a cadausuario crear sus cuadros de mandos, gestionarlos e, incluso, utilizarcuadros de mandos creados y compartidos por otros usuarios.

En este Capítulo se verá como cada usuario puede personalizarsus cuadros de mandos para organizar la información que se deseemanejar y presentar en cada uno de ellos.

12.1 Operaciones sobre un cuadro de mandos

En el rincón superior derecho de la ventana del cuadro de mandosJIRA proporciona una serie de operaciones, ilustradas en Figura12.1:

(i) Add Gadget, para añadir un gadget al cuadro de mandos, comoexplicado en §??.

(ii) Edit layout, para seleccionar la distribución del cuadro de man-dos, como explicado en §12.2.

(iii) Tools, un menú desplegable (Figura 12.2) que ofrece opera-ciones comunes de gestión, detalladas en el capítulo precedente(§11).

12.2 Selección de la distribución de un cuadro de mandos

JIRA ofrece distintas distribuciones, detalladas en Tabla 12.1, paraque el usuario pueda escoger la que mejor se adapte a sus cuadro demandos, de acuerdo a los gadgets que vaya a disponer en él.

Para elegir la distribución de un cuadro de mando es necesarioefectuar las siguientes operaciones:

309

12. Personalizar el cuadro de mandos

Figura 12.1: Ventana de cuadro de mandos — Operaciones

Figura 12.2: Ventana de cuadro de mandos — Menú Tools

Distribución Descripción

Página entera.

Dos columnas.

Dos columnas, derecha doble.

Dos columnas, izquierda doble.

Tres columnas.

Tabla 12.1: Cuadro de mandos — Distribuciones

310

12.3. Añadir gadgets al cuadro de mandos

(i) Seleccionar el control Edit layout (véase §12.1) en la barra deherramientas de la ventana del cuadro de mandos.

(ii) Seleccionar la nueva disposición (véase §12.1) en la ventana deselección de disposiciones, ilustrada en Figura 12.3.

Figura 12.3: Ventana de selección de distribución del cuadro de mandos

(iii) Cerrar la ventana de selección de distribuciones utilizando elcontrol Close.

El cuadro de mandos utilizará ahora la nueva distribución selec-cionada.

12.3 Añadir gadgets al cuadro de mandos

El usuario puede disponer en un cuadro de mandos cualquiera delos gadgets disponible en JIRA. La lista de gadgets disponibles pordefecto está detallada en §12.7. Es importante subrayar que el admi-nistrador de la plataforma puede añadir gadgets adicionales y que, porla naturaleza y la flexibilidad proporcionada por el estándar Open-Social, se pueden utilizar gadgets de otras aplicaciones utilizando suURL.

Para añadir un gadget a un cuadro de mandos es necesario efectuarlas siguientes operaciones:

(i) Seleccionar el control Add gadget (véase §12.1) en la barra deherramientas de la ventana del cuadro de mandos.

(ii) Seleccionar el gadget que se desea añadir escogiéndolo en laventana de selección de gadgets que JIRA presentará al usuarioilustrada en Figura 12.4.

311


Figura 12.4: Ventana de selección de gadget

(iii) Los gadgets están organizados en categorías y un usuario puederestringir el número de gadgets propuestos en la ventana deselección escogiendo la categoría deseada en el navegador decategorías en la parte izquierda de la ventana.

(iv) El usuario puede buscar un gadget utilizando el control de bús-queda en el rincón superior derecho de la ventana de selección.

(v) Para añadir un gadget, pulsar el botón Add it now del gadgetdeseado.

(vi) Para finalizar la inserción de gadgets y cerrar la ventana deselección, pulsar el botón Finished en el rincón inferior derechode la ventana de selección.

Muchos gadgets, especialmente los gadgets que utilizan una fuen-te de datos para proporcionar información al usuario, necesitan serconfigurados después de haberlos añadido a un cuadro de mandos. Elproceso de configuración es específico de cada gadget y a continua-ción (§12.7 y sucesivas) se detallará el proceso de configuración de losgadgets distribuidos con JIRA.

312

12.4. Operaciones sobre un gadget en un cuadro de mandos

12.4 Operaciones sobre un gadget en un cuadro de man-dos

Cada gadget en un cuadro de mandos tiene una barra de herramientasque está visible cuando el ratón está encima de la barra del título delmismo, como ilustrado en Figura 12.5. Los controles de la barra de

Figura 12.5: Barra de herramientas de un gadget

herramientas permiten personalizar el tamaño del gadget y efectuaroperaciones comunes sobre él. La funcionalidad de cada control de labarra de herramientas está resumido en Tabla 12.2.

Control DescripciónMover el gadget.Maximizar el tamaño del gadget.Restablecer el tamaño del gadget.Menú de operaciones.

Tabla 12.2: Barrade herramientas de un gadget — Controles

El menú de operaciones, accesible utilizando el control ( ) e ilus-trado en Figura 12.6, permite efectuas operaciones comunes sobreun gadget:

(i) Cambiar el tamaño del gadget.

313


(ii) Cambiar el color del gadget, escogiéndolo de una lista de coloresofrecidos por JIRA.

(iii) Eliminar el gadget.(iv) Configurar el gadget.(v) Refrescar el contenido del gadget.

Figura 12.6: Barra de herramientas de un gadget — Menú deoperaciones

12.5 Mover un gadget en un cuadro de mandos

Los gadgets de un cuadro de mandos pueden disponerse a placer, paraorganizar el aspecto del cuadro como desee el autor del mismo.

Para mover un gadget de una posición a otra, es suficiente arras-trar el gadget con el ratón en la nueva posición, como ilustrado enFigura 12.7.

Figura 12.7: Mover un gadget en un cuadro de mandos

314

12.6. Eliminar un gadget de un cuadro de mandos

12.6 Eliminar un gadget de un cuadro de mandos

Para eliminar un gadget de un cuadro de mandos es necesario se-leccionar la operación Delete del menú de operaciones del gadget,como descrito en §12.4. JIRA pedirá confirmación al usuario, en unaventana parecida a la que se ilustra en Figura 12.8, y si el usuarioconfirma la operación pulsando el botón Ok JIRA eliminará el gadgetseleccionado del cuadro de mandos.

Figura 12.8: Ventana de confirmación de eliminación de un gadget deun cuadro de mandos

12.7 Gadgets disponibles

JIRA pone a disposición del usuario un gran número de gadgets y,además, el usuario podrá añadir a un cuadro de mando gadgets queprocedan de plugins de JIRA o de otras aplicaciones. En Tabla 12.3se detalla la lista de gadgets incluidos en JIRA y una breve descripciónse su funcionalidad.

Gadget DescripciónActivity stream Resumen de la actividad reciente.Administration Enlaces rápidos a funciones administrativas.Assigned to me Incidencias abiertas en cualquier proyecto

asignadas al usuario conectado.Average age Gráfico de barras del número medio de días

en los cuales una incidencia se ha quedadoabierta.


315


Gadget DescripciónBamboo charts† Gráficos y estadísticas de una instancia de

Bamboo.Bamboo plan sum-mary chart†

Resumen gráfico de un plan de construcciónde Bamboo.

Bamboo plans† Resumen de los planes de una instancia deBamboo y de sus estados.

Bugzilla ID search Búsqueda por ID de una incidencia en unainstancia de Bugzilla.

Calendar† Fechas de caducidad de incidencias y versio-nes en un calendario.

Clover coverage† Cobertura de Clover de planes de una instan-cia de Bamboo.

Created vs. resolved Gráfico de diferencias de las incidencias crea-das y resueltas en un intervalo de tiempo.

Crucible charts† Resúmenes estadísticos gráficos de las revi-siones de Crucible.

Favourite filter Lista de los filtros favoritos del usuario co-nectado.

Filter result Resultados de un filtro.FishEye charts† Gráficos de estadísticas sobre un repositorio

de FishEye.FishEye recent chan-gesets†

Resumen de los cambios recientes en un re-positorio de FishEye.

In progress Incidencias en progreso y asignadas al usua-rio conectado.

Introduction Mensaje de bienvenida configurable.Issue statistics Estadísticas sobre los resultados de un filtro

por el campo especificado.JIRA: news Noticias recientes sobre Atlassian JIRA.Pie chart Gráfico de torta de los resultados de un filtro

o las incidencias de un proyecto agrupadaspor el campo especificado.

Projects Información y filtros relacionados con el pro-yecto especificado.

Quick links Enlaces útiles a incidencias asignadas alusuario conectado.

Recently created is-sues

Gráfico de barras de la frecuencia de creacióny resolución de las incidencias.

Resolution time Gráfico de barras del tiempo medio de reso-lución de las incidencias.

Road map Resumen del road map de versiones a entre-gar y del trabajo a realizar por cada versión.


316

12.8. Activity stream gadget

Gadget DescripciónText† Fragmento HTML configurable.Time since issues Gráfico de barras del número de incidencias

cuyo campo de tipo fecha elegido cumpla elcriterio escogido.

Two dimensional filterstatistics

Datos estadísticos sobre el filtro escogido enforma tabular.

Voted Incidencias votadas por el usuario conectado.Watched Incidencias observadas por el usuario conec-

tado.† Los gadgets marcados con el símbolo † serán

disponibles solo si el administrador de JIRAlos ha instalado.

Tabla 12.3: Gadgets para el cuadro de mandos de JIRA

12.8 Activity stream gadget

El gadget Activity stream permite de obtener el resumen de la acti-vidad reciente en un grupo de proyectos, opcionalmente filtrada poruna lista de usuarios. Este gadget también proporciona un feed RSSque puede utilizarse para consultar la información proporcionada porel gadget a través de un lector de feeds RSS.

Para configurar este gadget es necesario efectuar las siguientesoperaciones:

(i) Acceder a la pantalla de configuración del gadget, ilustrada enFigura 12.9.

(ii) Seleccionar los proyectos cuya actividad se desea observar selec-cionándolos en la lista de selección múltiple del control Projects.

(iii) Opcionalmente, seleccionar los usuarios con los cuales se deseafiltrar la lista de resultados introduciendo sus nombres, separa-dos por coma (,), en el control Username.

(iv) Introducir el número de elementos a visualizarse en la lista enel control Number of entries.

(v) Seleccionar la frecuencia de actualización de los datos del gadgetescogiendo un valor en el menú desplegable del control Refreshinterval.

(vi) Confirmar la configuración pulsando el botón Save.

317


Figura 12.9: Gadget Activity stream — Configuración

Después de haber configurado el gadget, se visualizarán los datosobtenidos como ilustrado en Figura 12.10.

12.9 Administration gadget

El gadget Administration proporciona “atajos” a las tareas adminis-trativas más comunes. Debido a la naturaleza de las operaciones pro-porcionadas, este gadget es de utilizada para usuarios que posean elpermiso global JIRA Administrators o JIRA System Administrators.

Este gadget no posee ningún tipo de configuración y un ejemplopuede verse ilustrado en Figura 12.11.

318

12.9. Administration gadget

Figura 12.10: Gadget Activity stream

Figura 12.11: Gadget Administration

319


12.10 Assigned to me gadget

El gadget Assigned to me proporciona la lista de incidencias asig-nadas al usuario corriente y las columnas visualizadas en la lista deresultados pueden ser configuradas por el usuario.



Figura 12.12: Gadget Assigned to me

(ii) Introducir el número de elementos a visualizarse en la lista enel control Number of results.

(iii) Opcionalmente, seleccionar las columnas a visualizar en la listade resultados seleccionándolas en la lista de selección múltiplesdel control Columns to display.

(iv) Seleccionar la frecuencia de actualización de los datos del gadgetescogiendo un valor en el menú desplegable del control Refreshinterval.

(v) Confirmar la configuración pulsando el botón Save.

320

12.11. Average age chart gadget


Figura 12.13: Gadget Assigned to me

12.11 Average age chart gadget

El gadget Average age chart proporciona un gráfico de la edad media(en días) de las incidencias no resueltas, en el proyecto o en el filtroespecificado, en los instantes especificados.



(ii) Seleccionar el proyecto o el filtro a utilizarse como fuente dedatos introduciendo su nombre en el control Project or savedfilter o seleccionándolo en la ventana de selección de filtros yproyectos a la que se accede seleccionando el control Advancedsearch.

321


Figura 12.14: Gadget Average age chart

(iii) Seleccionar el tamaño del interval de tiempo a utilizarse en elmenú desplegable del control Period.

(iv) Introducir el número de días a tomarse en consideración en elcontrol Days previously.

(v) Seleccionar la frecuencia de actualización de los datos del gadgetescogiendo un valor en el menú desplegable del control Refreshinterval.

(vi) Confirmar la configuración pulsando el botón Save.


322

12.11. Average age chart gadget

Figura 12.15: Gadget Average age chart

323

13Gestionar el perfil del usuario

El perfil de usuario es el área privada que contiene un resumen dela posición global del usuario, de sus proyectos y de sus tareas ydonde cada usuario de forma independiente puede especificar valorespersonalizados para un conjunto de parámetros que personalizan lafuncionalidad y la apariencia de la plataforma. En este área, además,el usuario tiene acceso a algunas útiles herramientas tales como unconjunto de reportes personales.

Ejemplos de parámetros de configuración de interés muy comúnque pueden establecerse a nivel de perfil de usuario son:

(i) El tamaño de página.(ii) El idioma del interfaz gráfico.(iii) El huso horario utilizado en la actualidad.(iv) El tipo de formato de email que se desean recibir.(v) Las columnas visualizadas por defecto en los navegadores de

incidencia.

Para acceder al perfil del usuario, es necesario seleccionar el propionombre de usuario en la barra de herramientas de JIRA o el elementoProfile en ese mismo menú desplegable (como puede verse en Figura13.1):

La ventana del perfil de usuario (Figura 13.2), contiene algunospaneles, sobre los cuales destacan los siguiente1:

(i) Details: donde puede consultarse un resumen de los detalles delusuario.

1Los paneles visibles en la ventana del perfil de usuario pueden depender delas características de la instalación de la plataforma y de la información presentepor cada uno de los usuarios.

325

13. Gestionar el perfil del usuario

Figura 13.1: Barra de herramientas — Perfil de Usuario

(ii) Preferences: un conjunto de configuraciones y personalizacionesde la plataforma.

(iii) Activity Stream: el flujo de actividad del usuario en cuestión.

Figura 13.2: Perfil de Usuario

Para modificar una propiedad en cualquier panel que lo prevea,es necesario utilizar el icono de edición ( ): JIRA proporcionará unaventana de edición en la cual será posible personalizar las propiedadesmodificables.

326

13.1. Modificar los detalles del usuario

13.1 Modificar los detalles del usuario

En el panel Details es posible modificar los siguientes parámetros:

(i) El avatar del usuario.(ii) El nombre completo del usuario.(iii) La dirección email del usuario.(iv) La contraseña del usuario.

Para modificar uno de estos datos, con la excepción del avatar, esnecesario efectuar las siguientes operaciones:

(i) Seleccionar el icono de edición ( ) del panel.(ii) En la ventana de edición proporcionada por JIRA (Figura

13.3), modificar los parámetros que se desean modificar utili-zando los campos correspondientes.

Figura 13.3: Perfil de usuario — Edición de los detalles de usuario

13.1.1 Modificar el avatar del usuario

Para modificar el avatar del usuario, es necesario efectuar las siguien-tes operaciones:

(i) Seleccionar el avatar corriente del usuario o el icono de edicióndel avatar ( ) que se encuentra a su derecha.

(ii) En la ventana de edición del avatar (Figura 13.4) seleccionarun avatar entre los avatares disponibles o subir al servidor unavatar personalizado.

327


Figura 13.4: Perfil de usuario — Edición del avatar del usuario

(iii) En la ventana de edición del avatar (Figura 13.4) puede se-leccionarse a) un avatar entre los distribuidos con JIRA, dispo-nibles en la pestaña Built-in; b) un avatar entre todos los dis-ponibles en la plataforma, disponibles en la pestaña All; c) unavatar entre los subidos por el usuario, disponibles en la pes-taña Custom. Para seleccionar un avatar entre los avataresexistentes, es necesario seleccionarlo con un click del mouse.

(iv) Si se prefiere utilizar un avatar personalizado en lugar de unavatar de los disponibles en la plataforma, es posible subir unaimagen a JIRA. Para subir un avatar personalizado, seleccio-nar el botón Choose File y seleccionar la imagen deseada. Enla ventana de edición de los avatares personalizados (Figura13.5) será posible escoger la porción de la imagen subida que sedesea utilizar. El avatar debe ser cuadrado y puede escogerse laparte del a imagen deseada arrastrando la “rejilla” del avatar ycambiar su dimensión arrastrando los tiradores cuadrados quese encuentran en sus vértices.

(v) Finalizar la operación seleccionando el botón Choose Avatar yel avatar seleccionado se asociará al usuario.

13.1.2 Modificar la contraseña

Como visto en la sección precedente (§13.1), la contraseña de unusuario puede modificarse utilizando el procedimiento allí detallado,siempre que la gestión de las contraseña no haya sido delegada a unprograma externo. Sin embargo, la contraseña puede modificarse di-

328

13.1. Modificar los detalles del usuario

Figura 13.5: Perfil de usuario — Edición del avatar del usuario

rectamente seleccionando el enlace Change Password del campo Pass-word en el panel Details. En este caso, JIRA visualizará la ventana decambio de contraseña (Figura 13.6) podrá cambiarse la contraseñautilizando el procedimiento detallado a continuación:

(i) Introducir la contraseña actual en el campo Current Password.(ii) Introducir la nueva contraseña en el campo New Password.(iii) Introducir nuevamente la nueva contraseña en el campo Confirm

Password.(iv) Confirmar la operación pulsando el botón Update.

Figura 13.6: Perfil de usuario — Cambio de contraseña

329


13.2 Modificar las preferencias del usuario

En el panel Preferences pueden cambiarse los siguientes parámetrosde configuración del usuario:

(i) Page Size (Tamaño de página): el número de incidencias visua-lizadas en una página del navegador de incidencias.

(ii) Email Type (Formato email): el formato de los emails que sedesea recibir de la plataforma.

(iii) Language (Idioma): el idioma del interfaz web de JIRA.(iv) Time Zone (Huso horario): el huso horario a asociar al usuario.(v) My Changes (Mis cambios): parámetro que controla si un usua-

rio recibe notificaciones sobre sus propios cambios.(vi) Sharing (Intercambio): valor por defecto de la opción de inter-

cambio de filtros y cuadros de mandos.(vii) Keyboard Shortcuts (Atajos de teclado): parámetro que controla

si los atajos de teclado de JIRA están habilitados.(viii) Navigator Columns (Columnas del navegador): columnas visi-

bles por defecto en la ventana del navegador de incidencias.

Las preferencias del usuario, con la excepción de las columnas delnavegador, pueden cambiarse utilizando los correspondientes camposde la ventana de modificación de preferencias (Figura 13.7) accesibleseleccionando el icono de edición ( ).

13.2.1 Cambiar las columnas del navegador de inciden-cias

Las columnas que por defecto se utilizan en el navegador de inciden-cias se establecen utilizando las siguientes opciones:

(i) Las columnas especificadas en el perfil del usuario conectado, siexisten.

(ii) Las columnas especificadas por el administrador a nivel de pla-taforma.

Cada usuario, por lo tanto, puede personalizar el aspecto del navega-dor de incidencias para que se utilicen, por defecto, las columnas quemás le interesen.

Para modificar las columnas que el navegador de incidencias uti-lizará por defecto, es necesario efectuar las siguientes operaciones:

330

13.2. Modificar las preferencias del usuario

Figura 13.7: Perfil de usuario — Modificación de las preferencias

(i) Seleccionar el enlace View Navigator Columns en el campo Na-vigator Columns.

(ii) Seguir el procedimiento ya ilustrado en §6.3.

331

Apéndices e índices

333

ADocumento XML de búsqueda

• title:<title>[TEST-4] This is a test</title>

• link:<link>https://jira.url:443/jira/browse/TEST-4</link>

• project:<project id="10330" key="TST">Test</project>

• description:<description>Issue description.<description>

• environment:<environment>Sydney network<environment>

• key:<key id="22574">TEST-4</key>

• summary:<summary>This is a test<summary>

• type:<type id="3"iconUrl="http://jira.url/jira/images/icons/...">Task

</type>

• priority:<priorityid="4"iconUrl="http://jira.url/jira/images/icons/...">Minor

<priority>

335

A. Documento XML de búsqueda

• status:<status

id="5"iconUrl="http://jira.url/jira/images/icons/...">Resolved

</status>

• resolution:<resolution id="1">Fixed</resolution>

• labels:<labels>

<label>focus</label>...

<labels>

• assignee:<assignee username="jsmith">John Smith</assignee>

• reporter:<security id="10021">Private</security>

• created:<created>

Mon, 1 Sep 2008 17:30:03 -0500 (CDT)</created>

• updated:<updated>

Mon, 1 Sep 2008 17:30:03 -0500 (CDT)</updated>

• resolved:<resolved>

Mon, 1 Sep 2008 17:30:03 -0500 (CDT)</resolved>

• due:<due>

Mon, 1 Sep 2008 17:30:03 -0500 (CDT)</due>

• version:<version>2.4.7</version>

• fixfor:

336

<fixVersion>2.6</fixVersion>

• component:<component>Documentation</component>

• votes:<votes>1</votes>

• comments:<comments><comment id="39270" author="jsmith"

created="Tue, 24 Feb 2009 16:45:02 -0600 (CST)">this looks familiar

</comment>...

</comments>

• attachments:<attachments><attachment id="30318" name="image.png"

size="16161" author="yoz"created="Mon, 9 Feb 2009 13:32:58 -0600 (CST)"/>

...</attachments>

• timeoriginalestimate:<timeoriginalestimate seconds="600">10 minutes

</timeoriginalestimate>

• timeestimate:<timeestimate seconds="300">5 minutes

</timeestimate>

• timespent:<timespent seconds="300">5 minutes

</timespent>

• aggregatetimeoriginalestimate:<aggregatetimeoriginalestimate seconds="36000">10 hours

</aggregatetimeoriginalestimate>

• aggregatetimeestimate:

337

A. Documento XML de búsqueda

<aggregatetimeremainingestimate seconds="18000">5 hours

</aggregatetimeremainingestimate>

• aggregatetimespent:<aggregatetimespent seconds="18000">

5 hours</aggregatetimespent>

• timetracking:<timeoriginalestimate seconds="600">

10 minutes</timeoriginalestimate><timeestimate seconds="300">

5 minutes</timeestimate><timespent seconds="300">

5 minutes</timespent><aggregatetimeoriginalestimate seconds="36000">

10 hours</aggregatetimeoriginalestimate><aggregatetimeremainingestimate seconds="18000">

5 hours</aggregatetimeremainingestimate><aggregatetimespent seconds="18000">

5 hours</aggregatetimespent>

• issuelinks:<issuelinks>

<issuelinktype id="10020"><name>Duplicate</name>

<inwardlinks description="is duplicated by"><issuelink><issuekey id="22477">INTSYS-1009</issuekey>

</issuelink></inwardlinks>

</issuelinktype></issuelinks>

• subtasks:<subtasks>

<subtask id="22623">TEST-8</subtask></subtasks>

338

• customfield_xxxxx:<customfields><customfield id="customfield_10112"

key="com.atlassian.jira.plugin.system.customfieldtypes:select"><customfieldname>Department</customfieldname><customfieldvalues>

<customfieldvalue>Adminstration</customfieldvalue></customfieldvalues>

</customfield></customfields>

• allcustom:<customfields><customfield id="customfield_10112"

key="com.atlassian.jira.plugin.system.customfieldtypes:select"><customfieldname>Department</customfieldname><customfieldvalues>

<customfieldvalue>Adminstration</customfieldvalue></customfieldvalues>

</customfield>...

</customfields>

339

BCampos y funciones JQL

Este capítulo es un capítulo de referencia sobre los aspectos del len-guaje JQL que, por razones de espacio o oportunidad, no se handetallado en otros capítulos del libro. Como tal, este capítulo seráútil a la hora de solucionar las dudas o profundizar las cuestiones quepuedan surgir mientras se editan consultas JQL.

B.1 Campos

En este apartado se detallarán las características de los campos quepueden utilizarse en las consultas JQL.

En la primera sección se detallarán los tipos y los operadores so-portados por cada uno de los campos. La mayoría de las característi-cas de un campo están determinadas por su tipo y las característicascomunes a todos los campos se han detallado anteriormente en §7: eneste capítulo, por lo tanto, se dedicará una sección exclusivamente aaquellos campos que necesitasen información adicional.

B.1.1 ¿Nombres o identificadores?

Algunos campos representan atributos que pueden ser filtrados tantopor nombre como por identificador. Los identificadores son “coorde-nadas” únicas, generalmente numéricas, que JIRA establece al mo-mento de la creación de una “entidad” y no cambiarán nunca a lolargo de la vida de la misma. Los nombres, sin embargo, son “mne-mónicos” asignados por los administradores del proyecto y puedencambiarse en cualquier momento.

Durante la edición de consultas que utilicen campos con esta ca-racterística, es aconsejable utilizar el identificador en lugar del nombresiempre que se pueda. Debido a la “volatilidad” de los nombres, las

341

B. Campos y funciones JQL

consultas que utilicen este dato son frágiles y susceptibles a invalidar-se con el paso del tiempo. Si, además, se decide grabar una consultay almacenarla como filtro, es todavía más importante utilizar pará-metros que no estén susceptibles a variaciones ya que, con el paso deltiempo, una modificación en un nombre podría invalidar cualquierfiltro que esté utilizando este último como valor de un campo.

La utilización de identificadores en lugar de nombres aporta ade-más otra ventaja. Los identificadores son coordenadas únicas a nivelglobal: ninguna entidad de JIRA, en cualquier proyecto, podrá serasignada un identificador ya utilizado por otra entidad. Los nombres,sin embargo, no garantizan este tipo de unicidad y, por lo tanto, unaconsulta que utilice nombres es frágil ya que, si no se toman precau-ciones1, podrían devolverse resultados que no se esperan provenientesde otros proyectos.

Los campos que tienen esta particularidad son los campos de lostipos siguientes:

(i) Versión(ii) Componente(iii) Filtro(iv) Nivel de seguridad(v) Prioridad(vi) Resolución(vii) Estado(viii) Tipo de incidencia

Esta información también está convenientemente resumida en TablaB.1.

B.1.2 Tipos de campos JQL

Los campos JQL están subdivididos en tipos y esta propiedad de-termina la mayoría del comportamiento del campo, tanto a nivel deformato de los valores aceptados, como a nivel de operadores (§B.1.3)o funciones (§B.2) soportadas por dichos campos.

Los tipos de campos que existen en JIRA son los detallados enTabla B.1. La primera segunda columna de esta tabla indica elsímbolo que hemos escogido para referirnos al tipo de campo. Lautilización de esta simbología se debe a razones prácticas, como por

1Tales como filtrar de forma explícita la lista de proyectos en la que se estáefectuando la búsqueda.

342

B.1. Campos

Tipo Símbulo Clave/ValorVersión v •Usuario uCategoría lTexto tComponente c •Fecha fFiltro x •Incidencia iNivel de seguridad s •Duración dPrioridad o •Proyecto pResolución r •Estado e •Tipo de incidencia y •Número nCascading option co

Tabla B.1: Tipos de campos JQL.

ejemplo situaciones en los cuales existen restricciones de espacio comolas tablas, y está restringida al contexto de esta guía.

La segunda columna de la tabla indica si el campo soporta la“dualidad identificador/nombre” durante la evaluación de las consul-tas. Cuando se utilicen campos de este tipo, se recomienda seguir lasindicaciones detalladas en §B.1.1.

B.1.3 Operadores soportados por los campos

En Tabla B.2 se detallan los operadores soportados por todos loscampos. Para razones de espacio se utilizará una sola columna paralos siguientes grupos de operadores:

(i) = y 6=, indicados con el símbulo =.(ii) ˜ y !˜, indicados con el símbulo ≈.(iii) >,≥, < y ≤, indicados con el símbulo ≥.(iv) is, is not, indicados con el símbulo ≡.(v) in, not in, indicados con el símbulo ∈.

343


Si un campo soporta un operador entonces soportará también el ope-rador inverso y si un campo es de un tipo para el cual existe la relaciónde órden, soportará todos los operadores en (iii).

En la columna tipo se detallará el tipo de campo utilizando lossímbolos definidos en Tabla B.1.

tipo = ≈ ≥ ≡ ∈affectedVersion v • • • •assignee u • • •category l • • •comment t •component c • • •created f • • • •description t • •due f • • • •environment t • •filter x • •fixVersion v • • • •issueKey i • • • •level s • • •originalEstimate d • • • •parent i • •priority o • • • •project p • • •remainingEstimate d • • • •reporter u • • •resolution r • • • •resolved f • • • •status e • • •summary t • •text t •type y • • •timeSpent d • • • •updated f • • • •voter u • • •votes n • • •watcher u • • •workRatio n • • • •

Tabla B.2: Operadores soportados por los campos JQL.

En el caso de los campos personalizados, la lista de operadoressoportados dependerá del tipo de campo en cuestión:

344

B.1. Campos

(i) Numéricos: los campos de tipo número o fecha soportarán re-laciones de equivalencia, órden.

(ii) Selección: los campos de tipo picker, selección, check box y radiosoportarán relaciones de equivalencia.

(iii) Texto: los campos de tipo texto soportarán todas las funciona-lidades relacionadas con la búsqueda de texto.

En Tabla B.3 puede verse la lista de operadores soportados por losvarios tipos de campos personalizados.

= ≈ ≥ ≡ ∈Numérico • • • •Selección • • •Texto • •

Tabla B.3: Operadores JQL soportados por campos personalizados.

B.1.4 Campos de tipo versión

Los campos de tipo versión soportan los operadores y las funcionesdetalladas en Tabla B.4.

tipo = ≈ ≥ ≡ ∈affectedVersion v • • • •fixVersion v • • • •releasedVersions() •unreleasedVersions() •

Tabla B.4: Operadores y funciones soportados por campos de tipoversión.

Como explicado en §B.1.1, debido a que el nombre de una versiónpuede cambiar a lo largo de la vida de un proyecto y debido a queproyectos distintos pueden tener versiones con el mismo nombre, seaconseja utilizar el identificador de versión en las búsquedas, espe-cialmente cuando las búsquedas se graban en filtros. De esta forma,siendo éste un valor único que no puede cambiarse, los filtros existen-tes no se verán afectados por eventuales operaciones de renombradode las versiones de un proyecto.

345


Los campos de tipo versión soportan la relación de órden detalladaen §??.

Ejemplo B.1. Para buscar las incidencias que afecten a la versión1.0, será necesario utilizar la siguiente proposición:

affectedVersion = "1.0"

Nótese que en la proposición precedente, debido a que el punto (.)es un carácter reservado (véase §7.2), es necesario poner el valor delcampo entre comillas.

Ejemplo B.2. Para buscar las incidencias que afecten a la versióncuyo identificados es 10350, será necesario utilizar la siguiente propo-sición:

affectedVersion = 10350

B.1.5 Campos de tipo usuario

Los campos de tipo usuario soportan los operadores y las funcionesdetalladas en Tabla B.5.

tipo = ≈ ≥ ≡ ∈assignee u • • •reporter u • • •voter u • • •watcher u • • •currentUsers() •membersOf() •

Tabla B.5: Operadores y funciones soportados por campos de tipousuario.

El valor especificado para un campo de tipo usuario se compararácon los atributos nombre, identificado y dirección de correo electró-nico de los usuarios de JIRA y se devolverán aquellas incidenciaspara las cuales al menos uno de estos atributos satisfaga el criterioespecificado.

Cuando se evalúen proposiciones que utilicen los campos voter ywatcher se podrá acceder exclusivamente a los valores para los cuales

346

B.1. Campos

el usuario que efectúa la búsqueda tenga el permiso View voters andwatchers.

Ejemplo B.3. Para buscar las incidencias cuyo asignatario sea elusuario que efectúa la búsqueda, será necesario utilizar la siguienteproposición:

assignee = currentUser()

Ejemplo B.4. Para buscar las incidencias cuyo asignatario tenga ladirección de correo electrónico especificada, será necesario utilizar lasiguiente proposición:

assignee = "[email protected]"

nótese que en la proposición precedente, debido a que el arroba (@)es un carácter reservado (véase §??), es necesario poner el valor entrecomillas.

B.1.6 Campos de tipo categoría

Los campos de tipo categoría soportan los operadores y las funcionesdetalladas en Tabla B.6.

tipo = ≈ ≥ ≡ ∈category l • • •—

Tabla B.6: Operadores y funciones soportados por campos de tipocategoría.

B.1.7 Campos de tipo texto

Los campos de tipo texto soportan los operadores y las funcionesdetalladas en Tabla B.7.

Todos los campos detallados en Tabla ?? permiten efectuar bús-quedas en los campos correspondientes de las incidencias.

El campo text, sin embargo, no corresponde a ningún atributo deuna incidencia y es un campo “maestro” que permite buscar en todoslos campos de tipo texto en una única proposición. Los campos que

347


tipo = ≈ ≥ ≡ ∈comment t •description t • •environment t • •summary t • •text t •—

Tabla B.7: Operadores y funciones soportados por campos de tipo texto.

se examinarán durante una proposición que utilice el campo text sonlos siguientes:

(i) Título.(ii) Descripción.(iii) Entorno.(iv) Comentarios.(v) Campos personalizados que utilicen el buscador de texto libre

(§??), tales como:a) Campo de texto libre.b) Campo de texto.c) Campo de texto de sola lectura.

Ejemplo B.5. Para buscar las incidencias cuyo título contenga eltérmino transferencia será necesario utilizar la siguiente proposición:

summary ~ transferencia

Ejemplo B.6. Para buscar las incidencias que tengan un campode texto que contenga el término enrico será necesario utilizar lasiguiente proposición:

text ~ enrico

Ejemplo B.7. Para buscar las incidencias que tengan un campo detexto que contenga la frase pago de factura será necesario utilizar lasiguiente proposición:

348

B.1. Campos

text ~ "pago de factura"

B.1.8 Campos de tipo componente

Los campos de tipo componente soportan los operadores y las funcio-nes detalladas en Tabla B.8.

tipo = ≈ ≥ ≡ ∈component c • • •componentsLeadByUser() •

Tabla B.8: Operadores y funciones soportados por campos de tipocomponente.

Como explicado en §B.1.1, el valor especificado para un campo detipo componente puede ser tanto el nombre como el identificador delcomponente. Es aconsejable utilizar el identificador del componen-te en lugar del nombre ya que el primero es un identificador único,generado al momento de la creación del componente, que no puedecambiarse a lo largo de la vida del proyecto. El nombre de un compo-nente, sin embargo, puede cambiarse en cualquier momento y, por lotanto, las consultas que utilicen este dato son frágiles y susceptibles ainvalidarse con el paso del tiempo. Los nombres de los componentes,además, no siendo únicos, pueden repetirse en múltiples proyectos y,por lo tanto, las consultas pueden devolver datos inesperados si estasituación no se maneja oportunamente.

Ejemplo B.8. Para buscar las incidencias que pertenezcan al compo-nente cuyo identificador es 20500, será necesario utilizar la siguienteproposición:

component = 20500

B.1.9 Campos de tipo fecha

Los campos de tipo fecha soportan los operadores y las funcionesdetalladas en Tabla B.9.

El formato de los valores aceptados para un campo de tipo fechason los siguientes:

349


tipo = ≈ ≥ ≡ ∈created f • • • •due f • • • •resolved f • • • •updated f • • • •currentLogin() •lastLogin() •now() •

Tabla B.9: Operadores y funciones soportados por campos de tipo fecha.

(i) "yyyy/MM/dd HH:mm".(ii) "yyyy-MM-dd HH:mm".(iii) "yyyy/MM/dd".(iv) "yyyy-MM-dd".(v) "±xw yd zh tm".

Los primeros 4 formatos se utilizan para especificar una fecha abso-luta mientras que el último formato se utiliza para indicar una fecharelativa.

En el formato de campo para fechas relativas, los coeficientes de loscampos w, d, h y t indican, respectivamente, el número de semanas,horas, días y minutos. El signo + indicará una intervalo en el futuromientras que el signo − indicará una intervalo en el pasado.

El campo due solo contiene información acerca de la fecha deresolución e ignora la información relativa a la hora.

Ejemplo B.9. Para buscar las incidencias que se hayan creado des-pués del día 06/09/2010 (6 de Septiembre del 2010), será necesarioutilizar la siguiente proposición:

created > "2010/09/06"

Nótese que, para satisfacer el formato de este campo, deberá ponerseantes el año, seguido por mes y día.

Ejemplo B.10. Para buscar las incidencias que no se hayan actua-lizadas en las últimas 3 semanas, será necesario utilizar la siguienteproposición:

updated < "-3w"

350

B.1. Campos

B.1.10 Campos de tipo filtro

Los campos de tipo filtro soportan los operadores y las funcionesdetalladas en Tabla B.10.

tipo = ≈ ≥ ≡ ∈filter x • •—

Tabla B.10: Operadores y funciones soportados por campos de tipofiltro.

El campo JQL filter no es un atributo de las incidencias de JIRAy proporciona un mecanismo para acotar las incidencias filtradas alos resultados de un filtro existente.

Como explicado en §B.1.1, es aconsejable utilizar el identificadordel filtro en lugar del nombre ya que el primero es un identificadorúnico, generado al momento de la creación del filtro, que no puedecambiarse a lo largo de su vida. El nombre de un filtro, sin embargo,puede cambiarse en cualquier momento y, por lo tanto, las consultasque utilicen este dato son frágiles y susceptibles a invalidarse con elpaso del tiempo.

Cuando se utiliza este campo es importante subrayar lo siguiente:

(i) El ordenamiento que, opcionalmente, se especifique en la con-sulta (con el operador order by) tendrá precedencia sobre elordenamiento especificado en el filtro.

(ii) No puede ejecutarse una consulta que genere un bucle infinito,por ejemplo utilizando un filtro que a su vez haga referencia alfiltro corriente.

Ejemplo B.11. Para buscar las incidencias devueltas por el filtrocon identificador 12000 para seleccionar aquellas asignadas al usuarioenrico, será necesario utilizar la siguiente proposición:

filter = 12000 and assignee = enrico

Ejemplo B.12. Para buscar las incidencias devueltas por el filtrollamado Órdenes impagados, será necesario utilizar la siguiente pro-posición:

351


filter = "Órdenes impagados"

Nótese que, en este caso, se está utilizando el nombre de un filtro enlugar de su identificador y, por lo tanto, el usuario está expuestos alos problemas detallados en §B.1.1.

B.1.11 Campos de tipo incidencia

Los campos de tipo incidencia soportan los operadores y las funcionesdetalladas en Tabla B.11 y Tabla B.12.

tipo = ≈ ≥ ≡ ∈issueKey i • • • •issueHistory() •linkedIssues() •votedIssues() •watchedIssues() •

Tabla B.11: Operadores y funciones soportados por campos de tipoincidencia.

tipo = ≈ ≥ ≡ ∈parent i • •—

Tabla B.12: Operadores y funciones soportados por campos de tipoincidencia.

Ejemplo B.13. Para buscar la incidencia con identificador JGD-135,será necesario utilizar la siguiente proposición:

issueKey = JGD-135

B.1.12 Campos de tipo nivel de seguridad

Los campos de tipo nivel de seguridad soportan los operadores y lasfunciones detalladas en Tabla B.13.

Como explicado en §B.1.1, es aconsejable utilizar el identificadordel nivel de seguridad en lugar del nombre ya que el primero es un

352

B.1. Campos

tipo = ≈ ≥ ≡ ∈level s • • •—

Tabla B.13: Operadores y funciones soportados por campos de tiponivel de seguridad.

identificador único, generado al momento de la creación del nivel, queno puede cambiarse a lo largo de su vida. El nombre de un nivel deseguridad, sin embargo, puede cambiarse en cualquier momento y, porlo tanto, las consultas que utilicen este dato son frágiles y susceptiblesa invalidarse con el paso del tiempo.

Ejemplo B.14. Para buscar la incidencia con nivel de seguridad Res-ponsables de proyecto o operadores, será necesario utilizar la siguienteproposición:

level in ("Responsables de proyecto",operadores)

B.1.13 Campos de tipo duración

Los campos de tipo duración soportan los operadores y las funcionesdetalladas en Tabla B.14.

tipo = ≈ ≥ ≡ ∈originalEstimate d • • • •remainingEstimate d • • • •timeSpent d • • • •—

Tabla B.14: Operadores y funciones soportados por campos de tipoduración.

El formato de los valores aceptados para un campo de tipo dura-ción es:

(i) "±xw yd zh tm".

Los coeficientes de los campos w, d, h y t indican, respectivamente, elnúmero de semanas, horas, días y minutos. El signo + indicará una

353


intervalo en el futuro mientras que el signo − indicará una intervaloen el pasado.

B.1.14 Campos de tipo prioridad

Los campos de tipo prioridad soportan los operadores y las funcionesdetalladas en Tabla B.15.

tipo = ≈ ≥ ≡ ∈priority o • • • •currentLogin() •lastLogin() •now() •

Tabla B.15: Operadores y funciones soportados por campos de tipoprioridad.

Como explicado en §B.1.1, es aconsejable utilizar el identificadorde la prioridad en lugar del nombre ya que el primero es un identi-ficador único, generado al momento de la creación del nivel, que nopuede cambiarse a lo largo de su vida. El nombre de una prioridad,sin embargo, puede cambiarse en cualquier momento y, por lo tan-to, las consultas que utilicen este dato son frágiles y susceptibles ainvalidarse con el paso del tiempo.

Ejemplo B.15. Para buscar las incidencias con prioridad High, seránecesario utilizar la siguiente proposición:

priority = High

B.1.15 Campos de tipo proyecto

Los campos de tipo proyecto soportan los operadores y las funcionesdetalladas en Tabla B.16.

El campo project permite filtrar las incidencias por proyecto y elvalor utilizado en la proposición será comparado con los atributosnombre de proyecto, clave de proyecto e identificador de proyecto: lasincidencias que pertenezcan a un proyecto que satisfaga al menos unode dichos atributos serán devueltas como resultado.

354

B.1. Campos

tipo = ≈ ≥ ≡ ∈project p • • •projectsLeadByUser() •projectsWhereUserHasPermission() •projectsWhereUserHasRole() •

Tabla B.16: Operadores y funciones soportados por campos de tipoproyecto.

Ejemplo B.16. Para buscar las incidencia que pertenezcan al pro-yecto que se llame JIRA Guide, será necesario utilizar la siguienteproposición:

project = "JIRA Guide"

Ejemplo B.17. Para buscar las incidencia que pertenezcan al pro-yecto cuya clave sea JRAGD, será necesario utilizar la siguiente pro-posición:

project = "JRAGD"

B.1.16 Campos de tipo resolución

Los campos de tipo resolución soportan los operadores y las funcionesdetalladas en Tabla B.17.

tipo = ≈ ≥ ≡ ∈resolution r • • • •—

Tabla B.17: Operadores y funciones soportados por campos de tiporesolución.

Como explicado en §B.1.1, el valor especificado para un campo detipo resolución puede ser tanto el nombre como el identificador de laresolución. Es aconsejable utilizar el identificador del resolución enlugar del nombre ya que el primero es un identificador único, generado

355


al momento de la creación de la misma, que no puede cambiarse a lolargo de su vida. El nombre de una resolución, sin embargo, puedecambiarse en cualquier momento y, por lo tanto, las consultas queutilicen este dato son frágiles y susceptibles a invalidarse con el pasodel tiempo.

Ejemplo B.18. Para buscar las incidencia que no hayan sido resuel-tas todavía, será necesario utilizar la siguiente proposición:

resolution = unresolved

Ejemplo B.19. Para buscar las incidencia que no hayan sido resultascon resolución Cannot reproduce, será necesario utilizar la siguienteproposición:

resolution = "Cannot Reproduce"

B.1.17 Campos de tipo estado

Los campos de tipo estado soportan los operadores y las funcionesdetalladas en Tabla B.18.

tipo = ≈ ≥ ≡ ∈status e • • •—

Tabla B.18: Operadores y funciones soportados por campos de tipoestado.

Como explicado en §B.1.1, el valor especificado para un campode tipo estado puede ser tanto el nombre como el identificador delestado. Es aconsejable utilizar el identificador de estado en lugardel nombre ya que el primero es un identificador único, generado almomento de la creación del mismo, que no puede cambiarse a lo largode su vida. El nombre de un estado, sin embargo, puede cambiarseen cualquier momento y, por lo tanto, las consultas que utilicen estedato son frágiles y susceptibles a invalidarse con el paso del tiempo.

Ejemplo B.20. Para buscar las incidencia que estén en estado Open,será necesario utilizar la siguiente proposición:

356

B.1. Campos

status = Open

B.1.18 Campos de tipo tipo de incidencia

Los campos de tipo tipo de incidencia soportan los operadores y lasfunciones detalladas en Tabla B.19.

tipo = ≈ ≥ ≡ ∈type y • • •—

Tabla B.19: Operadores y funciones soportados por campos de tipo tipode incidencia.

Como explicado en §B.1.1, el valor especificado para un campo detipo tipo de incidencia puede ser tanto el nombre como el identifica-dor del tipo de incidencia. Es aconsejable utilizar el identificador detipo de incidencia en lugar del nombre ya que el primero es un identi-ficador único, generado al momento de la creación del mismo, que nopuede cambiarse a lo largo de su vida. El nombre de un tipo de inci-dencia, sin embargo, puede cambiarse en cualquier momento y, por lotanto, las consultas que utilicen este dato son frágiles y susceptiblesa invalidarse con el paso del tiempo.

Ejemplo B.21. Para buscar las incidencia de tipo bug, será necesarioutilizar la siguiente proposición:

type = Bug

Ejemplo B.22. Para buscar las incidencia de tipo factura, será ne-cesario utilizar la siguiente proposición:

type = Factura

357


tipo = ≈ ≥ ≡ ∈votes n • • •workRatio n • • • •—

Tabla B.20: Operadores y funciones soportados por campos de tiponúmero.

B.1.19 Campos de tipo número

Los campos de tipo número soportan los operadores y las funcionesdetalladas en Tabla B.20.

El campo votes permite filtrar las incidencias utilizando el númerousuarios que hayan votado la incidencia.

El campo work ratio permite filtrar las incidencia utilizando el por-centaje de trabajo, w, definido como relación entre trabajo realizado,wr, y trabajo estimado total, wt:

w = wrwt· 100 (B.1)

B.2 Funciones

JIRA ofrece un conjunto de funciones JQL que pueden utilizarse enlas consultas en lugar de un valor. Las funcionen responden a la ne-cesidad de poder expresar, grabar y compartir consultas en las cualesaparecen campos cuyo valor depende, por ejemplo, del usuario queesté ejecutando la misma y que deberían establecerse en “tiempo deejecución”.

El valor devuelto por una función, generalmente, depende de pa-rámetros tales como el usuario que efectúa la consulta, el instante enque se efectúa una consulta, las políticas de seguridad en vigor o losatributos de las incidencias que se examinan. Algunas funciones, ade-más, devuelven valores de los parámetros de configuración de JIRA ysus proyectos (tales como los componentes liderados por un usuario).Sin ellas, no sería posible efectuar algunas consultas de forma sencillay sería necesario efectuarlas “en dos pasos”: antes, habría que deter-minar los valores por los que se desean filtrar los campos2 y, después,efectuar la consulta con los valores adecuados.

2Ya sea a través de otra consulta o examinando directamente la configuraciónde JIRA y sus proyectos.

358

B.2. Funciones

Sin funciones no podrían compartirse, por ejemplo, consultas tansencillas como incidencias abiertas por el usuario que efectúa la con-sulta. En falta de una función (currentUser()) que devuelva “di-námicamente” el nombre del usuario actualmente conectado, cadausuario debería remplazar el valor del campo assignee en la consul-ta:

assignee = enrico ...

De esta forma, sería materialmente imposible grabar esta consulta enun filtro y compartirlo con otros usuarios ya que, cada uno de ellos,debería modificar la misma y guardarla en otro filtro.

Las funciones devuelven valores de distintos tipos y, por lo tanto,una función no puede utilizarse con cualquier combinación de campoy operador: dependiendo de la combinación utilizada, como puedeverse en Tabla B.21, existe un conjunto de funciones soportadascuya funcionalidad será detallada a continuación.

tipo = ≈ ≥ ≡ ∈cascadeOption(.,.) co •componentsLeadByUser(.) c •currentLogin() f • •currentUser() u •issueHistory() i •lastLogin() f • •linkedIssues(.,.) i •membersOf(.) u •now() f • •projectsLeadByUser(.) p •projectsWhereUserHasPermission(.) p •projectsWhereUserHasRole(.) p •releasedVersions(.) v •standardIssueTypes() y •subtaskIssueTypes() y •unreleasedVersions(.) v •votedIssues() i •watchedIssues() i •

Tabla B.21: Funciones JQL soportados por tipo de campo de campo yclase de operador.

359


En la primera columna de la tabla se indica el nombre de la fun-ción. Si la función acepta parámetros, entonces se indicarán con lanotación (.,.) en el nombre de la función.

En la segunda columna se indica el tipo de campo con el cual puedeutilizarse la función. La nomenclatura de tipos es la misma que se hautilizado en precedencia y que es detallada en Tabla B.1.

En las siguientes columnas se indica cuales operadores están so-portados por la función, agrupando los operadores JQL en los gruposque se han utilizado con anterioridad. Para mayores detalles sobreesta notación, véase §B.1.3.

Ejemplo B.23. La función projectsWhereUserHasPermission, porejemplo, tiene las siguientes características:

(i) Acepta un parámetro.(ii) Puede utilizarse con campos de tipo proyecto.(iii) Puede utilizarse exclusivamente con operadores de tipo ∈, es

decir, los operadores in y not in.

Ejemplo B.24. La función currentLogin, por ejemplo, tiene lassiguientes características:

(i) No acepta ningún parámetro.(ii) Puede utilizarse con campos de tipo fecha.(iii) Puede utilizarse exclusivamente con operadores de tipo = y ≥,

es decir, los operadores =, !=, <, <=, > y >=.

B.2.1 Función cascadeOption

La función cascadeOption soporta el tipo de campo y los operadoresdetallados en Tabla B.22. Esta función permite filtrar las inciden-

tipo = ≈ ≥ ≡ ∈cascadeOption(.,.) co •

Tabla B.22: Tipo de campo de campo y clase de operador soportada porcascadeOption.

360

B.2. Funciones

cias por un campo de tipo cascading select de uno o dos niveles deprofundidad.

La función acepta dos parámetros:

(i) El primer parámetro identifica la opción de primer nivel contrala cual hay que filtrar el campo de las incidencias.

(ii) El segundo parámetro, un parámetro opcional, identifica la op-ción de segundo nivel contra la cual hay que filtrar el campo delas incidencias.

Para indicar como parámetro a una opción vacía puede utilizarse lapalabra clave none.

Ejemplo B.25. Si se ha definido un campo personalizado de tipocascading option, llamado provincia, para filtrar aquellas incidenciascuyo campo sea la pareja (España, Madrid), será necesario efectuarutilizar la siguiente proposición:

provincia in cascadeOption("España", "Madrid")

Ejemplo B.26. Si se ha definido el mismo campo personalizado des-crito en el ejemplo B.25, para filtrar aquellas incidencias cuyo camposea la pareja (España, ∅), es decir, en el cual el valor de primer ni-vel sea España y el valor de segundo nivel esté vacío, será necesarioefectuar utilizar la siguiente proposición:

provincia in cascadeOption("España", none)

Ejemplo B.27. Si se ha definido el mismo campo personalizado des-crito en el ejemplo B.25, para filtrar aquellas incidencias cuyo campoesté vacío (en ambos niveles), será necesario efectuar utilizar la si-guiente proposición:

provincia in cascadeOption(none)

361


tipo = ≈ ≥ ≡ ∈componentsLeadByUser(.) c •

Tabla B.23: Tipo de campo de campo y clase de operador soportada porcomponentsLeadByUser.

B.2.2 Función componentsLeadByUser

La función componentsLeadByUser soporta el tipo de campo y losoperadores detallados en Tabla B.23. Esta función permite filtrar lasincidencias por un campo de tipo componente utilizando el conjuntode componentes cuyo líder sea el usuario especificado por parámetro.La función acepta un parámetros:

(i) El primer parámetro, opcional, identifica el usuario líder de loscomponentes que se desean buscar. En el caso en que no se es-pecificare este parámetro, la función devolverá los componentesliderados por el usuario que está efectuando la consulta.

En el caso en que el usuario que efectúa la consulta no está au-tenticado en JIRA, así como en el caso en que se pretenda grabarla consulta en un filtro que pueda ser utilizado por un usuario noautenticado, el parámetro debe ser especificado.

Ejemplo B.28. Para filtrar aquellas incidencias cuyo campo componentcontenga un componente liderado por el usuario enrico, será necesarioefectuar utilizar la siguiente proposición:

component in componentsLeadByUser(enrico)

Ejemplo B.29. Para filtrar aquellas incidencias cuyo campo componentcontenga un componente liderado por el usuario que está efectuandola consulta, será necesario efectuar utilizar la siguiente proposición:

component in componentsLeadByUser()

362

B.2. Funciones

tipo = ≈ ≥ ≡ ∈currentLogin() f • •

Tabla B.24: Tipo de campo de campo y clase de operador soportada porcurrentLogin.

B.2.3 Función currentLogin

La función currentLogin soporta el tipo de campo y los operadoresdetallados en Tabla B.24. Esta función devuelve la fecha correspon-diente al momento en que el usuario que está efectuando la consultaha efectuado login en la plataforma. Véase la función lastLogin(§??), que devuelve la fecha de autenticación en la sesión anterior.

Ejemplo B.30. Para filtrar aquellas incidencias que se han creadodespués de que el usuario haya hecho login, será necesario efectuarutilizar la siguiente proposición:

created > currentLogin()

Ejemplo B.31. Para filtrar aquellas incidencias que se han actualiza-do después de que el usuario haya hecho login, será necesario efectuarutilizar la siguiente proposición:

updated > currentLogin()

Ejemplo B.32. Para filtrar aquellas incidencias que se han resueltodespués de que el usuario haya hecho login, será necesario efectuarutilizar la siguiente proposición:

resolved > currentLogin()

B.2.4 Función currentUser

La función currentUser soporta el tipo de campo y los operadoresdetallados en Tabla B.25. Esta función devuelve el usuario actual-mente conectado a la plataforma.

363


tipo = ≈ ≥ ≡ ∈currentUser() u •

Tabla B.25: Tipo de campo de campo y clase de operador soportada porcurrentUser.

Si el usuario que efectúa la consulta no está autenticado en JIRA,esta función no está disponible. En este caso, por lo tanto, así comoen el caso en que se pretenda grabar la consulta en un filtro que puedaser utilizado por un usuario no autenticado, no hay que utilizar estafunción.

Ejemplo B.33. Para filtrar aquellas incidencias asignadas al usuarioque está efectuando la consulta, será necesario efectuar utilizar lasiguiente proposición:

assignee = currentUser()

Ejemplo B.34. Para filtrar aquellas incidencias asignadas al usuarioque está efectuando la consulta y que no hayan sido creadas por él,será necesario efectuar utilizar la siguiente proposición:

assignee = currentUser() and created != currentUser()

B.2.5 Función issueHistory

La función issueHistory soporta el tipo de campo y los operadoresdetallados en Tabla B.26. Esta función devuelve el conjunto de inci-

tipo = ≈ ≥ ≡ ∈issueHistory() i •

Tabla B.26: Tipo de campo de campo y clase de operador soportada porissueHistory.

dencias que estén en la historia reciente del usuario, es decir, aquellasincidencias que el usuario haya utilizado recientemente.

364

B.2. Funciones

Si el usuario está autenticado en la plataforma, JIRA devolverálas últimas 50 incidencias que el usuario haya utilizado en la sesióncorriente y en las demás sesiones. Si el usuario no está autenticado,JIRA devolverá exclusivamente las incidencias que hayan sido utili-zadas en la sesión de navegación corriente.

Ejemplo B.35. Para filtrar aquellas incidencias asignadas al usua-rio que está efectuando la consulta y que hayan sido utilizadas re-cientemente por el mismo, será necesario efectuar utilizar la siguienteproposición:

assignee = currentUser() and issue in issueHistory()

B.2.6 Función lastLogin

La función lastLogin soporta el tipo de campo y los operadoresdetallados en Tabla B.27. Esta función devuelve la fecha correspon-

tipo = ≈ ≥ ≡ ∈lastLogin() f • •

Tabla B.27: Tipo de campo de campo y clase de operador soportada porlastLogin.

diente al momento en que el usuario que está efectuando la consultaha efectuado login en la plataforma en la sesión precedente. Véase lafunción currentLogin (§??), que devuelve la fecha de autenticaciónen la sesión corriente.

Ejemplo B.36. Para filtrar aquellas incidencias que se han resueltodespués de la precedente sesión de usuario, será necesario efectuarutilizar la siguiente proposición:

resolved > lastLogin()

365


tipo = ≈ ≥ ≡ ∈linkedIssues(.,.) i •

Tabla B.28: Tipo de campo de campo y clase de operador soportada porlinkedIssues.

B.2.7 Función linkedIssues

La función linkedIssues soporta el tipo de campo y los operadoresdetallados en Tabla B.28. Esta función devuelve el conjunto de in-cidencias con las cuales la incidencia especificada establece un enlace.La búsqueda se puede acotar utilizando los parámetros de la función,que son los siguientes:

(i) El primer parámetro es la clave de la incidencia de la cual sebuscan los enlaces.

(ii) El segundo parámetro, opcional, es el tipo de enlace que se deseaencontrar. Es importante subrayar que este parámetro es case-sensitive.

Ejemplo B.37. Para filtrar aquellas incidencias que tengan un en-lace con la incidencia JRAGD-1, será necesario efectuar utilizar lasiguiente proposición:

issue in linkedIssues(JRAGD-1)

Ejemplo B.38. Para filtrar aquellas incidencias que tengan un enlacede tipo is duplicated by con la incidencia JRAGD-1, será necesarioefectuar utilizar la siguiente proposición:

issue in linkedIssues(JRAGD-1, "is duplicated by")

B.2.8 Función membersOf

La función membersOf soporta el tipo de campo y los operadoresdetallados en Tabla B.29. Esta función devuelve el conjunto deusuarios que pertenecen al grupo especificado por parámetro. Losparámetros aceptados por la función son los siguientes:

366

B.2. Funciones

tipo = ≈ ≥ ≡ ∈membersOf(.) u •

Tabla B.29: Tipo de campo de campo y clase de operador soportada pormembersOf.

(i) El grupo del cual se quieren encontrar los usuarios.

Ejemplo B.39. Para filtrar aquellas incidencias que tengan un enlacede tipo is duplicated by con la incidencia JRAGD-1, será necesarioefectuar utilizar la siguiente proposición:

issue in linkedIssues(JRAGD-1, "is duplicated by")

B.2.9 Función now

La función now soporta el tipo de campo y los operadores detalladosen Tabla B.30. Esta función devuelve la fecha correspondiente al

tipo = ≈ ≥ ≡ ∈now() f • •

Tabla B.30: Tipo de campo de campo y clase de operador soportada pornow.

instante en que se está evaluando la función.

Ejemplo B.40. Para filtrar aquellas incidencias que hayan venci-do en el instante de la búsqueda, será necesario efectuar utilizar lasiguiente proposición:

due < now() and status not in (closed, resolved)

B.2.10 Función projectsLeadByUser

La función projectsLeadByUser soporta el tipo de campo y los ope-radores detallados en Tabla B.31. Esta función devuelve el conjuntode proyectos liderados por el usuario especificado por parámetro. Losparámetros aceptados por la función son los siguientes:

367


tipo = ≈ ≥ ≡ ∈projectsLeadByUser(.) p •

Tabla B.31: Tipo de campo de campo y clase de operador soportada porprojectsLeadByUser.

(i) El primer parámetro, opcional, es el usuario del cual se quierenbuscar los proyectos liderados. Si no se especifica ningún valor,la función devolverá los proyectos liderados por el usuario queestá efectuando la consulta.

Si el usuario que efectúa la consulta no está autenticado en JIRA,el parámetro debe ser especificado. En este caso, por lo tanto, asícomo en el caso en que se pretenda grabar la consulta en un filtroque pueda ser utilizado por un usuario no autenticado, no hay queutilizar esta función sin especificar el parámetro.

Ejemplo B.41. Para filtrar aquellas incidencias que estén abiertas enun proyecto liderado por uno mismo, será necesario efectuar utilizarla siguiente proposición:

project in projectsLeadByUser() AND status = Open

Ejemplo B.42. Para filtrar aquellas incidencias que estén abiertasen un proyecto liderado por el usuario enrico, será necesario efectuarutilizar la siguiente proposición:

project in projectsLeadByUser(enrico) AND status = Open

B.2.11 Función projectsWhereUserHasPermission

La función projectsWhereUserHasPermission soporta el tipo decampo y los operadores detallados en Tabla B.32. Esta funcióndevuelve el conjunto de proyectos en los cuales el el usuario posee elpermiso especificado por parámetro. Los parámetros aceptados porla función son los siguientes:

368

B.2. Funciones

tipo = ≈ ≥ ≡ ∈projectsWhereUserHasPermission(.) p •

Tabla B.32: Tipo de campo de campo y clase de operador soportada porprojectsWhereUserHasPermission.

(i) El primer parámetro es el permiso que tiene que tener el usua-rio en los proyectos especificados. Puede utilizarse cualquierpermiso de proyecto, cuya lista puede encontrarse en §??.

En el caso en que el usuario que efectúa la consulta no está au-tenticado en JIRA, así como en el caso en que se pretenda grabarla consulta en un filtro que pueda ser utilizado por un usuario noautenticado, esta función no puede utilizarse.

Ejemplo B.43. Para filtrar aquellas incidencias que estén abiertas encualquier proyecto donde se tenga permiso para resolver incidencias,será necesario efectuar utilizar la siguiente proposición:

project in projectsWhereUserHasPermission("Resolve Issues")AND status = Open

B.2.12 Función projectsWhereUserHasRole

La función projectsWhereUserHasRole soporta el tipo de campo ylos operadores detallados en Tabla B.33. Esta función devuelve el

tipo = ≈ ≥ ≡ ∈projectsWhereUserHasRole(.) p •

Tabla B.33: Tipo de campo de campo y clase de operador soportada porprojectsWhereUserHasRole.

conjunto de proyectos en los cuales el el usuario posee el rol especi-ficado por parámetro. Los parámetros aceptados por la función sonlos siguientes:

(i) El primer parámetro es el rol que tiene que tener el usuario enlos proyectos especificados.

369


En el caso en que el usuario que efectúa la consulta no está au-tenticado en JIRA, así como en el caso en que se pretenda grabarla consulta en un filtro que pueda ser utilizado por un usuario noautenticado, esta función no puede utilizarse.

Ejemplo B.44. Para filtrar aquellas incidencias que estén abiertas encualquier proyecto donde se tenga rol de desarrollador, será necesarioefectuar utilizar la siguiente proposición:

project in projectsWhereUserHasRole("Developers")AND status = Open

B.2.13 Función releasedVersions

La función releasedVersions soporta el tipo de campo y los opera-dores detallados en Tabla B.34. Esta función devuelve el conjunto

tipo = ≈ ≥ ≡ ∈releasedVersions(.) v •

Tabla B.34: Tipo de campo de campo y clase de operador soportada porreleasedVersions.

de versiones entregadas en el proyecto especificado por parámetro.Los parámetros aceptados por la función son los siguientes:

(i) El primer parámetro, opcional, es el proyecto del que se se deseaobtener las versiones entregas. Si se omite este parámetro, lafunción devolverá las versiones entregadas de cualquier proyec-to.

Ejemplo B.45. Para filtrar aquellas incidencias cuyo atributo re-suelta en versión sea una versión entregada de cualquier proyecto,será necesario efectuar utilizar la siguiente proposición:

fixVersion in releasedVersions()

Ejemplo B.46. Para filtrar aquellas incidencias cuyo atributo re-suelta en versión sea una versión entregada del proyecto JRAGD,será necesario efectuar utilizar la siguiente proposición:

370

B.2. Funciones

fixVersion in releasedVersions(JRAGD)

B.2.14 Función standardIssueTypes

La función standardIssueTypes soporta el tipo de campo y los ope-radores detallados en Tabla B.35. Esta función devuelve el conjunto

tipo = ≈ ≥ ≡ ∈standardIssueTypes() y •

Tabla B.35: Tipo de campo de campo y clase de operador soportada porstandardIssueTypes.

de tipos de incidencias de primer nivel, eso es, tipos de incidenciasque no corresponden a sub-tareas.

Ejemplo B.47. Para filtrar aquellas incidencias que no sean sub-tareas, será necesario efectuar utilizar la siguiente proposición:

issuetype in standardIssueTypes()

B.2.15 Función subtaskIssueTypes

La función subtaskIssueTypes soporta el tipo de campo y los ope-radores detallados en Tabla B.36. Esta función devuelve el conjunto

tipo = ≈ ≥ ≡ ∈standardIssueTypes() y •

Tabla B.36: Tipo de campo de campo y clase de operador soportada porsubtaskIssueTypes.

de tipos de incidencias de segundo nivel, eso es, tipos de incidenciasque corresponden a sub-tareas.

Ejemplo B.48. Para filtrar aquellas incidencias que sean sub-tareas,será necesario efectuar utilizar la siguiente proposición:

371


issuetype in subtaskIssueTypes()

B.2.16 Función unreleasedVersions

La función unreleasedVersions soporta el tipo de campo y los ope-radores detallados en Tabla B.37. Esta función devuelve el conjunto

tipo = ≈ ≥ ≡ ∈unreleasedVersions(.) v •

Tabla B.37: Tipo de campo de campo y clase de operador soportada porunreleasedVersions.

de versiones por entregar en el proyecto especificado por parámetro.Los parámetros aceptados por la función son los siguientes:

(i) El primer parámetro, opcional, es el proyecto del que se se deseaobtener las versiones por entregar. Si se omite este parámetro,la función devolverá las versiones por entregar de cualquier pro-yecto.

Ejemplo B.49. Para filtrar aquellas incidencias cuyo atributo re-suelta en versión sea una versión no entregada de cualquier proyecto,será necesario efectuar utilizar la siguiente proposición:

fixVersion in unreleasedVersions()

Ejemplo B.50. Para filtrar aquellas incidencias cuyo atributo re-suelta en versión sea una versión no entregada del proyecto JRAGD,será necesario efectuar utilizar la siguiente proposición:

fixVersion in unreleasedVersions(JRAGD)

372

B.2. Funciones

tipo = ≈ ≥ ≡ ∈votedIssues() i •

Tabla B.38: Tipo de campo de campo y clase de operador soportada porvotedIssues.

B.2.17 Función votedIssues

La función votedIssues soporta el tipo de campo y los operadoresdetallados en Tabla B.38. Esta función devuelve las incidencias quehan sido votadas por el usuario que efectúa la consulta.

En el caso en que el usuario que efectúa la consulta no está au-tenticado en JIRA, así como en el caso en que se pretenda grabarla consulta en un filtro que pueda ser utilizado por un usuario noautenticado, esta función no puede ser utilizada.

Ejemplo B.51. Para filtrar aquellas incidencias que hayan sido vo-tadas por el usuario que efectúa la consulta, será necesario efectuarutilizar la siguiente proposición:

issue in votedIssues()

B.2.18 Función watchedIssues

La función watchedIssues soporta el tipo de campo y los operadoresdetallados en Tabla B.39. Esta función devuelve las incidencias que

tipo = ≈ ≥ ≡ ∈watchedIssues() i •

Tabla B.39: Tipo de campo de campo y clase de operador soportada porwatchedIssues.

están siendo observadas por el usuario que efectúa la consulta.En el caso en que el usuario que efectúa la consulta no está au-

tenticado en JIRA, así como en el caso en que se pretenda grabarla consulta en un filtro que pueda ser utilizado por un usuario noautenticado, esta función no puede ser utilizada.

373


Ejemplo B.52. Para filtrar aquellas incidencias que están siendo ob-servadas por el usuario que efectúa la consulta, será necesario efectuarutilizar la siguiente proposición:

issue in watchedIssues()

B.3 Palabras reservadas

El lenguaje JQL tiene también palabras reservadas que, para poderseutilizar en una consulta, deberán ser “protegidas” con comillas. EnTabla B.40 se detallará la lista completa de palabras reservadas deeste lenguaje.

374

B.3. Palabras reservadas

abort decimal goto modify rowsaccess declare grant modulo selectadd decrement greater more sessionafter default group multiply setalias defaults having next shareall define identified noaudit sizealter delete if not sqrtand delimiter immediate notin startany desc in nowait strictas difference increment null stringasc distinct index number subtractaudit divide initial object sumavg do inner of synonymbefore double inout on tablebegin drop input option thenbetween else insert or toboolean empty int order transbreak encoding integer outer transactionby end intersect output triggerbyte equals intersection power truecatch escape into previous uidcf exclusive is prior unionchar exec isempty privileges uniquecharacter execute isnull public updatecheck exists join raise usercheckpoint explain last raw validatecollate false left remainder valuescollation fetch less rename viewcolumn file like resource whencommit field limit return wheneverconnect first lock returns wherecontinue float long revoke whilecount for max right withcreate from min rowcurrent function minus rowiddate go mode rownum

Tabla B.40: Palabras JQL reservadas.

375

CChangelog

C.1 1.01

(i) Se añadió el capítulo Changelog (§C).(ii) Se actualizó la lista de campos por defecto de una incidencia a

los campos presentes en JIRA 5.(iii) Se actualizaron algunos pantallazos para reflejar algunas mejo-

ras introducidas en JIRA 5.(iv) Se actualizó la sección §3.3 para contemplar la nueva barra de

herramientas de administración introducida en JIRA 5.(v) Se actualizó la sección §4 para reflejar las mejoras introducidas

en JIRA 5.(vi) Se actualizó la sección §5.11 para detallar el procedimiento de

creación de enlaces entre incidencias en diferentes instancias deJIRA.

(vii) Se añadió la sección §5.19.2 para detallar el procedimiento decreación de enlaces entre incidencias y páginas de Confluence.

(viii) Se añadió la sección §5.19.3 para detallar el procedimiento decreación de enlaces entre incidencias y recursos identificados porURL.

(ix) Se añadió la sección §5.19.4 para describir la integración entreJIRA y Crucible.

(x) Se añadió la sección §5.19.5 para describir la integración entreJIRA y FishEye.

(xi) Se añadió la sección §5.19.6 para describir la integración entreJIRA y Bamboo.

377

Índice alfabético

JIRA Administratorspermiso, 308

JIRA System Administratorspermiso, 308

created:, véase Búsquedadue:, véase Búsquedafield, 245jira.clone.linktype.name, 101jira.clone.prefix, 102my, véase Búsquedaos_authType, 243os_username, 243overdue, 179tempMax, 242, 245today, véase Búsquedatomorrow, véase Búsquedaupdated:, véase Búsquedayesterday, véase Búsqueda

Activity streamgadget, véase Gadget

Add commentspermiso, 88

Administer projectpermiso, 13

Administrationgadget, véase Gadget

Alfresco, 184Apache Lucene, 184

Apple Mail, 243Apple Safari, 243Assign issue

permiso, 139Assigned to me

gadget, véase GadgetAtajos de teclado, 45

formularios, 47globales, 47tecla modificadora, 45ventanas de incidencias, 47

Atlassian SDK, 5Attach screenshot, véase Cap-

turas de pantallasAverage age

gadget, véase Gadget

Búsqueda, 147avanzada, 148, 158, 162,

185de texto, 171aproximada, 174carácter de escape, 173caracteres especiales, 173estructura, 172fuzzy, 174operador, 172operadores, 175palabras especiales, 173

379

Índice alfabético

por importancia, 175por proximidad, 174término, 172

exportación, 231exportar a Microsoft Ex-

cel, 246exportar a Microsoft Word,

245exportar a XML, 244feed RSS, 242ordenar, 163permalink, 162por atributos de inciden-

cia, 153por campos personalizados,

157por componentes, 151por fechas, 154por porcentaje de trabajo

realizado, 157por versiones, 151rápida, 162, 177c:, 181created:, 179due:, 179overdue, 179r:me, 179r:none, 179r:, 179today, 180tomorrow, 180updated:, 179v:, 181yesterday, 180en un proyecto, 179integrar en navegador, 178navegar a incidencia, 178por componente, 181por estado, 180por fecha, 179por prioridad, 180

por reporter, 179por resolución, 180por tipo, 180por versión, 181por versión de resolución,181

vencidas, 179simple, 147, 148

modificar, 158Bamboo

builds, 63, 68Bamboo charts

gadget, véase GadgetBamboo plan summary chart

gadget, véase GadgetBamboo plans

gadget, véase GadgetBeneficiencia, 9Browse project

permiso, 88Browse projects

permiso, 113Bugzilla ID search

gadget, véase GadgetBulk change

permiso, 131Bulk operation, véase Opera-

ción masiva

Caché del navegador, 284Calendar

gadget, véase GadgetCampos de texto

formatear, 90Capturas de pantallas

adjuntar, 83Change log, véase ProyectoClover coverage

gadget, véase GadgetComentarios, 87

creación, 87

380

Índice alfabético

eliminación, 89modificación, 89visibilidad, 88

Comment issuepermiso, 139

Componentes, véase ProyectoConfiguración de campos, 6, 90Contraseña, véase UsuarioControl de horario, véase Re-

gistro de trabajoCreate issue

permiso, 94Create issues

permiso, 128Create shared object

permiso, 211, 217Created vs. resolved

gadget, véase GadgetCrucible charts

gadget, véase GadgetCuadro de mando, 106Cuadro de mandos, 285

añadir gadget, 301buscar, 295copiar, 293creación, 290distribución, 299eliminar, 294eliminar un gadget, 305gestión, 288modificar, 293mover un gadget, 304operaciones, 299operaciones sobre un gad-

get, 303

Dashboard, véase Cuadro de man-dos

Delete all commentspermiso, 89

Delete all work logs

permiso, 125Delete own comments

permiso, 89Delete own work log

permiso, 125Drupal, 184Due date, véase Fecha de reso-

lución

Edit all commentspermiso, 89

Edit all work logspermiso, 125

Edit issuepermiso, 139, 140

Edit issuespermiso, 115

Edit own commentspermiso, 89

Edit own work logpermiso, 125

Enlace, véase IncidenciaEsquema de nivel de seguridad

de incidencias, 114Esquema de notificación, 144Esquema de pantallas

por tipo de incidencia, 120Esquemas, 7, 28Etiqueta

crear, 114eliminar, 116

Favourite filtergadget, véase Gadget

Fecha de resolución, 106Feed RSS

búsqueda, véase Búsque-da

Ficheros adjuntos, 82, 101JARnavegar, 84

381

Índice alfabético

remover, 85ZIPdescargar, 84navegar, 84

Filtro, 147, 148, 162, 207, 242buscar, 220compartir, 217copiar, 222creación, 209exportación, 231favoritoañadir, 215eliminar, 215

gestión, 213orden de columnas, 225eliminar, 228modificar, 227

sumario, 212suscripción, 231periodicidad, 233

Fisheyechangesets, 69

FishEye chartsgadget, véase Gadget

FishEye recent changesetsgadget, véase Gadget

Flujo de trabajo, 24, 80transición, 80

GadgetActivity stream, 305, 307feed RSS, 307

Administration, 305, 308Assigned to me, 305, 310Average age, 305Average age chart, 311Bamboo charts, 305Bamboo plan summary chart,

305Bamboo plans, 305Bugzilla ID search, 305

Calendar, 305Clover coverage, 305Created vs. resolved, 305Crucible charts, 305Favourite filter, 305FishEye charts, 305FishEye recent changesets,

305In progress, 305Issue statistics, 305JIRA: news, 305Pie chart, 305Projects, 305Quick links, 305Recently created issues, 305Resolution time, 305Road map, 305Text, 305Time since issues, 305Two dimensional filter sta-

tistics, 305Voted, 305Watched, 305

Generic eventevento, 33

Google Chrome, 182GreenHopper, véase JIRA

HTTP, 242, 243HTTPS, 244

In progressgadget, véase Gadget

Incidencia, 16cambiar tipo de, 127campos, 16compartir por mail, 81convertir en sub-tarea, 97creación, 73duplicar, 100

crear enlace a, 101

382

Índice alfabético

enlace, 100, 102gestionar, 105

etiqueta, véase Etiquetamover a otro proyecto, 127navegar a, 178planificar, 106prioridad, 21registro histórico de cam-

bios, 141resolución, 23tipo, véase Tipo de inci-

denciaventana de detalle, 78vigilar, 143votar, 143

Incidenciaswatch, 78

Issue assignedevento, 33

Issue closedevento, 33

Issue comment editedevento, 33

Issue commentedevento, 33

Issue createdevento, 33

Issue deletedevento, 33

Issue movedevento, 33

Issue reopenedevento, 33

Issue resolvedevento, 33

Issue statisticsgadget, véase Gadget

Issue updatedevento, 33

Issue worklog deletedevento, 33

Issue worklog updatedevento, 33

JIRAGreenHopper, 42modo, 40público, 40privado, 40

JIRA Query Language, véaseJQL

JIRA: newsgadget, véase Gadget

JQL, 185campos, 187affectedVersion, 335assignee, 336category, 337comment, 337component, 339created, 339description, 337due, 339environment, 337filter, 341fixVersion, 335issueKey, 342level, 342originalEstimate, 343priority, 344project, 344remainingEstimate, 343reporter, 336resolution, 345resolved, 339status, 346summary, 337text, 337timeSpent, 343type, 347updated, 339voter, 336

383

Índice alfabético

votes, 348watcher, 336workRatio, 348tipo categoría, 337tipo componente, 339tipo duración, 343tipo estado, 346tipo fecha, 339tipo filtro, 341tipo incidencia, 342tipo número, 348tipo nivel de seguridad,342

tipo prioridad, 344tipo proyecto, 344tipo resolución, 345tipo texto, 337tipo tipo de incidencia,347

tipo usuario, 336tipo versión, 335

caracteres reservados, 187funciones, 348cascadeOption, 350componentsLeadByUser,

352currentLogin, 353currentUser, 353issueHistory, 354lastLogin, 355linkedIssues, 356membersOf, 356now, 357projectsLeadByUser, 357projectsWhereUserHasRole,

359projectsWhereUserHas-Permission, 358

releasedVersions, 360standardIssueTypes, 361subtaskIssueTypes, 361

unreleasedVersions, 362votedIssues, 363watchedIssues, 363

operadores, 191contains, 196does not contain, 197equals, 192greater than equals,194

greater than, 193in, 195is not, 198is, 198less than equals, 195less than, 194not equals, 192not in, 196

palabras claves, 188and, 189empty, 190not, 190null, 191order by, 191or, 189

palabras reservados, 187,364

queryestructura, 186

Keyboard shortcuts, véase Ata-jos de teclado

Lenguaje de búsqueda, 107, 158Licencia comercial, 8Licencia de evaluación, 8Licencia gratuita, 8, 9Licencias, 8Link issues

permiso, 102Log work

campo, 120

384

Índice alfabético

Lucene, véase Apache Lucene

Manage watcher listpermiso, 145

MediaWiki, 184Microsoft Excel, 166, 246Microsoft Internet Explorer, 182Microsoft Word, 166, 245Modify reporter

permiso, 140Move issues

permiso, 128, 131Mozilla, 178, 182Mozilla Firefox, 182Mozilla Thunderbird, 243

Navegador de incidencias, 43,147

configurar columnas, 167descripción, 162

Navegador de proyecto, 51activity stream, 58builds, 68builds de la versión, 63change log, 60components, 65estructura, 51Fisheye changeset, 69issues, 58labels, 67popular issues, 61road map, 58source, 69summary, 56versions, 61

Nivel de seguridad, 110Nomenclatura, xxx

OpenSearch, 182clientes, 182

OpenSocial, 5, 286

Operación masiva, 130, 132eliminación, 133migración, 133modificación, 139

Organizaciones, 9no académicas, 9no comerciales, 9no gubernamentales, 9no políticas, 9seculares, 9sin ánimo de lucro, 9

os_password, 243

Perfil de usuario, véase Usua-rio

Perfil del usuario, 45Permalink, 90, 162

registro de trabajo, véaseRegistro de trabajo

Pie chartgadget, véase Gadget

PluginsJIRA Charting, 257

Prioridad, véase IncidenciaProjects

gadget, véase GadgetProyecto, 12

change log, 16componentes, 12, 115explorar, véase Navegador

de proyectoroad map, 16versiones, 14, 115

Proyectos open source, 9

Query Language, véase Lengua-je de búsqueda

Quick linksgadget, véase Gadget

Recently created issues

385

Índice alfabético

gadget, véase GadgetRegistro de trabajo, 117

crear, 120crear en transición de flu-

jo de trabajo, 123eliminar, 125estimación, 119modificar, 125permalink, 124

Renderers, 90Wiki-style, 90code macro, 92macros, 91sintaxis de macros, 91

Reporteaverage age, 277caché del navegador, 284created vs. resolved issues,

267pie chart, 273recently created issues, 278resolution time, 271single level group by, 266time since issues, 280time tracking, 263user workload, 260version workload, 261workload pie chart, 257

Reportes, 255incluidos con JIRA, 255plugin, 255

Resolución, véase IncidenciaResolution time

gadget, véase GadgetRoad map, véase Proyecto

gadget, véase GadgetRoles de proyecto, 7RSS, véase Feed RSS

Schedule issuepermiso, 139

Schedule issuespermiso, 106

Set issue securitypermiso, 37, 113

SQL, 185SELECT, 185

Sub-tareas, 93, 101convertir en incidencia, 99crear, 94duplicar, 102gestión, 95

Textgadget, véase Gadget

Time since issuesgadget, véase Gadget

Time tracking, véase Controlde horario

Tipo de incidencia, 18Two dimensional filter statis-

ticsgadget, véase Gadget

Usuarioavatar, 317

modificar, 317contraseña, 317

modificar, 318email, 317nombre completo, 317perfil, 315

Version-pickertipo de campo, 136

Versiones, véase ProyectoView voters and watchers

permiso, 145, 337Voted

gadget, véase Gadget

Watch, véase Incidencias

386

Índice alfabético

Watchedgadget, véase Gadget

Wiki markup, 88Wiki-style renderer, véase Ren-

derersWordPress, 184Work logged on issue

evento, 33Work started on issue

evento, 33Work stopped on issue

evento, 33Workflow, véase Flujo de tra-

bajo

387

Bibliografía

[1] The Grey Blog, http://thegreyblog.blogspot.com/

[2] Creative Commons, Attribution-NonCommercial-NoDerivs 3.0Unported.http://creativecommons.org/licenses/by-nc-nd/3.0/

[3] Creative Commons, Attribution-NonCommercial-NoDerivs 3.0Unported.http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode

[4] Creative Commons, Public domain.http://wiki.creativecommons.org/Public_domain

[5] Creative Commons, Frequently Asked Questions — Do CreativeCommons licenses affect fair use, fair dealing or other exceptionsto copyright?.http://wiki.creativecommons.org/Frequently_Asked_-Questions#Do_Creative_Commons_licenses_affect_fair_use.2C_-fair_dealing_or_other_exceptions_to_copyright.3F

[6] Creative Commons, Frequently Asked Questions — I don’t likethe way a person has used my work in a derivative work orincluded it in a collective work; what can I do?.http://wiki.creativecommons.org/Frequently_Asked_-Questions#I_don.E2.80.99t_like_the_way_a_person_has_-used_my_work_in_a_derivative_work_or_included_it_in_a_-collective_work.3B_what_can_I_do.3F

[7] Creative Commons, Frequently Asked Questions — When arepublicity rights relevant?.http://wiki.creativecommons.org/Frequently_Asked_-Questions#When_are_publicity_rights_relevant.3F

389

Bibliografía

[8] Atlassian, Atlassian JIRA Pricing.http://www.atlassian.com/software/jira/pricing.jsp

[9] Atlassian, Atlassian Experts.http://www.atlassian.com/resources/experts

[10] Atlassian, Atlassian JIRA Documentation.http://confluence.atlassian.com/display/JIRA/JIRA+Documen-tation

[11] Atlassian, Atlassian JIRA User’s Guide.http://confluence.atlassian.com/display/JIRA/JIRA+User-%27s+Guide

[12] Atlassian, Atlassian Partner Directory.http://confluence.atlassian.com/display/APW/Navigation

[13] Atlassian, End of support announcements for JIRA.http://confluence.atlassian.com/display/JIRA/End+of+Su-pport+Announcements+for+JIRA

[14] Sunfreeware, Freeware and Open Source Software (FOSS) forSun Microsystems’ Solaris.http://www.sunfreeware.com/

[15] Blastwave, Blastwave.org — An OpenSolaris Community Site.http://www.blastwave.org/

[16] OpenCSW, OpenCSW.http://www.opencsw.org/

[17] Atlassian JIRA, JIRA does not install well on Vista/Win7 withUAC and the installer.http://jira.atlassian.com/browse/JRA-19683

[18] VeriSign, Official VeriSign Home Page.http://www.verisign.com/

[19] Thawte, Official Thawte Home Page.http://www.thawte.com/

[20] Apache HTTP Server, SSL/TLS Strong Encryption: FAQ.http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts

[21] Apache-SSL, Apache-SSL.http://www.apache-ssl.org/

390

Bibliografía

[22] Apache, Apache ISAPI Redir DLL.http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/

[23] Atlassian JIRA Installation Guide, Integrating JIRA with IIS.http://confluence.atlassian.com/display/JIRA/Integrating+-JIRA+with+IIS

[24] The Grey Blog, Setting Up Solaris 10 Projects to ControlResource Usage.http://thegreyblog.blogspot.com/2009/01/setting-up-sola-ris-10-projects-to.html

[25] The Grey Blog, Credentials and Projects for a Solaris 10SMF-Managed Service.http://thegreyblog.blogspot.com/2010/06/credentials-and--projects-for-solaris-10.html

[26] OpenSearch.org, OpenSearch.org Home Page.http://www.opensearch.org/

[27] OpenSearch.org, OpenSearch search clients.http://www.opensearch.org/Community/OpenSearch_enabled_-search_clients

[28] Atlassian Plugin Exchange, Atlassian Plugin Exchange.https://plugins.atlassian.com/

[29] Atlassian Documentation, JIRA Extensions.http://confluence.atlassian.com/display/JIRAEXT/JIRA+Extensions

[30] Atlassian Documentation, Atlassian Developer Network.http://confluence.atlassian.com/display/DEVNET

[31] JIRA Charting Plugin, JIRA Charting Plugin.https://studio.plugins.atlassian.com/wiki/display/JCHART/-JIRA+Charting+Plugin

[32] Scrum, Wikipedia, the free encyclopedia,http://es.wikipedia.org/wiki/Scrum

391

jira user guide 1.01

Documents

obra misma

lostrminos de licencia

licencia gratuita

i derechos de uso justo

usuariocasos de uso

administradorcasos de

ejemplosvolumen ii

derechos morales