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 56 Siguiente »



Común a 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.



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.


Si la prioridad de la incidencia es P1 y en NWT el Proveedor indica que se requiere Versión de Emergencia, se generará una entidad de este tipo en la que quedará automáticamente incluida la incidencia.


Si la incidencia llega a JIRA por error o con datos incorrectos, existe la posibilidad de escalarla a NWT.


Creación

    • Por integración. Se crean en estado BACKLOG asignadas a R. PRODUCTO tanto si su origen es la gestión de problemas como si es la gestión de incidencias.


Acciones en estado BACKLOG

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ESCALAR

R. PRODUCTOPROVEEDORCGES

BACKLOG a CERRADA


(Sin resolver) a (Cancelada)
ASIGNAR A VERSIÓN

R. PRODUCTOPROVEEDOR

BACKLOG a EN VERSIÓN

N/A
CLONAR (en cualquier aplicación)

R. PRODUCTOPROVEEDOR

N/AN/A


Acciones en estado EN VERSIÓN

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

DESASIGNAR DE VERSIÓN

R. PRODUCTOPROVEEDOR

EN VERSIÓN a BACKLOG


N/A
ASIGNAR OT

R. PRODUCTO

N/A

N/A
CLONAR (en versiones de la misma aplicación)

R. PRODUCTOPROVEEDOR

N/AN/A
VALIDAR

R. PRODUCTOR. FUNCIONALOCA

N/AN/A
EDITAR

R. PRODUCTOR. FUNCIONALOCA

N/AN/A
CIERRE RFC

PROCESO AUTOMATIZADO

EN VERSIÓN a CERRADA

(Sin resolver) a (Cerrada)
  •  

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 WISHLISTasignadas a R. PRODUCTOpara origen gestión de proyectos.
    • Se crean en estado BACKLOGasignadas a R. PRODUCTO para origen gestión de problemas.
  • Directamente en JIRA en estado WISHLIST asignadas a R. PRODUCTOpor usuarios de la aplicación. TODOS LOS USUARIOS


Acciones en estado WISHLIST


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR MEJORA

R. PRODUCTOR. FUNCIONAL

WISHLIST a BACKLOG


N/A
NO APROBAR MEJORA

R. PRODUCTOR. FUNCIONAL

BACKLOG a CERRADA

  • Rechazo: (Sin resolver) a (Rechazada)
  • Escalado: (Sin resolver) a (Escalada)
CLONAR (en cualquier aplicación)

R. PRODUCTOR. FUNCIONALPROVEEDORCOLABORADOR


N/AN/A
ESCALAR (Sólo para mejoras creadas por integración y que no han cambiado de estado)

CGES

N/A(Sin resolver) a (Escalada)




Acciones en estado BACKLOG

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

A WISHLIST 

R. PRODUCTOR. FUNCIONAL

BACKLOG a WISHLIST


N/A
ASIGNAR VERSIÓN

R. PRODUCTO

BACKLOG a EN VERSIÓN

N/A

CLONAR (en cualquier aplicación)

R. PRODUCTOR. FUNCIONAL

N/AN/A
ESCALAR (Sólo para mejoras creadas por integración y que no han cambiado de estado)

CGES

N/A(Sin resolver) a (Escalada)




Acciones en estado EN VERSIÓN


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

DESASIGNAR DE VERSIÓN

R. PRODUCTO

EN VERSIÓN a BACKLOG

N/A
ASIGNAR OT

R. PRODUCTO

N/A

N/A
CLONAR (en versiones de la misma aplicación)

R. PRODUCTO

N/AN/A
VALIDAR

R. PRODUCTOR. FUNCIONALCGES

N/AN/A
EDITAR

R. PRODUCTOR. FUNCIONALOCA

N/AN/A
CIERRE RFC

PROCESO AUTOMATIZADO

EN VERSIÓN a CERRADA

(Sin resolver) a (Cerrada)



Versión

Una versión es un contenedor de mejoras e incidencias, es decir, tiene un alcance y un presupuesto determinados a partir de la que se lanzan trabajos para el proveedor  (órdenes de trabajo). Existe la posibilidad de que sea necesario un estudio de viabilidad del de la versión antes de comenzar a trabajar para que el Jefe de Proyecto decida una alternativa en el caso de que haya más de una y la reserva correspondiente de HBS.

Por cada uno de los meses de duración de la versión se creará una subtarea de Previsión en la que se podrán estimar las HBS previstas y donde se irán incurriendo las HBS que el proveedor registre en ese mes en las órdenes de trabajo asociadas a la versión.

