aprobaciones - indra...reflejar cuándo el equipo de indra está realizando el diseño y cuando...

Guía de Uso

JIRA-CLIENTE ESTÁNDAR

con

APROBACIONES

(Caso práctico)

Versión 3.0 Madrid, Julio de 2018

Guía de uso de JIRA Cliente Estándar con Aprobaciones - Caso práctico 4

1 OBJETIVO DEL DOCUMENTO 4

2 SOLUCIO� N ESTÁ� NDÁR CON ÁPROBÁCIONES 4

Perfiles de usuario 4 2.1

Tipos de petición 5 2.2

1.2.1 Flujo de trabajo de las issues de tipo Soporte Funcional 5 1.2.2 Flujo de trabajo de las issues de tipo Soporte Funcional Planificado 6 1.2.3 Flujo de trabajo de las issues de tipo Correctivo 7 1.2.4 Flujo de trabajo de las issues de tipo Correctivo Planificado 8 1.2.5 Flujo de trabajo de las issues de tipo Pequeño Evolutivo 9 1.2.6 Flujo de trabajo de las issues de tipo Gran Evolutivo 10 1.2.7 Flujo de trabajo de las issues de tipo Epic 10

Tipos de sub-tasks 11 2.3

1.2.8 Flujo de trabajo de las sub-tasks de tipo Client Defect 11 1.2.9 Flujo de trabajo de las sub-tasks de tipo Issue Change Request Subtask 12

3 CÁSO PRÁ� CTICO (CORRECTIVO PLÁNIFICÁDO) 13

Creación de una petición por parte del cliente 13 3.1

3.1.1 Pestaña de campo 15 3.1.2 Pestaña gente 16 3.1.3 Pestaña fechas 17 3.1.4 Pestaña claves 17 3.1.5 Pestaña estimación 18 3.1.6 Pestaña compromiso de Servicio 19

Parámetros y ventanas de la petición de JIRA-Cliente con Aprobaciones 21 3.2

3.2.1 Cabecera de la petición 21 3.2.2 Menú de una petición 22 3.2.3 Sección Detalles 27 3.2.4 Sección Descripción 28 3.2.5 Sección Actividad 28 3.2.6 Sección Personas 29 3.2.7 Sección Fechas 30 3.2.8 Agile 31

Evolución por parte del equipo de soporte y seguimiento por parte del cliente 33 3.3

3.3.1 Aprobado y puesta en producción 43 3.3.2 Reapertura de una tarea por parte del cliente 44 3.3.3 Aceptación y cierre de una tarea por parte del cliente 45 3.3.4 Cancelación de tareas 48 3.3.5 Borrado de tareas 50


4 CÁSO PRÁ� CTICO (GRÁN EVOLUTIVO) 52

Creación de una petición tipo Gran Evolutivo 52 4.1

Parámetros y ventanas de una petición de tipo Gran Evolutivo 52 4.2

Evolución por parte del equipo de soporte y seguimiento por parte del cliente 53 4.3

ÁNEXO I. VENTÁNÁ EDITÁR INCIDENCIÁ 55


1 Objetivo del documento

El objetivo de este documento consistirá en describir varios casos prácticos aplicados a la solución de JIRA Cliente Estándar con Aprobaciones (en adelante JIRA-Cliente con Aprobaciones) y de esta forma estudiar sus ciclos de trabajo desde la creación de la petición, la evolución desde el equipo de soporte y el seguimiento por parte del cliente.

Además de analizar los tipos de perfiles definidos para interactuar con la herramienta así como qué parámetros y ventanas de configuración se incluyen según el tipo de petición.

2 Solución Estándar con Aprobaciones

Para las operaciones que así lo soliciten, la versión de JIRA-Cliente con Aprobaciones dispone de características necesarias para realizar por parte del cliente las aprobaciones adicionales de las diferentes fases de cada petición.

El acceso y nivel de permisos sobre la herramienta están definidos mediante los siguientes perfiles.

Perfiles de usuario 2.1

Usuario del servicio: es el encargado de dar de alta las solicitudes (Soporte Funcional, Correctivo, Pequeño Evolutivo o Gran Evolutivo). Realizará el seguimiento de la evolución de las tareas y podrá aceptar o rechazar las acciones y trabajos realizados por el equipo de soporte de Indra.

Responsable del servicio: es un perfil destinado a realizar tareas de supervisión y seguimiento. También puede crear nuevas solicitudes.

Readonly: Es un perfil, de solo lectura, destinado a usuarios del cliente que permite consultar la evolución de las Incidencias del proyecto pero no permite realizar ninguna actividad operativa sobre el mismo, es decir, no permitirá crear Incidencias, ni realizar modificaciones, ni realizar transiciones de ningún tipo.

Administrador: Perfil destinado a realizar labores de administración.


Tipos de petición 2.2

Los tipos de issue definidos en JIRA-Cliente con Aprobaciones son los mismos que los de JIRA Cliente Estándar (Soporte Funcional, Correctivo, Pequeño Evolutivo y Gran Evolutivo), aunque tienen diferencias en lo relativo a sus flujos de trabajo y propiedades. En los siguientes apartados se describen esas diferencias.

1.2.1 Flujo de trabajo de las issues de tipo Soporte Funcional

El flujo de trabajo de las issues de tipo Soporte Funcional con Aprobaciones es igual al de las issues de tipo Soporte Funcional de JIRA Cliente Estándar. La aprobación por parte del cliente se representa mediante el estado Aprobado después del estado Entregado, esto permite al cliente indicar explícitamente si aprueba los trabajos asociados al soporte funcional. No obstante, como se ve en el flujo de trabajo, sigue existiendo también la posibilidad de pasar directamente al estado Cerrada desde el estado Entregado. Algunas de las transiciones dentro de este flujo de trabajo son responsabilidad del cliente y se realizan desde JIRA Cliente Estándar. Sin embargo, otras transiciones son responsabilidad del equipo de soporte de Indra y se desencadenan a partir de transiciones realizadas en JIRA-MInd-ALM. En la leyenda insertada en la imagen se indica el código de colores empleado para reflejar a quién corresponde la responsabilidad de cada transición.

Imagen nº 1 Soporte Funcional


1.2.2 Flujo de trabajo de las issues de tipo Soporte Funcional Planificado

