Controles de cambio ( CC )
Revisión del 22:53 13 mar 2019 de Rsilva (discusión | contribuciones)
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.
Sumario
Software estándar a utilizar
El levantamiento de un CC se realiza a través del Mantis.
Flujo de proceso
En esta sección se describe el flujo de proceso por el cual deberá pasar el CC que es el que se describe a continuación:
Alta de la solicitud
Para realizar el levantamiento una solicitud de CC, es necesario registrarlo a través del Mantis.
Campos estándar de CC
 Warning: | Es necesario que el STAKEHOLDER complete todos los campos normales y obligatorios que se piden. |
Categoría
Seleccione del listado la opción que mas se adecue a su solicitud de CC.
Reproducibilidad
Seleccione del listado la opción que mas se adecue a su solicitud de CC.
Severidad
Seleccione del listado la opción que mas se adecue a su solicitud de CC.
Prioridad
Seleccione del listado la opción que mas se adecue a su solicitud de CC.
Seleccionar perfil
Seleccione del listado la opción que mas se adecue a su solicitud de CC.
Versión del producto
Seleccione del listado la opción que mas se adecue a su solicitud de CC.
Asignar a
Si la solicitud de CC se va asignar algún recurso, seleccione el identificador del Desarrollador.
Resumen
Proporcione información de lo descrito en el campo Descripción la cual deberá ser breve y detallada.
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 |
Información adicional
Utilice este campo para describir información adicional a la que se proporciono, la cual servirá para tener un entendimiento de lo que se esta solicitando en la solicitud de CC.
Adjuntar Etiquetas
El llenado de este campo facilita la gestión, seguimiento y generación de reportes de los Tickets.
| 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. |
Ambiente
Seleccione del listado la opción que mas se adecue a su solicitud de CC.
Subir archivos
Incluir información de acuerdo a las siguientes condiciones:
* Si el tipo de solicitud de CC es Mejora : Historias de usuario. * Si el tipo de solicitud de CC es Error/Bug : Evidencias de la incidencia ocurrida.
Adicionalmente a lo descrito anteriormente, se deberán incluir archivos con información relevante a la solicitud de CC.
Flujo de proceso
En esta sección se describe el flujo de proceso por el cual deberá pasar el CC 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. No quiere decir que el Ticket ya esta siendo atendido. |
| 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. |
Asignación de la solicitud (Ticket):
La asignación de una solicitud de CC puede ser realizada por:
Desarrollador:
Se define ( Auto asignación ). Lo que se busca con esto es fomentar la iniciativa del Desarrollador, su capacidad de Auto gestión
y de Autorganizacion. Es importante que el Desarrollador antes de asignarse una solicitud (Ticket) considere las siguientes condiciones:
a. No tener actividades mapeadas en un Sprint o Cronograma activo de mayor relevancia o prioridad.
b. Que se tenga conocimiento del aplicativo bajo el cual fue registrada la solicitud, en caso de que sean solicitudes de CC de prioridad
Alta. Esto para evitar que exista desviación de tiempo por desconocimiento de la plataforma.
Si son solicitudes de CC de prioridad Normal o Baja, el Desarrollador puede asignarse la solicitud (Ticket) aunque no
tenga conocimiento del proyecto, para este caso sera necesario que el Desarrollador valide con el Gestor o Coordinador de
proyectos si puede tomar esta actividad.
Gestor de proyectos/Coordinador de proyectos:
a. Esta asignación se hace directamente por cualquiera de los roles antes mencionados y se realiza de acuerdo a la prioridad que tenga el
Ticket.
Análisis de la solicitud (Ticket):
Una vez que la solicitud fue Auto Asignada o recibió Asignación directa por el Gestor o el Coordinador 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, realizando un previo análisis de los artefactos que van a sufrir cambios.
Es necesario que liste los artefactos como pueden ser:
* Clases
* Métodos
* Base de datos:
* Procedimientos
* Tablas
* Vistas
* Funciones
Que van a ser modificados a nivel de código fuente.
b. Recurrir al Gestor o Coordinador de proyectos, cuando implique cambios a otras áreas de desarrollo (Web Service, Back Office,
etc). A fin de que el Gestor o Coordinador de proyectos pueda asignar a quien pueda atenderlo.
c. Documentar en el campo Tiempo estimado los tiempos que se van a utilizar para la solución del CC, incluyendo en estos tiempos:
* Tiempo de Desarrollo de áreas involucradas.
* Pruebas Unitarias.
* Pruebas de Integración.
d. El área de QA debe documentar en el campo Tiempo estimado, sus tiempos de pruebas a realizar de acuerdo a la información,
que se tenga en la solicitud de CC. Si este campo no esta documentado, el Gestor de proyectos solicitara al área de QA que
documente sus tiempos estimados de pruebas de QA.
| Warning: | Las pruebas unitarias deben contemplar el tiempo de diseño y ejecución en el TestLink. |
| 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):
| Warning: | Una solicitud de control de cambio es APROBADA cuando aparece en el campo Aprobado la palabra SI: |
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 aprobarlo o no.
Resolución de la solicitud (Ticket):
Una vez que la solicitud del control de cambio ha sido APROBADA, el Desarrollador procederá a realizar lo que se describe a
continuación:
a. Llevar a cabo la implementación de la solución del CC, de acuerdo a la información registrada en el campo Descripción.
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. Generara el reporte de Pruebas Unitarias en formato de archivo PDF y lo incluirá en el repositorio de
Telstock en la ubicación que corresponda al proyecto.
d. 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. Una vez que el ambiente de QA este totalmente listo, el Desarrollador cambiara el estatus de la solicitud de CC a RESUELTA
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
* Versión del APK (Si aplica) que se esta liberando
Validación de solicitud (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. Ejecutar los escenarios de prueba considerando el tiempo estimado que se coloco en la solicitud.
c. Si al ejecutar los escenarios de prueba existen incidencias relacionadas al control de cambio entonces:
1. QA registrara en Mantis las incidencias con las siguientes Etiquetas:
Incidencias QA.
Empresa a la que pertenece la solicitud.
2. QA relacionara el Ticket de la incidencia a la solicitud de CC inicial.
3. El Desarrollador corrige las incidencias de acuerdo a lo considerado en el apartado: Resolución de la solicitud (Ticket)
descrito anteriormente.
4. QA valida la corrección de las incidencias y cierra aquellas que estén resueltas y reasigna las que aun no estén.
b. Si al final de la ejecución de los escenarios de prueba no existe ninguna incidencia, QA coloca como nota en la solicitud (Ticket) el
Vo.Bo en el siguiente formato:
Se valido el presente control de cambio con todos los escenarios exitosos, se da el Vo.Bo de QA
Agregar la siguiente información:
* Ruta de deposito en donde esta la matriz de pruebas.
* Ruta de deposito en donde esta el reporte de pruebas.
c. 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. |
| Warning: | La gestión por parte del Desarrollador debe ser similar a un Ticket de control de cambio normal, la única diferencia es que no se va a solicitar aprobación para estos Tickets. Únicamente pueden ser asignados por el QA Manager. |
