El objetivo del proceso Planificación del Proyecto es establecer un calendario y una previsión de recursos fiable para el proyecto, tanto para el cliente, como para el equipo del proyecto. En la planificación se determinarán las principales tareas e hitos del proyecto y se podrá establecer un calendario para ellos en función de los recursos que se les asignen.

La planificación del proyecto se realizará a distintos niveles durante el ciclo de vida del proyecto:

• Planificación a nivel de proyecto: Al comienzo del proyecto, una vez determinado el alcance del proyecto y establecidos los recursos, humanos, podemos hacer una primera planificación, que nos permite situar en el tiempo las principales tareas e hitos.
• Planificación a nivel de Release: La planificación nos permite agrupar los distintos requitos del proyecto en Releases y hacer planificación a nivel de Releases. Estas planificaciones de Releases se harán al comienzo de cada Release y nos obligarán a ajustar las planificaciones anteriores.
• Planificación a nivel de iteración o Sprint: Evidentemente estas planificaciones a más bajo nivel serán cada vez más precisas y nos obligarán a replanificar Releases posteriores y todo el proyecto.

La Planificación del Proyecto también nos permitirá ver cómo influyen en la fecha de finalización del proyecto la asignación de más o menos recursos.

Por último, la Planificación del proyecto nos sirve como herramienta de comunicación con el cliente y nos permite llegar a acuerdos con él y mejorar el entendimiento que este tiene sobre el proyecto.

La Planificación del Proyecto es tarea del Jefe de Proyecto

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

2.1. Crea un nuevo Cronograma

2.2. Incluye las tareas más relevantes del proyecto.

La plantilla del cronograma proporcionada por MEDEA incluye las tareas más relevantes para planificar el proyecto, lo cual no significa que no haya otras tareas dentro del proyecto, pero al nivel de planificación que necesitamos en este punto no son relevantes. Las tareas que incluye el cronograma son:

1. Tareas de definición del proyecto. El cronograma debe hacerse, al menos, después de tener definido el alcance y, preferiblemente, después de tener los requisitos funcionales y no funcionales. Si no se dispone de los requisitos funcionales y no funcionales, el cronograma no tiene garantías suficientes.
2. Tareas de definición de requisitos, de visión, funcionales y no funcionales.
3. Tareas de análisis.
4. Tareas de diseño. Incluye definición de arquitectura, módulos, base de datos y prototipado de pantallas.
5. División del trabajo en Release que incluyan grupos definidos de requisitos a implementar. Dentro de cada Release tendremos las siguientes tareas:
   1. Tareas de Desarrollo. Sprints en un desarrollo iterativo e incremental.
   2. Tareas de escritura de casos de prueba. Para los requisitos que forman parte de un sprint.
   3. Tareas de Ejecución de test funcionales. Para cada sprint.
   4. Tareas de Ejecución de test de rendimiento. Para cada sprint.
   5. Preparación del entorno de preproducción.
   6. Realización de pruebas de usuario.
   7. Elaboración de manuales y ayudas.
   8. Formación de los usuarios.
   9. Preparar el entorno de producción.

Estas son las tareas propuestas desde MEDEA, pero puedes añadir otras si lo consideras necesario. El quitar alguna es más delicado, te lo desaconsejo vivamente.

2.3. Revisa el Cronograma

El momento para hacer una primera versión del cronograma es en el momento en que esté definido el alcance, o sea al terminar el documento de Visión. Antes de esto cualquier intento de realizar un cronograma es pura especulación. No obstante el Cronograma debe ser revisado y refinado en los siguientes casos:

• Al finalizar la especificación de requisitos funcionales y no funcionales.
• Al finalizar el diseño de la aplicación
• Al finalizar cada una de las iteraciones de desarrollo
• Al finalizar cada una de las Releases del producto.

Para ajustar el cronograma al proyecto resulta muy útil utilizar los asistentes que Microsoft Project 2003 proporciona. Para acceder a dichos asistentes es necesario habilitar la barra de herramientas Guía de Proyectos. Para ello selecciona la opción de menú Ver → Barras de herramientas → Guías de Proyecto.

Aquí puedes conseguir un pequeño Manual de Microsoft Project 2003

3.1. Introduce un calendario para el proyecto

Para ello especifica:

1. Fecha de comienzo: Para ello selecciona el asistente de la barra Guía de proyectos Tareas → Definir el proyecto
2. Define el calendario: Por defecto será el calendario estandar. Para ello selecciona el asistente de la barra Guía de Proyectos Tareas → Definir periodos laborales generales.

Introduce el horario, los días festivos, etc.

Para ello selecciona el asistente de la barra Guía de proyectos Recursos → Especificar personas y equipamiento del proyecto.

En la primera pantalla indica Especificar recursos de manera manual. A partir de ahí en la tabla de la derecha introduce cada una de las personas que van a participar en el proyecto.

Es importante especificar el nombre de la persona en cuestión en la columna Nombre del recurso. Los roles ahora no son determinantes, ya que una misma persona puede desempeñar varios roles. No dupliques a la persona, aunque desempeñe varios roles en el proyecto, ya que esto dificulta la administración. El resto de los campos son optativos.

Si todavía no se sabe concrétamente qué personas participárán en el proyecto, se puede sustituir el nombre de la persona en Nombre del recurso por uno genérico (Analista 1, Analista 2, Programador 1, Programador 2, etc).

Introduce el esfuerzo estimado de todas y cada una de las tareas.

Nota 1: Aunque MicrosoftProject indica duración, en realidad en este punto debemos introducir esfuerzo, que se ajustará más adelante con los recursos que le asignemos.

Nota 2: Para hacer la estimación inicial de las tareas sigue las instrucciones para realizar estimaciones.

Para introducir el esfuerzo optimista, esperado y pesimista de cada una de las tareas es necesario habilitar la barra de tareas Análisis Pert. Para ello selecciona la opción de menú Ver → Barras de herramientas → Análisis Pert. Selecciona en la barra de tareas la opción Hoja de entradas Pert.

Introduce en ella las duraciones optimista, esperada y pesimista para cada una de las tareas. No introduzcas el campo Duración, ya que al realizar el cálculo Pert se sobreescribe. Recuerda las instrucciones para realizar estimaciones.

No les pongas duración alguna a los hitos (debes saber cuáles son, y si tienes dudas consultar el Diagrama de Gantt y los verás porque están marcados con un rombo negro).

Una vez introducidas todas las estimaciones puedes ver los diagramas de Gantt optimista, esperado y pesimista pulsando los botones correspondientes de la barra de herramientas Análisis Pert. Para calcular la Duración pulsa el botón Calcular Pert de la barra de herramientas Análisis Pert.

Una vez tengamos estimado el esfuerzo debemos asignar recursos a las tareas. Si la tarea utiliza un único recurso (el trabajo lo hace sólo una única persona) lo más sencillo es, en el diagrama de Gantt (menú Ver → Diagrama de Gantt), seleccionar la persona en la columna Nombre de los recursos. Si hay que introducir más de un recurso en una tarea (el trabajo lo hacen entre varias personas) lo más sencillo es hacer doble click sobre la tarea y en la ventana emergente que aparece seleccionar la pestaña Recursos y añadir los recursos necesarios.

Al introducir más de un recurso en una tarea, en el Diagrama de Gantt aparecerá un icono de advertencia (!) en la columna Indicadores (marcada con una “i”) con varias opciones desplegables, para que confirmemos la manera en que se reprograma la tarea:

• Reducir la duración y mantener el trabajo constante.
• Aumentar el trabajo y mantener la duración constante.
• Reducir la capacidad máxima de los recursos.

Tendremos que decidir entre las tres opciones según afecte la incorporación de más recursos a la fecha de finalización o no.

Una vez realizado el cronograma disponemos de mucha información sobre la planificación del proyecto.

1. Por una parte disponemos de un diagrama de Gantt con todas las tareas del proyecto, las relaciones entre ellas, recursos asignados y fechas de inicio y fin.
2. Por otra parte, señaladas en rojo podemos ver el camino crítico del proyecto (menú Ver → Gant de Seguimiento). El camino crítico está formado por todas aquellas tareas que influyen decisivamente en la fecha final del proyecto. Aquellas tareas con el fondo rojo indican el camino critico. Las que tienen el fondo azul no están en el camino crítico y por tanto un retraso en ellas no influye decisivamente en la fecha final del proyecto.
3. Tenemos también el diagrama de Gantt optimista, pesimista y esperado que nos permite trabajar con rangos de fechas para las tareas, no con una fecha fija.

