DATOS DE IDENTIFICACIN Autor: Raudel Arteaga Tovar. Institucin de adscripcin: Instituto Tecnolgico Superior Zacatecas Sur.

r. Direccin electrnica: rnod@live.com.mx rea temtica: Currculo. Nombre de la ponencia: Anlisis de la aplicacin de la metodologa Scrum en proyectos de software escolares

RESUMEN
Las metodologas tradicionales de desarrollo han planteado un sinfn de posibles mejoras al proceso de desarrollo, pero resulta claro que aun siguen presentndose deficiencias que hasta el da de hoy no ha sido posible corregir. Scrum es una metodologa gil, no tradicional, que en la actualidad es considerada como una de las que mejores resultados han aportado al proceso de fabricacin de software. En los ltimos aos una nueva metodologa de desarrollo ha tratado de abrirse camino en la industria del software, sin que haya despuntado en forma definitiva, pues aun existe una gran cantidad de detractores que se oponen a su implementacin. Quizs por desconocimiento o tal vez por un arraigo tan grande en cuanto a los modelos que suponen las metodologas tradicionales no se le abren las puertas a esta nueva forma de crear software. En el Instituto Tecnolgico Superior Zacatecas Sur (ITSZaS) hasta el da de hoy, nicamente se haban considerado metodologas tradicionales para ilustrar a los alumnos sobre el proceso de fabricacin de software. A raz del presente proyecto, con la inclusin novedosa de una metodologa gil, se han creado nuevas expectativas al respecto de estas tcnicas de desarrollo de software. Desde el punto de vista de una Institucin educativa de nivel superior, debemos estar siempre a la vanguardia con respecto a nuevas tecnologas. Concretamente dentro de la Ingeniera en Sistemas Computacionales y dado que la especialidad de nuestra carrera es la Ingeniera de Software resulta primordial abrirnos a metodologas que a diario estn surgiendo en el contexto del desarrollo de software.

ANTECEDENTES
La Ingeniera de Software al igual que muchas otras disciplinas ha sufrido cambios sustanciales con el paso del tiempo. Cada da surgen nuevos modelos con los cuales se pretende dar solucin a todos los problemas que plantea la industria del software; sin

embargo aun no se logran resultados definitivos con los cuales se obtengan productos con las caractersticas deseadas en cuanto a la calidad, el desempeo y los tiempos de entrega. Los mtodos giles ofrecen muchos recursos con los cuales se pueden mejorar las consideraciones antes mencionadas en cuanto a calidad, desempeo y tiempo de entrega. Aunado a esto ofrecen hacer del proceso una fase ms concreta, sencilla, mucho menos burocrtica y exenta de la tan abundante documentacin generada en el anlisis y diseo de las metodologas tradicionales. Scrum se considera como una de las metodologas giles ms representativas de esta nueva corriente. Actualmente cuenta con un sustento metodolgico muy grande y poco a poco est probando su eficiencia. Se encuentra en proceso de implantacin en muchas empresas a lo largo de todo el planeta, en muchas otras ya ha sido utilizado y sus ventajas han sido comprobadas. En el Instituto Tecnolgico Superior Zacatecas Sur (ITSZaS) se oferta la carrera de Ingeniera en Sistemas Computacionales, en la cual se imparten una serie de materias relacionadas con la Ingeniera de software. Hasta el da de hoy, nicamente se han considerado metodologas tradicionales para ilustrar a los alumnos sobre el proceso de fabricacin de software. Durante el perodo escolar agosto-diciembre 2010, el alumno del noveno semestre de la carrera de Ingeniera en Sistemas Computacionales Roberto Bauelos vila, curs la residencia profesional en la empresa reconocida a nivel mundial IBM, en donde estn utilizando una suite de desarrollo llamada Concert/Jazz para administrar procesos de desarrollo de software basados en Scrum. En mi papel de asesor de este proyecto sostuve varias entrevistas con dicho alumno en las cuales me surgi la idea de relacionar la metodologa Scrum, con alguna de las materias que se imparten en el ITSZaS. Est idea con respecto a trabajar con sta metodologa gil, tuvo adems el antecedente de haber sido el tema de investigacin para titularme de la maestra en Ingeniera de Software, la cual curs en el Centro de Investigacin en Matemticas, en el periodo comprendido de agosto 2008 agosto 2010. Con estos elementos me surgi la idea de promover el uso de una metodologa de desarrollo de software gil, conocida como Scrum, en un proyecto con los alumnos del noveno semestre de la carrera de Ingeniera en Sistemas Computacionales. Este proyecto se desarroll considerando las materias de: Modelos de Desarrollo Global (GDM) y Desarrollo de Proyectos de Software. Hasta ese momento los proyectos solo haban considerado metodologas tradicionales para el desarrollo de software, concretamente el modelo en Cascada.

