SCRUM en la educación: Caso de estudio como método de trabajo

Andrea Plaza Cordero, Miguel Arcos Argudo, Rodolfo Bojorque Chasi Grupo de Investigación en Inteligencia Artificial y Tecnología de Asistencia, GI-IATa

Universidad Politécnica Salesiana, UPS Cuenca-Ecuador

aplaza@ups.edu.ec, marcos@ups.edu.ec, rbojorque@ups.edu.ec

Abstract— El desarrollo ágil es un conjunto de técnicas que

nacieron inicialmente para la gestión de proyectos de software, pero en el transcurso del tiempo han sido exportados a otros tipos de proyectos. Es un cambio radical a las técnicas de desarrollo de sistemas tradicionales; para que un método sea considerado ágil debe cumplir con los 12 principios del Manifiesto Ágil. El desarrollo ágil a diferencia del tradicional tiene un punto a su favor, que es la gestión del cambio, de allí que el presente trabajo se basa en usar la metodología SCRUM como método de enseñanza-aprendizaje en una asignatura, ya que la misma se mueve en un entorno de extrema incertidumbre, no por los contenidos y tiempos, ya que los planes de estudio se encuentran definidos y el período académico es fijo, mas bien porque en cada proyecto el docente establece los requisitos necesarios que justifiquen el cumplimiento del resultado de aprendizaje, además el equipo de trabajo se empodera en el proyecto. El objetivo de este estudio es evaluar la posibilidad de proporcionar a los docentes un método que reduzca el número de deserción de estudiantes. Se tomó como plan piloto una asignatura con 11 estudiantes, en el segundo parcial se implementó el método SCRUM. El enfoque propuesto se basa en tres etapas principales: a) determinación del sprint backlog o lista de tareas de la iteración. b) desarrollo del sprint. c) Entrega del working product. Los resultados obtenidos son prometedores, ya que muestran que el 73% de estudiantes culminaron sus estudios, en comparación con el primer parcial que se tenía un porcentaje de aprobación del 45%.

Keywords— metodologías de desarrollo de sistemas, desarrollo ágil, manifiesto ágil, SCRUM, sprints, educación, pedagogía.

I. INTRODUCCIÓN Las metodologías de desarrollo de sistemas (SDM) se han visto inmersas en un cambio drástico con la aparición del desarrollo ágil, esto debido a que los SDM tradicionales no eran una buena alternativa ante las restricciones de flexibilidad y de tiempo que conllevan los proyectos. Esta nueva metodología ha sido propulsada por la Alianza Ágil, una organización que promueve el desarrollo ágil [3], y que en base a su manifiesto ágil <www.agilemanifesto.org> indica los siguientes valores:

Individuos e interacciones sobre procesos y herramientas.

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual.

Respuesta ante el cambio sobre seguir un plan.

Como se puede apreciar los elementos a quienes da mayor peso son: individuos e interacciones, software funcionando, colaboración con el cliente y respuesta ante el cambio, por lo que el desarrollo ágil es considerada como la más idónea en entornos dinámicos [5], a diferencia de las SDM tradicionales donde el cambio siempre ha sido un problema latente, ya sea porque la participación del cliente toma mayor énfasis en la especificación de requerimientos y se reduce en las siguientes etapas [6] o porque la documentación se vuelve un aspecto burocrático perdiendo de vista en muchos casos el funcionamiento del software, de cualquier manera dependiendo del proyecto y los elementos que intervengan puede resultar uno y otro una ventaja.

Como se menciona en los elementos del Manifiesto la documentación extensiva no es un punto que se mantenga y de prioridad en el desarrollo ágil, de allí que el conocimiento que se genere es importante ya que necesita guiar al personal en el desarrollo del software; el conocimiento al no poseer una documentación formal se lo convierte en producto que se lo debe transferir [4], de allí que consideran que todo el equipo debe conocer sobre todo el proyecto no existiendo figuras sesgadas dentro del equipo de trabajo.

En resumen, los 12 principios del Manifiesto hacen hincapié en las interacciones de los desarrolladores y el cliente, la entrega continua de resultados, la colaboración permanente con el cliente, y la capacidad de responder a requerimientos volátiles o cambios que se presenten.

