El objetivo del proceso Seguimiento del Proyecto es comprobar que las planificaciones y estimaciones que hemos realizado sobre el tiempo y los recursos del proyecto se están cumpliendo. Durante todo el transcurso del proyecto vigilaremos su marcha y lo confrontaremos con la planificación, si se producen desviaciones respecto a lo planificado debemos tomar medidas para corregir las desviaciones o volver a planificar el proyecto.

El seguimiento del proyecto se realizará a distintos niveles durante el ciclo de vida del proyecto:

• Seguimiento a nivel de iteración o Sprint: Que nos permite vigilar la marcha de un sprint y tomar medidas en caso de desviaciones.
• Seguimiento a nivel de Release: Que nos permite vigilar la marcha de una release. El seguimiento a nivel de releases nos permite ajustar el número de características a añadir/eliminar/modificar durante el transcurso de la release, asignar más recursos si fuera necesario o tomar cualquier medida destinada a cumplir las estimaciones.
• Seguimiento a nivel de hitos: Nos permite confrontar las fechas en que se alcanzan los hitos marcados en el proyecto con las fechas previamente planificadas y nos permite conocer cómo van a afectar a los hitos posteriores para tomar las medidas necesarias.

El seguimiento del proyecto es tarea del Jefe de Proyecto

El seguimiento de una iteracción se consigue a través de la reunión diara de Scrum.

Estas reunión se debe de realizar cada día exactamente a su hora y en el mismo sitio. Lo ideal es realizarla frente a un tablón (material) de tareas, compuesto de 3 columnas (Sin asignar, en progreso y finalizadas), y en el que las tareas son representadas a través de post-it, colocadas en cada una de las columnas.

La duración de la reunión no debería de sobrepasar los 15 minutos.

La agenda de estas reuniones diarias consisten en contar cada miembro del equipo de trabajo, de manera muy resumida, los progresos realizados en las tareas asignadas, los posibles inconvenientes o dificultades encontradas, y la asignación (si procede) de nuevas tareas.

Actualización del “tablón”

Si se utiliza un tablón material de tareas, éstas deben ir actualizándose en los Scrum diarios. Conforme cada persona describe lo que hizo el día anterior y lo que hará hoy, mueve los post-it en el tablón. Conforme describa elementos no planificados, pondrá un posít nuevo para cada uno de ellos.

Actualización de las tareas en JIRA

Cada miembro del equipo debería mantener actualizadas las tareas asignadas a él en JIRA diariamente, siguiendo las siguientes normas:

• Antes de la reunión diaria de Scrum: En cada una de las tareas en las que se haya trabajado, se deberán “Registrar horas de trabajo” correspondientemente. En aquellas tareas que se hayan finalizado, se les deberá indicar “Parar Progreso”, y posteriormente “Resolver Incidencia”.
• Tras la reunión diaria de Scrum: Asignarse las tareas nuevas (“Asignar a mí”) que se hayan establecido en la reunión.

El seguimiento diario del Sprint deberá ser realizado por el Jefe de Proyecto. Para ello, se utilizará JIRA para obtener la información relativa a las tareas y el equipo que conforman este Sprint.

Es responsabilidad del Jefe de Proyecto:

• Asegurarse de que todas las tareas son actualizadas diariamente.
• Detectar (e intentar resolver) problemas, cuellos de botella, incidencias,… que dificulten la correcta marcha del Sprint.

Para ello, el jefe de proyecto dispone de los paneles de control , y concretamente del Panel de Seguimiento diario del Sprint.

Para esta tarea se deben de dar de alta un JIRA con los siguientes datos

En la demostración de Sprint, el equipo de trabajo mostrará a los asistentes (entre ellos el cliente o dueño del producto) el trabajo realizado durante el Sprint. Se realizará una demostración “en vivo” del producto, mostrando el funcionamiento de las historias y tareas terminadas en el Sprint.

La reunión en sí se planteará en 2 partes:

• Introducción con los Objetivos del Sprint. Para ello se utilizará la plantilla de presentación de Demo de Sprint. En esta presentación se describe el plan original del Sprint y las historias a desarrollar; luego se comenta que es lo que se encuentra terminado y se explica que ha pasado con lo no desarrollado a grandes rasgos.

• Demostración de la funcionalidad desarrollada. Se realiza una demostración en el entorno de desarrollo o si la madurez del producto lo impide, en el equipo (PC) de uno de los desarrolladores. Se debe de mostrar el producto real funcionando (no se debería enseñar la funcionalidad en base a diapositivas, aunque se pueden llevar unas capturas de pantalla para en caso de “desastre”).

A esta reunión asisten todos los integrantes del equipo, el Scrum Master, el Dueño del Producto, usuarios y cualquier otro interesado en el sistema.

La demostración no debe durar más de 2 horas, aunque en general con 1 hora es suficiente para que todos puedan ver el producto, debatirlo y proponer cambios para el próximo Sprint.

