tema3,Implementación de proyectos de

Implementación de proyectos de innovación

[3.1] ¿Cómo estudiar este tema?

[3.2] El inicio del proyecto

[3.3] Los roles del proyecto

[3.4] El cronograma del proyecto (Diagrama de Gantt)

[3.5] El diagrama PERT o de relación de los paquetes de trabajo

[3.6] Las revisiones de proyecto

[3.7] Una metodología estándar para la ejecución de los

proyectos: Agile

T

EM

A

Diseño y gestión de proyectos I+D+i

TEMA 3 - Esquema

Esquema


TEMA 3 - Ideas clave

Ideas clave

3.1. ¿Cómo estudiar este tema?

Para estudiar este tema es necesario estudiar las ideas claves del tema. Puedes

completar más información viendo y leyendo el resto de secciones.

Este tema pone en marcha la praxis del proyecto, estudiando las partes de gestión del

proyecto, desde el inicio en la llamada reunión de lanzamiento (Kick-Off) hasta su

finalización. Veremos los diferentes estadios del proyecto, los roles de los integrantes

del consorcio, los líderes de paquetes de trabajo, el rol del coordinador, el rol del líder

científico tecnológico, la justificación del proyecto, el impacto que tiene sobre la

sociedad, la tecnología y los negocios.

También veremos quién evalúa el proyecto, qué reportes (informes) se han de realizar

durante la vida del proyecto, que entregables debemos contemplar en el contrato.

Finalmente se propone una metodología de gestión de proyectos llamada Agile.

3.2. El inicio del proyecto

Se establece, inmediatamente después de la negociación, una fecha para el inicio del

proyecto, que será el mes 1 (M1). En ese uno se realiza la primera reunión de consorcio al

completo, también llamada Kick-off meeting, donde se presentarán los paquetes de trabajo

y se establecerán las líneas principales del proyecto revisando el llamado DoW o contrato

con la EC, que establece las pautas necesarias para la realización del proyecto.



Se revisa la estructura de los Work Packages (WP) y su contenido a nivel global:

Se reúnen todos los líderes de los paquetes de trabajo para refinar y planificar las tareas

específicas del mismo. Se establece la metodología de trabajo y comunicación entre los

miembros del paquete y qué resultados se esperan de éste a corto plazo.

3.3. Los organismos de gestión del proyecto

La gestión de un proyecto de innovación requiere una organización del proyecto

muy eficiente y bien estructurada. De particular importancia son la distribución de

responsabilidades y el flujo de información, tanto para el control y presentación de



informes, como para una correcta gestión del consorcio y su relación con la

EC. Una gestión de conflictos clara es necesaria para garantizar la resolución de

conflictos rápida y aceptable, al tiempo que reduce los riesgos de una posible

escalada de conflictos.

Una evaluación completa y el análisis de riesgos potenciales es importante para

preparar y realizar las acciones correctoras necesarias si las requiere. Ejemplo de los

organismos de gestión de un proyecto europeo:

IPR Audit Committee

(IAC)

Business AdvisoryCommittee

General Assembly

IP Co‐ordinationCommittee

(IPCC)

IP Co‐ordination(IPC)

IP Manager(IPM)

IP Secretariat(Administrative,

financial, legal support)

Executive IP Management(EPM)

A0 ‐ Project Coordination & Management

Reports, directions...

EUROPEAN COMISSION

External International Advisory

Committee (EAC)

Activity 1Leader

Activity 1

Activity 2Leader

Activity 2

Activity 3Leader

Activity 3

Activity 4Leader

Activity 4

Activity 5Leader

Activity 5

Activity 6Leader

Activity 6

Reporting path(admin)

Controllingpath

Los organismos típicos de gestión de proyectos europeos para una buena gestión

comprenden los siguientes elementos:

Asamblea general

Organismos típicos de gestión de proyectos

ExternarAvizor

Comité (EAC)