A pesar de que las metodologías ágiles generan una apreciación de no poseer una planificación, esto no es del todo cierto, ya que enfatizan buena parte en el proceso de planificación de la documentación resultante [1].

El desarrollo ágil es un conjunto de metodologías orientadas hacia la gestión de proyectos de software donde tratan que las iteraciones se realicen en periodos cortos de tiempo priorizando el factor humano [2], aquí los usuarios y los desarrolladores trabajan en equipos de preferencia pequeños en todo el transcurso del proyecto, siendo necesario que exista gran colaboración entre los miembros, ya que con los usuarios

187International Conference on Information Systems and Computer Science

PROCEEDINGS BOOK INCISCOS 2016

se identifica cual será la aceptación satisfactoria en cada iteración, por ende, uno de los aspectos a considerar es que los clientes sean cualificados para adoptar una metodología ágil. Las metodologías ágiles recopilan buenas prácticas de ingeniería de software, aunque su aplicación extrema puede ser objeto de debate y contraproducente [3].

Algunos ejemplos de metodologías ágiles incluyen SCRUM, KANBAN, Programación Extrema (XP) (e.g., [7,8, 9]).

En la misma línea es importante señalar que la mayoría de los estudios realizados en metodologías ágiles son casos de estudio y pocos son estudios empíricos [4], pero estos se encuentran en un enfoque de desarrollo de proyectos de software.

II. ANTECEDENTE

A. Scrum A mediados de la década de los 80s, Hirotaka Takeuchi y

Ikujiro Nonaka definieron una estrategia de desarrollo de producto flexible donde su equipo de trabajo llegaba al resultado final como una unidad, igual como en el juego de “rugby”, donde el equipo se pasa el balón hacia atrás y adelante, y van ganando campo hasta llegar a la meta.

Ken Schwaber y Jeff Sutherland adaptan el concepto propuesto por Hirotaka Takeuchi y Ikujiro Nonaka al ámbito de la ingeniería del software, denominándola Scrum y la presentan en 1995 Conferencia internacional sobre programación, lenguajes y aplicaciones orientadas a objetos, siendo una de las metodologías ágiles, desde entonces es una de las más populares, ya que es compatible con todo tipo de empresas y con cualquier tipo de proyecto [11].

Scrum presenta 6 principios que todo proyecto está obligado a seguir para garantizar el resultado deseado, y son:

Control del proceso empírico: Se refiere a que debe existir transparencia entre el equipo el trabajo, además de la inspección y adaptación al cambio.

Auto-organización: El equipo de trabajo es responsable de los resultados, por lo que se empoderan del proyecto dando como resultado individuos con un alto compromiso en el trabajo, y no empleados que sólo siguen reglas pero que no tienen ese sentido de responsabilidad.

Colaboración: El equipo trabaja conjuntamente como una sola unidad, generando un compromiso compartido entre todos.

Priorización basada en el valor: Se basa en dar el mayor valor de negocio en todo el transcurso del proyecto.

Asignación de un bloque de tiempo: El tiempo es una restricción, por lo que los sprints, las reuniones diarias, las reuniones de planificación de sprint y las reuniones de revisión de sprint tienen un limitante de tiempo que no se debe extender.

Desarrollo iterativo: Trata sobre el manejo de los cambios en el proyecto mediante sprints cortos de tiempo en donde el cliente recibe una retroalimentación constante viendo los entregables, y en caso de que considere el cliente podrá modificar los requisitos para el siguiente sprint.

Además, Scrum plantea 5 fases con 19 procesos en total en donde se define el flujo a seguir para ejecutar un proyecto, como se muestra en la Tabla I.

TABLE I. RESUMEN DE LOS PROCESOS DE SCRUM [11]

Fase Procesos

1 Inicio 1. Creación de la visión del proyecto. 2. Identificación del Scrum Master y

el (los) socios(s). 3. Formación de equipos Scrum. 4. Desarrollo de épica(s). 5. Creación de la lista priorizada de

pendientes del producto. 6. Realizar la planificación de

lanzamiento. 2 Planificación y

estimación 7. Creación de historias de usuario. 8. Aprobación, estimación y

asignación de historias de usuario. 9. Creación de tareas. 10. Estimación de tareas. 11. Creación de la lista de pendientes

del sprint. 3 Implementación 12. Creación de entregables.

