Proceso: Estimación e incurridos en mejoras

Objetivo

Gestionar de forma eficaz las estimaciones y los incurridos en cada mejora.

Alcance

Aplica a todos las mejoras de todos los productos de la DGSIC. No implica obligatoriedad ninguna, es decir, si el Responsable de producto no cree conveniente estimar e incurrir en mejoras, puede seguir con el ciclo de vida habitual.

Roles y responsabilidades

• Responsable de producto: Encargado de apobar la estimación de las previsiones y los incurridos de estas
• Proveedor: Encargado de crear, estimar las previsiones e incurrir en estas.

Ciclo de vida de la mejora

Las mejoras se crean en estado WISHLIST tanto por integración como directamente en Jira (El campo Entrada es G. Proyectos).

Las creadas por integración pueden venir de:

• Creación por ayudaDIGITAL (El campo Entrada es G. Proyectos)
• Como consecuencia de la resolución de un problema (El campo Entrada es G. Proyectos)

Una vez en WISHLIST tanto el Responsabke de producto como el Responsable funcional pueden

• Aprobar la mejora. Si es de integración se cierra en ayudaDIGITAL, informando al usuario que la regsitró que su propuesta tiene sentido y se acometerá. Tanto si es de integración como si no lo es, en Jira  pasa a BACKLOG. 
• No aprobar la mejora:
  • Si es de integración, puede escalarla, ya que puede ser que no se trate de una mejora o que la aplicación en la que se haya registrado no sea la correcta. En ese caso, el registro de JIRA se cierra (con resolución escalada) pero en ayudaDIGITAL permanece abierto. Puede ocurrir que la solicitud se retipifique bien y vuelva a integrarse con JIRA, dando lugar a otro registro.
  • Rechazar la mejora. En JIRA se cierra con resolución Rechazada y en ayudaDIGITAL se cierra también, informando al usuario que la regisdtró de que su propuesta no va a acometerse.

Es al llegar a BACKLOG cuando puede estimarse la mejora. La estimación pude hacerse igualmente con la mejora ya incluida en una versión, es decir, en estado EN VERSION.

Tanto Responsable de producto como Proveedor pueden crear subtareas de la mejora. Se llaman previsiones y se crean por meses naturales.

 Al editar la mejora, aparecen campos que ayudarán a su estimación y que son opcionales:

• Estimación original. Este campo podrá ser informado por el Responsable de producto para tener idea de la estimación de la mejora y poder controlar desviaciones respecto a las estimaciones posteriores de las previsiones.
• Fecha de inicio deseada y Fecha fin deseada: podrán informarlas tanto Responsable de producto como proveedor. Tendrá como ventaja que se crearán automáticamnete una previsión por cada mes comprendido entre ambas fechas, lo que facilitará para mejoras con plazo de ejecución grande, la creación de las prevsiones.

Cuando la mejora se incluye en una versión para su despliegue pasa a estado EN VERSION.

En ese estado, podrán hacerse todas las acciones que se hacen en BACKLOG, estimar mejora, crear previsiones, estimar previsiones, aprobar previsiones, incirrir en previsiones.

Cuando la versión pase a IMPLANTADA, es decir, se haya cerrado la PL correspondiente a la última entrega, la mejora pasará a estado CERRADA con resolución Cerrada.

Ciclo de vida de la previsión

Las previsines se crean en estado PDTE. ESTIMAR asignadas al Proveedor, que estimará pasando a PDTE. APROBAR asignada al Responsable de producto.

El Responsable de producto podrá aprobar o no la estimación. En caso de que no la apruebe, la previsión volverá a PDTE. ESTIMAR para que el proveedor corrija la estimación inicial.

En el caso de que el Responsable de producto la apruebe, la previsión pasará a estado APROBADA asignada al Proveedor. En ese estado, podá incurrir tantas veces como quiera. Cuando acabe de incurrir, pasará la previsión a PDTE. REVISION para que el Responsable de producto revise los incurridos:

• Si los acepta, la previsión pasa a CERRADA
• Si no los acepta, la previsión pasa a NO ACEPTADA teniendo el proveedor que volver a incurrir. Al hacerlo, la previsión volverá a PDTE. REVISION asignada al Responsable de producto.

Con objeto de eliminar los ficheros de incurridos de las OTs, es recomendable al incurrir hacerlo con registros en los que se especifique en el comentario el perfil del incurrido y una breve descripción de lo que hace.