TEMA. 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

Transcripción

1 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 TEMA

2 Esquema TEMA 3 - Esquema

3 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 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.

4 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 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

5 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: EUROPEAN COMISSION A0 Project Coordination & Management External International Advisory Committee (EAC) IPR Audit Committee (IAC) Business Advisory Committee General Assembly Reports, directions... IP Co ordination Committee (IPCC) IP Co ordination (IPC) IP Secretariat (Administrative, financial, legal support) IP Manager (IPM) Executive IP Management (EPM) Controlling path Reporting path (admin) Activity 1 Leader Activity 2 Leader Activity 3 Leader Activity 4 Leader Activity 5 Leader Activity 6 Leader Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 Activity 6 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 Externar Avizor Comité (EAC) IPR Audita Comité (IAC) Business Avizor Comité (BAC) IP Coordinación Committe (IPCC) 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

6 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 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

7 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 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.

8 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.

9 El Diagrama PERT es a menudo acoplado al Diagrama de Gantt 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 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.

10 Fuente: 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:

11 Individuos e interacciones Software funcionando Colaboración con el cliente Respuesta ante el cambio sobre procesos y herramientas sobre documentación extensiva sobre negociación contractual 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 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

12 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.

13 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, William.Wake@acm.org, 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.

14 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.

15 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 Debe 2 Debería Características que hay que implementar absolutamente se clasifican como deben. Si cualquiera de estas características no se realizan, e l proye cto no se consid erará un fracaso Características que son importantes para el éxito del proyecto, pero no son absolutamente necesarias 3 Podría 4 Características que están bien pero no son características principales, se clasifican como podría No se hacen Características que no se Van a implementar esta vez El iceberg del Product Backlog: la prioridad respecto a los Sprints y las Releases:

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

17 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: 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. El artículo está disponible en el aula virtual o en la siguiente dirección web: TEMA 3 - Ejemplos

18 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. El artículo está disponible en el aula virtual o en la siguiente dirección web: TEMA 3 - Lo + recomendado

19 + 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. Manifiesto por el desarrollo Ágil del software Manifiesto por el desarrollo del software con sus principios, firmantes, etc. TEMA Información

20 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. El artículo está disponible en el aula virtual o en la siguiente dirección web: TEMA 3 - Actividades

21 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: A. Relacionar Tareas. B. Planificar los recursos. C. Planificar las tareas. C. B+C. 3. Los organismos de gestión de un proyecto europeo: A. Relacionar Tareas. B. Planificar los recursos. C. Planificar las tareas. 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. TEMA 3 - Test de autoevaluación