13. Llevar a cabo la reunión diaria. 14. Mantenimiento de la lista

priorizada de pendientes del producto.

4 Revisión y retrospectiva

15. Convocar el Scrum de Scrums. 16. Demostración y validación del

sprint. 17. Retrospectiva del sprint.

5 Lanzamiento 18. Envío de entregables. 19. Retrospectiva del proyecto.

III. TRABAJO RELACIONADO La metodología Scrum ha ido evolucionando y

perfeccionándose desde su aparición en el año de 1995 con Ken Schwaber y Jeff Sutherland; desde un comienzo el enfoque fue basado en el desarrollo de software, aunque en la década de los 80s, Hirotaka Takeuchi y Ikujiro Nonaka ya habían presentado un enfoque de desarrollo flexible en diferentes casos en la industria de la fabricación [11].

En distintos tipos de proyectos se ha implementado la metodología Scrum [13, 14, 15]. Muchas investigaciones se han desarrollado sobre las metodologías de aprendizaje [16, 17], sin embargo, la mayoría se basan en metodologías basadas explícitamente en la educación, mientras muy poco se ha trabajado con relación a metodologías distintas a las educativas.

188International Conference on Information Systems and Computer Science

PROCEEDINGS BOOK INCISCOS 2016

[12] introdujeron Scrum al ámbito educativo para el desarrollo de los proyectos estudiantiles, donde un punto a considerar es la colaboración entre los estudiantes, siendo una de las ventajas pedagógicas que les impulsó a su implementación. El aprendizaje basado en proyectos al ser una estrategia de enseñanza rápida y considerada en ocasiones caótica, fue Scrum la mejor manera de afrontar este tipo de proyectos. En el desarrollo de su caso de estudio, determinaron que Scrum funciona mejor cuando los integrantes son multi-funcionales y pequeños, pero que estos a su vez ayuden en un proyecto más grande, y así eliminar redundancia.

El presente artículo, no sólo se basa en la implementación para proyectos estudiantiles, sino a todo el ámbito de clases, desde el aprendizaje hasta los proyectos.

IV. METODOLOGÍA Y CONSTRUCCIÓN

A. Preguntas de investigación El objetivo del caso de estudio es obtener evidencia que

responda a las siguientes preguntas de investigación: RQ1: ¿Ayuda Scrum para responder a los cambios en un proyecto educativo donde la incertidumbre y el tiempo son factores cruciales? RQ2: ¿Es Scrum eficaz para la preservación del trabajo de equipo donde los estudiantes suelen trabajar individualmente?

Para responder a RQ1, el docente de la asignatura analiza las evaluaciones formativas y sumativas de cada equipo de trabajo, y en base a un análisis estadístico se determinó la tasa de deserción en comparación con el primer parcial.

Para responder a RQ2, el docente compara las evaluaciones individuales y grupales para determinar si existe un resultado promedio.

B. Descripción del Caso de Estudio Se plantea una propuesta de procedimiento para actuar

oportunamente ante el cambio, y así reducir la tasa de deserción. Como el estudio presenta tiempos de ejecución limitados, fue necesario adaptar Scrum al proyecto. La Figura 1 muestra la adaptación de Scrum al estudio planteado.

Figura 1. Adaptación de Scrum como método educativo.

El primer paso fue determinar los requisitos del Product Owner, en este caso del docente de la asignatura, que fueron descompuestos en una lista de historias de usuario o más conocidos como product backlog, luego las historias de usuario o requisitos fueron priorizados en base a los resultados de aprendizaje de la asignatura, como se muestra en la Tabla II.

Se ha planteado dos historias de usuario: Pilas y Colas, Arboles, en la primera historia de usuario se definen dos sprints, mientras en la segunda se definen cinco sprints. Por razones de espacio, me he enfocado en cuatro sprints (de siete sprints). Cabe señalar, que cada sprint corresponde a un subcojunto de requerimientos.

TABLE II. RESUMEN DEL PRODUCT BACKLOG

Priorización Sprints

3 Pilas y Colas Como estudiante debe transformar una expresión infija a postfija.

3 Pilas y Colas Como estudiante debe la expresión postfija transformarla a infija.

4 Arboles Como estudiante debe conocer los atributos de los árboles.