IPR Audita Comité (IAC)

Business Avizor

Comité (BAC)

IP CoordinaciónCommitte (IPCC)

1 2 3 4 5

Asamblea General

La asamblea general es el mayor órgano de gestión de los proyectos de innovación

europeos. Todos los socios están representados en ella. Siguiendo las recomendaciones

sobre el órgano gestor ejecutivo (EPM) y el comité de coordinación (IPCC), la asamblea



general toma las decisiones finales sobre las políticas del consorcio, sobre modificaciones

o extensiones del Consortium Agreement, o sobre los objetivos del proyecto. El IPCC y la

EPM mantendrán informada a la asamblea general sobre sus progresos o logros.

External Advisory Committee (EAC)

El Comité de asesoramiento externo asesora sobre la dirección científica de los proyectos

desde una óptica externa. Revisa anualmente el progreso del proyecto a nivel académico,

tecnológico, tendencias del mercado, nuevos desarrollos sociales, que el proyecto debe

tener en cuenta. También asesora en cómo encajar el proyecto en nuevas ideas de

negocio y de posible explotación de los resultados del mismo. Suele estar representado

por altos ejecutivos de la industria, profesores sénior de las universidades, etc.

IPR Audit Committee (IAC)

El comité sobre derechos intelectuales (Intelectual Property Rights) es un grupo reducido

de expertos que asesoran toda la información relevante a los derechos de autor que surjan

del proyecto.

Business Advisory Committee (BAC)

El comité de negocios debe estar compuesto por altos ejecutivos de negocios, seleccionados

por los socios del consorcio. Normalmente tres expertos vendrán de grandes compañías y

uno por parte de las PYMES. Su misión es desarrollar propuestas concretas sobre los

nuevos negocios que se pueden realizar con lo investigado en el proyecto.

IP Coordination Committe (IPCC)

El comité de coordinación del IP (Integrated Project) -que es una tipología de proyectos

grandes dentro de la EC- es el responsable de la coordinación de la gestión técnica global

y de la coordinación de los diferentes paquetes de trabajo (WP). Las tareas propias del

mismo incluyen, reportes periódicos, redistribución de los recursos si es necesario y la

gestión del primer nivel de resolución de conflictos. El IPCC se reúne mensualmente para

tratar los temas necesarios y se conforma por el coordinador del proyecto y los líderes de

los paquetes de trabajo.

3.4. Los roles del proyecto

El rol de coordinador en un proyecto europeo es: el único interlocutor con la

Comisión Europea y responsable último del proyecto. Éste es el encargado de realizar



los trámites administrativos durante toda la vida del proyecto. Es el que recibe el dinero

por adelantado de todo el proyecto, y es él el que reparte el dinero a todo el resto de

socios del proyecto. Es el que realiza los informes de justificación económica generales,

y el que solicita los informes de reporting del resto de los socios. También es el

responsable de generar y discutir el contrato con los socios y con la EC.

El rol de coordinador científico-técnico es el encargado de marcar las guías técnicas y

de arquitectura general del proyecto, es el concentrador y responsable de marcar las

tendencias y aunar los diferentes requisitos técnicos en la línea que marque la dirección a

seguir.

El rol de líder de paquete de trabajo. Es el responsable del paquete de trabajo y de su

relación con los otros paquetes. Es el que marca la línea a seguir dentro del paquete y que

se realicen las entregas correspondientes a tiempo y en calidad.

3.5. El cronograma de proyecto (Diagrama de Gantt)

El diagrama de Gantt es una herramienta de planificación de tareas necesarias para la

realización de un proyecto. Desarrollado y popularizado alrededor de 1910 por Henry L.

Gantt, esta herramienta es utilizada para modelar y representar fácilmente la planificación

de las tareas de un proyecto de innovación. El diagrama de Gantt es muy utilizado por los

jefes de proyecto, lo que sea su sector de actividad.



Ventajas del Diagrama de Gantt

