Establecer el flujo del proceso de validación de una mejora o una incidencia antes de su despliegue en un entorno productivo.
Este proceso aplica a los productos de tipo aplicación que se gestionan en JIRA.
Los roles que intervienen en este proceso son
Rol | Descripción |
---|---|
Responsable de producto | Es el máximo responsable del producto desde el punto de vista de su gestión. |
Responsable funcional | Es el responsable de la evolución del producto, indicando lo que tiene o no valor para el mismo. |
Proveedor | Responsable de acometer los desarrollos de los evolutivos de los productos y de corregir las posibles incidencias |
Oficina Técnica de Calidad (OCA) | Responsable de hacer la validación funcional de la entregas |
Una vez que el proveedor desarrolla las mejoras que constituyen el alcance de una versión, es necesario que sean validadas normalmente por el Responsable Funcional/Responsable de producto de la aplicación.
Si en la validación se encuentran incidencias, al tratarse de entornos no productivos, no pueden ser consideradas incidencias como tale, por lo que deben ser consideradas no conformidades. Pueden ser de tipo funcional, técnica o de regresión. En los dos primeros casos, siempre debe haber una mejora o incidencia que las origine, mientras que en el tercer caso no es neceario.
Cuando se detecta una no conformidad no podrá validarse la mejora/incidencia afectada hasta que:
Cuando se detecta una no conformidad, hay que indicar la entrega en la que se detecta y las o las mejoras/incidencias a las que afecta en el caso de ser de tipo funcional o técnica. Cuando el proveedor del aplicativo la comienza a corregir, el estado para validación de la misma de Identificada a En desarrollo y a Pdte. validar una vez que esté corregida, indicando la entrega en la que se corrige. En ese momento, podrá ser validada por el Responsable Funcional o el Responsable de Producto:
Es posible que se detecte una no conformidad que no sea tal, y que tras ser analizada se llegue a la conclusión de que realmente no lo sea y que se trate de una mejora o de una incidencia. En el caso de que sea una mejora, podría convertirse en una entidad de ese tipo en el mismo estado en el que estuviera la no conformidad origen. Para ello será necesario indicar la urgencia de la futura mejora y explicar el o los motivos que llevan a este cambio.
Si la no conformidad por el contrario se decide que es una incidencia, se cerrará directamente para poder registrar la incidencia por los canales reglamentarios.
Para acceder al manual de JIRA en el que se detalla el flujo de mejoras, incidencias y no conformidades, pincha aquí.