4 Arboles Como estudiante debe crear y eliminar un árbol binario de búsqueda.

El primer día del segundo parcial, se procedió a realizar un sprint planning meeting con los estudiantes, que será el equipo de trabajo, con ellos se afinaron los detalles de las tareas que se deben realizar para lograr el objetivo del sprint. Esta actividad dio como resultado el Sprint Backlog, que es un documento donde se describen las tareas que se deben realizar para cumplir con el sprint. En la Tabla III se puede apreciar las tareas a desarrollar del Sprint 1; a todos los sprints se les asignó tareas.

TABLE III. SPRINT BACKLOG

Tareas Sprint 1: Pilas y Colas

1 Solicitar el ingreso de la expresión infija.

2 Transformar la expresión infija a postfija, considerando las reglas de precedencia de los operadores. Es importante presentar cada paso cuando se apile o desapile un número o un operador

3 Con la expresión postfija se va a obtener el resultado final. Es importante presentar cada paso cuando se apile o desapile

4 Realizar informe según el formato respectivo.

Cada sprint tiene un período de dos a tres semanas, periodo que fue definido en base al sprint backlog y en el cual el equipo debe trabajar en las tareas de desarrollo correspondientes; como los estudiantes no presentan dominio en la temática, la ejecución de los sprints se desarrolla posterior a las clases. Una vez que inicia el sprint, no puede ser modificado, sólo en caso de que el cambio modifique todo lo planificado podrá

189International Conference on Information Systems and Computer Science

PROCEEDINGS BOOK INCISCOS 2016

reconsiderarse y analizar nuevamente, lo cual no sucedió en este estudio, ya que se conocía claramente los requerimientos.

Cuando se concluye con cada sprint los equipos de trabajo entregarán el working product. En el sprint review meeting el docente valida el producto resultante, y en caso de considerarlo oportuno podrá modificar las historias de usuario para que se cumplan los objetivos de aprendizaje. De allí que Scrum es comparado con en el juego de rugby, que en ocasiones se adelanta o existen retrocesos que deben ser realizados oportunamente, y no como en los modelos de enseñanza tradicionales que se sigue la planificación sin verificar si los estudiantes están participando y generando buenos resultados.

Cuando se finaliza cada historia de usuario, se procedió a realizar una retrospectiva del proyecto total, con el objetivo de agregar una mejora continua al proceso y empoderarles de los proyectos.

Los artefactos y los diferentes talleres que se han planteado realizar son:

Evaluación formativa: Se realiza mediante el proceso de aprendizaje, con el objetivo de brindar retroalimentación hacia el docente y el estudiante sobre el progreso del último.

Evaluación sumativa: Se realiza cuando se ha concluido una temática o un tiempo establecido, para certificar el resultado de aprendizaje.

Con el propósito de validar el estudio, se ha conducido un caso de estudio en el segundo parcial en el período académico Marzo-Agosto 2015 de la asignatura Estructura de Datos con 11 estudiantes y 0 retirados. En ambos parciales se trabajó con el método basado en problemas, en donde los equipos de trabajo tienen que desarrollar proyectos, los cuales poseen el mismo nivel de puntaje y el tiempo de trabajo autónomo de ambos parciales corresponde a 27 horas. En el primer parcial se realizaron las revisiones preliminares a los proyectos sin interferir en los grupos; mientras que en el segundo parcial se cambió la metodología a Scrum, en donde luego de cada revisión conjuntamente con el equipo de trabajo se desarrolló una retroalimentación, y en caso de ser necesario se cambiaron las historias de usuario. Hasta el primer parcial se tenía una media de 35. Por ello, se busca aplicar SCRUM [10] y así reducir la tasa de deserción de los estudiantes. Es importante señalar que los estudiantes ya poseen un nivel considerable en programación, con respecto al dominio de la temática se dictarán las respectivas clases y los requisitos de los proyectos a desarrollar.

En total 12 personas participaron en el caso de estudio, 1 product owner (quien desempeñará ambas tareas de scrum master y de product owner), y 11 estudiantes que forman parte del equipo de trabajo. Según [11] recomiendan que los equipos de trabajo estén conformados de 6 a 10 personas como máximo, por lo que se crearon 4 equipos de trabajo (3 equipos de 3 estudiantes y 1 equipo de 2 estudiantes).

