Tarea: Revisar solicitudes de cambio
En esta tarea se define cómo realizar la priorización de las solicitudes de cambio.
Disciplinas: Configuración y Gestión de cambios
Objetivo
  • El objetivo de esta tarea es determinar si la solicitud de cambio (CR) se debe aceptar o si se debe etiquetar como rechazada. Para las CR aceptadas, esta tarea valora la prioridad, el esfuerzo, la planificación, etc., para determinar si el cambio está en el ámbito del release actual.
Relaciones
Pasos
Planificar la reunión de revisión del CCB

El Comité de control de cambios (o configuración) es el comité que supervisa el proceso de cambio consistente en representantes de todas las partes interesadas, incluidos los clientes, los desarrolladores y los usuarios. En un proyecto más pequeño, una única persona, como el gestor de proyectos o el arquitecto de software, puede desempeñar este rol. En Rational Unified Process, esto lo muestra el rol de Gestor de control de cambios.

La función de esta reunión es revisar las solicitudes de cambio enviadas. En la reunión, se realiza una revisión inicial del contenido de la CR para determinar si se trata de una solicitud válida. Si es así, se determina si el cambio está dentro o fuera del ámbito del release actual, en función de la prioridad, la planificación, los recursos, el nivel de esfuerzo, el riesgo, la gravedad y otros criterios relevantes que determine el grupo. Esta reunión suele tener lugar una vez por semana. Si el volumen de la CR aumenta sustancialmente, o cuando se está llegando al final de un ciclo de release, la reunión puede tener lugar incluso diariamente. Los miembros típicos de la reunión de revisión del CCB son el gestor de prueba, el gestor de desarrollo y un miembro del departamento de marketing. Puede que los miembros consideren necesarios asistentes adicionales "según convenga".

Recuperar solicitudes de cambio para su revisión

El formulario de solicitud de cambio es un producto de trabajo enviado formalmente que se utiliza para rastrear todas las solicitudes, incluidas las nuevas características, las solicitudes de mejora, los defectos, los requisitos modificados, etc. Esto incluye la información de estado relacionada de todo el ciclo vital del proyecto. El historial de cambios se mantendrá junto con la CR, incluidos todos los cambios de estado, y las fechas y los motivos de dicho cambio. Esta información estará disponible para las revisiones repetidas y para el cierre final. En Producto de trabajo: Solicitudes de cambio se incluye un formulario de solicitud de cambio de ejemplo.

Revisar las solicitudes de cambio enviadas

La función de esta tarea es revisar las solicitudes de cambio enviadas. Este estado se produce como resultado de 1) un nuevo envío de CR, 2) la actualización de una CR existente o 3) la consideración de una CR pospuesta para un ciclo de release nuevo. La CR se coloca en la cola de revisión de CCB. Esta acción no tiene como resultado ninguna asignación de propietario.

En la reunión del CCB, se realiza una revisión inicial del contenido de la CR para determinar si se trata de una solicitud válida. Si es así, se determina si el cambio está dentro o fuera del ámbito del release actual, en función de la prioridad, la planificación, los recursos, el nivel de esfuerzo, el riesgo, la gravedad y otros criterios relevantes que determine el grupo.

Si se determina que la CR es válida, pero está "fuera del ámbito" del release actual, se colocará en el estado pospuesto y se mantendrá y reconsiderará para próximos releases. Se puede asignar un release de destino para indicar el marco horario en que se debe enviar la CR para que vuelva a la cola de revisión de CCB.

Si se considera que una CR es un duplicado de otra CR que ya se ha enviado, se debe asignar al administrador de revisión del CCB o al miembro del equipo asignado para resolverla. Cuando la CR se coloca en estado Duplicada, se registra el número de la CR original (en la pestaña Archivos de datos adjuntos de ClearQuest). Inicialmente, un emisor debe consultar en la base de datos de CR si una CR determinada tiene duplicados antes de enviarla. Esta operación evitará varios pasos del proceso de revisión y, por lo tanto, nos ahorrará un montón de tiempo. Los emisores de CR duplicadas deben añadirse a la lista de notificación de la CR original para futuras notificaciones relacionadas con la resolución.

A veces, un revisor del CCB o un miembro asignado del equipo determinan que una CR no es válida o que es necesaria más información del emisor. Si ya está asignada (Abierto), la CR se elimina de la cola de resolución y se vuelve a revisar. Una autoridad designada del CCB se asigna para la confirmación. No es necesario que el emisor realice ninguna acción, a no ser que lo considere necesario; en ese caso, el estado de la CR se cambiará a Más información. La CR volverá a revisarse en la reunión de revisión del CCB teniendo en cuenta cualquier información nueva. Si se confirma que no es válida, el CCB cerrará la CR y notificará al emisor.

Cuando se ha determinado que una CR se encuentra "en el ámbito" del release actual, se asigna a un estado Abierto en espera de una resolución. Se resolverá antes que un objetivo de destino próximo. Se define como perteneciente a la "cola de asignación". Los miembros de la reunión son la única autoridad que puede abrir una CR en la cola de resolución. Si se detecta una CR de prioridad dos o superior, debería avisarse inmediatamente al gestor del proyecto o al QE. En este punto, puede decidir convocar una reunión de revisión del CCB urgente o limitarse a abrir la CR en la cola de resolución inmediatamente.

Una CR abierta es responsabilidad del gestor de proyectos, que debe asignar el trabajo en función del tipo de CR y actualizar la planificación, si es apropiado.

Los estados típicos que puede pasar una solicitud de cambio se muestran en Gestión de solicitudes de cambio.



Más información