En el gráfico, el proceso termina con la decisión de si se implementa el cambio o no, de modo que si se decide llevarlo a cabo, ésto disparará los procesos correspondientes en las disciplinas de Requisitos, Análisis y/o Desarrollo.

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ística”/“Mejora”/“Bug”, rellenando el campo Disciplina-Proceso con “Gestión de la Configuración - GC-Controlar los Cambios”:

Además, en la descripción del JIRA introducir la siguiente lista, que servirá de recordatorio de lo que hay que ir rellenando en el JIRA conforme vaya avanzando la petición de cambio:

• Fecha: fecha de la petición de cambio.
• Fuente: persona que ha identificado la necesidad del cambio.
• Autor: persona que ha formalizado la petición de cambio.
• Descripción: en qué consiste el cambio.
• Justificación: describir la necesidad del cambio.

En este punto, es donde la petición de cambio recibe la primera valoración por el 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.

El Jefe de Proyecto crea una subtarea sobre el jira de la Petición de Cambio, y la asigna a un Analista, para que este último calcule el coste y el impacto de implementar la petición de cambio.

El Analista debe indicar la siguiente información en el JIRA correspondiente a la Petición de Cambio en cuestión:

• 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.
• Versión: versión del producto en la que se espera incluir la resolución de la petición de cambio.

Esta tarea es opcional

Una petición de cambio puede suponer desde un pequeño cambio en un artefacto, hasta un cambio en los requisitos, o incluso la aparición de nuevos requisitos, incluso cambios en la arquitectura y/o el diseño, por lo que si el cambio es importante o el Jefe de Proyecto lo estima conveniente, un Analista creará un documento de Petición de Cambio que refleje con detalle el coste y el impacto en el resto del Proyecto de la posible implementación del citado cambio.

En base al informe del Analista, 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:

• 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.

La aprobación de la petición de cambio probablemente implique la necesidad de actualizar el Documento de Requisitos, o incluso el de Análisis y/o Diseño, junto con las matrices de trazabilidad que existan (recuerda que es fundamental indicar el código del JIRA en los “commit” que se hagan al repositorio SVN).

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

• NOTAS:
  • XXX: Código del proyecto.
  • 1.2.3: Número de version del documento.

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 la tarea 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.