En la última década, el desarrollo ágil de software está adquiriendo una gran relevancia en el área de la ingeniería del software, debido a que su adopción en las empresas está revirtiendo en un aumento de la calidad y competitividad en el mercado. Las metodologías ágiles no son sólo una forma de desarrollar software, sino que van más allá. Estas metodologías están basadas en una serie de principios y valores que pueden adoptarse en cualquier tipo de proyecto que se realice de una forma iterativa e incremental. Entre los valores y principios que fomentan las metodologías ágiles están: el trabajo en equipo, el valor de las personas y la comunicación entre las mismas, la capacidad de evaluación y auto-evaluación, el seguimiento del proyecto, la capacidad de adaptarse fácilmente a los cambios que suceden a lo largo del proyecto, etc. Así mismo, estas metodologías proponen una serie de prácticas enmarcadas dentro del desarrollo del proyecto, de tal forma que permiten adoptar estos valores y principios ágiles. Como se puede observar, estos valores y principios no son específicos del desarrollo software, y por lo tanto, se pueden trasladar y adoptar a un proyecto educativo.

Las asignaturas en formato ECTS representan el marco adecuado para adopción de los valores, principios y prácticas ágiles. Además, dicha adopción consigue dar un soporte de calidad para realizar la  evaluación de asignaturas mediante técnicas ágiles, ya que estas técnicas han sido ampliamente probadas y adoptadas con éxito en empresas de gran prestigio. De esta forma, el alumno alcanzaría sus objetivos de aprendizaje de forma satisfactoria, junto con competencias de trabajo en equipo, liderazgo, participación, gestión y defensa oral, entre otras.

En esta propuesta de Proyecto de Innovación Educativa (PIE) se persigue adoptar un subconjunto de prácticas ágiles y la aplicación de una metodología ágil para realizar el seguimiento del ritmo de aprendizaje de los alumnos. De tal forma que el alumno maximice su rendimiento, y mejore los resultados de las asignaturas que cursa, mediante la adopción de valores y principios ágiles y la aplicación de sus técnicas,. Por lo tanto, el objetivo de este PIE es el de implantar un proyecto de aprendizaje ágil para que el alumno y el profesor se beneficien de las ventajas que estas metodologías ofrecen. Concretamente, este proyecto de aprendizaje ágil se desea implantar en asignaturas del título de Graduado en Ingeniería del Software de la Escuela Universitaria de Informática, impartidas por los departamentos de Organización y Estructura de la Información y de Organización de Empresas.  Este proyecto se aplicaría durante el curso académico 2010-2011 para contribuir y mejorar el proceso de implantación del título de Graduado en Ingeniería del Software. Así mismo, la implantación de este proyecto dotaría de un beneficio adicional al alumno, ya que aprendería y aplicaría una metodología de desarrollo ágil de forma natural, adquiriendo una formación y experiencia que se requiere a los alumnos que se gradúan en Ingeniería del Software.

Cabe destacar que la novedad de adoptar valores, principios y prácticas ágiles en la enseñanza abre un amplio campo de estudio y difusión de resultados. Por ello, uno de los objetivos académicos de este proyecto es el de compartir nuevos conceptos y metodologías de enseñanza con el resto de la comunidad académica, así como obtener resultados empíricos gracias a su puesta en marcha.

Por lo tanto, este proyecto de innovación docente se caracterizaría por ser un proyecto:

• Innovador: La adopción de valores y principios ágiles junto con la aplicación de técnicas y metodologías ágiles en el ámbito de la educación resulta innovador y abre un campo muy amplio de difusión de ideas y resultados en revistas y conferencias, tanto nacionales como internacionales
• Interdepartamental: En este proyecto se involucran miembros pertenecientes  dos departamentos diferentes de la Escuela Universitaria de Informática.
• Interdisciplinar: El proyecto abarca diferentes áreas de aprendizaje, empresa y desarrollo de software, y diferentes competencias (conocimiento, calidad técnica, trabajo en equipo, etc.)
• Colaborativo: Trabajo en equipos
• Multimedia: utilización de sistemas colaborativos web y generación de portafolios digitales de las asignaturas y del título grado.

