Las peticiones de cambio suelen venir de clientes y usuarios cuando éstos se plantean nuevas necesidades, pero también pueden venir del equipo de desarrollo con el fin mejorar la calidad del producto o por la detección de un bug o por dificultades técnicas no previstas.

Si finalmente se decide implementar el cambio propuesto, puede suponer desde un pequeño cambio en un artefacto, hasta un cambio en los requisitos, o incluso la aparición de nuevos requisitos, pudiendo llegar a afectar a la arquitectura y/o el diseño del proyecto.

El objetivo del proceso de Control de Cambios es registrar cada petición de cambio y su ciclo de vida, y mantener informado al solicitante de la evolución del mismo:

• Registrando la Petición de Cambio.
• Evaluando la propuesta de cambio (si se rechaza el proceso termina aquí).
• Valorando el coste y el impacto de su posible implementación.
• Y finalmente decidiendo si se lleva a cabo o no, cuando y en qué versión del producto.

Los siguientes son los roles participantes en este proceso:

El Jefe de Proyecto crea un JIRA para registrar la petición de cambio, del tipo Nueva característic, Mejora o Bug, rellenando el campo Disciplina-Proceso con “Gestión de la Configuración - GC-Controlar los Cambios”:

La información que aparece en la descripción del JIRA se irá introduciendo según vaya avanzando el ciclo de vida de la petición del cambio.

En este punto, es donde la petición de cambio recibe la primera valoración por parte del Jefe de Proyecto (o el Comité de Control de Cambios, si existe). Si se rechaza, el Jefe de Proyecto lo hará constar en la petición y el trámite se dará por concluido.

Hay que indicar el resultado de esta primera valoración en el JIRA correspondiente a la Petición de Cambio, modificando el estado del jira mediante la opción “Flujo de Trabajo”, e indicando:

• Parada: si la Petición de Cambio se deja en espera.
• Anulada: si la Petición de Cambio es rechazada por el Jefe de Proyecto.

Si no se anula, es posible que ya se pueda dar un valor inicial a la prioridad de la Petición de Cambio, en cuyo caso se usará el campo “Prioridad” del jira.

El Jefe de Proyecto gestionará un conjunto de peticiones de cambio como si de un Sprint se tratase, ejecutando la tarea de Planificación de Sprint (del proceso Planificar Proyecto en la disciplina Gestión de Proyecto), y tratando cada petición de cambio como si fuese una historia, de forma que como resultado de la tarea anterior (de “Planificación de Cambios”) se crearán las subtareas necesarias (de Desarrollo) para implementar cada petición de cambio. En este caso cada jira de Petición de Cambio hará las veces de Historia.

En algunos casos el impacto de la petición de cambio puede ser grande e implicar no sólo codificación, sino definición de requisitos, análisis y/o diseño. En esos casos revisitaremos las disciplinas y procesos de MEDEA necesarios. Los jiras que surjan como consecuencia de la ejecución de los procesos de las disciplinas de requisitos y análisis o diseño deben relacionarse con el jira original de la petición del cambio, el bug, la mejora o la nueva funcionalidad. Para relacionarlos utilizaremos un Link del tipo se relaciona con entre los jiras de las disciplinas y el jira de la petición de cambio. Para cada tarea que se ponga en la “Planificación de Cambios”, hay que poner el label “CAMBIO” a todos los jiras que se generen, para mantener la trazabilidad.

Conforme se vaya definiendo el Alcance/Coste/Impacto de la Petición de Cambio, el Jefe de Proyecto debe indicar la siguiente información en el JIRA correspondiente a la Petición de Cambio en cuestión (mediante comentarios):

• Impacto directo: elementos afectados directamente organizados por categoría, por ejemplo artefactos (clases java, tablas de BD, etc), requisitos (funcionales, no funcionales, historias), arquitectura/diseño, etc.
• Esfuerzo: estimación del esfuerzo requerido (hay un campo en JIRA para ésto).
• Alternativas: descripción de otras posibles alternativas para abordar el cambio, si las hay.
• Consecuencias del rechazo: descripción de las consecuencias de rechazar el cambio.
• Prioridad (hay un campo en JIRA para ésto).
• Versión: (hay un campo en Jira para esto). versión del producto en la que se espera incluir la resolución de la petición de cambio.

Finalmente el CCB (Comité de Control de Cambios) o el Jefe de Proyecto decidirán si se llevará a cabo el cambio, y en tal caso cuando (en qué release).

El Jefe de Proyecto hará constar la decisión del CCB en el JIRA correspondiente a la Petición de Cambio (mediante un comentario):

• Estado: aprobada/rechazada/pospuesta (JIRA tiene un campo para ésto).
• Fecha: fecha en la que se tomó la decisión.
• Versión: versión del producto en la que se espera la resolución de la petición de cambio.
• Motivo del rechazo: descripción del motivo de rechazo.

Hay que indicar el resultado de esta valoración en el JIRA correspondiente a la Petición de Cambio, modificando el estado del jira mediante la opción “Flujo de Trabajo”, e indicando:

• Parada: si la Petición de Cambio se deja pospuesta.
• Anulada: si la Petición de Cambio es rechazada.

Puedes incluir en el campo comentarios del Jira la siguiente información e ir rellenándola cuando corresponda.

h4.Evaluación
* Impacto directo:
* Esfuerzo:
* Alternativas:
* Consecuencias del rechazo: 
* Prioridad:
* Versión:
h4.Estimacion
* Estado:
* Fecha:
* Motivo rechazo:
* Version:

Se irán creando subtareas bajo el jira de la Petición de Cambio, para cada tarea de Desarrollo (implementación) que se genere como consecuencia de la petición de cambio (una vez hecha la “reunión de planificación de sprint de cambios”).

La Petición de Cambio NO se cerrará hasta que el citado cambio haya sido implementado, testeado e incluido en una release .

Además del Tiempo Dedicado al Proceso (ver más abajo), el resto de métricas sobre las Peticiones de Cambios se pueden ver en el proceso Contabilidad del Proyecto. Y de todas ellas, las más importantes son el nº de peticiones de cambio (PC) (desglosado por tipo) y el tiempo total invertido en resolver dichas PCs (desglosado también por tipos).

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = CFG-Control Cambios

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.