DEFINICIN DEL PROBLEMA

Hasta este momento los alumnos del ITSZaS de la carrera de Ingeniera en Sistemas computacionales, solamente han trabajado con metodologas tradicionales para el desarrollo de software. Las grandes empresas de software a nivel mundial, estn abriendo sus puertas

a los mtodos giles. Al egresar de la carrera nuestros alumnos se encuentran con un panorama sumamente nuevo y que se sale del contexto con el cual estaban familiarizados. De tal manera que el desconocimiento sobre mtodos giles o bien el proceso de adaptacin se convierte en un factor en contra de una posible contratacin. Existe un desconocimiento prcticamente absoluto de parte de los alumnos del ITSZaS con respecto a las metodologas giles de desarrollo de software. Adems de este desconocimiento de parte de nuestros alumnos, no se tiene evidencia alguna que nos indique si logra un ahorro de tiempo en la elaboracin de un proyecto basando en diferentes metodologas (giles/tradicionales). De igual manera se desconoce si se obtienen mejoras en un proyecto similar elaborado bajo dos enfoques metodolgicos diferentes.

OBJETIVOS
OBJETIVO GENERAL
Coordinar la fabricacin de un software bajo dos metodologas de desarrollo: una tradicional Cascada y la otra gil Scrum. Posteriormente analizar los resultados obtenidos, considerando a los factores relevantes en cuanto al tiempo de desarrollo, la planeacin, los requerimientos cumplidos, las caractersticas ms representativas de los mtodos giles, las cuales se anexan en el apartado del marco terico y el resultado final.

OBJETIVOS ESPECFICOS
Capacitar a los alumnos en la metodologa Scrum. Coordinar la fabricacin de un proyecto de software basado en Scrum. Disear los instrumentos de evaluacin del proyecto. Documentar las incidencias en base a la realizacin del proyecto. Solventar los problemas y errores que surjan en el transcurso del proyecto. Estructurar la informacin obtenida al trmino del proyecto. Analizar la informacin obtenida. Establecer conclusiones sobre la aplicacin de Scrum en un proyecto de software.

JUSTIFICACIN
El panorama mundial con respecto a la industria del software es de apertura e innovacin. Cada da es posible encontrar readaptaciones a las metodologas tradicionales de desarrollo de software y as como se readaptan surgen otras nuevas, siempre en busca de mejorar los procesos ya existentes. Las metodologas giles da con da van ganando terreno y se implantan en las fbricas de software, de tal manera que los estudiantes no pueden permanecer al margen en el dominio de stas tcnicas. La academia debera incorporar dentro de la currcula a los mtodos giles como una alternativa ms para la elaboracin de programas. Los mtodos giles presentan un panorama ms sencillo y concreto para la administracin de todos los documentos generados durante el desarrollo de un sistema. La cantidad de documentos decrece considerablemente considerando a Scrum con respecto a cualquier metodologa tradicional.