El flujo de trabajo de las issues de tipo Soporte Funcional Planificado con Aprobaciones tiene dos estados que permiten por parte del cliente la aprobación o rechazo de la estimación (desde el estado Pendiente Aprobación) y posteriormente la aprobación o rechazo de la planificación (desde el estado Pendiente Aprobación Plan) de los trabajos asociados al soporte funcional. Desde el estado Entregado, existe la posibilidad de pasar directamente al estado Cerrada. La leyenda indica, mediante el código de colores empleado en la imagen, a quién corresponde la responsabilidad de cada transición.

Imagen nº 2 – Soporte Funcional Planificado.


1.2.3 Flujo de trabajo de las issues de tipo Correctivo

El flujo de trabajo de las issues de tipo Correctivo con Aprobaciones frente al de las issues de tipo Correctivo de JIRA Cliente Estándar se diferencia en que después del estado Entregado tiene dos estados adicionales: Aprobado y Puesta en Producción, que permiten al cliente indicar explícitamente si aprueba los cambios asociados al correctivo y reflejar su puesta en producción. No obstante, sigue existiendo también la posibilidad de pasar directamente al estado Cerrada desde el estado Entregado.

Imagen nº 3 – Correctivo.


1.2.4 Flujo de trabajo de las issues de tipo Correctivo Planificado

El flujo de trabajo de las issues tipo Correctivo Planificado dispone de mayor detalle en el proceso de estimación y planificación. En esta versión con aprobaciones de JIRA Cliente Estándar, se puede indicar explícitamente por parte del cliente la aprobación o rechazo de la estimación (desde el estado Pendiente Aprobación ) y posteriormente la aprobación o rechazo de la planificación (desde el estado Pendiente Aprobación Plan ). Una vez aprobada

la entrega, desde el estado Aprobado, la transición Poner en Producción podrá ser realizada tanto desde JIRA Cliente como desde JIRA interno (Mind). Del mismo modo que en las issues de tipo Correctivo, sigue existiendo la posibilidad de pasar directamente al estado Cerrada desde el estado Entregado.

Imagen nº 4 – Correctivo Planificado.


1.2.5 Flujo de trabajo de las issues de tipo Pequeño Evolutivo

Los Pequeños Evolutivos tienen, al final del flujo de trabajo, los estados para la aprobación (Aprobado y Puesta en Producción ) al igual que ocurre en

los Correctivos. Desde el estado Puesta en Producción , el cliente podrá Rechazar la petición durante el periodo de garantía (nº días después de puesta en producción) al estado Entregado . Y no va a poder recibir desde el JIRA Interno Mind , ninguna solicitud de nuevo cambio de alcance puesto que, cualquier propuesta desde este estado, deberá de ser contemplado como una nueva petición. Además, los Pequeños Evolutivos también disponen de mayor detalle en el proceso de estimación y planificación. En esta versión con aprobaciones de JIRA Cliente Estándar , se puede indicar explícitamente por parte del cliente

la aprobación o rechazo de la estimación (desde el estado Pendiente Aprobación ) y posteriormente la aprobación o rechazo de la planificación (desde el estado Pendiente Aprobación Plan ).

Imagen nº 5 – Pequeño Evolutivo.


1.2.6 Flujo de trabajo de las issues de tipo Gran Evolutivo

El tipo de issue Gran Evolutivo tiene los mismos estados que el tipo Pequeño Evolutivo, pero además añade dos estados (Elaboración Diseño y Pendiente Aprobación Diseño ) para reflejar cuándo el equipo de Indra está realizando el diseño y cuando está a la espera de que el cliente lo apruebe o rechace. Al igual que en Pequeño Evolutivo, desde el estado Puesta en Producción el cliente podrá Rechazar la petición durante el periodo de garantía (nº días

después de puesta en producción) al estado Entregado . Y no va a poder recibir desde el JIRA Interno Mind , ninguna solicitud de nuevo cambio de alcance puesto que, cualquier propuesta desde este estado, deberá de ser contemplado como una nueva petición.

Imagen nº 6 – Gran Evolutivo.

1.2.7 Flujo de trabajo de las issues de tipo Epic

Para ampliar la información y modo de trabajo de este tipo de issues se recomienda ver la documentación de Servicio (GA) Básico.


Tipos de sub-tasks 2.3

1.2.8 Flujo de trabajo de las sub-tasks de tipo Client Defect

El tipo Client Defect, representan fallos de implementación detectados por el cliente antes de

la aceptación. Será el cliente quien abra una sub-tarea de tipo Client Defect y podrá rechazar

su resolución desde el estado Cerrada.

Imagen nº 7 – Subtarea Client Defect.


1.2.9 Flujo de trabajo de las sub-tasks de tipo Issue Change Request Subtask

En proyectos de Servicios y para issues de tipo: Pequeño Evolutivo y Gran Evolutivo ,

cuando sea necesario reflejar un Cambio de Alcance (CA) se podrá realizar mediante el alta de una subtask ICR (subtarea Issue Change Request) en JIRA-MInd-ALM, para que a su

vez, cree una subtarea en el Jira Cliente Estándar con Aprobaciones.

En el siguiente apartado se explica cómo generar una sub-task de este tipo (ICR).

Imagen nº 8 – Subtarea Issue Change Request Subtask.


3 Caso práctico (Correctivo Planificado)

En este apartado se explicará paso a paso:

El proceso de la creación de una petición desde el cliente y edición posterior. La evolución por parte del equipo de soporte.

Su seguimiento desde el cliente.

Los campos relativos a la creación de una issue son comunes a todas los tipos de petición, por el contrario, sus estados podrán ir variando a través del ciclo de vida de la petición según se trate de un tipo u otro.

Creación de una petición por parte del cliente 3.1

Pulsando el botón Crear situado en el menú superior de la herramienta de JIRA-Cliente con Aprobaciones se iniciará el proceso de alta de una petición. (Imagen nº 9).

Imagen nº 9 - Opción Crear del menú superior JIRA-Cliente con Aprobaciones.


La ventana Crear incidencia permite la configuración de los datos relativos a la petición. (Imagen nº10).

Imagen nº 10 - Ventana Crear incidencia.


Los campos (enumerados en la imagen nº10) a completar son los siguientes:

1. Proyecto: Permite seleccionar el Proyecto desde el desplegable Proyecto. Los datos marcados con el asterisco en rojo (*) son campos obligatorios.

Imagen nº 11 – Selección de Proyecto y tipo de incidencia.

2. Tipo de Incidencia: Permite seleccionar desde el desplegable Tipo de Incidencia, que tipo de Incidencia se desea dar de alta. Para este ejemplo se ha seleccionado una petición de tipo Correctivo. (*) Campo obligatorio.

