Controles de cambio

Este tipo de solicitudes son aquellas que se presentan bajo las siguientes circunstancias:

• Mejoras sobre algún modulo de un aplicativo existente.
• Corrección de errores que se presenten en un aplicativo existente.

Estos casos se podrían presentar en ambientes productivos o en proyectos que estén cerrados y pueden ser registrados por cualquier persona ( STAKEHOLDERS ) que tenga algún interés en un determinado proyecto.

Warning:

Es necesario que el STAKEHOLDER complete todos los campos obligatorios que se piden.

Software estándar a utilizar

El levantamiento de un control de cambio se realiza a través del Mantis.

Etiquetas

Warning:

Es importante mencionar que NO se deben crear etiquetas nuevas, si no trabajar con las etiquetas existentes

Warning:

Es importante que le indiquemos las siguientes etiquetas en el campo de la solicitud: Adjuntar Etiquetas * Control de Cambio. * Error/Bug o Mejora. * Empresa a la que pertenece la solicitud.

Warning:

Es importante mencionar que SOLO se debe seleccionar un tipo de control de cambio que determine si es un Error/Bug o Mejora para un cliente. En el caso de que el tipo de control de cambio sea Error/Bug y Mejora para el mismo cliente, se tendrán que generar solicitudes por separado.

Descripción

Warning:

Es necesario que se especifique de forma muy detallada la descripción del control de cambio que se esta solicitando.

Pasos para reproducir/a ejecutar

Warning:

En el caso se que el tipo de solicitud sea Error/Bug se deberá documentar los pasos a reproducir enumerados y añadir las evidencias a la solicitud

Mejora

Warning:

En el caso se que el tipo de solicitud sea Mejora se deberá documentar las historias de usuario a la solicitud.

Flujo de proceso

En esta sección se describe el flujo de proceso por el cual deberá pasar el control de cambio registrado, que es el que se describe a continuación:

Revisión de la solicitud (Ticket):

    El Gestor de proyectos realiza una revisión de toda la información contenida en el Ticket.
    
    Si considera que la información proporcionada es insuficiente:
    a. Cambiara el estado del Ticket a SE NECESITAN MAS DATOS en el Mantis.
    b. Añadirá una nota etiquetando al STAKEHOLDER que registro el Ticket, para indicarle el detalle de la información que hace falta.
    
    En caso contrario a lo descrito anteriormente:
    a. Cambiara el estado del Ticket a ACEPTADO o asignara el Ticket a un Desarrollador en el Mantis.

Warning:

Si el estado del Ticket es ACEPTADO, solo quiere decir que el Gestor de proyectos ya lo recibió y valido la información contenida en el Ticket.

Warning:

Es posible que el Gestor de proyectos pueda contactar al STAKEHOLDER para solicitar información adicional a la que se tiene en el Ticket.

Implementación de la solicitud (Ticket):

    La implementación de una solicitud puede ser atendida como se describe a continuación:
    
    Desarrollador:
    Esta implementación puede ser por Auto asignación del Desarrollador en el Mantis bajo las siguientes condiciones:
    
    a. No se tiene carga de trabajo por el termino de un Sprint para un proyecto.
    b. Conocimiento del aplicativo bajo el cual fue registrada la solicitud.
    c. Aprendizaje de nuevas tecnologías relacionadas con la solicitud registrada.
    
    Asignación directa por medio del Gestor de proyectos:
    a. Se realiza la asignación de la solicitud a un determinado Desarrollador.
    