Los planes de Scrum son sumamente ms flexibles que la forma planteada por las tcnicas tradicionales, permitiendo adecuaciones ms acertadas y fciles de realizar. De tal manera que se adecuan los cambios sobre la marcha. En la poca actual, marcada por tantos y tan constantes cambios es necesario dotar a nuestros alumnos de las herramientas ms variadas y completas para que puedan enfrentarse al mercado laboral de una manera directa. Para muchos alumnos e incluso para gente quien ya se encuentra laborando en la industria del software resulta sumamente agobiante el hecho de tener que trabajar con metodologas consideradas como burocrticas, llenas de trmites y documentos. Los mtodos giles brindan un enfoque ms prctico, pudiendo resultar muy amigables para los desarrolladores, permitiendo que haya ms gente interesada en la ingeniera de software. El alumno Roberto Bauelos, quien como ya haba indicado estuvo realizando su residencia en IBM, precisamente en un proyecto basado en Scrum, comenta que esta empresa requiere que los ingenieros contratados cuenten ya con alguna experiencia en cuanto al desarrollo gil. Resulta mucho ms sencillo contratar a estudiantes recin egresados si ya conocen algo de estas metodologas a diferencia de tener que capacitarlos al respecto. El proceso de adaptacin a la forma de trabajo de la empresa se realiza de una manera ms natural. Nuestros alumnos deben contar con otras alternativas metodolgicas para desarrollar software que las impuestas por las tcnicas tradicionales. De tal manera que sera interesante poner en contraste en un mismo proyecto el desarrollo tradicional en un equipo de trabajo y una metodologa gil en otro equipo.

MARCO TERICO
EL DESARROLLO GIL DE SOFTWARE
El desarrollo gil de software se considera como un paradigma de desarrollo de software basado en procesos giles. Los procesos giles de desarrollo de software, anteriormente se conocan como metodologas livianas. Su propsito era tratar de evitar los tortuosos y burocrticos procesos de las metodologas tradicionales enfocndose en la gente y los resultados.

Caractersticas del desarrollo gil.

Dentro de las caractersticas de un proceso gil se pueden mencionar adems, las siguientes: Incremental: se realizan pequeas entregas de software, considerando ciclos rpidos. Cooperativo: los clientes y los desarrolladores trabajan de forma cooperativa, en constante comunicacin y manteniendo siempre la cercana.

Sencillo: Se considera que el mtodo por s mismo debe ser muy simple, adems de fcil de aprender y modificar. Documentado y adaptable: en este aspecto se permiten realizar cambios de manera imprevista.

Comparacin tradicionales.

entre

las

metodologas

giles

las

metodologas

En la Tabla 1 se muestran las principales diferencias de las metodologas giles con respecto a las tradicionales.

Metodologas giles Basadas en heursticas provenientes de prcticas de produccin de cdigo.

Metodologas Tradicionales Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo.

Especialmente preparados para cambios Cierta resistencia a los cambios. durante el proyecto. Impuestas internamente (por el equipo). Impuestas externamente. Proceso menos controlado, con pocos principios. Proceso mucho ms controlado, con numerosas polticas/normas.

No existe contrato tradicional o al menos Existe un contrato prefijado. es bastante flexible. El cliente es parte del equipo de desarrollo. Grupos pequeos (<10 integrantes) y trabajando en el mismo sitio. Pocos artefactos. Pocos roles. El cliente interacta con el equipo de desarrollo mediante reuniones. Grupos grandes y posiblemente distribuidos. Ms artefactos. Ms roles.

Menos nfasis en la arquitectura del La arquitectura del software es esencial y se software. expresa mediante modelos. Tabla 1. Comparacin de las metodologas agiles con respecto a las tradicionales.

Elementos de las metodologas giles.

Algunos de los elementos ms importantes de las metodologas giles de desarrollo de software son los siguientes: Poca documentacin. Simplicidad. Anlisis como una actividad constante. Diseo evolutivo. Integraciones. Revisiones y pruebas diarias.

Actualmente, una de las metodologas giles ms populares para la gestin de proyectos tanto de software como de otros tipos es Scrum. Existen adems otras metodologas especficas para el desarrollo de software las cuales se consideran otras alternativas para el desarrollo, entre ellas se encuentran: ISO/IEC 15504, ISO/IEC 12207 y CMMI.

Scrum
Consiste en un proceso de desarrollo de software iterativo e incremental el cual se utiliza comnmente en entornos basado en las metodologas giles de desarrollo de software. Esta tcnica se considera enfocada a la gestin de procesos de desarrollo de software, pero, puede ser utilizado en equipos de mantenimiento de software.