El diagrama de Gantt permite:

Hacer visible el progreso de las tareas de un proyecto de manera simple y concisa.

Planificar sus necesidades en recursos humanos y materiales.

Ayudar en la construcción del presupuesto del proyecto.

Seguir los costes de proyecto: consumo de recursos humanos J/h, equipo.

Comunicar simplemente sobre el adelanto del proyecto.

Ejemplo de un Diagrama de Gantt

3.6. El diagrama PERT o de relación de los paquetes de trabajo

El método de PERT del inglés Program Evaluation and Review Technique es una

herramienta de gestión de proyecto que permite administrar la planificación de un

proyecto. Este método permite modelizar las tareas y los lazos entre éstas de un proyecto

en forma de red llamada Red PERT o Diagrama PERT.

La Red PERT permite identificar el camino crítico de un proyecto y concentrar los

esfuerzos en las tareas componiéndolo. El camino crítico siendo el encadenamiento de

tareas cuya duración total es la más larga del proyecto.

Inventado a finales de los años 1950 por la marina americana para coordinar los

trabajos del proyecto POLARIS (realización de misiles a ojivas nucleares), este método

permitió coordinar varios millares de subcontratistas, reduciendo costes y los plazos.



El Diagrama PERT es a menudo acoplado al Diagrama de Gantt.

3.7. Las revisiones de proyecto

Se realizan normalmente cada año por parte de la Comisión Europea encabezado por

un oficial de proyecto (Project Officer) que contrata una serie de expertos independientes

que evaluarán el progreso del proyecto y aprobarán los costes del mismo dependiendo de

si se han cumplido las expectativas del proyecto en períodos de 12 meses.

Al finalizar la review, la EC distribuirá un reporte de revisión, o Review Report con los

aspectos a mejorar, los que siguen una buena línea y consejos para el siguiente año de

proyecto.

3.8. Una metodología estándar para la ejecución de los proyectos:

Agile

Ahora que tenemos claros los roles, los organismos de gestión de un proyecto, vamos a

estudiar qué metodologías nos pueden ayudar a gestionar y llevar a cabo el proyecto

durante todo su ciclo de vida.



Fuente: http://www.dilbert.com/

¿Qué es una metodología Agile?

Un conjunto de valores & principios (el manifiesto) y un conjunto de prácticas (los

métodos). Agile es una mentalidad y una forma diferente de trabajar que permite

obtener antes el valor de negocio.

Existen varias metodologías llamadas agiles como:

XP - Extreme Programming.

Crystal Clear.

DSDM - Dynamic Systems Developmemt Method.

FDD - Feature Driven Development.

ASD - Adaptive Software Development.

XBreed.

Extreme Modeling.

Scrum.

Pero nos centraremos en la metodología Scrum. Todas ellas se basan en “el manifiesto”:

Manifiesto por el Desarrollo Agil de Software

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia

experiencia como ayudando a terceros. A través de este trabajo hemos aprendiendo a

valorar:



Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la

izquierda.

Las bases fundamentales de Agile son:

1. Empirismo: inspeccionar y adaptar ciclos de una manera rápida.

2. Auto-organización: los equipos se administran y organizan ellos mismos.

3. Colaboración: los clientes colaboran con los desarrolladores.

4. Asignación de prioridades no pierda tiempo centrándose en el trabajo que no agrega

valor inmediato.

5. Tiempo: crea el ritmo que impulsa el desarrollo.

La metodología SCRUM

Scrum define un proceso empírico, interactivo e incremental de desarrollo que intenta

obtener ventajas respecto a las otras aproximaciones de desarrollo de software

(cascada, espiral, prototipos, etc.) mediante la aceptación de la naturaleza caótica del

desarrollo de software y la utilización de prácticas que tienden a manejar la

impredectibilidad y el riesgo a niveles aceptables.

El mismo surge de un artículo de 1986 de la Harvard Business Review titulado The