Asigna tiempos a la tarea del Jira Demo de sprint Nº

Tras la reunión de demo de sprint, crea un acta que recoja los cambios propuestos por el cliente para el siguiente Sprint, que sea aprobada por el cliente:

Asigna tiempos a la tarea del Jira Demo de sprint Nº

Para esta tarea se deben de dar de alta un JIRA con los siguientes datos

La reunión de Retrospectiva del Sprint es una reunión en la cual los miembros del Equipo discuten el Sprint que acaba de finalizar, y determinan qué podría cambiarse en el próximo Sprint para que sea más productivo y mejor.

La demostración del Sprint se centra en qué está desarrollando el equipo y si es acorde a las necesidades del cliente, mientras que la retrospectiva se centra en cómo están desarrollando el sistema.

El encargado de guiar la reunión es el Jefe de Proyecto, mostrando la dedicación del equipo dando a conocer los imprevistos e impedimentos que pudieron influir en el transcurso del Sprint.

El equipo debería dividir los temas del Sprint en:

• Bueno
• A mejorar
• Mejora (concreta, de aquí se eligirán dos o tres para poner foco en el próximo Sprint).

La dinámica será en que cada miembro del equipo exponga su impresión del Sprint y agregue temas a las dos primeras columnas. Cuando los miembros del equipo discuten sobre el Sprint que acaba de finalizar, no solo tratan temas técnicos, sino que tiene que surgir cualquier tipo de mejora, que puede estar dada en los procesos que el equipo utiliza para hacer su trabajo, temas de comunicación, etc.

Crea un nuevo documento con las conclusiones sacadas en la retrospectiva de sprint.

Tras realizar la retrospectiva de sprint introduce tiempos en Jira y da el jira por cerrado.

Al final del sprint podemos sacar un informe de hoja de tiempos Time sheet report en Jira en el que nos indica el tiempo empleado por cada una de las personas durante el sprint.

Para obtener este informe seleccionamos la opción de menú Projects → NombreProyecto → Informes → Time Sheet Report. La información a indicar para obtener el informe es:

El informe nos da información sobre el número de horas empleadas por cada una de los miembros del equipo diariamente, y también en que ha estado trabajando cada uno de los días.

El seguimiento de la release me permite conocer la marcha global de la release, cuánto me estoy desviando de las planificaciones hechas y me permite tomar decisiones si observo desviaciones significativas sobre la marcha del proyecto. Para realizar el seguimiento de la Release me puedo ayudar de una serie de paneles de seguimiento que me ayudarán a ver la marcha de la Release. En Paneles de Control hay instrucciones acerca de cómo crear paneles de seguimiento de Release.

Para esta tarea se deben de dar de alta un JIRA con los siguientes datos

El principal momento para realizar el seguimiento de la Release es tras finalizar un sprint. Al comienzo del sprint el equipo de trabajo se propuso realizar una cantidad de trabajo según el Plan de Iteración, al final del sprint deberá comprobar si el trabajo va según lo estimado, mejor de lo estimado o con retraso. Para ver el resultado final del sprint puedes consultar la Pizarra de Tareas de Jira. Una vez visto el desarrollo del sprint, debes replanificar la release. Para ello

• Abre el Plan de Release o el último Seguimiento de Release.
• Copia la hoja 1.0.0-sprint1, o la correspondiente a la última iteración, y colocale el nombre 1.0.0-sprint2, o el que corresponda.
• Vuelve a planificar la Release tal y como indica MDA-TR-1.0-Planifica las Releases.

Para replanificar la release no debes cambiar sin más la fechas, sino que debes tener en cuenta las siguientes cuestiones:

• ¿Han cambiado o pueden cambiar los recursos? ¿Puedes incorporar más gente al proyecto? ¿Hay personas que salen del proyecto?
• ¿La lista de funcionalidades sigue siendo la misma? ¿Es posible retrasar funcionalidades? ¿Han aparecido funcionalidades nuevas? ¿Alguna funcionalidad se ha caido por el camino?

Guarda el nuevo Plan de Release en la carpeta de Seguimiento

Una vez replanificada la Release debes actualizar el cronograma. Para ello sigue los pasos indicados en MDA-TR-1.0-Realizar el cronograma modificando las fechas de los sprints siguientes al anterior. Si ya has realizado alguna revisión del cronograma abre el seguimiento del cronograma.

Cada vez que modifiques el cronograma recuerda realizar una línea base tal y como se indicaba en 4.- Establece una línea base en el cronograma. Puedes comparar la marcha del proyecto con la línea base seleccionando Ver → Gantt de seguimiento. Veras en negro la línea base (o planificación anterior) con la situación anterior y ver cómo de buena fue la planificación anterior y ver las modificaciones que ha sufrido el proyecto.

También puedes ver la desviación en días seleccionando la opción de menú Ver → Tabla → Variación que muestra el número de días de retraso que llevamos con respecto a la planificación inicial.