METODOLOGA
ACTIVIDADES A DESARROLLAR
Capacitar a los alumnos en la metodologa Scrum. Coordinar la fabricacin de un proyecto de software basado en Scrum/Cascada. Disear los instrumentos de evaluacin del proyecto. Documentar las incidencias en base a la realizacin del proyecto. Solventar los problemas y errores que surjan en el transcurso del proyecto. Estructurar la informacin obtenida al trmino del proyecto. Analizar la informacin obtenida. Establecer conclusiones sobre la aplicacin de Scrum en contraparte con la metodologa de Cascada, en un proyecto de software. Elaborar un informe sobre los resultados del proyecto.

En una primera etapa ser necesario capacitar a los alumnos en la metodologa Scrum ya que hasta el momento desconocen su fundamentacin y aplicacin. Para comenzar con dicha capacitacin se dar a conocer toda la fundamentacin terica de Scrum. Posteriormente se aplicar una herramienta de simulacin conocida como El Expendedor, el cual familiariza al usuario en la aplicacin de Scrum a un proyecto de software. En cuanto concluya la capacitacin de Scrum se coordinar la fabricacin de un proyecto de software basado en Scrum/Cascada, dentro de las materias de Modelos de Desarrollo Global (GDM) y Desarrollo de Proyectos de Software, en la cuales se desarrolla un software basndose en una metodologa tradicional. Se disearn los instrumentos de evaluacin del proyecto para denotar los aciertos y desaciertos en la aplicacin de Scrum/Cascada para el desarrollo de proyectos de software. En el transcurso del proyecto ser necesario documentar las incidencias en base a la realizacin del software para contar con evidencias sobre las ventajas o desventajas que plantea Scrum.

Dada la poca experiencia de los alumnos con respecto a Scrum, ser necesario solventar los problemas y errores que surjan en el transcurso del proyecto. Toda la informacin generada por el proyecto aparecer de una manera desarticulada, por lo que se vuelve necesario estructurar la informacin obtenida al trmino del proyecto. Luego que el sistema est terminado y aprobado, es necesario analizar la informacin obtenida para poder establecer las conclusiones sobre la aplicacin de Scrum/Cascada en un proyecto de software. Ser necesario contar con una computadora para cada uno de los 18 alumnos involucrados en el proyecto, la cual deber tener instaladas las siguientes herramientas de software. J2SDK. Eclipse. Enterprise Software Architect. NetBeans.

RESULTADOS
La primera etapa de este proyecto consisti en la aplicacin de un juego de simulacin conocido como El expendedor, en el cual se fabrica un artefacto expendedor de artculos deportivos bajo ciertas especificaciones. Se conforman dos equipos de trabajo, el primero de ellos siguiendo los preceptos de la metodologa tradicional en Cascada; el segundo bajo el esquema de Scrum, un mtodo gil. Se les explico a todos los integrantes de ambos equipos el propsito y las reglas del juego. Los resultados obtenidos de esta experiencia fueron los siguientes:

EXPENDEDOR
En un principio ninguno de los equipos sigue reglas denotadas por cada metodologa. En la metodologa en Cascada si los integrantes del equipo no estn asignados a otro proyecto permanecen ociosos. Cuando Scrum comienza el sprint 1, Cascada todava no entrega la documentacin de la primera iteracin. El equipo Scrum si no tiene claros los requerimientos acude al cliente para que los aclare, tantas veces como sea necesario. En general, es comn que no se entiendan correctamente los requerimientos y por consecuencia se hagan cosas que no se pidieron. En Scrum el equipo se involucra desde el inicio a diferencia de cascada. En Cascada resulta sumamente ilustrativo ver el anlisis y el diseo.