Conviene revisar también el diagrama de red (menú Ver → Diagrama de Red), que nos permite ver la secuencia temporal y las superposiciones de tareas en el tiempo de manera más clara que el diagrama de Gantt. Para ello en la barra de vistas que se selecciona con la opción de menú Ver → Barra de Vistas selecciona la opción Diagrama de Red. En este diagrama aparecen las tareas con forma de rectángulo, los hitos con forma de hexágono y las tareas que agrupan otras tareas como trapezoides. En rojo aparece el camino crítico del proyecto con aquellas tareas decisivas para la finalización del proyecto en la fecha dada y en azul las tareas que no influyen en el camino crítico.

También debemos revisar el gráfico de recursos (menú Ver → Gráfico de Recursos) que nos permite comprobar que no hay ninguna persona que tenga más del número de horas estipuladas en el calendario ningún día. Si detectamos que alguna persona tiene más horas de las debidas podemos acudir al uso de recursos (menú Ver → Uso de Recursos) para ver con detalle en qué tareas está asignado un recurso y me permite cambiar fechas o recursos en las tareas.

Además podemos ver el Calendario (menú Ver → Calendario), que se activa pulsando la opción calendario en la barra de vistas que habilitamos anteriormente. En él veremos las tareas a realizar en cada uno de los días.

Finalmente, con el cronograma tenemos un artefacto que nos permite realizar un seguimiento del proyecto, afinar posteriormente nuestras estimaciones y tomar medidas en el caso en que se produzcan desviaciones significativas sobre lo estimado.

Asigna tiempos a la tarea de Jira Crear el Cronograma.

En esta tarea el cliente debería firmar el acta de aprobación, con lo cual da su conformidad al Plan de Proyecto y al cronograma y nos permite continuar avanzando en el proyecto.

Los puntos a los que debe prestar más atención en el Plan del Proyecto y aprobar son:

• Apartado 5 del Plan del Proyecto.
  • Cronograma del proyecto.
  • Plan de monitorización y control.
  • Escalado de asuntos
• Apartado 6 del Plan del Proyecto.
  • Equipo de trabajo.
  • Equipo del Cliente.

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

Cada uno de los miembros del equipo asistentes a la tarea clonará la tarea y se asignará las horas.

Convoca la reunión con el orden del día Aprobar la planificación del proyecto

Tras la reunión de aprobación crea un acta y aprobarla por parte del cliente.

1. Que cada una de las personas de ÁTICA que han participado en la reunión se asignen el tiempo que ha durado la reunión.
2. Que el Jefe de Proyecto dé por cerrada la tarea una vez se apruebe el acta de la reunión.

Las líneas base sirven para comparar el progreso real del proyecto con respecto a lo planificado. Para poder realizar un seguimiento de la marcha del proyecto y ver las necesidades que ha sufrido con respecto a lo planificado debemos introducir una línea base en el proyecto.

Para guardar una línea base seleccionar la opción de menú Herramientas → Seguimiento → Guardar línea de base….. En la ventana que se abre marcar el Option Button Guardar línea de base y en el combobox seleccionar una de las líneas de base que aparecen.

Más adelante, en el proceso Seguimiento del Proyecto veremos como utilizar las líneas base.

Medea va a utilizar un ciclo de vida iterativo e incremental para desarrollar las aplicaciones y como metodología de gestión de Releases e Iteraciones vamos a utilizar Scrum. Si no tienes muy claro como se gestiona un proyecto mediante Releases e iteraciones consulta el apartado Releases e Iteraciones de MEDEA.

Un libro muy ameno sobre Scrum es Scrum y XP desde las trincheras. En 2 horas, no se necesita más para leerlo, puedes aprender todo lo que necesitas saber sobre Scrum. Has de ser consciente que en MEDEA no vamos a seguir un Scrum puro, aunque sí lo suficientemente reconocible.

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

Para planificar una release lo primero que debes hacer es asignar prioridad a los requisitos tal y como dice en Releases e Iteraciones. La prioridad debe determinarse por el cliente -a nosotros como programadores debe darnos igual programar primero unas funcionalidades u otras- con la excepción de programar primero aquellas funcionalidades que nos permitan construir la arquitectura de la aplicación que estamos desarrollando.

