Estás viendo una versión antigua de esta página. Ve a la versión actual.

Comparar con el actual Ver el historial de la página

« Anterior Versión 36 Siguiente »

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.
Todos los usuarios con este rol pueden hacer las mismas acciones independientemente de la entidad y de la aplicación
  • 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.
¿Cómo puedes usar esta guía rápida?


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


No Conformidad










Historias de usuario



Creación

    •  Se crean en el mismo estado en el que esté la mejora origen, que puede ser BACKLOG o EN VERSIÓN, asignadas a R. PRODUCTO y por los roles R. PRODUCTO y R. FUNCIONAL. Pueden crearse con una plantilla disponible en Confluence


Acciones en estado BACKLOG

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ASIGNAR A VERSIÓN

R. PRODUCTO

La mejora origen debe haberse previamente asignado a versión o automatizar

este proceso para que la mejora arrastre sus historias de usuario

BACKLOG a EN VERSIÓN

N/A


Acciones en estado EN VERSIÓN

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

INCLUIR EN SPRINT (Previamente es necesario crear el sprint y arrastar la historia) Quedará informado el sprint en el que está incluida la historia

R. PRODUCTO

N/A


N/A
COMENZAR SPRINT El Sprint pasará a estar activo para que sea posible comenzar a crear tareas)

R. PRODUCTO

N/A

N/A

CREAR SUBTAREAS

R. PRODUCTO
PROVEEDOROCA


N/AN/A
CREAR ERRORES

R. PRODUCTO

PROVEEDOROCA


N/AN/A
EDITAR

R. PRODUCTO

PROVEEDOR OCA
N/AN/A
RESOLVER (se pretende automatizar esta acción una vez que todas la ssubtareas y errores estén cerradas) (por ahora deberá hacerse por procedimeineto, no acceder a ella hasta que las subtareas no estén cerradas)

PROVEEDOR

EN VERSIÓN a PDTE. VALIDAR

N/A

Acciones en estado PDTE. VALIDAR

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR
R. PRODUCTO
R. FUNCIONAL
OCA
N/AN/A
VALIDAR
OCA

R. PRODUCTO

R. FUNCIONAL


PDTE. VALIDAR a VALIDADA OCA


PDTE. VALIDAR a VALIDADA

N/A
NO VALIDAR

R. PRODUCTO

R. FUNCIONAL

OCA

PDTE. VALIDAR a NO ACEPTADA

N/A

 

Acciones en estado NO ACEPTADA


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

R. FUNCIONALR. PRODUCTOOCA

N/AN/A
CREAR ERRORES
OCA


R. PRODUCTOR. FUNCIONAL


PROVEEDOR

N/AN/A
RESOLVER

R. PRODUCTO

R. FUNCIONAL

OCA

NO ACEPTADA a PDTE. VALIDAR

N/A



Acciones en estado VALIDADA


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR
R. PRODUCTO
R. FUNCIONAL
OCA
N/AN/A
CIERRE RFC
PROCESO AUTOMATIZADO



VALIDADA a CERRADA

(Sin Resolver) a (Cerrada)








  • Sin etiquetas