Scrum en su primer sprint no cumpli con los objetivos 1, 2, 3 y 4 por completo. Para la segunda iteracin de Scrum, fue necesario priorizar los objetivos no cumplidos juntos con los 2 nuevos. El primer sprint puede tener retardos en el cumplimiento de los requerimientos, pues siempre se realizan los de mayor valor primero. La planeacin de la metodologa en Cascada produce muchos retrasos. Los requerimientos flexibles en Scrum permiten que las nuevas aportaciones o necesidades del cliente se vean plasmados en el siguiente sprint. En el sprint 3 Scrum recuper los objetivos que aun no cumpla. El cliente solicit nuevos requerimientos. En este momento Cascada sigue enfrascado con la planeacin. La gente de Scrum se enfrenta a un problema para cumplir con un requerimiento. Cascada empieza la construccin cuando Scrum est en los requerimientos 9 y 10. Cuando el equipo de la metodologa en Cascada estaba a punto de empezar con la fabricacin del expendedor, el equipo de Scrum ya haba presentado su expendedor. El equipo en Cascada comenta que quizs su producto hubiera sido de mayor calidad, pues tenan un diseo ms firme. El proceso natural de Cascada no permiti brincar fases, a diferencia de la flexibilidad de Scrum. Cascada gener evidencia, lo cual resulta sumamente til si se requiere realizar modificaciones al producto, o bien reutilizar algunos activos.

PROYECTOS DE SOFTWARE
Se plante para su elaboracin un proyecto de software bajo los mismos requerimientos. Se trat de un sistema de inventarios, punto de venta y administrador en general para un Spa/Esttica. Dos equipos seran los encargados de fabricar los dos programas, uno de ellos bajo el enfoque de la metodologa en Cascada y el otro considerando la tcnica de desarrollo Scrum. Cada equipo se integr por nueve alumnos del octavo semestre de la carrera de Ingeniera en Sistemas Computacionales. Este proyecto fue desarrollado a partir del mes de febrero del 2011, y concluy en el mes de junio del mismo ao. Se realizaron 3 reuniones de seguimiento del proyecto y una reunin final, en donde presentaron sus resultados. Todo el material generado, documentos, plantillas, planes, scripts, as como el software resultante fueron entregados en formato digital como evidencia de los resultados logrados, as como para servir de referencia en las conclusiones de esta investigacin. Los resultados obtenidos fueron los siguientes:

PRIMERA REUNIN
En la primera etapa Scrum no demostr diferencias significativas con respecto a las metodologas tradicionales. Los dos equipos prcticamente presentaron los mismos avances, debido a que en esta parte se supone que segn las metodologas tradicionales es

aun temprano para ver avances palpables en cuanto al software. La metodologa Scrum si permite ver un prototipo parcial del sistema, pero en este caso aun no se present ninguno. El equipo Scrum presenta grandes deficiencias con respecto al contacto con el cliente, no aprovechan las ventajas que proporciona esta metodologa para comunicarse constantemente con el cliente. El equipo Cascada est trabajando tal y como lo propone su tcnica.

SEGUNDA REUNIN
El equipo Scrum tuvo algunos inconvenientes, ya que aun cuando existen algunos documentos que no le agregan valor al proyecto, tuvieron que generarse, pues en la materia de Desarrollo de Proyectos de Software son necesarios ciertos diagramas de diseo. Por ello, hasta este momento no presentaron la parte del sistema que ya tenan codificado. El equipo en Cascada aun no empezaba la codificacin, ya que se encontraba aun en la parte del diseo.

TERCERA REUNIN
En esta reunin ambos equipos presentaron avances del software, hasta este punto no se vea ninguna mejora entre el hecho de utilizar la metodologa en Cascada o la Scrum, ya que el sistema que mostraron contena prcticamente los mismo elementos codificados hasta ese momento. Al ser cuestionado el equipo Scrum sobre este acontecimiento, se argument que el cliente segua proponiendo cambios y agregando requerimientos en cada reunin que tenan con l. El equipo en Cascada, haba cerrado sus requerimientos desde la fase uno del proyecto, por lo que en ese momento ya haba concluido tambin el anlisis y el diseo y se encontraban en plena fase de codificacin. A diferencia Scrum tena que estar cambiando los planes y modificando algunos documentos a la par de la codificacin.

PRESENTACIN DEL PROYECTO