Análisis de la solicitud (Ticket):

    Una vez que la solicitud fue Auto Asignada o recibió Asignación directa por el Gestor de proyectos al Desarrollador en el Mantis.
    
    El Desarrollador procederá a realizar lo que se describe a continuación:
    a. Documentar el campo Descripción técnica en el Mantis, previo análisis del control de cambio solicitado el cual seria identificar los
       artefactos que van a sufrir cambios tanto a nivel de código como de base de datos.
    b. Recurrir al Gestor de proyectos cuando se detecte, que el requerimiento solicitado implica cambios a otros artefactos que no sean
       los que el Desarrollador vaya a cambiar, para asignar a otro recurso que atenderá dichos cambios a los artefactos. El recurso asignado
       deberá incluir en el mismo campo Descripción técnica en el Mantis, previo análisis de los artefactos que van a sufrir cambios.
    c. Documentar en el campo Tiempo estimado los tiempos que se van a utilizar para la solución del control de cambio, incluyendo en estos
       tiempos las Pruebas Unitarias y Pruebas de Integración.
    d. El Gestor de proyectos solicitara al área de QA que documente el tiempo estimado de pruebas de QA.

Warning:

Es importante mencionar que si el requerimiento implica cambios a otros artefactos que no sean los que el Desarrollador vaya a cambiar, la responsabilidad del Ticket es del Desarrollador asignado.

Warning:

Es importante mencionar que si existen otras solicitudes de controles de cambio que tengan que ver con la solicitud de cambio actual, se relacionen mediante el apartado Relaciones de Mantis.

Aprobación de la solicitud (Ticket):

    Una vez que se tiene la información en los campos Descripción técnica y Tiempo estimado, el Gestor de proyectos solicita la
    aprobación del control de cambio a la Directiva para su resolución.
    
    La Directiva revisa la solicitud del control de cambio en el Mantis para aprobar o no el control de cambio.

Warning:

Una solicitud de control de cambio es APROBADA cuando aparece en el campo Aprobado la palabra SI.

Resolución de la solicitud (Ticket):

    Una vez que la solicitud del control de cambio a sido APROBADA, el Desarrollador procederá a realizar lo que se describe a continuación:
    a. Realizar los cambios a los artefactos.
    b. Una vez que haya terminado los cambios a los artefactos, realizara el proceso de las Pruebas Unitarias y Pruebas de Integración
       a través del TestLink.
    c. Una vez que el proceso de las Pruebas Unitarias y Pruebas de Integración sea correcto, el Desarrollador, procederá al despliegue
       de los cambios a los artefactos al ambiente de QA.
    e. El Desarrollador cambiara el estatus de la solicitud de control de cambio a RESUELTO en el Mantis.
    f. El Desarrollador añadirá una nota al Ticket, indicando al QA Manager la siguiente información:
    
       Atención a QA Manager
       
       Por favor apoyarnos con las pruebas del presente control de cambio.
       Las rutas de Pruebas Unitarias se encuentran en el repositorio en esta ruta (Ruta repositorio)
       Y las rutas del TestLink se encuentran en esta ruta (Ruta TestLink).
       La información para las pruebas es la siguiente:
       * Url del aplicativo
       * Usuarios de prueba
       * Contraseñas
       

Pruebas QA:

    Una vez que el estatus de la solicitud de control de cambio sea RESUELTO, QA procederá a realizar lo que se describe a continuación:
    a. Validar que tiene la información completa de las Pruebas Unitarias y que pueda acceder al ambiente, con toda la información para las
       pruebas.
    b. Si al final del proceso de las pruebas no existieran incidencias, QA va a colocar en la solicitud (Ticket) con el Vo.Bo con el
       siguiente formato:
       
       Se valido el presente control de cambio con todos los escenarios exitosos, se da el Vo.Bo de QA
       
    c. El Gestor de Proyectos procede a cerrar la solicitud (Ticket).
    
    
    d. En caso contrario a lo descrito anteriormente, QA registrara solicitudes (Tickets) en Mantis con las Etiquetas:
       * Incidencias QA.
       * Empresa a la que pertenece la solicitud.
    e. QA relacionara en el control de cambio inicial las incidencias, las solicitudes (Tickets) que genero por incidencia.
    f. QA cerrara los tickets por incidencias una vez que estén resueltas.
    g. El Gestor de Proyectos procede a cerrar la solicitud (Ticket).     
       

Warning:

QA debe establecer los limites de sus pruebas, dentro del tiempo inicial que se estimo.