A partir de la motivación y características de este PIE es posible establecer unos los objetivos generales a satisfacer. Estos se detallan a continuación:

• Mejorar el proceso de implantación del Graduado de Ingeniería del Software adoptando los valores, principios y prácticas de las metodologías ágiles.
• Implantar un método de aprendizaje ágil que permita:
  • Mejorar el seguimiento del alcance de los objetivos a adquirir por parte del alumno.
    • Establecer un método de evaluación innovador, iterativo e incremental.
    • Proporcionar mecanismos que permitan adaptarse a nuevas necesidades o situaciones que surjan durante el proceso de aprendizaje del alumno.
• Potenciar y evaluar tanto las competencias técnicas y de aprendizaje del alumno, como las competencias transversales.
• Aprender de forma inherente la adopción de las metodologías ágiles.
• Utilizar métodos de enseñanza/aprendizaje semi-presenciales mediante sistemas colaborativos web que permitan el trabajo en grupo en red y la generación de portafolios digitales.
• Enriquecer los conocimientos adquiridos por el alumno mediante seminarios y ponencias de profesionales de la empresa y docentes de reconocido prestigio en universidades nacionales e internacionales.
  • Publicar las ideas innovadoras del proyecto y los resultados de su puesta en marcha en revistas y conferencias de ámbito nacional en internacional.
  • Aplicar un PIE en el que estén involucrados distintos departamentos de la Escuela Universitaria de Informática (inter-departamental).
  • Desarrollar el proyecto de forma cofinanciada, concretamente la cantidad de 1200 €, entre los distintos proyectos de innovación educativa que se pongan en marcha en la Escuela Universitaria de Informática durante el curso académico 2010-2011.Estos 1200 € serán destinados: 500 € a equipos de sobremesa, 250€ a material fungible y 450 € a difusión de resultados.

Este PIE se basa en los valores, principios y prácticas que soportan las metodologías ágiles y su aplicación dentro del entorno educativo, y por tanto, su puesta en marcha y desarrollo está pautado por dichas metodologías. De entre todas las metodologías ágiles existentes, se ha elegido una de las más adoptadas por grandes empresas de desarrollo software para la gestión de proyectos, Scrum. A continuación se detalla en qué consiste esta metodología, para así, posteriormente describir las fases en que se divide este proyecto.

a)   SCRUM

Scrum es un proceso para la gestión y control del producto software que trata de eliminar la complejidad en estas tareas, para así centrarse en la construcción de un producto software que satisfaga las necesidades del negocio. Scrum se concentra, principalmente, en las personas y el equipo de desarrollo que construye el producto. Su objetivo es que los miembros del equipo trabajen juntos y de forma eficiente obteniendo productos complejos y sofisticados. Los equipos se guían por su conocimiento y experiencia más que por planes de proyecto formalmente definidos. La planificación detallada se realiza sobre cortos espacios de tiempo (denominados iteraciones o sprints) lo que permite una constante retroalimentación que proporciona inspecciones simples y un ciclo de vida adaptable. Así, el desarrollo de productos se produce de forma incremental y con un control empírico del proceso que permite la mejora continua.

Un concepto fundamental en Scrum es el backlog (ver Figura 1). Existen 2 niveles de backlog: el backlog del producto (o proyecto) y el backlog del sprint (correspondiente a una iteración, normalmente de 30 días). El backlog contiene historias de usuario, que representan aquellas características que se pretende que tenga el producto a desarrollar. Es el equivalente a lo que en metodologías convencionales representan los requisitos. El backlog del producto es elaborado por el cliente y el equipo de desarrollo scrum. Cada historia de usuario es evaluada en términos de esfuerzo necesario y luego organizado en sprints, de acuerdo al número de personas del equipo y el tiempo disponible.

     i.        Ciclo de Vida SCRUM

La Figura 1 muestra las fases del ciclo de vida del desarrollo propuesto por el método Scrum, así como la dependencia temporal que existe entre ellas. A continuación se explica cada una de estas fases:

http://picasaweb.google.es/lh/photo/WsHh-S2pYHpppAxv8nsy6Gx17cGdjG2vF0amDGLi55I?feat=directlink

Figura 1. Ciclo de Vida SCRUM

• Fase de Sprint-0 o Pre-game. Durante esta fase cliente y miembros del equipo Scrum definen las historias de usuario. Las historias de usuario son priorizadas por su importancia, según los criterios del cliente, y refinadas para la identificación de las tareas específicas a desarrollar. El resultado de esta fase es el backlog del producto. Finalmente las historias de usuario son agrupadas en sprints de corta duración (aproximadamente de 30 días) según su prioridad.
• Fase de Planificación. Por cada sprint, se realiza una reunión de planificación que establece si las historias de usuario que deben ser implementadas en la iteración actual se pueden llevar cabo con los recursos disponibles. En el caso de no sea posible, se reasignan historias, para no exceder la capacidad del grupo y evitar la sobrecarga. En el caso de que se hayan planificado pocas historias de usuario, se incorporan nuevas historias de usuario a la iteración. La estimación de las historias de usuario se realiza de forma conjunta entre clientes, y el equipo de desarrollo utilizando la técnica del planning game. El objetivo es mover aquellas historias de usuario con mayor prioridad para el cliente al backlog del sprint. Las historias de usuario son ‘congeladas’ en el backlog del sprint de forma que no puedan producirse cambios sobre los aspectos que se encuentran en fase de desarrollo durante el sprint en cuestión.
• Reunión diaria.Durante cada día de que consta el sprint se realiza una reunión operativa, informal y ágil con el equipo de desarrollo, de un máximo de quince minutos, en la que a cada integrante del equipo se le hacen tres preguntas:
  • ¿Qué tareas ha hecho desde la última reunión?
  • ¿Qué tareas va ha hacer hoy?
  • ¿Qué obstáculos ha identificado que puedan impedir su avance normal?
• Fase de revisión. El resultado de un sprint podría siempre es una parte de la funcionalidad final del producto terminada. En el caso de proyectos en los que no haya implementación, el resultado podrá ser un entregable, un documento, parte del producto final, o algún otro artefacto que demuestre los avances realizados en el sprint. En la reunión de revisión del proyecto se muestran estos avances y se incorporan, si fuese necesario, nuevas historias de usuario al backlog del producto.
• Fase de retrospección o análisis. La reunión retrospectiva permite mejorar de forma continua el proceso de desarrollo: el equipo de desarrollo analizará los objetivos marcados inicialmente en el backlog del sprint, las capacidades o habilidades del equipo, las condiciones de negocio actuales, los avances tecnológicos, los aspectos positivos y negativos del sprint, etc. Todo ello servirá de retroalimentación para aplicar los cambios y ajustes necesarios para el siguiente sprint.

   ii.        Roles en SCRUM

Scrum define los siguientes roles:

• el propietario del producto (Product Owner,
•  el maestro de scrum (Scrum Master),
•  el equipo de desarrollo (Scrum Team),
• el cliente o usuario.

El product owner es la persona encargada de la dirección y control del backlog del producto. Es una persona física no una organización o comité, el propio cliente u otra persona que tenga el conocimiento suficiente sobre el producto o pueda estar en continuo contacto con el cliente para marcar las prioridades del proyecto. Es la persona oficialmente responsable del proyecto que de forma visible y objetiva debe tomar todas las decisiones de negocio para el producto. Debe asistir a las reuniones de planificación y de revisión de cada sprint y estar en continuo contacto con el equipo para proporcionar detalles sobre las historias de usuario y constante retroalimentación que dirija el desarrollo del sprint.

El scrum master es la persona responsable del éxito al aplicar la metodología SCRUM en el desarrollo del proyecto o producto, asegurando que los valores, prácticas y reglas son seguidos por el resto del equipo. En concreto, es la persona que asegura el seguimiento de la metodología guiando las reuniones, ayudando al equipo ante cualquier problema que pueda aparecer y controlando que el trabajo sigua el ritmo adecuado.

El scrum team está formado por las personas responsables de implementar el backlog del producto definido por el propietario del producto. El equipo tiene plena autoridad para tomar todas las decisiones que consideren adecuadas en el desarrollo del proyecto, auto-organizándose y auto-disciplinándose. A la hora de formar el equipo, es importante tener en cuenta, que se recomienda que un scrum team no supere los 10 miembros para que la metodología se adopte con éxito.

El cliente es el beneficiario final del producto. Están implicados durante todo el ciclo de vida del producto observando los progresos, aportando ideas, sugerencias o necesidades. Su participación es importantísima e imprescindible en esta metodología.

b)   DESCRIPCIÓN DE LAS FASES DEL PIE

Dados los objetivos del proyecto y las características de la metodología SCRUM, se han definido las siguientes fases:

1.   IMPLANTACIÓN

Para poder adoptar este PIE es necesaria una fase previa a su adopción, llamada implantación. Esta fase consiste en realizar los estudios que se requieran e instalar las infraestructuras necesarias para adoptar correctamente el proyecto. Esta fase se puede dividir en las siguientes acciones principales:

• Estudio de soluciones software con licencia GPL

Hoy en día existen en el mercado herramientas colaborativas que dan soporte a SCRUM, pero como primera aproximación a la implantación de este PIE, es posible utilizar herramientas no propietarias, en las que no es necesario pagar una licencia software. Por lo tanto, será necesario hacer un estudio de aquellas herramientas con licencia GPL que se adecuen lo máximo posible a las necesidades de este PIE.

• Estudio del diseño y adaptación de herramientas

Tras haber seleccionado la herramienta colaborativa que de soporte a este proyecto, será necesario adaptarla para suplir las posibles carencias que pueda tener y diseñar su formato para facilitar la adopción de la metodología. Por lo tanto, se deberá de realizar un estudio de qué extender y cómo hacerlo, así como diseñar la configuración de la herramienta software.

• Diseño e instalación de herramientas colaborativas

La extensión y el diseño obtenidos en la acción anterior se deberán de implementar e instalar junto con la herramienta.

• Creación de manuales de usuario

Se deberá de desarrollar un manual de usuario o guía del alumno que explique las funcionalidades básicas de la herramienta y cómo utilizarla, para que así, el alumno le saque el mayor beneficio posible de dicha herramienta.

2.   DEFINICIÓN Y ASIGNACIÓN DE ROLES

La puesta en marcha de este PIE requiere establecer los roles de cada miembro dentro del proyecto. Para ello se ha de tener en cuenta dos cosas: cuál es el producto y dónde se va implantar.

Por un lado, el producto de este proyecto de aprendizaje ágil es el de superar una asignatura del título de Graduado en Ingeniería del Software en un semestre del curso académico 2010-2011, maximizando la adquisición de conocimientos y competencias transversales por parte del alumno. Se ha de hacer notar, que aunque el producto se define a nivel de asignatura, este producto se puede generalizar en un producto global, siendo este el conjunto de los productos que el alumno obtiene de las asignaturas que desarrolla durante el semestre y/o curso académico.

Por otro lado, este proyecto pretende implantar experiencias piloto en diferentes asignaturas del título de Graduado en Ingeniería del Software. Luego, los roles se definirán a nivel de asignatura:

• Product Owner: Tal y como se ha definido en la sección anterior (ver sección 1.a), el product owner es una persona física, no una organización o comité, el propio cliente u otra persona que tenga el conocimiento suficiente sobre el producto. Por lo tanto, en este PIE el product owner es el profesor que imparte la asignatura en el grupo en el que se implante la experiencia piloto. Además, en este caso el product owner coincide con el cliente del producto, ya que él es el que espera que el alumno supere la asignatura y en qué términos. En aquellos casos en los que se considere conveniente y sean diferente persona, se podría diferenciar entre el product owner y el cliente, siendo el cliente el profesor responsable de la asignatura. En esta fase del proyecto se establecerán qué profesores son los product owners de cada asignatura que participe en la implantación del PIE.
• Scrum Team: Tal y como se ha definido en la sección anterior (ver sección 1.a), el scrum team está formado por las personas responsables de implementar el producto. Por lo tanto, en este proyecto el scrum team es el grupo de alumnos que van a desarrollar la asignatura siguiendo un aprendizaje ágil. El número de grupos por asignatura, así como el número de alumnos que constituyan el scrum team dependerá de la asignatura. Concretamente, el número de alumnos que constituyan el equipo vendrá impuesto por el tipo de trabajos y/o prácticas que se desarrollen en la asignatura. En esta fase del proyecto se definirán el número de alumnos por equipo en cada asignatura y el número de grupos que se quieren poner en marcha. Para ello se tendrán en cuenta dos restricciones, el scrum team no debe estar formado por más de 10 miembros, y no se debe implantar el PIE en toda la asignatura, para así  poder estudiar y hacer comparativas entre los alumnos que siguen el PIE y los que no, dentro una misma asignatura.
• Scrum Máster:Tal y como se ha definido en la sección anterior (ver sección 1.a), el scrum másteres la persona que asegura el seguimiento de la metodología guiando las reuniones, ayudando al equipo ante cualquier problema que pueda aparecer y controlando que el trabajo siga el ritmo adecuado. El Scrum máster, en este caso estará compuesto por dos personas, el que ejerza de scrum master y una persona de apoyo. Concretamente, el scrum master será un alumno del equipo, y la persona de apoyo será un profesor del PIE que no sea ni el product owner ni el cliente. El Scrum máster será rotativo, de forma que todos los alumnos, tomen la responsabilidad de dirigir el equipo, para así desarrollar sus competencias transversales de liderazgo, coordinación, motivación, etc., y ser evaluados por ello. En esta fase del proyecto se definirán los scrum masters de apoyo de cada asignatura, ya que el scrum master no se define hasta que no se pone en marcha el proyecto en la asignatura.

3.   DEFINICIÓN DE BACKLOGS Y SPRINTS

La puesta en marcha de este PIE requiere establecer claramente el backlog del producto (pre-gamme). Uno de los aspectos más relevantes de este enfoque es que el backlog se puede definir desde los objetivos y competencias de las asignaturas y no desde los temarios. Este cambio permite que la posterior evaluación de las asignaturas se pueda establecer e función de los objetivos y criterios de superación de objetivos ideados en la concepción de las asignaturas y no desde la perspectiva organizativa de un temario.

El backlog del producto consiste en definir el conjunto de tareas y competencias que el alumno ha de superar en una asignatura. Esta fase de pre-game la realizarán los profesores de la asignatura. La definición de estos backlogs estará basada en los entregables, las competencias y objetivos establecidos en las Guías de Aprendizaje de las asignaturas de la UPM. Así mismo, estas tareas y/o competencias podrán detallarse más o extenderse, con el objetivo de favorecer los intereses del alumno. Una vez definido, para cada asignatura, sus respectivos backlogs se introducirán en la herramienta software colaborativa que se diseñó e instaló en la fase de implantación.