Imagen nº12 – Selección de tipo de petición.

A continuación se deberán de completar los campos incluidos en las pestañas de la petición y que se detallan a continuación.

3.1.1 Pestaña de campo

Siguiendo con la referencia de la ‘Imagen nº 10 - Ventana Crear incidencia’ los campos incluidos son los siguientes:

3. Resumen: Resume la incidencia o problema.

4. Descripción: Describe en mayor detalle. Se podrá minimizar pulsando el icono:

5. Componente(s): Desplegable que permite seleccionar el componente sobre el que se está trabajando.

6. Prioridad: Permite seleccionar la prioridad según el siguiente criterio de mayor a menor prioridad: Bloqueante, Crítica, Menor o Trivial.

Imagen nº13 – Prioridad.

Se ha de tener en cuenta que: una vez creada la petición solamente se podrá cambiar su tipo mientras permanezca en el estado Nuevo, después, ya no será posible.


7. Criticidad: Al igual que el anterior, permite seleccionar la criticidad del problema según el siguiente criterio: Ninguno, Alta, Media o Baja.

Imagen nº14 - Criticidad.

8. Versiones afectadas: versión o versiones que se pueden ver afectadas por los trabajos de la issue.

9. Etiquetas: Permite seleccionar una etiqueta existente o crear una nueva que pueda ser identificada en búsquedas posteriores.

10. Adjunto: Pulsando el botón: Elegir archivos se podrá adjuntar información que complemente la descripción de la petición.

11. Fecha de creación Demanda: Será la fecha que indique, cuando se cursó la solicitud.

12. Indicador de Exclusión de ANS: Permite indicar si se excluyen los indicadores ANS seleccionando la opción del desplegable: SI/Yes.

13. Razón Exclusión ANS: Cuando se ha seleccionado exclusión de los indicadores (campo anterior), permite describir por qué se excluyen dichos indicadores.

Cuando es necesario generar más de una petición se podrá seleccionar la

casilla: ubicada junto al botón Crear y Cancelar.

3.1.2 Pestaña gente

Permite seleccionar al responsable asignado a la petición mediante el desplegable Responsable. Si no se realiza una selección la aplicación asignará de manera automática al responsable del proyecto (definido desde la administración del proyecto). Pulsando la opción rápida: Asignarme a mí la incidencia se auto-asignará.

Imagen nº 15 - Pestaña Gente.


3.1.3 Pestaña fechas

Permite seleccionar desde el cliente las siguientes fechas habilitadas:

Fecha de Compromiso de Entrega (Due Delivery Date).

Fecha de Compromiso Respuesta: Según el horario del cliente.

Imagen nº 16 - Pestaña Fechas.

Las fechas inhabilitadas:

Fecha Inicio Prevista: no se rellenará ya que la planificación la realizará el equipo de soporte de Indra.

Fecha Fin Prevista: no se rellenará ya que la planificación la realizará el equipo de soporte de Indra.

3.1.4 Pestaña claves

A diferencia de la solución JIRA Cliente Estándar esta versión añade los campos adicionales Nombre Informador, Teléfono Informador, Email Informador.

Imagen nº 17 - Pestaña Claves.


Los campos son los siguientes:

Clave del cliente: Clave del proyecto cliente.

Nombre del informador: contacto de la persona del cliente que ha realizado la petición.

Teléfono del informador: Contacto de la persona del cliente que ha realizado la petición.

Email informador: Contacto de la persona del cliente que ha realizado la petición.

3.1.5 Pestaña estimación

Permite rellenar los datos de estimación:

Horas Estimadas: Permite incluir los datos de estimación de la tarea.

Horas Facturadas: Permite incluir los datos de facturación de la tarea

Imagen nº 18 - Pestaña Estimación.


3.1.6 Pestaña compromiso de Servicio

Esta pestaña no existía en la solución estándar y se añade para la versión de JIRA Cliente con Aprobaciones ya que registra los compromisos en tiempo adquiridos desde el soporte y las fechas de aprobación por el cliente.

Imagen nº 19 - Pestaña Compromiso de Servicio.

El significado de estos campos es el siguiente:

Compromiso de Entrega Estimación: fecha límite en la que el equipo de Indra se compromete a haber realizado la estimación de la issue (haber llegado al estado Pendiente Aprobación).

Aprobación Estimación: fecha en la que el cliente aprueba la estimación (transición desde el estado Pendiente Aprobación al estado Aprobado Estimación).

Compromiso Entrega Planificación: fecha límite en la que el equipo de Indra se compromete a haber realizado la planificación de la issue (haber llegado al estado Pendiente Aprobación Plan).

Aprobación Planificación: fecha en la que el cliente aprueba la planificación (transición desde el estado Pendiente Aprobación Plan al estado Planificación Aprobada).

Entrega: fecha en la que se han puesto a disposición del cliente el fruto de los trabajos realizados (transición desde el estado En curso al estado Entregado) para que los acepte (paso al estado Aprobado) o rechace (o paso al estado Reabierto).

Validación Usuario: fecha en la que el cliente acepta los trabajos realizados (transición desde el estado Entregado al estado Aprobado).


Continuando con el proceso de creación de la petición y tras completar los campos, al menos los campos marcados con asterisco rojo (*) de carácter obligatorio, se deberá de pulsar el botón Crear para generar la nueva petición.

Un mensaje emergente se mostrará indicando que la petición se ha creado correctamente. El mensaje es un hipervínculo que enlaza a la petición recién creada.

Imagen nº 20 – Mensaje confirmando que la petición ha sido creada.

Dentro de la opción Incidencias - Incidencias Recientes del menú superior de JIRA-Cliente con Aprobaciones se podrá observar que la incidencia recién creada aparece en primera posición.

Imagen nº 21 - Incidencias-Incidencias recientes.

Además mediante la Key de la incidencia, se podrá localizar desde la caja de búsqueda del menú superior de JIRA-Cliente con Aprobaciones con Aprobaciones. (Imagen nº19).

Imagen nº 22 - Opción Búsqueda del menú superior de JIRA-Cliente con Aprobaciones.

Si el usuario es Responsable o Informador de la petición se podrá localizar desde el gadget Mis asignaciones incluido en el Cuadro de Mando de JIRA-Cliente con Aprobaciones.


Parámetros y ventanas de la petición de JIRA-Cliente con 3.2

Aprobaciones

Toda la información de cada petición recién creada en JIRA-Cliente con Aprobaciones se recoge en una ventana como la que se muestra en la Imagen nº 23.