C. Análisis e interpretación Las preguntas de investigación se responden mediante la

Tabla IV, donde se indica por cada grupo y sprint el

cumplimiento que se ha obtenido, para lo cual utilizo una escala de 1 a 5, siendo 1 insatisfactorio y 5 satisfactorio. Este puntaje lo determino en base a la calificación que haya obtenido el grupo. Cada parcial fue establecido con un puntaje de 50, donde 35 puntos corresponden a resolución de problemas mediante proyectos y 15 puntos a la evaluación sumativa.

TABLE IV. RESULTADOS DE LAS HISTORIAS DE USUARIO

Grupo Sprint 1

Sprint 2

Sprint 3

Sprint 4

1 3 3.35 3.5 4.3

2 3 4 5 5

3 2 3 2 3.6

4 0 0.2 1.5 2.1

El 73% pasó la asignatura, teniendo una deserción del 27%, es decir que de los 11 estudiantes 8 pasaron.

RQ1: ¿Ayuda Scrum para responder a los cambios en un proyecto educativo donde la incertidumbre y el tiempo son factores cruciales? En el Sprint 2 y Sprint 4 se puede observar como el nivel de cumplimiento ha mejorado considerablemente, esto se debe a que en el primer sprint se revisa el cumplimiento con todo el grupo, y en caso de ser necesario el docente modificará la historia de usuario y de igual manera la metodología que esté usando.

Como ventaja considerable puedo indicar que sirvió de reforzamiento para los estudiantes, ya que al identificar que existen falencias se pudo tomar otras medidas para solucionarlo.

RQ2: ¿Es Scrum eficaz para la preservación del trabajo de equipo donde los estudiantes suelen trabajar individualmente?

Para responder esta pregunta se utilizaron las calificaciones de las evaluaciones sumativas donde se observa que en la primera evaluación la media es de 6.2, mientras en la segunda evaluación su valor es de 7.8, con lo que deduzco que los trabajos fueron realizados en su mayoría con la intervención de todos los estudiantes.

D. Evaluación de validación y limitación Para presentar validez interna de los resultados que se han

presentado se los identificó de la siguiente manera: Se ha determinado trabajar con 4 grupos de la misma asignatura, donde se han usado evaluaciones formativas por cada tema, para posterior realizar una evaluación sumativa para aumentar la fiabilidad de los resultados, ya que al tratarse de trabajos en grupos puede llegar a ocurrir que algún miembro del equipo no esté trabajando. Cabe señalar que las evaluaciones se realizaron tanto a nivel de evaluaciones prácticas y teóricas.

Adicionalmente, se realizaron observaciones a los diferentes grupos para determinar el nivel de compromiso y trabajo en equipo, estos resultados no se añadieron en el estudio ya que son subjetivos.

190International Conference on Information Systems and Computer Science

PROCEEDINGS BOOK INCISCOS 2016

Como limitación, puedo mencionar que como la tendencia de Scrum es trabajar como un equipo, cada equipo era independiente uno del otro por lo que se tenía que llevar las clases en muchos casos de forma independiente, aunque como restricción que impuse en el proyecto es que todas las historias de usuario se debían cumplir hasta la fecha indicada, lo cual se realizó con éxito.

Para finalizar, puedo indicar que al principio se sintió la resistencia por parte de los estudiantes al trabajar en equipos y siendo ellos los responsables de cumplir con los sprints, pero luego de observar los resultados de los siguientes sprints se pudo apreciar que los resultados fueron prometedores. Además, les hizo que se apoyen como equipo y que entre todos se alienten para continuar.

V. CONCLUSIONES Con la realización de este estudio se ha comprobado que

implementando las buenas prácticas de Scrum se ha tenido éxito y por ende una ventaja pedagógica, ya que en base a los resultados la tasa de aprobación fue del 73%, lo cual significa un gran punto a favor del estudio, puesto que en el primer parcial se tenía apenas el 45%, ya que con las revisiones de los ciclos de sprint, se logró tomar medidas correctivas a tiempo. Es importante indicar que para el primer parcial se tomó como aprobación que el estudiante haya cumplido con un mínimo de 35 puntos, mientras en el segundo parcial corresponde el mínimo a 70 puntos.