Existe la posibilidad de modificar el alcance incluyendo o excluyendo mejoras o incidencias. 

Si la implantación de la versión necesita la intervención del Proveedor de Sistemas, será necesario generar una RFC en FARO, donde el Proveedor generará PLs que transicionarán implantando el software en o en los entornos que se determinen y que terminarán cerrando la RFC. En ese momento, las mejoras e incidencias incluidas en la versión pasará a estado Cerrada, considerando que su implantación en el entorno de Producción está finalizada.

Durante este proceso será posible crear órdenes de trabajo y asociarlas a la versión. Como ya hemos comentado, las HBS incurridas en un mes determinado se irán sumando a las HBS incurridas de la subtarea de previsión correspondiente a ese mes (excepto patra las órdenes de tarbajo de tipo PST).

Creación 

Se crean en estado ABIERTAasignadas a R. PRODUCTO por R. PRODUCTO


Acciones en estado ABIERTA


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

GESTIONAR ALCANCE (incluir/excluir mejoras, incidencias o No conformidades en estado BACKLOGde esa aplicación)

R. PRODUCTO

N/A

N/A

COMENZAR (imprescindible que al menos haya una mejora o incidencia en la versión)

  • Si la versión está aprobada por R. ÁREA-->  R. PRODUCTO
  • Si la versión no está aprobada por R. ÁREA-->  R. ÁREA

ABIERTA a EN RESOLUCIÓN

ABIERTA a PDTE. COMIENZO RA

N/A
CANCELAR

R. PRODUCTO

ABIERTA a CERRADA

(Sin resolver) a (Cancelada)



Acciones en estado PDTE. COMIENZO RA


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

R. ÁREA

PDTE. COMIENZO RA a EN RESOLUCIÓN

N/A

CANCELAR

R. ÁREA

PDTE. COMIENZO RA a CERRADA

(Sin resolver) a (Cancelada)


Acciones en estado EN RESOLUCIÓN


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

GESTIONAR ALCANCE

R. PRODUCTO

N/A

N/A

GENERAR RFC

Necesario tener informado código de versión)


R. PRODUCTO

EN RESOLUCIÓN a EN RESOLUCIÓN CON RFC ABIERTA

N/A
CANCELAR



  • GESTIONAR ALCANCE  R. PRODUCTO
  • GENERAR RFC R. PRODUCTO→Obligatorio tener el código de la versión
    EN RESOLUCIÓN-->EN RESOLUCIÓN CON RFC ABERTA
  • FINALIZAR R. PRODUCTO→Obligatorio tener el código de la versión y todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cerrada)

  • CANCELAR R. PRODUCTO-->Obligatorio tener  todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cancelada)


Acciones en estado EN RESOLUCIÓN CON RFC ABIERTA

  • GESTIONAR ALCANCE  R. PRODUCTO
  • CANCELAR R. PRODUCTO-->Obligatorio tener  todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cancelada)

  • CIERRE RFC PROCESO AUTOMATIZADO →(Mejoras, incidencias y No conformidades incluidas en la versión se cierran)EN RESOLUCIÓN--->EN RESOLUCIÓN CON RFC CERRADA



Acciones en estado EN RESOLUCIÓN CON RFC CERRADA

  • FINALIZAR R. PRODUCTO→Obligatorio tener todas las OTs asociadas cerradas

EN RESOLUCIÓN CON RFC CERRADA--->CERRADA (Resolución Cerrada)



OT con crédito disponible


Creación

Si no es de tipo  PST ni de tipo EVS la crea R. PRODUCTOasignada a PROVEEDORen estado PDTE. CALENDARIZAR

    • Si es de tipo EVS la crea R. PRODUCTO:
      • Si el EVS está aprobado por el Responsable de Área--> asignada a PROVEEDORen estado PDTE. CALENDARIZAR
      • Si el EVS no está aprobado por el Responsable de Área→asignada a R. ÁREA en estado PDTE. APROBAR
    • Si es  de tipo PST la crea R. PRODUCTOPROVEEDORasignada aPROVEEDOR SISTEMASen estado PDTE. CALENDARIZAR


Acciones en estado PDTE. APROBAR


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR

R. ÁREA

 PDTE. APROBAR a PDTE. CALENDARIZAR


N/A
NO APROBAR

R. ÁREA

PDTE. APROBAR a CERRADA

(Sin resolver) a (No Aprobada RA)

Acciones en estado PDTE. CALENDARIZAR



ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