Imagen nº 23 – Ventana de un petición creada en JIRA-Cliente con Aprobaciones.

Tomando como referencia la imagen anterior (Imagen nº 23) se explica a continuación cada una de las secciones numeradas.

3.2.1 Cabecera de la petición

En la parte superior de la ventana (Nº1 - Imagen nº23 - Ventana petición JIRA-Cliente con Aprobaciones) se muestran los datos que sirven para identificar en primera instancia la incidencia, como son: el icono identificativo del proyecto, el nombre del proyecto, el código (Key) asignado a la petición y el título asignado a la petición creada.

Imagen nº24 – Cabecera de una petición.


3.2.2 Menú de una petición

Las Incidencias de JIRA-Cliente con Aprobaciones disponen de un menú (Nº1 - Imagen nº23 - Ventana petición JIRA-Cliente con Aprobaciones) en su parte superior que permite diferentes acciones sobre la petición.

Imagen nº 25 - Menú de una incidencia JIRA-Cliente con Aprobaciones

Las opciones de izquierda a derecha según la imagen nº25 son las siguientes:

3.2.2.1 Opción Editar del menú de la petición

La opción de edición abre la ventana de edición de la issue (ver imagen anexo 1) que posibilita la modificación de algunos campos que se completaron en la creación además de otros nuevos campos que se incluyen. Por otro lado, la petición también mostrará nuevas pestañas.

A continuación se explican qué diferencias y nuevos campos se incluyen en la ventana de la Incidencia cuando se visualiza en modo edición.

3.2.2.1.1 Pestaña de Campo

Cuando se pulse la opción Editar del menú de la Incidencia, las opciones a visualizar son prácticamente las mismas que se muestran a la hora de crear la petición (Imagen nº 10 - Ventana Crear incidencia), salvo, las siguientes diferencias.

1. Los campos modificables de la ventana edición serán todos a excepción del campo Tipo de Incidencia, ya que, una vez generada la petición no se podrá modificar.

Imagen nº 26 - Opción no habilitada. Tipo de Incidencia.

2. Los siguientes campos (Imagen nº27) se añaden a la Pestaña de Campo:

Entregas: Número de entregas hasta la aprobación de la issue. Campo no editable, será el equipo de soporte el encargado de actualizarla.

Defectos: Número de defectos detectados en las pruebas de usuario. Campo no editable, será el equipo de soporte el encargado de actualizarla.

Comentario: Campo de texto que permite añadir un comentario desde el cliente que por ejemplo pueda hacer referencia a alguna modificación o adjunto añadido.


Imagen nº 27 - Pestaña Campo – Modo edición Petición.

3.2.2.1.2 Pestaña Gente

Muestra el responsable asignado a la petición. Permite asignar a un nuevo Responsable y permite añadir un Comentario en la caja de texto. (Imagen nº28).

Imagen nº 28 - Pestaña Gente – Modo edición Petición.


3.2.2.1.3 Pestaña Stop – Parada

Esta nueva pestaña añade los siguientes campos que solo serán modificables por el equipo de soporte y el cliente en situaciones concretas:

Razón de Parada: Permite añadir información de parada desde JIRA-MInd hacia JIRA-Cliente con Aprobaciones, pero solamente cuando su valor es Client Doubts.

Comentario de Parada: Permite añadir un comentario de parada desde JIRA-MInd hacia JIRA-Cliente con Aprobaciones, pero solamente cuando su valor es Client Doubts

Razón de anulación: Permite añadir información de Anulación desde JIRA-MInd hacia JIRA-Cliente con Aprobaciones, pero solamente cuando su valor es Client Doubts

Comentario Reanudación: Permite añadir un comentario de parada desde JIRA-MInd hacia JIRA-Cliente con Aprobaciones, pero solamente cuando su valor es Client Doubts

Razón Reapertura: Estará habilitado para añadir información cuando desde JIRA-Cliente con Aprobaciones se realiza una transición desde el estado Entregado al estado Reabierto.

Comentario Reapertura: Permite registrar un comentario en la transición Reabrir realizada desde JIRA-Cliente con Aprobaciones.

Comentario: permite registrar toda la información deseada durante la evolución de los trabajos.

Imagen nº 29 - Pestaña Stop/Parada – Modo edición Petición.


3.2.2.1.4 Pestaña Fechas

La pestaña Fechas, en modo edición, incluye los campos explicados el apartado 3.1 y añade los siguientes nuevos campos:

Fecha de Inicio: Permite añadir al equipo de soporte (JIRA – Mind) una fecha de inicio.

Fecha Fin: Permite añadir al equipo de soporte (JIRA - Mind) una fecha fin. Comentario: Caja de texto no restringida que permite registrar cualquier comentario

durante la evolución de los trabajos.

Imagen nº 30 - Pestaña Fechas – Modo edición Petición.

3.2.2.1.5 Pestaña Claves

Añade una caja de texto Comentario que permite registrar cualquier comentario durante la evolución de los trabajos.

3.2.2.1.6 Pestaña Estimación


3.2.2.1.7 Compromiso del Servicio



3.2.2.2 Opción Comentar del menú de la petición

Permite añadir comentarios a la petición.


3.2.2.3 Opción Asignar del menú de la petición

Permite seleccionar un nuevo asignado o responsable del seguimiento de la petición.


3.2.2.4 Opción Más del menú de la petición

Este desplegable permite varias opciones como: Visualizar la petición dentro de una Pizarra Agile, Clasificar la petición en la lista de peticiones, Adjuntar archivos o Capturas de pantalla, Observar o ver a los Observadores, Crear una Sub-tarea, adjuntar un Enlace (*), Clonar la petición o añadir Etiquetas. (Imagen nº 55 Sub-menú Más de una incidencia JIRA-Cliente con Aprobaciones).

Imagen nº 33 - Sub-menú Más de una incidencia JIRA-Cliente con Aprobaciones.

(*) Se puede crear un Enlace de tipo Web vinculado a una dirección URL´s o enlazar la petición a otras incidencias estableciendo una relación de dependencia que se indicará en el


campo: Esta incidencia y la incidencia a la cual se enlaza indicada en by el campo: Incidencia

que se podrá seleccionar desde el desplegable adjunto que muestra el historial de búsqueda, o bien, escribiendo directamente la clave (Key) de la petición.

3.2.2.5 Opción Delete del menú de la petición

A la derecha el menú Más, se irán mostrando las posibles transiciones que puede realizar el usuario sobre la petición en función del estado en el que se encuentre la misma.