Sin lugar a dudas el software que present el equipo Scrum estuvo mucho ms completo y result del agrado del cliente en mayor medida que el sistema del equipo Cascada. La situacin fue clara, si bien se tuvo un ahorro de tiempo por parte de Scrum con respecto a la entrega de algunos documentos, se invirti ese ahorro en requerimientos y depuracin de los requerimientos iniciales. Cascada logr enfatizar en los documentos, pero la primera idea que tiene un cliente, no siempre es la adecuada, de tal manera que al cerrar los requerimientos en etapas iniciales se impidi obtener una idea clara en el propsito del sistema. Scrum tuvo la posibilidad de presentarle los avances del proyecto al cliente en repetidas ocasiones, con lo cual se planteaban nuevas ideas y perspectivas para ser anexadas al software.

CONCLUSIONES
El debate entre quienes apoyan las metodologas tradicionales y quienes estn a favor de los mtodos giles puede prolongarse indefinidamente. Resulta claro que ambas tcnicas tienen puntos tanto a favor como en contra. Pero en vez de sostener una disputa que no conduce a nada, se deberan analizar ambas vertientes de desarrollo de software y utilizar cada una de ellas en su contexto adecuado.

Sin duda los estudiantes de las disciplinas relacionadas con el desarrollo de software encuentran ms familiar y amigable el entorno de procesos denotado por las metodologas giles. Ven con beneplcito esta especie de libertinaje, luego de sentirse abrumados por los procesos hasta cierto punto tediosos y burocrticos que implica la fabricacin de software basndose en las tcnicas tradicionales. Pues en un principio y a simple vista esta forma de producir software se asemeja ms a lo que fue su primer acercamiento con la programacin. Muchos de estos alumnos aplauden estas metodologas, sin profundizar en las implicaciones que trae consigo su utilizacin ms all del desarrollo de un proyecto actual. No cabe duda que para muchos el elemento gil es lo ms actual en cuanto a la produccin de software. Claro, esto si se considera desde el punto de vista de la capacidad para proveer respuestas rpidas y ser adaptables al cambio. Estas dos cualidades han sido siempre haban buscadas, pero en el entorno de la ingeniera de software son indispensables. Las empresas, gobiernos y cualquier tipo de organizacin en donde se utilice el software claman por lograr todos los beneficios que el ser gil puede proveer. Se considera que las necesidades que puede tener un cliente con respecto al producto que requiere, pueden sufrir cambios sustanciales desde el momento de la contratacin de un proyecto de software, hasta el momento de su entrega. Resulta ser ms importante satisfacer estas ltimas que las primeras. Por lo tanto se requiere procesos de software diferentes y adaptables, los cuales en lugar de rechazar los cambios, sean capaces de incorporarlos. Estos procesos, adems deben producir versiones ejecutables del software en perodos cortos de tiempo, con el fin de satisfacer al cliente y obtener retroalimentacin de manera rpida con respecto al producto. Deben inventar soluciones sencillas y prcticas, de tal manera que el impacto producido por los cambios sea menor. Se considera tambin que deben mejorar la calidad del diseo de manera continua, logrando con ello que la siguiente iteracin requiera de un menor esfuerzo en comparacin con la actual. Para muchos todos los elementos resaltantes de los mtodos giles son simples quimeras, salidas de un entorno de ingeniera de software utpico y por ende muy difcil de lograr. Los elementos resaltados del manifiesto gil, siguen siendo considerados como simples falacias: Individuos e interacciones por encima de procesos y herramientas. Software funcional por encima de documentacin abundante. Colaboracin con los clientes por encima de negociacin de contratos. Respuesta al cambio por encima de seguimiento a planes.

REFERENCIAS
1. http://www.programacionextrema.org/ 2. http://tratandodeentenderlo.blogspot.com/2010/03/los-metodos-agiles.html 3. http://www.proyectosagiles.org/iniciativas-resultado-primer-encuentro-agil-

barcelona

4. http://www.rmya.com.ar/Download/Paper_BMOPA.pdf 5. http://mygnet.net/manuales/software/metodologias_tradicionales_vs_dot_metodolo

gias_agiles.1515
6. http://www.evaluandoerp.com/nota-786-Metodologias-tradicionales-vs-

metodologias-agiles-.html
7. http://rafinguer.blogspot.com/2010/03/metodologias-tradicionales-versus.html 8. http://www.seccperu.org/files/Metodologias%20Agiles.pdf