CALENDARIZAR
  • Si no es de tipo PST PROVEEDOR
  • Si es PST PROVEEDOR SISTEMAS

PDTE. CALENDARIZAR a PDTE. COMENZAR RESOLUCIÓN


N/A
CANCELAR

R. PRODUCTO

PDTE. APROBAR a CERRADA

(Sin resolver) a (Cancelada)


Acciones en estado PDTE. COMENZAR RESOLUCIÓN


  •  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR RESOLUCIÓN
  • Si no es de tipo PST PROVEEDOR
  • Si es PST PROVEEDOR SISTEMAS

PDTE. COMENZAR RESOLUCIÓN a EN RESOLUCIÓN


N/A
CANCELAR

R. PRODUCTO

PDTE. CALENDARIZAR a CERRADA

(Sin resolver) a (Cancelada)




Acciones en estado EN RESOLUCIÓN


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS
  • Si no es de tipo PST PROVEEDOR
  • Si es PST PROVEEDOR SISTEMAS

N/A

N/A
SEGUIMIENTO
  • Si no es de tipo PST PROVEEDOR
  • Si es PST PROVEEDOR SISTEMAS

N/A

N/A
RESOLVER
  • Si no es de tipo PST PROVEEDOR
  • Si es PST PROVEEDOR SISTEMAS
  • Si no es de tipo PST:
    • Si la OT es revisada por la OCA EN RESOLUCIÓN a PDTE. REVISIÓN OCA
    • Si la OT no es revisada por la OCA EN RESOLUCIÓN a PDTE. REVISIÓN JP
  • Si es PST EN RESOLUCIÓN a PDTE. REVISIÓN
N/A
CANCELAR

R. PRODUCTO

EN RESOLUCIÓN a PDTE. CANCELACIÓN

N/A


Acciones en estado PDTE. REVISIÓN OCA


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

INFORMAR REVISIÓN OCA

OCA

PDTE. REVISIÓN OCA a PDTE. REVISIÓN JP

N/A


Acciones en estado PDTE. CANCELACIÓN


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS
  • Si no es de tipo PST PROVEEDOR
  • Si es PST PROVEEDOR SISTEMAS

N/A

N/A
LIQUIDAR OT
  • Si no es de tipo PST PROVEEDOR
  • Si es PST PROVEEDOR SISTEMAS

PDTE. CANCELACIÓN a PDTE. REVISIÓN CANCELACIÓN

N/A


Acciones en estado PDTE. REVISIÓN JP


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR RESOLUCIÓN

R. PRODUCTO

PDTE. REVISIÓN JP a CERRADA

(Sin resolver) a (Cerrada)
NO ACEPTAR RESOLUCIÓN

R. PRODUCTO

PDTE. REVISIÓN JP a NO ACEPTADA JP

N/A

Si es de tipo EVS:

EDITAR (Informar campos Alternativa y Reserva HBS)

R. PRODUCTOPROVEEDOR

N/AN/A

Acciones en estadoPDTE. REVISIÓN

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR RESOLUCIÓN

R. PRODUCTO

PDTE. REVISIÓN JP a CERRADA

(Sin resolver) a (Cerrada)
NO ACEPTAR RESOLUCIÓN

R. PRODUCTO

PDTE. REVISIÓN JP a NO ACEPTADA JP

N/A


Acciones en estado PDTE. REVISIÓN CANCELACIÓN


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR CANCELACIÓN

R. SISTEMAS

PDTE. REVISIÓN a CERRADA

(Sin resolver) a (Cancelada)
NO ACEPTAR CANCELACIÓN

R. SISTEMAS

PDTE. REVISIÓN a PDTE.CANCELACIÓN

N/A


Acciones en estado NO ACEPTADA


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS

PROVEEDOR SISTEMAS

N/AN/A

RESOLVER

PROVEEDOR SISTEMAS

NO ACEPTADA a PDTE. REVISIÓN

N/A


Acciones en estado NO ACEPTADA-JP


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

    • Rechazo sólo por motivos técnicos:
      RESOLVER

PROVEEDOR

NO ACEPTADA JP a PDTE. REVISIÓN JP

N/A
    • Rechazo por costes:
      REGISTRAR HBS

PROVEEDOR

N/AN/A
    • Rechazo por costes:
      RESOLVER

PROVEEDOR

NO ACEPTADA JP a PDTE. REVISIÓN JP

N/A

OT con estimación

Creación

 R. PRODUCTOPROVEEDOR 