Cuando la petición figura en estado Nuevo, la petición podrá transicionar a Deleted (eliminado) pulsando este botón.

3.2.3 Sección Detalles

La sección Detalles (Nº3 en la Imagen nº21 - Ventana petición JIRA-Cliente con Aprobaciones) muestra los principales parámetros de la petición y su estado actual.

Cuando tras un análisis desde el equipo de soporte MInd la petición ha sido estimada, se ha indicado la clave del cliente y sus datos y se ha indicado su exclusión de los ANS, en la parte inferior de la sección Detalles se podrá apreciar tres nuevas pestañas. (Imagen nº34).

Imagen nº 34 – Sección Detalles

Estas son:

Pestaña de Campo: Indica si la petición, por el tipo de proyecto o incidencia, está excluida de los Acuerdos de Nivel de Servicio (ANS) además de un comentario adjunto explicando el motivo. Otra información de interés es el ID de la petición Externa (Exernal Issue ID) y que se refiere a la petición que tiene asociada en Jira-Interno.

Claves: Muestra la clave del proyecto y datos del informador como Nombre, teléfono y email.

Estimación: Muestra las horas Estimadas y Facturadas definidas en la incidencia.

Nuevos campos son añadidos a esta sección aportando información relevante como:


Estado: Indica en qué estado se encuentra la Incidencia dentro del ciclo.

Resolución: Indica si la Incidencia está resuelta o no.

3.2.4 Sección Descripción

Describe de forma detallada el problema o las necesidades específicas de la petición. Esta sección puede combinarse con la posibilidad de adjuntar documentación desde el menú Más del menú superior de la petición. (Ver aparado: Adjuntar archivos)

3.2.5 Sección Actividad

En la parte inferior de la ventana de la petición se encuentra la sección Actividad. (Imagen nº 35 - Actividad).

Imagen nº 35 - Actividad

Esta sección tiene varias pestañas con información relacionada con los cambios que ha sufrido la petición. En la imagen se ve la pestaña

Todo: Muestra todos los datos anteriores.

Comentarios: que muestra aquellos comentarios insertados desde el cliente y el equipo de soporte de Indra en la petición asociada en JIRA-MInd.

Histórico de cambios: muestra cronológicamente los cambios efectuados en la petición.

Actividad: Muestra las actualizaciones realizadas en la petición.

Transitions: Muestra las transiciones realizadas a lo largo de la vida de la petición.


3.2.6 Sección Personas

En la sección Personas (como muestra la siguiente imagen) se muestra el Responsable y el Informador de la petición. Además, en la sección Observadores, se pueden incluir los usuarios que deben recibir notificaciones sobre los cambios experimentados en la petición.

Imagen nº 36 Personas.

Se podrán añadir Observadores para que reciban notificaciones, por ejemplo cuando se realicen cambios de estado en la petición, se añada un comentario, se suban adjuntos a la petición, etc.

Para añadir un observador se deberá hacer clic en el número indicador de observadores (ver siguiente ilustración). En el cuadro emergente, comenzar a escribir en el campo: Añadir Observadores y seleccionar al nuevo observador. (Imagen nº 37 - Añadir observadores).

Imagen nº 37 - Añadir observadores.


3.2.7 Sección Fechas

En parte superior derecha de la ventana de la petición, se encuentra la sección Fechas en donde se agrupan todas las fechas de la petición. (Imagen nº 38 - Fechas.).

Imagen nº 38 - Fechas.

Las fechas definidas para una petición se resumen en la siguiente tabla:

Nombre del campo Descripción

A entregar Fecha acordada de fin.

Creada Fecha de registro de la petición.

Fecha Creación Demanda Fecha insertada de forma manual con la fecha efectiva de la solicitud por parte del cliente.

Fecha Compromiso Respuesta Fecha prevista acordada de atención de análisis o puesta en curso de la petición.

Fecha Inicio Prevista Obligatoria al pasar al estado Estimado/Planificado en Evolutivos. Fecha prevista de paso al estado En Curso en Correctivo y Soporte.

Fecha Fin Prevista Obligatoria al pasar al estado Estimado/Planificado. Tomará por defecto el valor del campo A entregar, pudiéndose modificar.

Fecha Inicio Automática. Fecha de inicio real, es decir, fecha en la que se ha pasado al estado En Curso. Aunque se trate de una fecha automática se podrá modificar posteriormente de forma manual por el perfil responsable.

Fecha Fin Automática. Toma el valor del instante en el que la petición ha pasado al estado Entregado. Por lo tanto, es la fecha real de entrega de la petición. Aunque se trate de una fecha automática se podrá modificar posteriormente de forma manual por el perfil responsable.

Resuelta Automática. Toma el valor del instante en el que la petición ha pasado al estado Cerrado, fecha de cierre de la petición.

Actualizada Automática. Fecha en la que se realizó el último cambio en la petición.

Tratada Automática. Fecha en la que el equipo de soporte de Indra indica que empieza a realizar los trabajos asociados a la petición.


3.2.8 Agile

Permite ver la petición en una Pizarra Agile al pulsar sobre el enlace: Ver en la Pizarra.

Tras pulsar en dicho enlace la ventana Ir a Pizarra permite seleccionar en qué pizarra, en las que aparece la petición, se desea ver. (Imagen nº 39 - Ir a Pizarra).

Imagen nº 39 - Ir a Pizarra


Tras pulsar, se abrirá el tablero Agile que contiene la petición. Al ser una petición recién creada figurará en el Backlog del tablero. (Imagen nº 40 - Ejemplo de Pizarra Agil.).

Imagen nº 40 - Ejemplo de Pizarra Agil


Evolución por parte del equipo de soporte y seguimiento 3.3

por parte del cliente

El equipo de Soporte de Indra se encarga gestionar las Incidencias creadas automáticamente en JIRA-MInd a partir de la creación de las Incidencias desde JIRA-Cliente con aprobaciones.

El responsable del Componente recibirá una notificación por correo electrónico de la creación de cada nueva petición. (Imagen nº 41 - Notificación vía email).

Imagen nº 41 - Notificación vía email.

Otros usuarios del proyecto pueden también detectar la creación de la nueva petición en la sección: Flujo de Actividad del JIRA Project. Ver el apartado: Parámetros y ventanas de las Incidencias de Servicio (GA) con Aprobaciones sección: Actividad. (Imagen 42).

Imagen nº 42 - Flujo de actividad.


