Workflow de proceso de cambios ITSM

Workflow de proceso de cambios ITSM

Selecciona un estado para visualizar el detalle

The approval request has been confirmed

UAT's approval has been granted

Backlog

En este estado, se crea una HU con sus criterios de aceptación.

Una HU es una explicación informal y general de una funcionalidad de software escrita desde la perspectiva del usuario final.

Historia de Usuario

Estructura recomendada para una Historia de Usuario

Como un <Rol>, Yo quiero <Necesidad>,Para <Propósito> <Criterios de Aceptación>

Backlog

En los equipos donde existe Product Team, este es el encargado de revisar y priorizar la HU.En los equipos sin Product Team, la HU la revisa el especialista asignado y la debe priorizar el Squad Coordinator.La HU estará lista para dejar el estado Backlog cuando esté priorizada.

Transiciones EstándarUna vez priorizada la HU debe transicionar del estado Backlog a Selected for Development.Una HU en cualquier otro estado puede devolverse al estado Backlog.

En este estado, se crea una HU con sus criterios de aceptación.

Selected For Development

La HU se coloca en este estado cuando se han dado las condiciones mínimas para dejar el backlog y ser seleccionadas por el equipo para su desarrollo.

G1

Las condiciones mínimas son que la HU esté priorizada, se pueda estimar, se valide que sea lo suficientemente pequeña para generar valor y sus criterios de aceptación sean claros.

AprobacionesEl G1 es un control que genera el Product Team, donde se confirma la aprobación solicitada.

Transiciones con RestricciónEl Product Owner dentro del Product Team es el único rol que debe transicionar una HU del estado Backlog a Selected for Development cumpliendo con el G1.En los equipos sin Product Team, esta restricción no existe.

Analysis

Las HU que han sido seleccionadas para el desarrollo pasan por un proceso de análisis detallado.

Transiciones EstándarLa HU debe transicionar al estado Analysis si proviene del estado Selected for Development.Las HU pueden devolverse al estado Analysis desde cualquier otro estado dentro del flujo.

Build

En esta etapa el objetivo es construir la funcionalidad de acuerdo con la solicitud generada y los criterios de aceptación.

ConsideracionesEstados opcionales y considerados también como Build para LATAM

• Done Dev: Estado que se puede utilizar para indicar que el desarrollo de software ha terminado y pasa al Especialista Funcional.

Estados adicionales y considerados también como Build para NA

• Configuration

Transiciones EstándarUna HU en estado Analysis debe transicionar a Build.Una HU en cualquier otro estado puede devolverse al estado Build.

SIT

En este estado el equipo de desarrollo ejecuta las pruebas unitarias y de integración de la solución propuesta para la HU.

Transiciones EstándarUna HU en estado Build debe transicionar a SIT.Una HU en cualquier otro estado puede devolverse al estado SIT.

ConsideracionesEstados adicionales y considerados también como SIT para NA

• SIT Done

UAT

Es la etapa de Testing, donde el usuario realiza las UAT (Pruebas de Aceptación de Usuario), luego de recibir la implementación por parte del equipo técnico, confirmando el cumplimiento de los Criterios de Aceptación.

Transiciones EstándarUna HU en estado SIT debe transicionar a UAT.Si la UAT no es exitosa, la HU en estado UAT puede devolverse al estado Analysis o Build.Una HU en cualquier otro estado puede devolverse al estado UAT.

ConsideracionesEl Product Team es responsable de coordinar o ejecutar las pruebas definidas para la HU.Para los equipos sin Product Team, el End User es quién debe realizar las pruebas UAT.

Ready to Deploy

El equipo técnico se asegura de cumplir con los requisitos previos al despliegue de la funcionalidad.

G2

Nota: Los cambios con impacto en la disponibilidad de servicios a nivel regional también deben ser reportados en la Reunión de la Ventana de Mantenimiento de las Américas (CAB).

Transiciones con RestricciónLa HU solamente debe transicionar al estado Ready to Deploy si el estado anterior es UAT, generando el control G2 para los equipos que cuentan con proceso de cambios ágiles.Para los equipos sin Product Team, cualquier miembro del equipo puede pasar la HU del estado UAT a Ready to Deploy.

AprobacionesEl G2 es un control que se genera cuando la UAT es aprobada y el requerimiento está listo para pasar a productivo, y cuenta con todas las aprobaciones de Servicenow.

Ready to Deploy

El equipo técnico se asegura de cumplir con los requisitos previos al despliegue de la funcionalidad.

Nota: Los cambios con impacto en la disponibilidad de servicios a nivel regional también deben ser reportados en la Reunión de la Ventana de Mantenimiento de las Américas (CAB).

Para todos los equipos se debe verificar si el cambio requiere aprobación del CAB:

• Cambios relacionados con proyectos o mejoras
• Hay un impacto de disponibilidad confirmado o de alcance global con alto riesgo e impacto
• Hay un número o grupo importante de usuarios o servicios (infraestructura/aplicaciones) afectados
• Existen dudas/preocupaciones sobre el cambio que se va a implementar o que requiere validación o información adicional para las partes interesadas.
• Cambios que modifican la aplicación Y los procesos de negocio (Cambios que requerirían comunicación para ser enviados, nuevos lanzamientos de aplicaciones que necesitarán capacitación, comunicación, modelo de soporte)
• Cambio relacionado con permitir el acceso a datos críticos o sensibles.
• Cuando es solicitado por el Analista de Cambios/Implementador y el cambio cumple con los requisitos (está listo para la Aprobación G2)
• Por Change Manager /ITSM Decisión

Bussiness Confirmation

El Product Team confirma que la solución desplegada se encuentra funcionando de acuerdo con lo solicitado y no se afecta la estabilidad en productivo.

ConsideracionesUna vez el release se haya desplegado en productivo, el equipo técnico debe confirmar con el End User si fue exitoso, para que el Especialista Funcional pueda realizar esta transición en JIRA.

Transiciones con RestricciónLa HU debe transicionar al estado Bussiness Confirmation si el estado anterior es Ready to Deploy.

Done

El Product Team o End User confirma que todas las actividades asociadas a la HU solicitada se completaron de manera exitosa.

Transiciones con RestricciónLa HU debe transicionar al estado Done si el estado anterior es Bussines Confirmation.Para los equipos sin Product Team, el End User es quién debe confirmar para que el Squad Coordinator o Stream Lead pueda realizar esta transición en JIRA.

Cancelled

ConsideracionesCualquier rol que esté asociado a la HU puede realizar esta transición.Anexar soporte que justifique la cancelación de la HU.

Transición EstándarUna HU puede pasar al estado Cancelled desde cualquier etapa durante el proceso de atención de la HU.

En este estado quedaría la HU luego de que se decide no continuar su desarrollo.

Waiting

Cualquier rol puede realizar esta transición, en cualquier momento.

Transición EstándarUna HU puede pasar al estado Waiting desde cualquier etapa durante el proceso de atención de la HU.Estados opcionales y considerados también como Waiting para LATAM:

• Waiting Bussines: Dependencia con el negocio
• Waiting Tech: Dependencia con algún equipo ADC
• Waiting Freez Period
• Waiting Vendor
• Waiting ABAP

Estados adicionales y considerados también como Waiting para NA:

• Waiting Security
• Waiting I&O

En este estado quedaría la HU si se encuentra con alguna dependencia que la bloquee.