Tabla de contenidos

Generalidades para todas las entidades

• Existen una serie de acciones comunes a todas las entidades:
  • COMENTAR
  • ADJUNTAR ARCHIVOS
  • ENLAZAR
  • ETIQUETAR
    
    

• Los usuarios necesarios en un proyecto son:
  • Responsable de Área
  • Responsable de producto
  • Responsable funcional
  • Responsable de sistemas
  • Proveedor
    
    

Estos usuarios aunque aparezcan como asignados de las entidades pertenecen a roles definidos:

• COORDINADOR→Puede hacer todo lo que hace el rol JP-STIC además de ciertas acciones específicas que se detaññan
• JP-STIC→ A este rol pertenecen los usuarios Responsable de producto y Responsable de sistemas.

• FUNCIONAL→ A este rol pertenecen los usuarios Responsable funcional
• COLABORADOR–>Este rol se usa para ususarios que sólo pueden hacer las acciones comunes pero ninguna acción específica.

• Para cada una de los tipos de entidades de JIRA se detallan las acciones que pueden ejecutarse en cada uno de sus estados indicando:
  • Usuarios que pueden ejecutarla.
  • Si procede, cambio de estado de la entidad.
  • Si pocede, cambio de resolución de la entidad.

Los tipos de entidades que se contemplan en JIRA son:

• Incidencia
• Mejora
• Versión
• OT con crédito disponible
• OT con estimación
• No Conformidad

Incidencia

Las incidencias que llegan a JIRA suponen fallos en el software que hay actualmente en Producción y que se registran desde MiCS (Mi Centro Servicio) o desde NWT (Nueva Web Técnica).  Pueden por tanto tener su origen en incidencias de usuarios finales o en la resolución de un problema que debe ser acometida por el Proveedor del producto.

En cualquier caso son resueltas por el Proveedor en NWT y sólo llegan a JIRA si su corrección implica implantación y modificación de la línea base del producto. Por tanto, llegan a JIRA corregidas y a la espera de ser implantadas en Producción en la versión que el Responsable de Producto o el Proveedor consideren oportunas. Se crean informando la fecha de registro en NWT, el usuario afectado, el código de solicitud y la prioridad.

Una vez que la versión se implante (cierre de la RFC en FARO), significará que las incidencias están en Producción y se cerrarán en JIRA, lo que supondrá que acabarán su ciclo de vida también en NWT, comunicando al usuario afectado la resolución del fallo detectado.

Creación

• • Por integración. Se crean en estado 

    Estado
    colour Yellow title BACKLOG

     asignadas a 

    Estado
    title R. PRODUCTO

     tanto si su origen es la gestión de problemas como si es la gestión de incidencias.
    
    

• • 
    

Acciones en estado 

Estado
colour Yellow title BACKLOG

Acciones en estado 

Estado
colour Yellow title EN VERSIÓN

Mejora

Una mejora es cualquier petición de evolución de una aplicación. Puede ser registrada por cualquier usuario en MiCS (Mi Centro Servicios). Su origen puede ser esa petición de un usuario final o bien la respuesta a la solución de un problema que hace el Responsable de Producto. Pueden ser registradas directamente en JIRA por los usuarios logados en la herramienta.

La mejoras son analizadas por los Responsables Funcionales para determinar su viabilidad, y, si la tienen, establecer la urgencia con la que deben ser incluidas en una versión.

Cuando se aprueba una mejora por ser considerada viable, se informa al usuario que la registró cerrando la solicitud en el caso de registro en MiCS.

Una vez incluidas en una versión podrán asignarse a las OTs incluidas en esa versión para ser desarrolladas por el Proveedor correspondiente.

Una vez implantada la versión (RFC cerrada en FARO o versión finalizada si no se genera RFC) las mejoras se cerrarán en JIRA lo que significará que están implantadas en Producción.

Creación

• Por integración. 
  • Se crean en estado 

    Estado
    colour Blue title WISHLIST

    asignadas a 

    Estado
    title R. PRODUCTO

    para origen gestión de proyectos.
  • Se crean en estado 

    Estado
    colour Yellow title BACKLOG

    asignadas a 

    Estado
    title R. PRODUCTO

     para origen gestión de problemas.
• Directamente en JIRA en estado 

  Estado
  colour Blue title WISHLIST

   asignadas a 

  Estado
  title R. PRODUCTO

  por usuarios de la aplicación. 

  Estado
  title TODOS LOS USUARIOS

Acciones en estado WISHLIST

Acciones en estado 

Estado
colour Yellow title BACKLOG

Acciones en estado EN VERSIÓN

Historias de usuario

Creación

• •  Se crean en el mismo estado en el que esté la mejora origen, que puede ser 

    Estado
    colour Yellow title BACKLOG

     o

    Estado
    colour Yellow title EN VERSIÓN

     por los roles 

    Estado
    title R. PRODUCTO

     y 

    Estado
    title R. FUNCIONAL

    . Una Historia de Usuario sólo puede estar relacionada con una mejora.
    
    

  • 
    

Acciones en estado 

Estado
colour Yellow title BACKLOG

Acciones en estado 

Estado
colour Yellow title EN VERSIÓN

Es recomendable crear una pizarra SCRUM para organizar las historias de usuario en sprints y activar aquel en el que se vaya a trabajar.