La petición creada en JIRA-Cliente con aprobaciones se corresponderá con uno de los productos de operaciones de Servicios de Indra (Functional Support, Corrective, Feature Request o Big Feature Request).

El responsable del componente seleccionado en JIRA-Cliente con aprobaciones podrá asignar la petición a un usuario quién será el nuevo responsable para su gestión y seguimiento. Para ello se recurrirá al botón Asignar del menú de la petición. (Imagen 43).

Imagen nº 43 – Asignar desde el menú superior de la petición.

Se podrá incluir un Comentario en la incidencia que recibirá por email el usuario junto a la notificación de que la petición, le ha sido asignada. (Imagen nº44).

Imagen nº 44 – Añadir cometario el Asignar incidencia.

Tras asignar la Incidencia, se podrá comprobar en la sección Personas (Imagen) de la ventana de la petición, que el nombre del nuevo usuario responsable figurará en el campo: Responsable. (Imagen nº 45).

Imagen nº 45 - Responsable asignado.

Si el usuario con el que se ha accedido a JIRA-CLIENTE CON APROBACIONES es quién se debe de hacer cargo de la petición, podrá realizar una asignación directa pulsando el


botón: Asignarme a mí, dentro de la opción Asignar del menú, para auto-asignarse la petición. (Imagen nº 46).

Imagen nº 46 - Auto-asignado.

La gestión de la petición se realiza como con cualquier petición de Servicios, avanzando sobre el flujo de trabajo (workflow) según se van realizando las fases del proceso de resolución de la petición.

Desde el estado Nuevo (New) de la incidencia, mediante la transición Analyze (Imagen nº 47) se indica (desde JIRA-MInd) el inicio de la fase de ESTUDIO PREVIO.

Desde JIRA-MInd existirá la opción de insertar un comentario relativo a la transición.

Imagen nº 47 - Transición Analyze

Tras el paso anterior el cliente verá en JIRA-Cliente con Aprobaciones que la petición asociada ha evolucionado al estado ESTUDIO PREVIO. Además, el usuario de JIRA-Cliente con Aprobaciones que tiene asignada la petición y el informador recibirán un email que notifique el cambio de estado a ESTUDIO PREVIO. (Imagen nº 48).

Imagen nº 48 - Paso a Estudio Previo en JIRA-Cliente con Aprobaciones.


Este cambio de estado se puede ver también en la sección Actividad de la petición en JIRA-Cliente con Aprobaciones.

Imagen nº 49 – Vista sección actividad.

En JIRA-Cliente con Aprobaciones, del mismo modo que pueden recibir un comentario incluido en la incidencia, el usuario responsable de la incidencia también podrá, mediante el botón Comentar situado en la parte inferior de la ventana de la petición, agregar un comentario en la incidencia.

Imagen nº 50 – Botón para añadir un comentario.

Desde JIRA-MInd el equipo de soporte procederá a las labores de estimación y planificación de las tareas. Para esta estimación/planificación (en este ejemplo: correctivo planificado) se podrá indicar explícitamente desde el cliente la aprobación o rechazo de la estimación (desde el estado Pendiente Aprobación) y posteriormente la aprobación o rechazo de la planificación (desde el estado Pendiente Aprobación Plan).

Realizada la estimación en JIRA-Mind la petición quedará en Estimated. Mediante la transición Send To Approved se enviará al cliente para su aprobación pasando la petición al estado Pending Estimate Approval. Mientras, en JIRA-Cliente con Aprobaciones la petición se mostrará en estado PENDIENTE APROBACIÓN. (Imagen nº 51).



Desde el cliente se podrá Aprobar o Rechazar la estimación.

Rechazar: la petición pasará a estado RECHAZADA ESTIMACIÓN y en JIRA-Mind la petición se mostrará como Estimation Rejected. El Soporte Mind deberá de realizar una nueva estimación.

Aprobar: La estimación se aprueba. Se podrá adjuntar la fecha de aprobación y un comentario (imagen nº 52).


La petición pasa a estado APROBADO ESTIMACIÓN. (Imagen nº 53). El equivalente en JIRA- Mind será Approved Estimate.

Imagen nº 53 .


Tras la aprobación de la estimación por parte del cliente, desde JIRA-MInd el equipo de soporte procederá a la planificación de las tareas. Tendrán que completar como datos obligatorios la Fix Version/s y las fechas: Due Delivery Date (puede ser que desde el cliente ya se haya preestablecido esta fecha), Planned Start Date y Planned End Date. Tras planificar la petición, en desde JIRA-MInd, la petición pasará a estado Planning.

El equivalente en JIRA-Cliente con Aprobaciones será EN PLANIFICACIÓN.

De esta manera el cliente queda advertido sobre las tareas de planificación por parte del equipo de soporte aunque por el momento, no permitirá realizar ningún tipo de transición.

Imagen nº 54.

Tras la planificación desde JIRA-Mind se realizará la transición Send to Approve para ser aprobado desde el cliente. Esta acción permitirá al equipo de soporte adjuntar un archivo en caso necesario así como un comentario.

La petición en JIRA-Mind pasará a estado Pennding Plan Approval y el equivalente en el cliente será: PENDIENTE APROBACIÓN PLAN. (Imagen nº 55).

Imagen nº 55.

En este estado desde JIRA-Cliente con Aprobaciones nuevamente se podrá Aprobar o Rechazar la planificación propuesta por el Soporte Mind (imagen nº 56).


Imagen nº 56.

El cliente podrá:

1. Rechazar la planificación:

Desde el cliente se podrá rechazar la planificación (botón Rechazar) y añadir un comentario que indique el motivo del rechazo. La petición pasará a estado: RECHAZADA PLANIFICACIÓN (imagen nº 57).

Imagen nº 57.

La petición será devuelta al Soporte Mind cambiando al estado: Plan Rejected Desde JIRA-Mind se deberá de re-planificar las tareas para volver a enviar una nueva propuesta mediante la transición Send to Approve.

2. Aprobar la planificación:

La opción Aprobar abrirá una ventana para insertar la fecha de Aprobación Planificación y un campo para insertar un Comentario en caso necesario. Si no se especifica nada, se registrará la automáticamente la fecha actual.


Imagen nº 58.

En JIRA-Cliente con Aprobaciones la petición pasara al estado PLANIFICACIÓN APROBADA. (Imagen nº 59).

Imagen nº 59.

Mientras en JIRA-MInd la petición se mostrará en estado: Approved Plan.

