Actividades de iteración
En MSF for CMMI Process Improvement v5.0 se puede planear un proyecto como una serie de iteraciones. Cada iteración tiene normalmente una duración de cuatro a seis semanas; durante este período de tiempo el equipo de desarrollo implementa un conjunto especificado de requisitos.
Al principio de una iteración
La planeación de iteraciones tiene lugar al principio de cada una de ellas o con anterioridad a las mismas. Incluye las tareas siguientes:
Revisar los requisitos asignados a la iteración y definirlos con más detalle.
Crear elementos de trabajo de tarea para el trabajo que se debe realizar para implementar y probar cada requisito. Vincule las tareas al elemento de trabajo de requisito utilizando el tipo de vínculo primario.
Establecer el campo Estimación original de cada tarea. Divida las tareas cuyas estimaciones de tiempo sean superiores a unos días.
Comparar las estimaciones con el tiempo disponible para la iteración. Si el tiempo total de la estimación es demasiado prolongado, simplifique algunos requisitos o aplácelos a iteraciones posteriores.
Para obtener más información, vea Planear una iteración (CMMI).
Durante una iteración
Ejecución de tareas
Los miembros del equipo comienzan y completan tareas, registrando estos eventos en elementos de trabajo. La realización de una tarea puede incluir la protección de código de programa y otros artefactos. Cada tarea no debe tener una duración superior a unos días; las tareas con una duración superior se dividen durante la planeación de iteraciones. Para obtener más información, vea Crear, copiar y actualizar los elementos de trabajo y Completar tareas de desarrollo.
Si un miembro del equipo encuentra un obstáculo en su trabajo que no se puede resolver inmediatamente, debe registrar un elemento de trabajo de problema. Para obtener más información, vea Problema (CMMI).
Pruebas
Deben desarrollarse pruebas manuales o automáticas y se deben vincular casos de prueba a los requisitos del producto. No se puede considerar que un requisito de producto está completado hasta que el elemento de trabajo se vincula a casos de prueba superados y que demuestran que está funcionando.
El trabajo de desarrollo de las pruebas se debe incluir en las tareas vinculadas al requisito del producto.
Compilaciones graduales y nocturnas
El sistema de compilación compila el producto a partir de actualizaciones protegidas recientemente y ejecuta pruebas automatizadas. Puede establecer que se ejecuten pruebas principales de forma continua y también puede establecer que se ejecute un conjunto completo todas las noches. Esta práctica ayuda a garantizar que varios incrementos no creen una acumulación de errores. Para obtener más información, vea Administrar Team Foundation Build.
Reunión de debate
El equipo completo realiza una breve revisión diaria del progreso de las tareas de la iteración. Los miembros del equipo pueden proyectar el panel Progreso en la pared, compartirlo utilizando Office Live Meeting, o ambas cosas. Para obtener más información, vea Progreso (Panel de CMMI).
Cada miembro del equipo informa brevemente del progreso reciente, del trabajo asignado para el día y de los problemas de bloqueo.
El jefe de proyecto o el coordinador del equipo informa del progreso en la resolución de problemas. Para obtener más información, vea Administrar problemas (CMMI).
Se revisa el número de errores. Los errores deben tener prioridad sobre un nuevo desarrollo. El objetivo es que el número de errores sea bajo a lo largo del proyecto. Si el número de errores aumenta, se han de analizar las causas y el posible impacto en el trabajo de desarrollo.
Se revisa la tasa de evolución.
Ajustes del ámbito
Es posible que el gráfico Evolución indique que las tareas no se completarán al final de la iteración. En ese caso, el jefe de proyecto o el coordinador del equipo inicia un debate sobre cómo se pueden simplificar los requisitos para que se puedan cortar las tareas. Para obtener más información, vea Informe de evolución y tasa de avance (CMMI).
Se ajustan los requisitos y las pruebas correspondientes. Se incluye una nueva característica de requisito en el plan del proyecto para la funcionalidad que falta. En la revisión del plan del proyecto que se mantiene hacia el final de la iteración, la característica se puede asignar a una iteración o corte futuros.
No se consideran solicitudes de cambio ni riesgos durante una iteración.
Evaluación de errores
Algunos miembros del equipo (normalmente no todo el equipo) se reúnen con regularidad para revisar los errores. Cada miembro del equipo debe registrar un error cuando detecta un defecto. Un error registrado se inicia en el estado Propuesto y el objeto de la reunión de evaluación de errores es decidir si se debe corregir, posponerlo a una iteración posterior o rechazarlo.
Para obtener más información, vea Trabajar con errores.
Al final de una iteración
Comprobación
Se considera que los requisitos se han completado solo si se superan las pruebas asociadas. Para obtener más información, vea Comprobar los requisitos.
Retrospectiva
La mejora del proceso es un objetivo importante de CMMI.
Una retrospectiva de la iteración refleja qué fue bien o mal en la iteración y considera las mejoras al proceso y las herramientas utilizadas por el equipo. En Internet se dispone de un volumen significativo de material sobre retrospectivas.
Los miembros del equipo deben evitar cualquier asignación de culpabilidad. Se debe intentar mejorar el proceso para reducir la probabilidad de que los errores cometidos por individuos tengan efecto.
Cuando se introduce un cambio en el proceso, conviene asegurarse de que el equipo esté de acuerdo en las decisiones siguientes:
Cómo se sabrá si se trataba de una mejora.
Cuándo se realizará esa evaluación.
Qué se realizará en consecuencia.
Integración
Si este proyecto forma parte de un programa más amplio, cada equipo realiza su trabajo en una bifurcación del sistema del control de versiones. La bifurcación principal se reserva para integrar el trabajo de los equipos. Al final de una iteración, el equipo puede realizar una integración con la bifurcación principal. Para obtener más información, vea Bifurcar y combinar.
La integración consta de dos pasos:
Una integración hacia delante, para combinar el código más reciente de la bifurcación principal en la bifurcación local del proyecto. Después de realizar la combinación, se ejecutan pruebas manuales y automáticas. Esto producirá algunos defectos. La corrección de los defectos tiene una alta prioridad.
Una integración inversa. Se combina el código de la bifurcación local en la bifurcación principal, y se ejecutan la compilación y el conjunto de pruebas completo en la bifurcación principal. Se anulan los cambios si se producen errores. Se desaprueba la introducción de errores en la bifurcación principal. Si no se producen errores, la integración se declara completada.
Se recomienda realizar una integración al final de cada iteración. Si se retrasa este proceso, la lista de errores que se tengan que corregir después de la integración hacia delante será mayor. Si la corrección de errores requiere mucho tiempo, la bifurcación principal tendrá nuevo material y habrá que realizar otra integración hacia delante.
Preparar la siguiente iteración
Hacia el final de una iteración o a la terminación de la misma, se realizan varias actividades de administración del proyecto. Entre ellas se incluyen la revisión de riesgos y la revisión del plan con respecto a las solicitudes de cambio y las estimaciones de desarrollo modificadas.
Para obtener más información, vea Actividades de proyecto.