New Product Development Game de Takeuchi y Nonaka, que introducía las mejores

prácticas más utilizadas en 10 compañías japonesas altamente innovadoras. A partir

de ahí y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland

formalizan el proceso conocido como Scrum en el año 1995. Uno de los análisis más

importantes de la metodología desembocó en un libro escrito por dos de sus creadores,

Ken Schwaber y Mike Beedle [Schwaber, 2001].

Al principio del proyecto se define el Product Backlog, que contiene todos los requisitos

funcionales y no funcionales que deberá satisfacer el sistema a construir. Los mismos



estarán especificados de acuerdo a las convenciones de la organización ya sea mediante:

features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc.

El Product Backlog será definido durante reuniones de planeamiento con los

stakeholders. A partir de ahí se definirán las interacciones, conocidas como Sprint en la

jerga de Scrum, en las que se irá evolucionando la aplicación evolutivamente. Cada

Sprint tendrá su propio Sprint Backlog que será un subconjunto del Product Backlog

con los requisitos a ser construidos en el Sprint correspondiente. La duración

recomendada del Sprint es de un mes.



Dentro de cada Sprint el Scrum Master (equivalente al Líder de Proyecto) llevará a

cabo la gestión de la iteración, convocando diariamente al Scrum Daily Meeting que

representa una reunión de avance diaria de no más de 15 minutos con el propósito de

tener realimentación sobre las tareas de los recursos y los obstáculos que se presentan.

Al final de cada Sprint, se realizará un Sprint Review para evaluar los artefactos

construidos y comentar el planeamiento del próximo Sprint.

Como se puede observar en la Figura 3.1 la metodología resulta sencilla definiendo

algunos roles y artefactos que contribuyen a tener un proceso que maximiza el feedback

para mitigar cualquier riesgo que pueda presentarse.

Descripción de roles, artefactos, reuniones y proceso de desarrollo de Scrum.

Fuente: William C. Wake, [email protected], http://www.xp123.com

La intención de Scrum es la de maximizar la realimentación sobre el desarrollo

pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se está

extendiendo cada vez más dentro de la comunidad de Metodologías Agiles, siendo

combinado con otras -como XP- para completar sus carencias. Cabe mencionar que

Scrum no propone el uso de ninguna práctica de desarrollo en particular; sin embargo,

es habitual emplearlo como un framework ágil de administración de proyectos que

puede ser combinado con cualquiera de las metodologías mencionadas.



Un poco más a fondo: Creando el Product Backlog

El Product Backlog es una forma rápida de manejar las necesidades de los usuarios sin

tener que tratar con documentos de gran exigencia formal y tediosas tareas relacionadas

con el mantenimiento de los mismos. La intención es poder responder más rápido y con

menos sobrecarga rápidamente a las cambiantes necesidades reales.

¿Por qué necesitamos el Product Backlog?

Las principales razones para tener Backlog son:

Comunicación a las partes interesadas:

Al tener un Product Backlog, las partes interesadas tienen una imagen de lo que está

previsto y lo que no está previsto. Y al agregar sensación de velocidad, los interesados

también pueden obtener una opinión de la fecha en la que cosas van a ser implementadas.

Comunicación con los desarrolladores:

Los desarrolladores pueden ver la hoja de ruta por delante, pero también pueden ver

las prioridades: lo que deba aplicarse y lo que puede esperar. Esto también puede ser

una buena cosa durante el desarrollo real. Dependiendo de planes para el futuro

cercano, se pueden implementar soluciones diferentes.

Identificar posibles recortes en el ámbito de aplicación:

Al dividir la funcionalidad vaga en partes más específicas, pueden suprimir las cosas

menos importantes por ahora. Y esto puede comunicarse a las partes interesadas y los

desarrolladores.

¿Qué debe contener el Backlog?

Una lista de trabajo.

Requisitos funcionales: historias de usuario, funciones, productos, funcionalidades.

