Controles de cambio
Revisión del 00:19 7 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.
 Warning: | Es necesario que el STAKEHOLDER complete todos los campos obligatorios que se piden. |
Sumario
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.
Resolución 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, se procederá a lo que se describe a continuación:
