Un Primer Paso a la Agilidad: Retrospectivas para el Aprendizaje de la Ingeniería del SW

Un Primer Paso a la Agilidad: Retrospectivas para el Aprendizaje de la Ingeniería del SW Jennifer Pérez, Agustín Yagüe, Jessica Díaz, Santiago Alonso Departamento de Organización y Estructura de la Información E.U. Informática.Universidad Politécnica de Madrid (UPM) Madrid, España jenifer.perez@eui.upm.es, agustin.yague@upm.es, yesica.diaz@upm.es, salonso@eui.upm.es Resumen. En los últimos años la industria software demanda, cada vez más, ingenieros que posean conocimientos y experiencia en la aplicación de metodologías ágiles. Por otro lado, los principios y valores en los que se basan las metodologías ágiles fomentan la adquisición de competencias como la capacidad de organización, el trabajo en equipo, la comunicación, o el liderazgo, entre otras, denominadas en el marco del Espacio Europeo de Educación Superior (EEES) como competencias generales o transversales. Ambas razones justifican la adopción de las metodologías ágiles como métodos de aprendizaje activos, es decir, la implantación de metodologías ágiles durante todo el ciclo formativo del ingeniero software. Esta apuesta se ha materializado en el proyecto de innovación educativa Agile Learning - Aprendizaje Ágil, cuyos primeros pasos, resultados y lecciones aprendidas se presentan en este artículo.1 IntroducciónEl dinamismo y variabilidad de la actual industria software requiere la adaptación delas formas de desarrollar aplicaciones para ajustarse a un mercado cambiante y a lareducción de la vida de los productos [1]. El ciclo de vida de los productos yservicios software se acorta, lo que obliga a incrementar la productividad, adisminuir el tiempo de reacción, y a adaptarse rápidamente a los cambios y a lasnuevas necesidades de los clientes. Los métodos ágiles surgieron a partir delManifiesto Agile [2] como solución a las necesidades de la industria software actual.De hecho, desde el punto de vista de las metodologías ágiles el cambio se percibecomo una oportunidad para mejorar el sistema e incrementar la satisfacción delcliente; la gestión del cambio se convierte en un aspecto inherente al propio procesode desarrollo software, mejorando así su adaptación a entornos cambiantes. En la última década, el desarrollo ágil de software ha adquirido una gran relevanciaen el área de la industria software, debido a que su adopción en las empresas estárevirtiendo en un aumento de la calidad y competitividad en el mercado [3]. En losúltimos años, este evidente interés a nivel internacional por la adopción demetodologías ágiles [3], se está trasladando al ámbito nacional. Pero para dar un pasoadelante y llegar a equipararnos nacionalmente en esta adopción ágil con otros países,

es necesario que nuestros ingenieros de software no sólo dispongan de habilidades yconocimientos sobre la implantación de un desarrollo convencional, sino también deldesarrollo ágil. Es por ello, que la primera semilla o primer paso debemos darlo en suformación en ingeniería del software, de manera que los ingenieros de software que seincorporen al mundo laboral tengan las habilidades y conocimientos necesarios paraponer en marcha metodologías ágiles. Esto hace indispensable que los contenidosnecesarios para el aprendizaje de las metodologías ágiles se impartan en asignaturaspertenecientes a la rama de ingeniería del software. Pero además, en este artículo sepresenta una apuesta hacia la agilidad todavía mayor, la adopción de metodologíasdurante todo el ciclo formativo del ingeniero de software. Esta apuesta se hamaterializado en un proyecto de innovación educativa llamado Agile Learning -Aprendizaje Ágil [4]. El fundamento de este proyecto y el marco perfecto para suaplicación es la necesidad actual de la universidad española de adaptarse al EspacioEuropeo de Educación Superior (EEES). El EEES marca unas directrices a seguir, que afectan, no solo a la forma en que elalumno debe aprender, sino que también afectan a la forma en que el profesor debeenseñar, caracterizándose principalmente por un modelo de evaluación continua ymodelo de aprendizaje basado en competencias, tanto generales como específicas. Hasta ahora, la universidad se había ocupado únicamente en las competenciasespecíficas, es decir, la adquisición y desarrollo de conocimientos por parte delalumno. Sin embargo, el gran reto y cambio de la adaptación al EEES radica en laadquisición por parte del alumnado de competencias generales, es decir, capacidades,habilidades y/o aptitudes que el alumno debe desarrollar para aplicarlas a lo largo desu carrera profesional. Para cumplir dichas competencias generales se necesitan demétodos de aprendizaje activos que permitan que los alumnos desarrollen capacidadescomo: (i) Capacidad de organización y planificación; (ii) Comunicación; (iii)Liderazgo, (iv) Capacidad de evaluación y auto-evaluación; (v) Trabajo en equipo;(vi) Entrega de trabajos de calidad para el profesorado (vii) Seguimiento del procesode aprendizaje del alumno, etc. En este sentido, las metodologías ágiles proporcionan unos principios, valores, yprácticas que se presentan como una solución para esta necesidad [5]. Esto es debidoa que por un lado, posibilitan la adquisición de todas estas competencias de formaflexible y sencilla, y por otro lado, permiten que los ingenieros de software apliquenuna metodología ágil durante toda su formación. Esto permitirá no sólo mejorar lapreparación de nuestros ingenieros de software, sino que también, cuando uningeniero de software se incorpore al mundo laboral, tendrá la experiencia de 4 añosde aplicación de metodologías ágiles. En este artículo presentamos la idea global del proyecto Agile Learning -Aprendizaje Ágil1, el cual ha adoptado la metodología ágil Scrum [6, 7] y la haadaptado a un marco de trabajo académico. En concreto, en este trabajo se presenta laimplantación del trabajo en equipo, de entregas frecuentas en iteracionesincrementales y de reuniones retrospectivas. El proyecto ha sido aplicado en algunasasignaturas impartidas en el Departamento de Organización y Estructura de laInformación (OEI) [8] de la Escuela Universitaria de Informática (E. U. Informática)1 De ahora en adelante Agile Learning

[9] de la Universidad Politécnica de Madrid (UPM a través de la plataform de tele- P e M), d maenseñanz (moodle) [10] desarrollad en el marco del proyecto [4]. za da o La esttructura del artículo es la siguiente: el apartado 2 in ntroduce brev vemente lapropuesta del proyecto Agile Learn a o ning de adopta metodologí ágiles en e proceso ar ías elde apren ndizaje de la ingeniería d software. En el apar a del rtado 3, se eexplica lacontribucción de este artículo, m mientras que el apartado 4 detalla su soporte utecnológi ico. Finalmennte, el aparta ado 5 realiza una reflexió sobre las lecciones ónaprendida de la imp as plantación de esta propuesta, y el apa artado 6 pressenta lasconclusioones y los trab bajos futuros.2 Adopción de Metodología Ágiles en el Aprendi M a izajeLa incorrporación de metodología ágiles al ámbito aca e as adémico requ uiere unaadaptació al contexto de la enseñan en general, y al de la universidad, e centro y ón o nza, u ella asigna atura en el que se impart la docencia, en particu q te ular. Concreta amente, elproyecto Agile Learnin [4] se ha a ng adoptado la meetodología ágil Scrum [6, 7 y se ha 7]adaptado al contexto de las asignaaturas de Tecnologías de Desarrollo de Sistemas D eWeb (TD DSW) y Gesti de Proye ctos y del Ri ión iego (GPRS) que se impar arten en eldepartam mento OEI [8] de la E.U. Informática [9] de la UPM En esta s ] [ M. sección sedescriben brevemente Scrum y la ad n daptación que se ha realiza en el proy e ado yecto parasu adopci en el conte ión exto de la ens señanza en el que se quiere implantar. q2.1 Met todologías Ág giles : ScrumScrum [6 7] es un método ágil cen 6, m ntrado en la gestión de proy g yectos. Por el resulta llo,ser un méétodo óptimo para el apren ndizaje de técnnicas de plani ificación y segguimientode proyeectos. La retr roalimentación entre iterac n ciones constituye el elem mento máspotente d la metodología. El soft de ftware es desarrollado por equipos que se auto- r eorganizan en ciclos de corta durac n d ción (no más de 30 días) denominado sprints, s ) oscomenzan cada uno de ellos con u planificac ndo una ción y finalizaando con una revisión yretrospec ctiva. La Fig. 1 muestra, de forma simplif ficada, este modelo. Fig. 1. M Modelo de pro oceso Scrum

Las historias de usuario (requisitos) que deben ser implementadas son registradasen lo que se conoce como backlog de producto. El propietario del producto prioriza ydecide cuáles son las historias de usuario más importantes que deben serimplementadas en el siguiente sprint. Los miembros del equipo coordinan sus trabajosa través de reuniones diarias de no más de 10 minutos. En ellas, uno de los miembrosdel equipo, conocido como el maestro Scrum, ayuda a solucionar los problemas quevayan surgiendo para que el trabajo sea más eficiente.2.2 Aprendizaje ÁgilEl proyecto Agile Learning persigue dotar al alumno, futuro ingeniero de software,del beneficio adicional de aprender y aplicar una metodología de desarrollo ágil deforma natural, adquiriendo una formación y experiencia que se le requerirá en suincorporación a la industria software. Este proyecto de innovación docente secaracterizaría por ser un proyecto:  Innovador: La adopción de valores y principios ágiles junto con la aplicación de técnicas y prácticas ágiles en el ámbito de la educación resulta innovador y abre el camino hacia la agilidad.  Interdepartamental: En este proyecto se involucran miembros pertenecientes dos departamentos diferentes de la E. U. de Informática de la UPM: la Unidad Docente de Empresas y el Departamento de OEI.  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 plataformas de tele- enseñanza. Scrum, como metodología, propone un conjunto de procesos y de artefactosorganizados en sprints de manera que se obtenga el máximo beneficio de la rápidarespuesta del cliente al trabajo desarrollado. La implantación del modelo de procesoScrum a la enseñanza requiere de un proceso de análisis para su adaptación alcontexto específico en el que se va a implantar. Esta adaptación se debe plantear a dosniveles: por un lado la forma en que se va a trasladar el proceso Scrum al proceso deenseñanza. Y por otro, la identificación de los artefactos utilizados y del concepto deproducto final y de working product durante el proceso de enseñanza. Dentro del marco del proyecto Agile Learning, se han definido los conceptos deproducto final y working product para, a partir de ellos, adoptar Scrum. Un workingproduct en el ámbito académico es la entrega de un trabajo o un conjunto de trabajosque el profesor considera de valor como para que el alumno haya adquirido una seriede conocimientos y competencias generales evaluables. La entrega del producto finaltiene como resultado final la superación de la asignatura, lo que implica que elalumno ha adquirido el conocimiento y competencias requeridas por la asignatura.Por lo tanto, el producto final lo conforma el conjunto de working products que elalumno entrega al profesor y son evaluados a lo largo del tiempo en el que se impartela asignatura. El producto final se obtiene como resultado de un proceso deaprendizaje iterativo e incremental.

Dadas las particularidades del sistema educativo en relación con la inercia defuncionamiento, infraestructuras y la adopción de nuevas prácticas, metodologías,etc., no es factible la implantación completa de Scrum como base del modelo deaprendizaje en un único paso. Por ello, el proyecto Agile Learning define una hoja deruta que permite esta adopción de Scrum en el ámbito educativo universitario de unaforma iterativa, incremental y viable. El objetivo de la hoja de ruta es ayudar areproducir esta experiencia en otros centros guiándoles en aquellas cuestiones que hande tener en cuenta a la hora de su implantación. Esta hoja de ruta se divide en diversasfases que se detallan a continuación (ver Fig. 2):1. Definición del equipo Scrum. Los equipos Scrum están formados por un conjunto de alumnos. Estos pueden ser de diferente índole y número dependiendo de un conjunto de aspectos a tener en cuenta: a. Número de alumnos involucrados: Se recomienda que los equipos estén formados por un número de alumnos que permita reproducir el ambiente de un grupo de trabajo. Por ello, se recomienda que se encuentre entre 4 y 6 alumnos, aunque no es preceptivo, ya que hay asignaturas que por su índole requieren un número mayor o menor. b. Trabajos a realizar: El número y tipo de los trabajos a realizar dependerá de la naturaleza y complejidad de los trabajos a realizar. No tendrá mucho sentido crear equipos cuando todas las tareas a realizar por los alumnos sea individuales. c. Carácter del equipo: i. Equipo transversal a diversas asignaturas: el equipo podrá ser el mismo para diversas asignaturas cuando éstas permitan la definición de un único backlog de producto que el equipo pueda manejar y no sea relevante durante la realización de los sprints el estado en el que se encuentra el aprendizaje de una materia. ii. Equipos independientes entre asignaturas: el equipo varía en las asignaturas en número y en los miembros que lo conforman. Esta es la situación habitual y los alumnos tendrán que manejar diferentes backlogs de producto.2. Definición de los Sprint: Una iteración o sprint suele durar entre 2 o 4 semanas. En este caso, la temporalidad de la iteración la determinará el profesor en base a dos posibles criterios: por temas/bloque de temas o por entregas de trabajos. Se proponen estos dos indicadores, debido a que no siempre la entrega de trabajos coincide con el fin de un tema. Cada asignatura puede plantear duraciones diferentes para los sprints y se recomienda que, dentro de una asignatura, la duración del sprint se mantenga constante. Eso sí, siempre debe estar claro desde el comienzo las iteraciones que tiene la asignatura, los temas que conforman cada iteración y los entregables asociados que se evaluarán al final de la iteración.3. Selección de prácticas ágiles a adoptar: La adopción ágil educativa debe ser paulatina e incremental para que siempre tanto el alumno como el profesor vea una mejora en el proceso educativo y crezca su interés por el mundo ágil de forma natural. El cambio completo es demasiado grande para el modelo educativo universitario y podría acabar en fracaso. Por este motivo, en este artículo proponemos siempre comenzar por la organización en equipos y sprints

y co alguna ac on ctividad que tenga que ver con la gestión de lo grupos. v g os Conccretamente, y con el obje etivo de inten ntar cubrir la necesidad d que el a de alum mnado desarro olle sus com mpetencias tra ansversales [5 En este t 5]. trabajo se propone comenzar por las reuni r iones retrospectivas.4. Adoppción y adap ptación de las prácticas seleccionadas al contexto: Una vez s s selec ccionada una práctica, para poder adopta hay que ver cómo artic p arla v cular dicha activ vidad dependieendo del conte exto del equip Scrum. Esto radica princ po cipalmente en la cantidad de horas de trab a bajo que dispponga el equip Scrum par realizar po ra traba conjunto in situ: existir casos en que los alumn trabajen a ajo i rán q nos además de estud diar, y hagan el trabajo a diistancia de for colaborat rma tiva, pudiend reunirse do solo de manera esporádica. Y otros en los que los equ e s uipos Scrum c comparten much horas de trabajo y clase juntos. En base a ello se deberán de to has t e b omar unas medi idas de adapta ación para la c correcta adopc ción de la activ vidad. Fig. 2. Ho de Ruta de Adopción de Agile Lear oja d rning3 Retro ospectivas para el Ap rendizaje de Ingenier del SW d ríaDesarroll ágil sign lo nifica mejora continuam ar mente la form de trab ma bajar. Lasretrospectivas represen ntan un meca anismo adecuado para com menzar a iden ntificar lascosas que se pueden mejorar [11]. L retrospectivas se llevan a cabo al fin e m Las n inalizar unsprint y se centran en analizar lo que ha funcionado bien, lo que no se ha hecho n lcorrectammente y lo qu se puede mejorar para la siguiente iteración. Es ue stas duranalrededor de 2 horas y constan de las siguiente fases: desc r e es cripción de la práctica, aidentifica ación de probl lemas, identif ficación de las causas, establecimiento d un plan dede acción y conclusio n ones. En el ám mbito de la enseñanza no es posible ap e plicar estemismo fo formato ya qu un grupo de trabajo no suele ded ue n dicar más de 10 horassemanale a cada asign es natura y dedic 2 horas a analizar el trab supondría una gran car a bajo asobrecarg de control Por ello, e s necesario buscar una pa ga l. b articularizació que se ónadapte a l características del entorn las no. En el ccaso del proye Agile Lea ecto arning, las ret trospectivas co onsisten en un reunión naen horari de tutorías con el profes de la asig io sor gnatura tras la entrega y re a evisión delworking p product. A es reunión deb asistir fís sta eben sicamente los miembros del equipo y lse comple con una ev eta valuación del equipo y de sus miembros que formará p s parte de lacalificación del workin product en ng ntregado. Esta reunión sirve para que el equipo se a eauto-eval como grup de trabajo. De ahí que se requiera la presencia de cada uno lúe po . s ede los mmiembros, y si no es posi s ible, facilitar la conexión a distancia c con algúnsoftware que permita realizar tele econferencias. En esta aut to-evaluación se tratantantos los puntos positi s ivos y negativ como los puntos a mejo del funcio vos, orar onamientoen equipo para el sigu o uiente sprint y de cada un de los miem no mbros individ dualmente.Así mism el profeso les evalúa i mo, or indicándo qué cosas deben subsanar o m é n mejorar, y

reforzar aaquello que realicen de fo r orma satisfacto oria. Es impo ortante destaca que las arretrospectivas las empplea el profes para eval sor luar las comppetencias gen nerales delaprendiza mientras que las com aje mpetencias esspecíficas de la misma se evalúan emediante las revisiones de los sprin Esto es fu nts. undamental, ya que se ha de hacer un a eanálisis y seguimiento de cómo cad uno de los miembros alcanza como eq da m quipo y deforma inddividual las competencias generales que se les requie e eren. De este modo, seasegura q siempre en todas las re que e etrospectivas se analicen es temas y s consiga s stos serealizar u seguimiento de la evoluc un ción de cada una de estas competencias generales cde la asig gnatura. Fig. 3 Agi Learning Retrospective ile R Ademá de esta ad ás daptación de l reunión ret la trospectiva al ámbito acad l démico, laretrospectiva se ha extendido media ante la realizac ción de una ev valuación no p pública delas comp petencias adqu uiridas despu de la reu ués unión retrospe ectiva. Esta eevaluaciónprivada s realiza a través de la p se plataforma Moodle adaptad en el proy M da yecto (versección 4 Dicha eval 4). luación es neccesaria, ya que en el ámbito académico e buen o o elmal func cionamiento como equipo y como miembros de éste, va afe o m ectar a lacalificación final en la asignatura. C el objetiv de evitar su a Con vo uspicacias, co omplicidady/o falta de sinceridad en la calific d cación, la callificación se hace de forma privada. h aDicha ev valuación con nsta de tres evaluaciones evaluación del profeso a cada s: n ormiembro y al grupo, la auto-eval luación de ca miembro del equipo, y la co- adaevaluació de un miem ón mbro del resto de miembros del equipo. Por lo tanto, l reunión o laretrospectiva se redefin como se mu ne uestra en la Fi 3. ig. La apllicación específica, en el ám mbito de los esstudios de la Ingeniería del Software, Ise realiza de forma inc a cremental, tan en la meto nto odología (com ya se ha me mo encionadoanteriorm mente) como en el número d asignaturas involucradas Concretame e de s s. ente, se haimplantad en dos asig do gnaturas: Tecn nologías de Desarrollo de Sistemas Web (TDSW) D S by Gestión de Proyecto y del RieSg (GPRS). En el caso de TDSW, la ad n os go E dopción serealizó soobre un subc conjunto de a alumnos. Se formaron tres equipos Scr f s rum comoproyecto piloto, y en el caso de GPR la implant e RS tación se reali sobre el to de los izó otalalumnos de la asignatu En el cas de TDSW fueron 3 equi ura. so ipos de 3 alummnos cadauno. Y en el caso de GPRS, se orga n G anizaron 21 equipos Scrum formados po 4, 5 o 6 m oralumnos, siendo mayoritariamente g grupos de 5 al lumnos. La na aturaleza de lo equipos osScrum er de una gran variedad, en muchos casos todos los com ra s mponentes traabajaban yestudiaba simultáneam an mente, y por tanto el trab bajo normalme ente se hacía de formacolaborat uida, con los retos que est implica par el trabajo e equipo tiva y distribu to ra en[12].

4 Moo odle Agile Learning LTodo este soporte ágil para el apren e l ndizaje y eva aluación de assignaturas de ingenieríadel softwware y por ende, aprend dizaje de me etodologías ágiles en un contexto áacadémic requiere de una gestión organizada, debido al volu co, e d umen de equip que se poshan de gestionar de fo orma simultán y sincroni nea izada. Para el se ha esp ecializado llo,una plataaforma de en nseñanza Mo oodle [10] pa la constru ara ucción una p plataformaespecífica con las características re a equeridas para implantar este nuevo co a e oncepto deaprendiza ágil. Esta plataforma s conoce com Agile Moodle [4]¡Erro No se aje se mo or!encuentr el origen de la referen ra ncia.. En esta sección se va ilustrar có a ómo dichaherramien da soporte a la def nta finición de iteraciones, equipos y fi e inalmente,retrospectivas. CO ONFIDEN NCIAL Fig. 4 Ge estión de equ uipos Scrum. La her rramienta está orientada al trabajo colaborativo basad en grupos d trabajo. á do deA cada g grupo se le ofr rece un conjun de herram unto mientas colaboorativas para ffacilitar eldesarrollo de su trabajo Estas herra o o. amientas solo tienen visibili idad a nivel de grupo lo eque les ppermite aislar los contenido y asegurar la privacidad de sus conte os d enidos. LaFig. 4 muuestra el listad de los 21 g do grupos que par rticiparon en el proyecto en el marco e nde la asig gnatura GPRS. En cuanto a la organizació de la asign ón natura, los con ntenidos seestructura en iteracion En cada i an nes. iteración, se definen tareas y trabajos a d d desarrollar,y se pone a disposició de los equ e ón uipos el mater y docume rial entación nece esario paraadquirir l conocimie los entos específic de la asign cos natura. Por ejemplo, en la a asignaturade GPRS se definieron un total de 6 iteraciones. En las que se proporciona e material n E elque se immparte, el con njunto de entreegables que conforman el working prod c duct de laiteración, y finalmente las reuniones entre ellas re , s, etrospectiva (v Fig. 5). ver El cal lendario de la iteración es el que establece la fecha para la reunión e f aretrospectiva física. Una vez celeb U brada la reun nión física, se habilita la actividadllamada r retrospectiva dentro de la plataforma para que los alumnos y el profesor p l

puedan reealizar la eval luación, auto-e evaluación y co-evaluación del equipo du c n durante esaiteración en base a las conclusion de la re l nes eunión retrosp pectiva física En esta a.evaluació privada, vía la platafor ón rma Agile Moodle, se eva Mo alúan las commpetenciasgenerales objeto de la asignatura. Po ejemplo, en la asignatura de GPRS se evaluaron s or n alas comp petencias: Cappacidad de A Análisis, Capaacidad de Org ganización, TTrabajo enEquipo, RRazonamiento Crítico, y L o Liderazgo. Dicha evaluaci se realiza mediante D ión auna tabla en la que se permiten va a e alorar del 1 al 10 cada un de las com a na mpetenciasgenerales a cada uno de los miemb s bros del equip obteniendo una nota de su auto- po, eevaluació co-evaluac ón, ción, y evalu uación del profesor de las competencia a nivel s asindividua y en equipo (ver Fig. 6) . Finalmente, se obtienen informes que permiten al o eanalizar y realizar un seguimiento d la evolución de adquisición de compet s de n tencias delequipo y de sus miemb (ver Fig. 7 ). bros Fig. 5. Definición de iterac ciones: materia working product y reunion al, nes Fig. 6. Re etrospectiva de Evaluación de Competencias Generales e d

Fig 7. Informe de la Capacidad de Análisis de la Retrospec g. d d ctiva de la Itera ación 55 Lecc ciones apre endidasEsta sección presenta de forma resumida la primeras lecciones que se han a as l ueconsolida a la finalización de lo s cursos de las asignaturas TDSW y G ado GPRS. Laslecciones aprendidas se presentan en dos grupo sobre las metodologías ágiles y s s os: ssobre las materias espe ecíficas de Ing geniería del so oftware. rendizaje de Metodologías Ágiles5.1 Apr M sDebido a que los alum mnos no estab familiariza ban ados con Scru ni con las prácticas um ságiles, fu necesaria un sesión inici de presenta ue na ial ación de la meetodología. Lo equipos osde GPRS necesitaron aproximadam S a mente tres itera aciones para asimilar la nue forma a evade trabaja y alcanzar de forma regu los objetiv de las itera ar d ular vos aciones. Durant las primeras iteracione los grupo tenían un comportami te es, os iento máscercano a estructuras jerárquicas d funcionam de miento en cuan a la asign nto nación detareas. Al final del cur la mayorí de los grupo trabajaban de forma pro l rso, ía os, n oactiva, loque aume entaba la mottivación en la realización de los trabajos. También d a d durante lasprimeras iteraciones, las retrospect tivas reflejaban problemas de asimilac s ción de lametodolo ogía. Los pro oblemas de f funcionamient detectados estaban dir to s rectamenterelacionaados con los propios proc cesos de Scr rum, según avanzaba el c a curso, losproblema se fueron centrando en la resolución de conflictos int as n c ternos defuncionam miento y no tanto de la ad t dopción. Un aspecto relevan de las con a nte nclusionesemitidas por los particcipantes en el proyecto es que tenían la sensación de tener las l a ematerias más controla adas, fundame entalmente po el seguimi or iento y la ado opción deScrum co omo forma de trabajo. Ta d ambién se de etectaron alguunos problem mas, sirvancomo eje emplo: falta de participació de algunos alumnos, ab d ón bsentismo o p problemaspara com mpaginar la dedicación ex d xigida con otras materias impartidas de forma o sconvencio onal. Algunos de estos pro s oblemas no pu udieron ser resueltos, inclus a pesar sodel papel activo que lo profesores t l os tuvieron para buscar soluci iones. Si bien no puede nhacerse rresponsable a la metodolog de la apa gía arición de esto problemas,, tampoco ospermitió encontrar una solución para los mismos. a a

5.2 Aprendizaje de Ingeniería del SoftwareCon respecto a los contenidos específicos de las materias incorporadas al proyecto,pueden extraerse los siguientes conclusiones. La utilización de metodologías ágiles noha representado una mejora en el aprendizaje de contenidos con respecto a losresultados de años anteriores, al menos en la asignatura de TDSW. Es decir, losconocimientos adquiridos son los mismos. Sin embargo, el hecho de realizar con ellosreuniones periódicas de revisión de working product les hacía llevar al día lostrabajos, algo que también ocurre cuando los alumnos están inmersos en asignaturasguiadas por evaluación continua. Esto ha implicado que el índice de éxito en lasasignaturas haya sido alto, si bien no puede extrapolarse a que en todos los casos deaplicación puedan obtenerse resultados semejantes. Con respecto a los contenidos, alser evaluados periódicamente, aquellos alumnos con menor disponibilidad temporalfueron los que no consiguieron resultados satisfactorios. Esto puede apuntar que laaplicación de este tipo de metodologías en la enseñanza no sea la más adecuadacuando los estudiantes tienen que compaginar el estudio con otro tipo de actividades(laborales, familiares, etc.). Con respecto a la adquisición de competencias generales, los miembros del grupode trabajo han podido comprobar que ya soloel hecho de indicar a los alumnos quevan a ser evaluados en dichas competencias, provoca en ellos una reacción que leslleva a cuidar mucho más todos los aspectos que tienen que ver con dichascompetencias y por tanto, una mejora en la disposición a practicar con corrección lashabilidades que se las proporcionan. En el marco del proyecto se han tenido en cuentaaspectos como la "dirección" o liderazgo y organización. Por otra parte, el hecho detrabajar en equipo hace que las calificaciones individuales sean más complicadas deobtener por parte de los docentes, ya que al no existir una prueba final individual, escomplejo diferenciar el nivel de conocimientos alcanzado por cada miembro delequipo. Por último hay que destacar que los aspectos relacionados con la obtención decalificaciones cruzadas entre alumnos (co-evaluaciones) siempre aportan una serie decompromisos entre ellos que pueden provocar que dichas evaluaciones no sean nuncanegativas a no ser que en los equipos reine el caos más absoluto como formaorganizativa6 Conclusiones y Trabajos FuturosHoy en día, el desarrollo ágil de software ha adquirido una gran relevancia en el áreade la industria software y hay un gran interés en la adopción de las metodologíaságiles. En este artículo se propone como primer paso hacia la agilidad, el que losingenieros de software que se incorporen al mundo laboral tengan las habilidades yconocimientos para poner en marcha metodologías ágiles. Para ello, se hace necesarioque en las titulaciones de Ingeniería del Software se impartan estas metodologías. Sinembargo, en este artículo se da un paso más adelante, y se apuesta por una puesta enmarcha de las metodologías durante la formación del ingeniero. De este modo, supreparación será mayor y su adaptación al mundo laboral ágil será instantánea. En este artículo se presentan los primeros pasos para la adopción de metodologíaságiles en el ámbito académico como resultado de la implantación del proyecto Agile

learning. En línea con el proyecto, este artículo presenta la experiencia de impulsarlos principios y valores en los que se basan las metodologías ágiles para obtener dosventajas fundamentales: su aprendizaje y el fomento de la adquisición decompetencias generales como la capacidad de organización, el trabajo en equipo, lacomunicación, o el liderazgo, entre otras. Concretamente, este artículo presenta unaguía de implantación del trabajo en equipos y reuniones retrospectivas para que puedaser reproducida dicha adopción por otras instituciones. Además, presenta el soportetecnológico necesario para esta adopción, una plataforma de tele-enseñanzaespecializada para las necesidades planteadas. Este trabajo abre un camino muy largo que recorrer con una gran de trabajosfuturos, entre los que cabe destacar la adaptación de cada una de las técnicas yprácticas ágiles al ámbito académico y la mejora y construcción de mecanismostecnológicos que lo faciliten y lo hagan viable. Este es el primer paso hacia laagilidad.AgradecimientosEste trabajo está cofinanciado por el proyecto de innovación educativa AprendizajeÁgil- Agile Learning perteneciente al proyecto de innovación educativa de la E.U.Informática de la UPM y el proyecto INNoSEP: INcorporing inNOvation in SoftwareEngineering Processes TIN2009-13849. Además, los autores quieren hacer unagradecimiento a los miembros del proyecto Agile Learning, y en especial a losprofesores Jorge Tejedor y F. Javier Gil por el esfuerzo realizado en la implantaciónde estas ideas en la asignatura TDSW junto a los autores de este artículo. Finalmente,agradecer a Pablo Ortíz el trabajo realizado en el desarrollo de la plataforma AgileMoodle que ha permitido hacer realidad dicho proyecto.Bibliografía1. Boehm, B.: A View of 20th and 21st Century Software Engineering. In: 28th international conference on Software engineering, pp. 12--29. Shanghai, China, 2006.2. Agile Manifesto, 2011, http://agilemanifesto.org/3. Ambler S.: Agile Adoption Survey February 2008 www.agilemodeling.com/surveys4. Plataforma Moodle Agile Learning, http://agilelearning.eui.upm.es/5. Díaz, J., Pérez, J., Yagüe J., Alonso, S., Gil J.: Análisis Empírico del Papel de las Competencias Generales en el Marco de los Estudios Superiores, XVII Jornadas de Enseñanza de la Informática (JENUI 2011), Julio 2011.6. Schwaber K.: Agile Project Management with Scrum, Microsoft Press, 2004.7. Schwaber K. and Beedle M., Agile Software Development with Scrum, Prentice Hall, 2001.8. Departamento de Organización y Estructura de la Información (OEI), https://srvoei.eui.upm.es/web/9. Escuela Universitaria de Informática, http://www.eui.upm.es10. Moodle, http://moodle.org/11. Crispin, L., Gregory, J.: Agile Testing: A Practical Guide for Testers and Agile Teams, Addison-Wesley Professional, 2009.12. Eckstein J.: Agile Software Development with Distributed Teams. Dorset House Publ. Co., Inc., New York, NY, USA 2010.

Un Primer Paso a la Agilidad: Retrospectivas para el Aprendizaje de la Ingeniería del SW

by Agile Spain on Dec 20, 2011

Accessibility

Tags

Upload Details

Usage Rights

Statistics

Un Primer Paso a la Agilidad: Retrospectivas para el Aprendizaje de la Ingeniería del SW — Document Transcript