Desde JIRA-MInd, cuando el equipo de soporte esté en disposición de empezar los trabajos asociados a la petición, realizará la transición Work on it (Imagen nº81). Esta transición tendrá asociada la modificación obligatoria de los campos: Due Delivery Date, Fix Version y Component desde JIRA-MInd.

En JIRA-Cliente con aprobaciones se podrá comprobar que la incidencia ha cambiado al estado: EN CURSO, lo cual informa de que ya se está trabajando (desde JIRA-MInd) en la solución. (Imagen nº 60).


Imagen nº 60.

Cuando el equipo de soporte de Indra (JIRA-MInd) termine el desarrollo de la solución, realizará la transición Test para indicar que se inicia la fase de pruebas. (Imagen nº 61).

Imagen nº 61 – Transición al estado Test.

Esta transición Test llevará a la petición de JIRA-MInd al estado: Testing. (Imagen nº 62).

Imagen nº 62 - Cambio de estado a Testing en JIRA-CLIENTE CON APROBACIONES.

Sin embargo, en JIRA-<cliente con aprobaciones no se producirá ningún cambio de estado al tratarse de labores del equipo de soporte Mind.

Cuando la fase de pruebas (Testing) haya finalizado y haya sido satisfactoria, el equipo de soporte (en JIRA-MInd) realizará la transición Deliver.


La transición Deliver en JIRA-MInd lleva al estado Delivered. (Imagen nº 63).

Imagen nº 63 - Cambio de estado a Delivered en JIRA-MInd.

El equivalente en JIRA-Cliente con aprobaciones, será el paso al estado ENTREGADO. (Imagen nº 64).

Imagen nº 64 - Cambio de estado para Entregado en JIRA-Cliente con aprobACIONES.

De este modo, el cliente tendrá conocimiento de que los trabajos están completamente terminados.

A continuación mediante el menú (imagen nº 65) se seleccionará, desde el cliente, la opción deseada tras evaluar el trabajo realizado:

1. Aprobar el trabajo antes de la Puesta en Producción que podrá ser realizada desde

JIRA-Mind o desde JIRA-Cliente con aprobaciones o cerrar la petición. 2. Rechazarlos mediante la transición: Reabrir. 3. Considerarlos concluidos y aceptarlos mediante la transición: Cerrar Incidencia.

Imagen nº 65.


3.3.1 Aprobado y puesta en producción

Una vez entregado el trabajo, desde JIRA-Cliente con Aprobaciones se podrá Aprobar la solución y seleccionar entre varias acciones (Imagen nº66) para su puesta en producción:

Imagen nº 66.

Las acciones son:

No: Quedan aprobados los trabajos pero no se pone en producción.

Yes, from Jira Client: Quedan aprobados los trabajos y se pone en producción desde el cliente. Tras su puesta en producción la petición pasará al estado PUESTA EN PRODUCCIÓN y a continuación se concluirá con el cierre de la petición. (Imagen nº100)

Yes, from Jira Mind: Quedan aprobados los trabajos y se pone en producción por parte del equipo de soporte. El equipo pondrá en producción la solución y pasará la petición al estado Deplyment. El equivalente en JIRA-Cliente con aprobaciones será como en el punto anterior PUESTA EN PRODUCCIÓN y a continuación se concluirá con el cierre de la petición. (Imagen nº 67)

Ninguno: Se aprueba sin acción alguna.

Imagen nº 67 – Puesta en Producción.


3.3.2 Reapertura de una tarea por parte del cliente

Como se adelantaba en el punto anterior, mediante el botón de transición Reabrir de la petición en JIRA-CLIENTE CON APROBACIONES, el cliente puede rechazar la petición que había sido entregada por el equipo de soporte de Indra (en JIRA-MInd) . (Imagen nº 68).

En la ventana emergente (Imagen nº 69) de la transición Reabrir, el cliente debe clasificar la razón de la reapertura, seleccionando una de las opciones del campo Razón Reapertura.

Imagen nº 68 – Seleccionar la Razón de la Reapertura en la Ventana Reabrir.

Además se deberá de incluir un comentario que explique más detalladamente el motivo de la reapertura como muestra la siguiente (Imagen nº 69).

Imagen nº 69 – Añadir comentario de reapertura.


Una vez realizada la transición en JIRA-CLIENTE CON APROBACIONES quedará en estado: REABIERTO. (Imagen nº 70).

Imagen nº 70 - Cambio de estado Reabierto en JIRA-CLIENTE CON APROBACIONES.

Por otro lado la petición asociada en JIRA-MInd habrá realizado la transición al estado: Reopened (Imagen nº 71). De manera que el equipo de soporte tras comprobar que el cliente ha rechazado la entrega de los trabajos, deberá realizar los trabajos adicionales necesarios.

El equipo de soporte de Indra (JIRA-MInd) podrá ver la razón y el comentario de reapertura de la petición introducida por el cliente en la pestaña Stop/Reject de la petición.

Imagen nº 71 - Cambio de estado a Reopened en JIRA-MInd.

3.3.3 Aceptación y cierre de una tarea por parte del cliente

Si por el contrario, el cliente decide aceptar la entrega, deberá pulsar el botón: Cerrar Incidencia. (Imagen nº 72).

Imagen nº 72 - Transición Cerrar incidencia en JIRA-CLIENTE CON APROBACIONES.

En la ventana de la transición Cerrar Incidencia se debe de indicar el tipo de resolución que se aplica a la petición, para ello se seleccionará una de las opciones que tiene el campo: Resolución. (Imagen nº 73).


Imagen nº 73 - Opciones del Campo Resolución.

En la ventana de resolución de la petición, se actualiza automáticamente la fecha de cierre (campo Fecha Fin) y se puede introducir un comentario relativo al cierre de la petición. (Imagen nº 74).

Imagen nº 74 - Añadir comentario en Cerrar incidencia.

Al término de la transición de cierre, en JIRA-CLIENTE CON APROBACIONES se verá la petición en el estado CERRADA. (Imagen nº 75).

Imagen nº 75 - Paso a estado Cerrada en JIRA-CLIENTE CON APROBACIONES.


El mismo modo, desde JIRA-MInd, el equipo de soporte verá la petición asociada en el estado Closed. De esta forma se sabrá que el cliente ha aceptado los trabajos. (Imagen nº 76).

Imagen nº 76 - Paso a estado Closed en JIRA-MInd.

Si tras cerrar la incidencia se hubiera detectado alguna ‘no conformidad’ desde el cliente (JIRA-CLIENTE CON APROBACIONES), mediante el botón de transición Rechazar, el cliente podría reabrir nuevamente la petición. (Imagen nº 77).