Otro aspecto positivo fue, que como Scrum intenta que todo el equipo de trabajo conozca y no exista un especialista; la mayoría de los estudiantes poseen el conocimiento sobre la temática a tratar y la resolución de los proyectos. Además, que al llevar cada grupo el cuadro de dirección, se podía observar las actividades que faltaban por realizar, las que estaban hechas y los responsables, manteniendo un control. A diferencia de la revisión de avances donde por lo general la mayoría de los estudiantes no se empoderan del proyecto.

El caso de estudio permitió evaluar un proceso en un entorno real, en este caso en el ámbito educativo, lo cual es importante ya que existen factores externos que podrían afectar a los resultados de la investigación, e incluso en experimentos formales donde a pesar que se pueda replicar, no se tienen en cuentan factores, ya que se está llevando bajo valores controlados.

El trabajo de equipo resultó de 11 estudiantes, lo cual resultó conveniente como trabajo inicial, aunque Scrum provee mecanismos cuando se trabaja con equipos más grandes, el cual será uno de los trabajos a futuro.

Como trabajo futuro, se está analizando el perfeccionamiento de la implementación de Scrum con un solo grupo y planteando las historias de usuario como una sola unidad. Además, el siguiente estudio se podría presentar en ciclos superiores.

REFERENCIA [1] Boehm, Barry. “Get Ready for Agile Methods, With Care.” IEEE

Computer Jan. 2002. [2] A. Cockburn, J. Highsmith, Agile software development: the people

factor, IEEE Computer 34 (11) (2001) 131–133. [3] Paulk, M. C. (2002). Agile methodologies and process discipline.

Institute for Software Research, 3. [4] Chan, F. K., & Thong, J. Y. (2009). Acceptance of agile methodologies:

A critical review and conceptual framework. Decision Support Systems, 46(4), 803-814.

[5] A.S. Koch, Agile Software Development: Evaluating the Methods for Your Organization, Artech House, Boston, 2005.

[6] S. Nerur, R. Mahapatra, G. Mangalaraj, Challenges of migrating to agile methodologies, Communications of the ACM 48 (5) (2005) 73–78.

[7] Dimes, T. (2015). Conceptos Básicos De Scrum: Desarrollo De Software Agile Y Manejo De Proyectos Agile. Babelcube Inc..

[8] Kniberg, H., & Skarin, M. (2010). Kanban and Scrum-making the most of both. Lulu. com.

[9] Beck, K.. “Extreme Programming Explained. Embrace Change”, Pearson Education, 1999. Traducido al español como: “Una explicación de la programación extrema. Aceptar el cambio”, Addison Wesley, 2000.

[10] Schwaber, K., & Beedle, M. (2002). Agilè Software Development with Scrum.

[11] SCRUMstudyTM. (2016), Una guía para el cuerpo de conocimiento de SCRUM (Guía SBOKTM)

[12] Pope-Ruark, R., Eichel, M., Talbott, S., & Thornton, K. (2016). Let’s scrum: How scrum methodology encourages students to view themselves as collaborators. Teaching and Learning Together in Higher Education, 1(3), 5.

[13] Hong, N., Yoo, J., & Cha, S. (2010, November). Customization of scrum methodology for outsourced e-commerce projects. In 2010 Asia Pacific Software Engineering Conference (pp. 310-315). IEEE.

[14] Azham, Z., Ghani, I., & Ithnin, N. (2011, December). Security backlog in Scrum security practices. In Software Engineering (MySEC), 2011 5th Malaysian Conference in (pp. 414-417). IEEE.

[15] Williams, L., Brown, G., Meltzer, A., & Nagappan, N. (2011, September). Scrum+ engineering practices: Experiences of three microsoft teams. In 2011 International Symposium on Empirical Software Engineering and Measurement (pp. 463-471). IEEE.

[16] Johnson, D.W., & Johnson, R.T. (1999). Making cooperative learning work. Theory into Practice, 38, 67-73

[17] Frederick, T.A. (2008, December). Facilitating better teamwork: Analyzing the challenges and strategies of classroom-based collaboration. Business Communication Quarterly, 71 (4), 439-455.

191International Conference on Information Systems and Computer Science

PROCEEDINGS BOOK INCISCOS 2016