Una vez modificado el cronograma guarda la nueva copia del cronograma en la carpeta de seguimiento.

Si la planificación de la release ha variado tras la realización del sprint comunica al cliente la nueva planificación tal y como indica 9. Comunica al cliente la nueva planificación

Un buen seguimiento del proyecto implica un trabajo contínuo. Para ello dispones de los paneles de control ClaveProyecto-Release-Seguimiento y ClaveProyecto-Release-Estadísticas. Revísalos contínuamente para ver la marcha de tu proyecto.

En la planificación del proyecto definimos varios hitos. Durante todo el ciclo de vida del proyecto debemos hacer un seguimiento si se cumplieron las planificaciones en lo que respecta a los hitos. Los hitos que definimos en el cronograma son los siguientes:

• Inicio del proyecto
• Inicio de la toma de requisitos
• Inicio de Análisis y diseño
• Inicio desarrollo Release 1
• Inicio desarrollo Release n
• Inicio control de calidad Release 1
• Inicio control de calidad Release n
• Inicio despliegue Release 1
• Inicio despliegue Release n
• Liberación de Release 1
• Liberación de Release n

Además hay tareas relevantes que conviene hacerles un seguimiento para la buena marcha del proyecto. Estas otras tareas a las que hacer un seguimietno sería la finalización de grupos de tareas correspondientes a los hitos.

• Finalización del análisis y el diseño.
• Finalización del desarrollo de la Release n
• Finalización del control de calidad de la Release n
• Finalización del despliegue en pruebas de la Release n

Las tareas a realizar tras el seguimiento de estos hitos son exactamente las mismas que se identificaron en el seguimiento de las Release, modifica el cronograma y el documento de planificación de release, si es necesario, y comunica al cliente la nueva planificación. Revisa el apartado MDA-TR-1.0-Seguimiento de Releases para ver cómo realizar estas acciones.

• NOTAS:
  • XXX: Código del proyecto.
  • 1.2.3: Número de version del documento.
  • [NombreMódulo]: Nombre del módulo que se describe en este documento.

• NOTAS:
  • XXX: Código del proyecto.
  • 1.2.3: Número de version del documento.
  • [NombreMódulo]: Nombre del módulo que se describe en este documento.

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.Gestionproyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja GP.

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

• project = ClaveDelProyecto
• Disciplina-Proceso = Gestión de Proyectos-GP-Realizar el seguimiento del proyecto

Pulsa el botón Search

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

1. Entra en Jira en la opción Projects → Versiones del proyecto. Cuenta el número de sprints en todas las releases del proyecto.

1. Entra en Jira en la opción Ágil → Pizarra de publicación → Resumen del proyecto. A la derecha aparece un cuadro con el resumen del proyecto, todas las releases y los sprints del proyecto.
2. Haz doble click sobre “Resumen del proyecto”. La última línea te da el nº de historias del proyecto.

1. Entra en Jira en la opción Ágil → Pizarra de publicación → Resumen del proyecto. A la derecha aparece un cuadro con el resumen del proyecto, todas las releases y los sprints del proyecto.
2. Haz doble click sobre cada una de las releases del proyecto. La última línea te da el nº de historias de la release.

1. Entra en Jira en la opción Ágil → Pizarra de publicación → Resumen del proyecto. A la derecha aparece un cuadro con el resumen del proyecto, todas las releases y los sprints del proyecto.
2. Haz doble click sobre cada uno de los sprints del proyecto. La última línea te da el nº de historias del sprint.

1. Entra en Jira en la opción Ágil → Pizarra de publicación → Resumen del proyecto. A la derecha aparece un cuadro con el resumen del proyecto, todas las releases y los sprints del proyecto.
2. Haz doble click sobre “Resumen del proyecto”. Toma el valor Tiempo consumido. El valor viene dado en semanas, días, horas.

1. Entra en Jira en la opción Ágil → Pizarra de publicación → Resumen del proyecto. A la derecha aparece un cuadro con el resumen del proyecto, todas las releases y los sprints del proyecto.
2. Haz doble click sobre cada una de las releases del proyecto. Toma el valor Tiempo consumido. El valor viene dado en semanas, días, horas.

1. Entra en Jira en la opción Ágil → Pizarra de publicación → Sprint N → Gráfica por hora del trabajo restante-Burndown.
2. En el gráfico que aparece se ven las horas totales por sprint.

1. Abre el crónograma, selecciona la opción de menú Ver → Tabla → Variación
2. Toma el valor de la columna Var.comienzo para cada uno de los siguientes hitos.
   • Inicio desarrollo release (tantas como haya habido en el proyecto).
   • Inicio control calidad release (tantas como haya habido en el proyecto).
   • Inicio despliegue release (tantas como haya habido en el proyecto).
   • Liberación de la release (tantas como haya habido).