Imagen nº 77 - Transición Rechazar desde JIRA-CLIENTE CON APROBACIONES.


3.3.4 Cancelación de tareas

Para indicar que los trabajos de una petición se han detenido se puede pasar al estado Stop. (Imagen nº100). Para ello, en cualquier estado del proceso, el equipo de Indra podrá realizar la transición del mismo nombre desde el desplegable Workflow selección Stop.

Imagen nº 78 - Paso a Stop desde JIRA-MInd.

En la ventana de la transición, se debe indicar la razón de la parada en el campo Stop Reasons y añadir un comentario relacionado en el campo Stop Comment. (Imagen nº 79).

Imagen nº 79 - Indicar razón de la parada y comentario de la parada.

Una vez en este estado, si finalmente se decide cerrar definitivamente la petición sin terminar los trabajos, se debe de realizar la transición Cancel. (Imagen nº 80).

Imagen nº 80 - Transición Cancel para cierre definitivo por parte del equipo de soporte.


Del mismo modo, en la transición, se deberá indicar el motivo del cierre. (Imagen nº 81).

Imagen nº 81 - Completar campo Resolution Comment.

Así, en JIRA-MInd la petición en quedará en estado Closed y el campo Resolution con el valor: Invalid. (Imagen nº 82).

Imagen nº 82 - Pasa a estado Closed – Resolution: Invalid en JIRA-MInd

Y en JIRA-CLIENTE CON APROBACIONES la petición asociada en quedará en estado CERRADA y el campo Resolution con el valor: Inválido. (Imagen nº 83).

Imagen nº 83 - Pasa a estado Cerrada - Resolución: Invalido en JIRA-CLIENTE CON APROBACIONES.


3.3.5 Borrado de tareas

En ocasiones, una tarea se puede haber creado por error (por ejemplo se ha insertado por duplicado). En ese caso desde JIRA-CLIENTE CON APROBACIONES se puede realizar la transición Delete para marcar la petición como borrada. (Imagen nº 84).

Imagen nº 84 - Transición Delete.

En la ventana de la transición (Imagen nº 85) se solicita un comentario explicativo de los motivos para borrar la petición.

Imagen nº 85 – Ventana Delete.


Una vez realizada la transición, la petición pasará a ELIMINADO.

Imagen nº 86 – Ventana Delete.

Y no tendrá ninguna opción del menú habilitada, de modo que ya no se podrá salir de este estado.

En JIRA-Mind se verá que la petición pasará al estado Deleted y tampoco se podrá realizar ninguna acción operativa. (Imagen nº 87).

Imagen nº 87 – Transición a Deleted en JIRA-Mind .


4 Caso práctico (Gran Evolutivo)

En este apartado se explica el proceso de creación de una petición de tipo Gran Evolutivo desde el cliente, cómo editarlo tras su creación la petición y su evolución por parte del equipo de soporte y seguimiento desde el cliente.

Dado que gran parte de los procedimientos (creación de la petición y cumplimentación de los campos asociados a esta o la edición de dichos campos) son comunes, se invitará mediante enlaces a la revisión de ciertos puntos ya tratados en este documento.

Creación de una petición tipo Gran Evolutivo 4.1

Para la creación de una petición de este tipo se recomienda ver el apartado: 3.1 Creación de una petición tipo Correctivo por parte del cliente de este documento para revisar los campos que conforman la creación de una petición.

Tras pulsar el botón Crear se deberá de completar los campos de Proyecto y Tipo de Incidencia. En este caso se deberá de seleccionar Gran Evolutivo. (Imagen nº 88).

Imagen nº 88 – Creación Incidencia Tipo Evolutivo.

A continuación se procederá a completar los campos y pestañas (ver imagen nº 7 - Ventana Crear incidencia) de la petición. Dada la similitud se recomienda repasar el apartado 3.1 Creación de una petición tipo Correctivo por parte del cliente. Tras crear la petición se iniciará el ciclo de trabajo que se trata en el siguiente apartado.

Parámetros y ventanas de una petición de tipo Gran 4.2Evolutivo

Los parámetros y ventanas de la petición serán los mismos que en una petición de tipo Correctivo por lo que se recomienda ver el apartado: 3.2 Parámetros y ventanas de las Incidencias de Servicio (GA) con Aprobaciones.


Evolución por parte del equipo de soporte y seguimiento 4.3por parte del cliente

La evolución de una petición de tipo Gran Evolutivo no dista mucho de la evolución en una petición de tipo Correctivo Planificado, ya revisada en el apartado: 3.3 Evolución por parte del equipo de soporte y seguimiento por parte del cliente. Por este motivo se invita a repasar dicha sección.

Así pues el flujo de trabajo de una petición de tipo Gran Evolutivo transcurre por las mismas fases que las estudiadas en el flujo de una petición de tipo Correctivo hasta llegar al estado PLANIFICACIÓN APROBADO. Desde este estado, cuando ya ha sido aprobado por el cliente, la panificación el equipo de soporte pasará la petición a In funcional Analysis momento en el que comenzará las labores de diseño. La petición en JIRA-Cliente con Aprobaciones pasará al estado EN ELABORACION DISEÑO. (Imagen nº 89).


Concluidas las labores de diseño en JIRA-Mind se enviará para su aprobación a JIRA-Cliente con Aprobaciones mediante la transición Send to Approved pasando la petición en JIRA-Mind al estado: Analysis in Approval.

En JIRA-Cliente con Aprobaciones la petición se mostrará como PENDIENTE APROBACION DISEÑO. (Imagen nº 90).


La petición podrá ser Aprobada o rechazada:

En el caso de ser rechazada volverá a Elaboración Diseño.


En el caso de ser Aprobada la petición pasará al estado EN CURSO en el cliente lo cual informa de que ya se está trabajando (desde JIRA-MInd) en la solución. (Imagen nº 91).

Imagen nº 91 - Cambio de estado a En Curso en JIRA-Cliente con Aprobaciones.

A partir de aquí el flujo de trabajo de la petición, con las transiciones y estados que comprende, será el mismo visto en el apartado: 3.3 Evolución por parte del equipo de soporte y seguimiento por parte del cliente por lo que se invita a repasar dicha sección.


ANEXO I. VENTANA EDITAR INCIDENCIA

aprobaciones - indra...reflejar cuándo el equipo de indra está realizando el diseño y cuando...

Documents