Además, debido a que las tareas, entregas y tipos de trabajo pueden variar mucho dependiendo de la asignatura en esta fase del proyecto se definirán para cada asignatura la duración de cada sprint. Para ello, se tendrá en cuenta la planificación realizada en las Guías de Aprendizaje de las asignaturas de la UPM de las asignaturas en las que se implante el PIE. Una vez decidida la duración, se podrán establecer las fechas definitivas de las reuniones de revisión y retrospectiva, las cuales se introducirán en la herramienta colaborativa.

4.   DEFINICIÓN DEL PORTAFOLIO ELECTRÓNICO

La puesta en marcha de este PIE requiere establecer claramente las medidas de evaluación y los términos en los que se va a valorar el conjunto de evidencias de aprendizaje por parte del alumno, con el fin de que los alumnos vea sus resultados y progreso en la asignatura a lo largo de los distintos sprints. Estas medidas de evaluación se definirán utilizando técnicas como la de rúbricas propuesta por el Vicerrectorado de Ordenación Académica en su explicación acerca de las Guías de Aprendizaje de las asignaturas de la UPM o similares que resulten adecuadas al objetivo de evaluación del proyecto. Una vez definidas deberán de ser incluidas en la herramienta de desarrollo, vinculándolas al backlog y las reuniones de revisión y retrospectiva. Esto es debido a que en dichas reuniones se evaluarán, dado el backlog establecido para el sprint, cuáles son las evidencias de aprendizaje del alumno. Esta asociación permitirá obtener automáticamente una progresión en el tiempo (las distintas reuniones de cada sprint) del aprendizaje del alumno.

5.   DESARROLLO

Teniendo en cuenta todas las decisiones adoptadas en las fases anteriores del PIE, el proyecto de aprendizaje ágil ya puede implantarse en aquellas asignaturas que se haya decidido. A continuación, se describe el proceso de implantación y desarrollo para una asignatura:

1. Scrum team: Establecimiento del scrum team (o los scrum teams, si se pusiera más de un equipo en marcha). Dar de alta al equipo y a sus miembros en la herramienta colaborativa que dará soporte al proyecto.
2. Preparación: Reunión del product owner, cliente, scrum master de apoyo y el scrum team dónde se explica el modo de trabajo y se proporciona el material asociado a la herramienta colaborativa
3. Sprint 1:
   1. Selección de scrum master para el sprint.
   2. Reunión de planificación: Esta reunión se implanta mediante una tutoría grupal a la que asisten el product owner, el cliente, el scrum master de apoyo y el scrum team, incluido el scrum máster. Aplicando el planning game se seleccionarán el conjunto de tareas del backlog global que se van a desarrollar en el sprint, para así, constituir el sprint backlog. Esta selección se realizará teniendo en cuenta la prioridad de las tareas y sus dependencias temporales.
   3. Reunión diaria: El scrum team y el scrum máster deberán tener una reunión diaria de seguimiento de tareas de una duración menor de 15 minutos, no siendo necesariamente presencial. El scrum máster de apoyo no asistirá a todas estas reuniones, pero si al menos a una semanalmente, y asistirá al scrum master en sus labores de coordinador de equipo.
   4. Reunión de revisión: El día del vencimiento del sprint se hará una evaluación de las tareas acabadas y del grado de satisfacción de sus objetivos en base a los criterios de evaluación definidos en las fases anteriores del proyecto. Esta reunión se articulará mediante una tutoría grupal a la que asistirán el product owner, el cliente, el scrum master, el scrum master de apoyo y el scrum team. En esta evaluación de tareas y competencias derivadas de ellas se realizarán los siguientes tipos de evaluación
      1. Evaluación por el profesor al grupo y a los miembros individualmente
      2. Autoevaluación del grupo
      3. Evaluación entre los miembros del grupo
      4. Autoevaluación de cada miembro del grupo
   5. Reunión retrospectiva: Esta reunión se hará a continuación de la reunión de revisión y en el marco de la misma tutoría grupal con los mismos asistentes. En ella se analizarán los objetivos a alcanzados, los avances, las capacidades o habilidades del equipo e individuales (competencias transversales), etc., tanto los aspectos positivos, como los negativos. Estos se evaluarán con técnicas de evaluación Scrum y su resultado servirá de retroalimentación para el siguiente sprint. De este modo, la reunión retrospectiva permitirá realizar un seguimiento mucho más personalizado del grupo, y por ende del alumno, pudiendo, de esta manera, corregir en un plazo razonable  aquellas carencias que se pudieran presentar. Así mismo los tipos de evaluación que se realizarán son:
      1. Evaluación del profesor al grupo y a los miembros individualmente
      2. Autoevaluación del grupo
      3. Evaluación entre los miembros del grupo
      4. Autoevaluación de cada miembro del grupo
   6. Generación del portafolio: El resultado de la evaluación de las reuniones de revisión y retrospectiva se incluirán en el portafolio del alumno y del equipo dentro de la asignatura.
4. Sprint 2..Sprint n: Se repiten iterativamente las tareas descritas para el Sprint 1.

6.   ANÁLISIS DE RESULTADOS

Durante el desarrollo del proyecto y una vez finalizada su puesta en marcha durante un año académico, será posible hacer análisis empíricos de los resultados obtenidos, algunos de ellos podrían ser los siguientes:

• Comparativas para estudiar las tasas de éxito y fracaso tanto de alcance de objetivos de aprendizaje como de competencias transversales:
  • Dentro de una misma asignatura
  •  Asignaturas distintas
    • Específicas del grado y comunes
    • Interdepartamentales
• Ventajas e inconvenientes de un portafolio digital.
• Retrospectiva en el proyecto para detectar mejoras: Encuestas sobre la implantación del proyecto de aprendizaje ágil a los alumnos.

7.   DIFUSIÓN DE RESULTADOS

La novedad de adoptar valores, principios y prácticas ágiles en la enseñanza abre un amplio campo de difusión de resultados durante el desarrollo del proyecto. Así mismo, una vez finalizada su puesta en marcha durante un año académico, será posible hacer difusión de la experiencia y los estudios empíricos realizados. Por lo tanto será posible realizar:

• Publicación de los conceptos y análisis de resultados en revistas y congresos de carácter docente nacional e internacional.
• Impartición de seminarios sobre cómo adoptar una metodología ágil al aprendizaje y difundir la experiencia.

8.   DEFINICIÓN DE LÍNEAS FUTURAS

Tras un año de aplicación del proyecto y en base la experiencia obtenida, la última fase a desarrollar consistirá en establecer y definir la extensión de este PIE para el próximo curso académico 2011-2012:

• Extendiendo su aplicación tanto dentro de la asignatura como en el número de asignaturas.
• Aplicar más técnicas ágiles, que en esta primera puesta en marcha no se han considerado. Algunas de ellas, dentro del marco del título de Graduado en Ingeniería del Software, podrían ser de gran ayuda a la hora de evaluar aquellas asignaturas que requieren realizar un desarrollo software. Algunos ejemplos de estas técnicas son: acceptance-testing o pair programming.

La evaluación del proyecto presentado se realizará en base a los criterios que se enumeran a continuación:

1. Adopción de la metodología de aprendizaje ágil
   1. Portafolio: El propio portafolio de cada una de las asignaturas constituirá el grado de adopción y su resultado en dicha asignatura.
   2. Análisis de resultados: Proporcionará indicadores de tasa de éxito y fracaso y comparativas con la metodología convencional.
   3. Retrospectiva: Evaluación del progreso y mejora de adopción
   4. Encuesta del alumnado que ha participado en el proyecto piloto
2. Difusión de resultados
   1. Publicaciones en congresos y revistas nacionales e internacionales
   2. Seminarios impartidos