Para establecer las prioridades debemos reunirnos con el cliente y que sea él el que las determine. Una buena opción es aprovechar la reunión de validación de requisitos para establecer las prioridades.

En la primera hoja 1.0.0-sprint1 introduce todas las historias/requisitos del proyecto. Puedes introducirlas a mano o sacándolas de Jira. No olvides introducir la clave Jira.

Dale un valor al campo importancia y ordena las historias de mayor importancia a menor importancia. No importa que se repitan valores. Se trata únicamente de establecer un orden en el que queremos desarrollar. Buena idea es utilizar múltiplos de 10.

Una vez ordenadas las historias por orden de prioridad debemos estimar las historias. En como gestionar un proyecto con Releases e Iteraciones se daban instrucciones acerca de como planificar historias, o requisitos funcionales.

Para estimar las historias reune al equipo de programadores, analistas, diseñadores, y el cliente en el caso en que estes utilizando historias para definir los requisitos funcionales y realiza una reunión de planificación de Release.

Las historias siempre se estimarán en días ideales, suponiendo concentración máxima y 0 interrupciones. Más adelante utilizaremos la dedicación y el rendimiento para ajustar a días reales.

Durante la reunión el equipo y el cliente hablarán sobre cada una de las historias hasta que el equipo tenga una idea clara del contenido de la historia o requisito. Una vez el equipo lo tenga claro, los miembros del equipo realizan la estimación de la tarea mediante scrum poker. Para ello cada uno de los desarrolladores deposita una carta boca abajo. Cuando todos han depositado su carta, se vuelven boca arriba. Este juego se repite hasta que todos los miembros del equipo están de acuerdo en una determinada estimación para la tarea.

Para cada historia/requisito realizaremos dos estimaciones:

• Estimación optimista.
• Estimación pesimista.

Actualiza el campo Estimación Optimista y Estimación Pesimista para cada una de las historias en el Plan de Release.

Las columnas Estimación acumulada optimista y la Estimación acumulada pesimista se irán actualizando automáticamente.

Una vez estimadas las historias o requisitos definimos el equipo que va a trabajar en cada una de las releases. Para ello no necesitamos conocer las personas concretas, pero si deberíamos tener una idea de cuantas personas van a trabajar. Te recuerdo que esto es una planificación y por tanto está sujeta a variaciones durante el ciclo de vida del proyecto, pero debemos intentar ajustarnos lo más posible a la realidad para que las planificaciones sean lo más precisas posible.

Conocidos los miembros del equipo debemos planificar su capacidad de trabajo para luego calcular la velocidad del grupo. La capacidad de cada uno de los miembros viene dada por su dedicación al proyecto y por su nivel de experiencia.

Para la dedicación recomendamos siempre que la dedicación sea al 100% al proyecto. Los cambios de contexto siempre llevan tiempo. Para el nivel de experiencia utilizaremos un factor de corrección de .5 para programadores junior y .75 para programadores senior.

La velocidad del grupo, o capacidad de trabajo, es el sumatorio para cada uno de los programadores de (Dedicación en tanto por uno * Nivel experiencia en tanto por uno * nº de días de trabajo de la iteración)

Dispones de una pestaña llamada Equipo en el Plan de Release para introducir los equipos y calcular la velocidad del equipo. Introduce para cada release/iteración el nombre de los desarrolladores -o desarrolladorNº si no conoces el nombre todavía-. Para cada uno de ellos introduce:

• El nº de días que trabajaran en la iteración
• La dedicación en tanto por ciento
• La capacidad en tanto por ciento. (Programadores expertos tienen una capacidad típica entre el 70% y el 75%)

En la hoja de cálculo calculará automáticamente la velocidad para cada release/iteración.

La agrupación de historias en Releases es responsabilidad única del cliente. Es el cliente el que debe decir qué compone una release. Nosotros podemos ayudarle, pero la responsabilidad es únicamente suya.

Para determinar lo que compone una release dispone de dos opciones:

1. Definir la fecha de liberación de la release 1
2. Definir los requisitos que componen la release 1.

6.1. Definición de release basada en la fecha.

En el primer caso, como disponemos de las estimaciones de las historias/requisitos y de la capacidad de trabajo del equipo, iremos seleccionando historias hasta que alcancemos la fecha deseada. En este punto es importante tener en cuenta lo siguiente:

• Que disponemos de 2 estimaciones distintas, optimista, y pesimista. Debes ser consciente de que te mueves en un rango de fechas.
• Que hasta ahora estamos estimando exclusivamente el desarrollo.
• Que tienes que estimar también el resto de tareas que hay en el cronograma una vez finalizado el desarrollo de la release y que están relacionadas con el control de calidad y el despliegue.

6.2. Definición de release basada en funcionalidades

En el segundo caso, tendremos un rango de fechas en que las funcionalidades elegidas por el usuario estarán terminadas. También debes considerar que esta estimación es exclusiva del desarrollo y que hay que estimar el resto de tareas relacionadas con el control de calidad y el despliegue.

Una vez tengamos claro las releases asigna cada historia a una release determinada en la columna correspondiente del Plan de Release. La asignación de historias a release puede variar de la estimación optimista a la pesimista. Si es así, rellena las columnas Release optimista y Release Pesimista

6.3. Divide las Releases en iteraciones

Por último, el jefe de proyecto debe dividirla en iteraciones. Se recomienda como duración de cada iteración 3 semanas.

Más adelante veremos cómo se planifica una iteración, pero debes tener en cuenta que en una iteración de 3 semanas debes incluir:

• Un día de planificación de sprint
• Un día de demo de sprint
• Un día de descanso en el que el equipo de trabajo prueba cosas que facilitará la implementación de posteriores iteraciones.

Esto da una duración efectiva de 12 días por iteración. Divide las release en iteraciones de acuerdo con esta duración.

En la pestaña Resumen del Plan de Release introduce el número de la iteración, la fecha de inicio, la de fin, el nº de días de trabajo, la velocidad o capacidad del equipo de trabajo para cada iteración. La velocidad o capacidad de trabajo acumulada se calculará automáticamente.

Para ello entra en la opción de menú Agil → Pizarra de Planificación y dentro de ella selecciona el botón Agregar y en la ventana que aparece introduce:

• El nombre de la Release
• La Release padre (las releases no tienen release padre. Esto es para las iteraciones)
• La fecha de inicio
• La fecha de fin
• La fecha de publicación
• Una descripción de la Release.

Podemos asignar ya las historias a la release, pero yo lo haría tras la planificación de iteración.

En el Cronograma del proyecto introduce las nuevas fechas surgidas para las iteraciones y las releases en la Planificación de Release. Recuerda que lo planificado es exclusivamente para el desarrollo y que tienes que estimar también el resto de tareas que hay en el cronograma una vez finalizado el desarrollo de la release y que están relacionadas con el control de calidad y el despliegue.

Envía al cliente la nueva planificación y que te la valide. No es necesario hacer una reunión para esto. Basta con un correo. Guarda ese correo en /Proyecto/Documentacion/1.GestionProyecto/1.1.Planificacion

El objetivo de esta tarea es realizar la planificación del Sprint. Al finalizar la planificación de sprint tendremos:

• Un conjunto de historias descompuestas en tareas
• Las estimaciones del esfuerzo para desarrollar las tareas.
• Fechas de comienzo, finalización, demo de sprint y retrospectiva.

No es el objetivo de esta tarea hacer una descripción completa de la metodología Scrum referente a las reuniones de planificación. Para ello, se puede consultar Releases e Iteraciones y el manual de referencia Scrum y XP desde las trincheras.

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

OJO si venimos de Control de Cambios porque vamos a “Planificar Cambios”, usaremos la descripción “Planificación Cambios” y la etiqueta “CAMBIOS”.

El Jefe de Proyecto convocará una reunión de Planificación del Sprint con el equipo de trabajo, y a la cual puede (y debería) asistir el cliente. Para ello, se fijará la FECHA de planificación, y se convocará a los asistentes a través de la AGENDA corporativa de la Universidad de Murcia.

En la convocatoria de la reunión, se debería describir:

• Asistentes
• La duración de la reunión (no debería superar las 5-6 horas)
• AGENDA de la planificación
• Cualquier otro motivo de interés para el éxito de la reunión

1. Al inicio de la reunión de planificación, el Jefe de proyecto deberá:

• Formar el equipo de trabajo (miembros de desarrollo este Sprint)
• Asignarles un porcentaje (%) de dedicación al proyecto a cada uno.
• Asignarles un rendimiento estimado a cada uno.
• Calcular la velocidad, o capacidad de trabajo, de cada miembro del equipo en el sprint.
• Sumar las velocidades de todos los miembros para ver la velocidad del equipo en el sprint.

El resultado es una tabla similar a la siguiente:

2. Durante la reunión de planificación se deberán tomar decisiones como (para ampliar mas información, consultar Releases e Iteraciones y el manual de referencia Scrum y XP desde las trincheras).

• Definir tareas técnicas necesarias (intentar minimizar esto e incluirlas en las tareas resultantes de la descomposición de las historias).
• Descomponer las historias en tareas necesarias para poder realizar la funcionalidad incluida historias planteadas por el cliente.
• Estimar el tiempo necesario para realizar cada una de las tareas anteriores.
• Elegir las historias / tareas que entrarán dentro del Sprint.

3. Antes de finalizar la reunión, el Jefe de proyecto fijará las siguientes FECHAS:

• Fecha de inicio del Sprint
• Fecha de fin del Sprint.
• Fecha de la DEMO del Sprint
• Fecha de la retrospectiva del Sprint.

Tras la reunión de planificación, es importante mantener informado a los grupos sobre el inicio del mismo, e invitándoles a la asistenca de la próxima demostración del producto (fecha de la DEMO).

1. Para ello, el Jefe de Proyecto enviará un correo electrónico al resto de ATICA en el que informará de:

• Breve descripción del producto / proyecto que se está realizando.
• Objetivo del Sprint.
• Fechas del Sprint y duración.
• Historias y tareas que se van a abordar en este sprint.
• Nombres del equipo de trabajo
• Fecha de la próxima demostración y funcionalidades que se enseñarán.

A continuación se puede ver un ejemplo real del formato de un correo enviado para comunicar el inicio de un Sprint:

2. Envía también una copia del correo al cliente y a todos los interesados en el proyecto.

Tras la reunión, el Jefe de proyecto debe realizar las siguientes labores:

1. Dar de Alta el Sprint en JIRA

Para ello, desde AGIL –> Pizarra de Planificación, pulsaremos el botón Agregar. En la ventana que nos aparezca especificaremos.

• Nombre de la versión: En nuestro caso sprint.
• Padre: Se refiere a la versión o release de la que cuelga el sprint.
• Fecha de inicio.
• Fecha de Fin.
• Fecha de Publicación. Opcional
• Descripción. Una descripción del sprint. Incluye el objetivo

2. Dar de alta cada una de las tareas del Sprint

Como resultado de la planificación, se habrá generado la necesidad de crear nuevas tareas asociadas a cada una de las historias.

El Jefe de proyecto debe de crear dichas tareas en JIRA, como subtareas de la historia correspondiente.

Los datos de cada tarea serán:

OJO si venimos de Control de Cambios y hemos pasado por “Planificar Cambios”, usaremos la etiqueta “CAMBIOS”, y además las subtareas colgarán del jira correspondiente a la Petición de Cambio.

3. Cada una de las tareas debe ser asociada al Sprint dado de alta en el punto 1.

Para hacer esto tenemos dos opciones:

1. Al crear la subtarea rellenar el campo Version(es) Fijadas con el sprint que hemos dado de alta previamente.
2. En la pantalla de Jira Agil → Pizarra de planificación selecciona el filtro Version y No programada. Una vez hecho esto nos aparecerá una lista de todas las tareas/subtareas que no están asignadas a ninguna versión. En la parte de la derecha de la Pizarra de Planificación nos aparecen todas las versiones. Haciendo doble click sobre la versión del sprint actual se abre y vemos todas sus características. Si ahora pinchamos sobre las tareas y hacemos drag and drop sobre la versión automáticamente se asignará la tarea al sprint.

Introduce el tiempo utilizado en la planificación del sprint en el jira introducido al comienzo de esta tarea.

• 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-Planificar el 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 el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Gestión de Proyectos-GP-Planificar el proyecto
• Label = CRONOGRAMA

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 el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Gestión de Proyectos-GP-Planificar el proyecto
• Label = RELEASE

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 el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Gestión de Proyectos-GP-Planificar el proyecto
• Label = ITERACION

Pulsa el botón Search

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