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:
- 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.
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.
- 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/A | N/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/A | N/A |
| VALIDAR | R. PRODUCTOR. FUNCIONALOCA | N/A | N/A |
| EDITAR | R. PRODUCTOR. FUNCIONALOCA | N/A | N/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 |
|
| CLONAR (en cualquier aplicación) | R. PRODUCTOR. FUNCIONALPROVEEDORCOLABORADOR | N/A | N/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/A | N/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/A | N/A |
| VALIDAR | R. PRODUCTOR. FUNCIONALCGES | N/A | N/A |
| EDITAR | R. PRODUCTOR. FUNCIONALOCA | N/A | N/A |
| CIERRE RFC | PROCESO AUTOMATIZADO | EN VERSIÓN a CERRADA | (Sin resolver) a (Cerrada) |
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 por los roles R. PRODUCTO y R. FUNCIONAL. Una Historia de Usuario sólo puede estar relacionada con una mejora.
- 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 | ||
| CANCELAR | R. PRODUCTO R. FUNCIONAL | BACKLOG a CERRADA | (Sin Resolver) a (Cancelada) |
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. PRODUCTOR. FUNCIONALPROVEEDOR | N/A | N/A |
| CREAR ERROR | R. PRODUCTO R. FUNCIONAL PROVEEDOROCA | N/A | N/A |
| EDITAR | R. PRODUCTO R. FUNCIONAL PROVEEDOR OCA | N/A | N/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/A | N/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/A | N/A |
| CREAR ERRORES | OCA R. PRODUCTOR. FUNCIONAL PROVEEDOR | N/A | N/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/A | N/A |
| CIERRE RFC | PROCESO AUTOMATIZADO | VALIDADA a CERRADA | (Sin Resolver) a (Cerrada) |
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 e incluida en un Sprint Activo. Se crean en estado ABIERTA por R. PRODUCTO, R. FUNCIONAL
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/A | N/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 | EN RESOLUCIÓN a CERRADA | (Sin Resolver) a (Cerrada) |
| EDITAR | R. PRODUCTO PROVEEDOR | N/A | N/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/A | N/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/A | N/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/A | N/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 e incluida en un Sprint Activo. Se crean en estado ABIERTA por R. PRODUCTO, R. FUNCIONAL
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/A | N/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 | EN RESOLUCIÓN a CERRADA | (Sin Resolver) a (Cerrada) |
| EDITAR | R. PRODUCTO PROVEEDOR | N/A | N/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/A | N/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/A | N/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/A | N/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
Iniciar sprint en Trabajo pendiente. En nuestro ejemplo, iniciamos el Sprint 1
Al comenzar el SPRINT, podremos mover historias, subtreas y errores por las columnas
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2