se crean en estado PDTE. ESTIMAR

Acciones en estado PDTE. ESTIMAR

    • ESTIMAR PROVEEDOR
      PDTE. ESTIMAR--->ESTIMADA
    • CANCELARR. PRODUCTO y PROVEEDOR si es el informador


Acciones en estado ESTIMADA

    • APROBAR ESTIMACIÓN R. PRODUCTO
      ESTIMADA--->PDTE. COMENZAR RESOLUCIÓN
    • NO APROBAR ESTIMACIÓNR. PRODUCTO 
      ESTIMADA--->PDTE. ESTIMAR

Historias de usuario

Una historia de usuario es una entidad que se usa en los proyectos que se gestionan con metodología ágil para "descomponer las mejoras" y asociar tareas que se asignan a los integrantes del equipo. Esta gestión puede hacerse con la posiblidad que tiene la herramienta de uso de pizarras SCRUM que permiten la gestión de sprints en el que se incluyen estas historias que pueden a su vez descomponerse en subtareas y errores.

Creación

    •  Se crean en el mismo estado en el que esté la mejora origen, que puede ser BACKLOG o EN VERSIÓN por los roles R. PRODUCTO y R. FUNCIONAL. Una Historia de Usuario sólo puede estar relacionada con una mejora.


Acciones en estado BACKLOG

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EN VERSIÓN

R. PRODUCTO

La mejora origen debe haberse previamente asignado a una versión

BACKLOG a EN VERSIÓN

N/A

CREAR SUBTAREA


R. PRODUCTO

R. FUNCIONAL

PROVEEDOR

N/A

N/A
EDITAR

R. PRODUCTO

R. FUNCIONAL

PROVEEDOR


N/A

N/A


Acciones en estado 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. 

La configuración de las pizarras es independiente de los flujos de las historias de usuario y de subtareas y errores.

Puedes gestionar historias, tareas y subtareas sin haber configurado la pizarra.

Ver "Configuración pizarras SCRUM"


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

CREAR SUBTAREA

R. PRODUCTO

R. FUNCIONAL

PROVEEDOR

N/AN/A
CREAR ERROR

R. PRODUCTO

R. FUNCIONAL

PROVEEDOR

OCA

N/AN/A
EDITAR

R. PRODUCTO

R. FUNCIONAL

PROVEEDOR
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 procedimieneto, 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

PROVEEDOR

N/AN/A
VALIDAR OCA

OCA

PDTE. VALIDAR a VALIDADA OCA


NO VALIDAR OCA

OCA

PDTE. VALIDAR a NO ACEPTADA


VALIDAR

R. PRODUCTO

R. FUNCIONAL


VALIDADA OCA a VALIDADA

Si valida la OCA

PDTE. VALIDAR a VALIDADA

Si no valida la OCA

(Sin Resolver) a (Cerrada)
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. FUNCIONAL

R. PRODUCTO

OCA

N/AN/A
CREAR ERRORES

R. FUNCIONAL

R. PRODUCTO

OCA

PROVEEDOR

N/AN/A
RESOLVER

PROVEEDOR

NO ACEPTADA a PDTE. VALIDAR

N/A




Subtarea 


Creación

  • Se crean a como entidades de tipo subtarea a partir de una Historia de usuario que esté en estado EN VERSIÓN  o en BACKLOG. Se crean en estado ABIERTA por R. PRODUCTO, R. FUNCIONAL PROVEEDOR


Acciones en estado ABIERTA

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

(Obligatorio asignar la tarea a un integrante del equipo)

R. PRODUCTO

PROVEEDOR

ABIERTA a EN RESOLUCIÓN

N/A
CANCELAR

R. PRODUCTO

PROVEEDOR

ABIERTA a CERRADA

(Sin Resolver) a (Cancelada)
EDITAR

R. PRODUCTO

PROVEEDOR

N/AN/A


Acciones en estado EN RESOLUCIÓN

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

PARALIZAR

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a PARALIZADA

N/A
CANCELAR

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a CERRADA

(Sin Resolver) a (Cancelada)
RESOLVER

PROVEEDOR

R. PRODUCTO

EN RESOLUCIÓN a CERRADA

(Sin Resolver) a (Cerrada)
EDITAR

R. PRODUCTO

PROVEEDOR

N/AN/A
REGISTRAR HBS

PROVEEDOR

N/AN/A


Acciones en estado PARALIZADA

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REANUDAR

R. PRODUCTO

PROVEEDOR