Requisitos no funcionales: rendimiento, robustez, seguridad, facilidad de uso, errores,

los requisitos...

Priorización.

Estimación del equipo.

Tener información más detallada sobre los temas mayor prioridad.

Mantenimiento y publicaciones visibles.



Re-priorización al principio de cada iteración.

¿Qué granularidad debe contener el Backlog?

¿Qué prioridades se establecen?

Se clasifican los elementos entre las siguientes categorías:

1 2

3 4

Debe

Podría No se hacen

Debería

Características que hay que implementarabsolutamente se

clasifican como deben. Si cualquiera de estas

características no se realizan, el proyecto no se considerará

un fracaso

Características que sonimportantes para el

éxito del proyecto, perono son absolutamente

necesarias

Características que no seVan a implementar esta vez

Características que están bien pero no son características

principales, se clasificancomo podría

El iceberg del Product Backlog: la prioridad respecto a los Sprints y las Releases:


TEMA 3 - Ejemplos

Ejemplos

SCRUM. Introducción a la metodología

Presentación de SCRUM. Introducción a la metodología. La materia está encuadrada

dentro de la asignatura Administración y Control de Proyectos Informáticos II de la

Facultad de Ingeniería de la Universidad de Buenos Aires.

El artículo está disponible en el aula virtual o en la siguiente dirección web:

http://materias.fi.uba.ar/7546/material/Scrum_Intro.pdf

Metodologías Ágiles

La presentación de Jorge Ferrer Zarzuela presenta los siguientes objetivos: introducir

los principios de las metodologías ágiles; presentar una metodología ágil real (extreme

programming); explicar cómo aplicar una metodología ágil; analizar cuándo debe

usarse y cuándo no; debatir pros y contras.


http://libresoft.dat.escet.urjc.es/html/downloads/ferrer-20030312.pdf


TEMA 3 - Lo + recomendado

Lo + recomendado

No dejes de leer…

Definición de Scrum

En Wikipedia puedes acceder a una sección donde encontrarás una amplia definición

de Scrum con su historia, características, roles, reuniones, documentos, etc.


http://es.wikipedia.org/wiki/Scrum


TEMA 3 - + Información

+ Información

Webgrafía

Agilefant

Podrás acceder a la web de la herramienta de gestión agile donde existe la posibilidad

de instalar la aplicación y jugar con la misma.

http://www.agilefant.org/

Manifiesto por el desarrollo Ágil del software

Manifiesto por el desarrollo del software con sus principios, firmantes, etc.

http://www.agilemanifesto.org/iso/es/


TEMA 3 - Actividades

Actividades

Práctica: Metodologías Ágiles en el desarrollo del software

Realiza un comentario de texto de no más de dos folios después de la lectura del

documento Metodologías Ágiles en el desarrollo del software. Tendrás que realizar un

breve resumen del contenido y, del mismo modo, deberás elaborar una opinión

razonada sobre el tema y citar las ventajas e inconvenientes de esta metodología.


http://www.willydev.net/descargas/prev/TodoAgil.Pdf


TEMA 3 - Test de autoevaluación

Test de autoevaluación

1. Un diagrama de Gantt sirve para:

A. Relacionar Tareas.

B. Planificar los recursos.

C. Planificar las tareas.

D. B+C.

2. Un diagrama de PERT sirve para:




C. B+C.

3. Los organismos de gestión de un proyecto europeo:




D. B+C.

4. El/los interlocutor/es con la EC es:

A. El coordinador.

B. Los líderes del paquete de trabajo.

C. El coordinador técnico.

D. Los líderes de las tareas.

5. ¿Qué contiene el backlog?

A. La lista de personas del equipo.

B. Los requisitos funcionales.

C. Los requisitos no funcionales.

D. La prioridad de las tareas.

tema3,Implementación de proyectos de

Documents

Transcript of tema3,Implementación de proyectos de