PARALIZADA a EN RESOLUCIÓN

N/A
CANCELAR

R. PRODUCTO

PROVEEDOR

PARALIZADA a CERRADA

(Sin Resolver) a (Cancelada)
EDITAR

R. PRODUCTO

PROVEEDOR

N/AN/A


Acciones en estado  CERRADA

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REABRIR

(Comentario Obligatorio)

R. PRODUCTO

PROVEEDOR

CERRADA a EN RESOLUCIÓN

N/A
EDITAR

R. PRODUCTO

PROVEEDOR

N/AN/A

Error 


Creación

  • Se crean a como entidades de tipo subtarea a partir de una Historia de usuario que esté en estado EN VERSIÓN o posterior. Se crean en estado ABIERTA por R. PRODUCTO, R. FUNCIONAL PROVEEDOR  OCA


Acciones en estado ABIERTA

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

(Obligatorio asignar la tarea a un integrante del equipo)

R. PRODUCTO

PROVEEDOR

ABIERTA a EN RESOLUCIÓN

N/A
CANCELAR

R. PRODUCTO

PROVEEDOR

OCA

ABIERTA a CERRADA

(Sin Resolver) a (Cancelada)
EDITAR

R. PRODUCTO

PROVEEDOR

OCA

N/AN/A


Acciones en estado EN RESOLUCIÓN

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

PARALIZAR

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a PARALIZADA

N/A
CANCELAR

R. PRODUCTO

PROVEEDOR

OCA

EN RESOLUCIÓN a CERRADA

(Sin Resolver) a (Cancelada)
RESOLVER

PROVEEDOR

R. PRODUCTO

EN RESOLUCIÓN a CERRADA

(Sin Resolver) a (Cerrada)
EDITAR

R. PRODUCTO

PROVEEDOR

OCA

N/AN/A
REGISTRAR HBS

PROVEEDOR

N/AN/A


Acciones en estado PARALIZADA

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REANUDAR

R. PRODUCTO

PROVEEDOR

PARALIZADA a EN RESOLUCIÓN

N/A
CANCELAR

R. PRODUCTO

PROVEEDOR

PARALIZADA a CERRADA

(Sin Resolver) a (Cancelada)
EDITAR

R. PRODUCTO

PROVEEDOR

N/AN/A

Acciones en estado  CERRADA

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REABRIR

(Comentario Obligatorio)

R. PRODUCTO

PROVEEDOR

OCA

CERRADA a EN RESOLUCIÓN

N/A
EDITAR

R. PRODUCTO

PROVEEDOR

OCA

N/AN/A


Configuración pizarras SCRUM


Crear pizarra

Accede a la creación de pizarras y crea una pizarra de tipo SCRUM de un proyecto existente. Vamos a tomar como ejemplo el proyecto de Admisión Única (AU)









Configurar el filtro de la pizarra

Accede a la configuración de la pizarra y a partir de ahí a la posibilidad de modificar el filtro (Editar consulta de filtro), ya que el filtro muestra todas las entidades del proyecto.


Selecciona la entidad "Historia de usuario" y las subtareas de tipo Subtarea y Error en el filtro y guárdalo

Crear sprints

Accede de nuevo a la pizarra SCRUM que has creado y procede a crear los sprints que quieras para organizar en ellos las historias de usuario.

Configurar SPRINTS ACTIVOS

Configura las columnas. En este ejemplo hemos configuardo las columnas ABIERTA, EN RESOLUCIÓN, PROCESO VALIDACIÓN. PARALIZADA Y CERRADA.

Entra en la configuración de la pizarra y en la columna de la izquierda accede a Columnas. Puedes añadir, eliminar o cambiar el nombre de las que aparecen por defecto




Crea las que te van a aportar más para mover de una columna a otra las historias y, sobre todo, las subtareas y los errores

Incluye dentro de cada columna los estados que consideras deben estar en cada una de ellas. Por ejemplo, en la columna En validación, incluimos los estados "PDTE. VALIDAR" y "VALIDADA OCA"


Crea filtros rápidos para las subtareas y los errores

Inicia sprint en Trabajo pendiente. En nuestro ejemplo, iniciamos el Sprint 1



Al comenzar el SPRINT, podremos mover historias, subtreas y errores por las columnas



Cerrar Sprint activo

Los sprints se cierran manualmente sin restricción en la fecha dando la posibilidad de incorporar el trabajo no realizado a otros sprints creados.



Más información en https://www.atlassian.com/agile/tutorials/sprints


  • Sin etiquetas