Universidad Nacional del Centro de la
Provincia de Buenos Aires
Facultad de Ciencias Exactas
TRABAJO FINAL DE LA CARRERA DEINGENIERÍA DE SISTEMAS
Virtual Scrum Lego: Un Ambiente Virtual para la enseñanza
de Scrum con Lego.
Alumnos
Rodrigo Matías Pena
Marcos Adrián Suhit
Dirección
Dr. Álvaro Soria
Co-dirección
Ing. Ezequiel Scott
2
Agradecimientos
Queremos agradecer a todos aquellos que hicieron posible que hoy nos encontremos en esta etapa de la carrera, a quienes nos acompañaron a lo largo de la misma y que contribuyeron a que finalmente cumplamos con las metas planteadas. Ellos son, nuestras familias, quienes nos brindaron su afecto y colaboración durante estos años de estudio, nuestros amigos, con los cuales se compartieron momentos muy agradables he hicieron que el camino sea realmente más sencillo de transitar; y a los profesores, que nos educaron y capacitaron de la mejor manera con el objetivo de que seamos buenos profesionales. A nuestro Director Álvaro Soria y Co-Director Ezequiel Scott por su colaboración, disposición y confianza brindadas durante el desarrollo de este trabajo.
3
RESUMEN
Scrum es actualmente uno de los Métodos Ágiles para el desarrollo de software de mayor difusión en la industria. Acompañando esta tendencia, las universidades están incluyendo la enseñanza de dicha metodología dentro de su plan de estudios.
Dentro de dichos planes, los cursos que proponen enseñar Scrum utilizan diferentes estrategias. El uso de clases tradicionales, la puesta en práctica de un proyecto de Scrum en la clase, pero la tendencia actual apunta también a enseñar el Método Ágil a través de juegos.
Entre estos juegos para enseñar Scrum, se destacan los que usan ladrillitos de LEGO ya que este juego permite ejemplificar de manera muy similar el flujo real de la metodología a medida que se simula la construcción de un producto.
Sin embargo, para que estos juegos sean efectivos en contextos académicos donde asisten cientos de estudiantes, es necesario contar con los recursos materiales necesarios considerando la gran cantidad de estudiantes.
En este contexto, se presenta en este trabajo un enfoque basado en una plataforma virtual para dar soporte a la utilización de un juego que permita a los estudiantes experimentar con la metodología.
4
Contenido
CAPÍTULO 1 ... 9
1. INTRODUCCION A VIRTUAL SCRUM LEGO ... 10
1.1. INTRODUCCION ... 10
1.2. OBJETIVO ... 12
1.3. ESTRUCTURA DE LA TESIS ... 14
CAPÍTULO 2 ... 16
2. MARCO TEÓRICO ... 17
2.1. METODOLOGÍAS AGILES ... 17
2.1.1. DEFINICIÓN DE METODOLOGÍAS ÁGILES ... 18
2.1.2. SCRUM ... 20
2.1.3. ROLES DE SCRUM... 24
2.1.4. LOS BENEFICIOS DE USAR SCRUM ... 25
2.2. METODOS DE ENSEÑANZA ... 26
2.2.1. EL JUEGO COMO MÉTODO DE ENSEÑANZA ... 28
2.2.2. LA CONSTRUCCIÓN USANDO LEGO PARA LA ENSEÑANZA DE SCRUM ... 29
2.3. MUNDOS VIRTUALES ... 31
2.3.1. MUNDOS VIRTUALES COMO HERRAMIENTA DE ENSEÑANZA ... 35
2.4. TRABAJOS RELACIONADOS ... 38
2.4.1. ENSEÑANDO SCRUM A TRAVÉS DE LA SIMULACIÓN DE PROYECTOS ... 39
2.4.2. ENSEÑANDO SCRUM A TRAVÉS DE JUEGOS EDUCATIVOS ... 41
2.5. CONCLUSIONES ... 44
3. LA TESIS ... 47
3.1. VISIÓN GENERAL ... 49
3.2. DEFINICIÓN DEL PROYECTO PILOTO ... 50
3.3. PLANIFICACIÓN DEL SPRINT ... 53
3.4. EJECUCIÓN DEL SPRINT... 55
3.5. FINALIZANDO EL SPRINT ... 57
5
4.1. REQUERIMIENTOS FUNCIONALES DEL SISTEMA ... 60
4.2. ATRIBUTOS DE CALIDAD ... 62
4.3. ARQUITECTURA DE VSL ... 63
4.3.1. COMPONENTES ... 63
4.3.2. VISTA ESTÁTICA ... 65
4.3.3. MATERIALIZACIÓN DE LOS COMPONENTES ... 66
4.4. IMPLEMENTACIÓN DE LAS FASES DEL ENFOQUE ... 69
4.4.1. PLANIFICACIÓN DEL PROYECTO ... 70
4.4.1.1. Creación de modelo ... 71
4.4.2. PLANIFICACIÓN DEL SPRINT ... 74
4.4.2.1. Estimación de una tarea ... 75
4.4.3. EJECUCIÓN DEL SPRINT... 77
4.4.3.1. Comenzar una tarea ... 78
4.4.4. FINALIZACIÓN DEL SPRINT ... 81
4.4.4.1. Comparación de modelos ... 82
4.5. MODELO DE DATOS ... 85
4.5.1. TABLA PIEZA ... 85
4.5.2. TABLA CELDA ... 85
4.5.3. TABLA MODELO ... 86
4.5.4. TABLA MODELO TAREA... 86
4.5.5. TABLA MODELO ALUMNO ... 86
4.6. CONCLUSIÓN ... 88
5. EXPERIMENTOS Y RESULTADOS ... 90
5.1. OBJETIVO ... 91
5.2. PREPARACION DEL EXPERIMENTO ... 91
5.3. NARRATIVA DEL EXPERIMENTO ... 93
5.3.1. EXPERIMENTO REALIZADO CON MÉTODO TRADICIONAL ... 94
5.3.1.1. Carga y priorización de las User Stories ... 94
5.3.1.2. Planificación del Sprint Backlog ... 95
5.3.1.3. Estimación de User Stories ... 96
6
5.3.1.5. Cierre del Sprint ... 99
5.3.2. EXPERIMENTO REALIZADO CON VIRTUAL SCRUM LEGO ... 100
5.3.2.1. Carga y priorización de las User Stories ... 100
5.3.2.2. Planificación del Sprint Backlog ... 101
5.3.2.3. Estimación de User Stories ... 102
5.3.2.4. Control y Supervisión del trabajo durante el Sprint ... 103
5.3.2.5. Cierre del Sprint ... 106
5.4. REQUERIMIENTOS DE HARDWARE Y SOFTWARE ... 108
5.5. ENCUESTA ... 109
5.6. ANALISIS ESTADISTICO: CASO DE ESTUDIO ... 111
5.6.1. ANÁLISIS FUNCIONALIDAD ... 113
5.6.1.1. Resumen respuestas de Funcionalidad para grupo con Virtual Scrum Lego ... 113
5.6.1.2. Resumen respuestas de Funcionalidad para grupo con método estándar ... 115
5.6.1.3. Análisis Comparativo sobre Funcionalidad ... 117
5.6.2. ANÁLISIS DE USABILIDAD ... 120
5.6.2.1. Resumen respuestas de Usabilidad para grupo con Virtual Scrum Lego ... 121
5.6.3. ANÁLISIS DE PERCEPCIÓN ... 123
5.6.3.1. Resumen respuestas de Percepción para grupo con Virtual Scrum Lego ... 123
5.6.3.2. Resumen respuestas de Percepción para grupo con método estándar ... 126
5.7. CONCLUSIONES ... 133
6. CONCLUSIONES ... 135
6.1. CONTRIBUCIONES DEL PROYECTO ... 135
6.2. LIMITACIONES DE LA HERRAMIENTA ... 137
6.3. TRABAJOS FUTUROS ... 137
APÉNDICE A ... 139
7
Índice Ilustraciones
Ilustración 1: Vista Esquemática Virtual Scrum Lego ... 13
Ilustración 2: Encuesta Metodologías Utilizadas ... 21
Ilustración 3: Estructura Proceso Scrum ... 22
Ilustración 4: Roles De Scrum ... 24
Ilustración 5: Ingreso mensual a Second Life ... 34
Ilustración 6: Usuarios Activos en Mundos Virtuales ... 35
Ilustración 7: Componentes de un mundo ... 35
Ilustración 8: Esquema Conceptual Virtual Scrum Lego ... 48
Ilustración 9: Virtual Scrum Lego ... 49
Ilustración 10: Agregado de Imagen a Modelo ... 51
Ilustración 11: Modelo Creado por Profesor ... 51
Ilustración 12: Product Backlog en plena creación... 52
Ilustración 13: Estimación de Tarea con Planning Poker ... 53
Ilustración 14: Task Board de los Sprint creados ... 54
Ilustración 15: Alumnos construyendo el producto ... 55
Ilustración 16: Detalle Daily Meeting ... 56
Ilustración 17: Panel creación Daily Meeting ... 56
Ilustración 18: Chat entre Alumno y Profesor ... 57
Ilustración 19: Diagrama de Componentes Alto Nivel ... 64
Ilustración 20: Vista Estática ... 65
Ilustración 21: Diagrama de Clase ... 67
Ilustración 22: Herencia y Composite ... 69
Ilustración 23: Diagrama Use Case Map Crear Modelo ... 72
Ilustración 24: Diagrama de Actividad ... 73
Ilustración 25: Diagrama de Secuencia Crear modelo ... 74
Ilustración 26: Diagrama Use Case Map Estimación de tarea ... 75
Ilustración 27: Diagrama de secuencia Estimación de tarea ... 76
Ilustración 28: Diagrama de secuencia Estimación de tarea ... 77
Ilustración 29: Diagrama Use Case Map Iniciación de una tarea ... 79
Ilustración 30: Diagrama de Actividades de movimiento de pieza ... 80
Ilustración 31: Diagrama de Secuencia de movimiento de pieza... 81
Ilustración 32: Diagrama Use Case Map finalización de Sprint ... 82
Ilustración 33: Diagrama de Secuencia Comparar Modelos ... 83
Ilustración 34: Product Backlog ... 95
Ilustración 35: Cartas Póker Planning ... 96
Ilustración 36: Task Board ... 98
Ilustración 37: Product Backlog Virtual Scrum Lego... 101
Ilustración 38: Product Backlog (Creando Tareas) Virtual Scrum Lego ... 101
Ilustración 39: Estimación con Póker Planning en la sesión de planning ... 102
8
Ilustración 41: Task Board Virtual Scrum Lego ... 104
Ilustración 42: Desarrollo Tarea con Virtual Scrum Lego... 105
Ilustración 43: Desarrollo Colaborativo Virtual Scrum Lego ... 105
Ilustración 44: Finalización Tarea Virtual Scrum Lego ... 106
Ilustración 45: Requerimiento finalizado Virtual Scrum Lego ... 107
Ilustración 46: Histograma Entorno De Trabajo (Izquierda VSL – Derecha Método Tradicional) ... 118
Ilustración 47: Histograma Disponibilidad de Recursos (Izquierda VSL – Derecha Método Tradicional) ... 119
Ilustración 48: Histograma Aspectos Generales (Izquierda VSL – Derecha Método Tradicional) ... 119
Ilustración 49: Histograma Organización de las US (Izquierda VSL – Derecha Método Tradicional) ... 130
Ilustración 50: Histograma Planificación de Tareas del Sprint (Izquierda VSL – Derecha Método Tradicional) ... 130
Ilustración 51: Histograma Desarrollo de Tareas del Sprint (Izquierda VSL – Derecha Método Tradicional) ... 131
Ilustración 52: Histograma Cierre del Sprint (Izquierda VSL – Derecha Método Tradicional) ... 131
Índice Tablas
Tabla 1: Tabla comparativa de modelos planteados ... 43Tabla 2: Configuración de Equipos ... 108
Tabla 3: Respuesta a encuesta sobre Funcionalidad con Virtual Scrum Lego. ... 114
Tabla 4: Respuesta a encuesta sobre Funcionalidad para la prueba realizada a través del método tradicional. ... 116
Tabla 5: Opiniones cuantificadas de las preguntas sobre Funcionalidad. ... 117
Tabla 6: Estadísticos de Prueba. ... 117
Tabla 7: Respuesta a encuesta sobre Usabilidad con Virtual Scrum Lego ... 121
Tabla 8: Respuesta a encuesta sobre Percepción con Virtual Scrum Lego ... 124
Tabla 9: Análisis Comparativo sobre Percepción ... 127
Tabla 10: Opiniones cuantificadas de las preguntas sobre Percepción... 128
9
10
1.
INTRODUCCION A VIRTUAL
SCRUM LEGO
1.1.
INTRODUCCION
Scrum es actualmente uno de los métodos ágiles para el desarrollo de software de mayor difusión en la industria, esta metodología permite abordar proyectos complejos desarrollados en entornos dinámicos y cambiantes de un modo flexible. La razón de su popularidad se basa en sus potenciales mejoras en la productividad, la calidad y la satisfacción del cliente (Maher, Kourik, & Chookittikul, 2011) para el manejo de proyectos en entornos cambiantes que exigen rapidez en los resultados y requieren flexibilidad como requisito imprescindible.
Acompañando esta tendencia, las universidades están incluyendo la enseñanza de dicha metodología dentro de su plan de estudios (Scott, Rodriguez, Soria, & Campos, 2014). Dentro de dichos planes, los cursos que proponen enseñar
Scrum utilizan diferentes estrategias. El uso de clases tradicionales donde el profesor dicta los conceptos y los alumnos toman notas resulta una buena opción. Sin embargo, algunos profesores optan por centrar la clase en la puesta en práctica de un proyecto de Scrum, mostrando así las características de la metodología y permitiendo que los alumnos aprendan desde la experiencia (Mahnic, A capstone course on agile software development using scrum, 2012). La tendencia actual apunta también a enseñar el método ágil a través de juegos, para obtener una clase más flexible y entretenida.
Actualmente, existen algunos enfoques que han abordado la enseñanza de los métodos ágiles y algunas prácticas de la ingeniería de software utilizando juegos. Algunos ejemplos de esta tendencia son The risk is in the blocks!
11
a aquellos que abordan un proyecto con MetodologíaScrum y aporta mejoras en la comprensión de la importancia de la gestión de riesgos. Además facilita la discusión, volviéndola más entretenida, para identificar los riesgos en un proyecto. Otro juego dirigido a alumnos estudiantes de la Metodología Scrum
es Scrum Roles and Responsibilities Game (TastyCupcakes, 2008), con el
cual se obtienen resultados positivos en la comprensión de los roles y responsabilidades de Scrum además de permitir reflexionar y pensar en mejores formas de trabajar en equipo. The high-risk airplane factory
(TastyCupcakes, 2008) es otro juego relacionado con Scrum donde se aprende la importancia de los radiadores de información y las reuniones retrospectivas (Jimenez Diaz, 2011). Entre estos juegos para enseñar Scrum, se destacan los que usan bloques de LEGO (Freitas, 2008), ya que la construcción con estos bloques permite simular el incremento del producto de software de manera análoga al mundo real. Además, fomenta el trabajo en equipo ya que todos los miembros del mismo pueden colaborar en la construcción de las piezas solicitadas por el cliente.
Sin embargo, para que estos juegos sean efectivos en contextos académicos donde asisten cientos de estudiantes, es necesario contar con los recursos materiales y el espacio físico necesario considerando la gran cantidad de estudiantes. En este contexto, Virtual Scrum (Soria & Rodriguez, 2010) aparece como una alternativa a resolver el desarrollo distribuido. La herramienta además está dirigida tanto a estudiantes como profesionales, dando soporte al desarrollo distribuido de software mediante un mundo virtual. Las mejoras aportadas se relacionan con la facilidad para poder concretar reuniones de software, proveyendo salas que cuentan con los artefactos necesarios para dar soporte a los desarrolladores en las diferentes etapas de
Scrum.
12
real de trabajo basado en Scrum con gran verosimilitud. De esta manera, la propuesta apunta a mejorar la compresión de los estudiantes sobre el desarrollo de software basado en Scrum mediante la construcción de piezas con bloques LEGO. Asimismo, esta propuesta apunta a validar los beneficios y su potencial en el aprendizaje, estudiando el desempeño de los estudiantes cuando se hallan inmersos en este nuevo marco tecnológico.
1.2.
OBJETIVO
Se propone un enfoque para las problemáticas antes mencionadas a la hora de enseñar Scrum mediante la utilización de un juego LEGO en un mundo virtual. Un mundo virtual aporta beneficios, como por ejemplo permite simular con mayor verosimilitud un entorno real de trabajo basado en Scrum. En este entorno, las personas se pueden vincular a pesar que no se encuentren en el mismo lugar físico. Esto permite escalar al grupo de trabajo en la cantidad de integrantes que se desee sin necesariamente localizarse en la misma ubicación geográfica (Boeham, 2001). De la misma manera, complementar este entorno con un juego que use bloques LEGO permite también escalar la cantidad de piezas requeridas por cada equipo de estudiantes para llevar a cabo el requerimiento. Además, gracias a la modalidad de juego, la simulación del desarrollo del producto se encuentra fuera de riesgos a diferencia de un contexto real.
De esta manera, la utilización de bloques LEGO resulta una alternativa interesante a los métodos de enseñanza tradicionales, ya que la construcción con bloques permite simular el incremento del producto de software de manera análoga al mundo real. Entonces, nuestra propuesta es un enfoque soportado por una herramienta que simula un ambiente de trabajo característico de
13
aprender la MetodologíaScrum. La característica principal de esta herramienta es que permite dar soporte a la enseñanza de la metodología a través del juego con bloques LEGO, de manera totalmente diferente a la que lo hacen los enfoques tradicionales. La ilustración 1 describe una vista esquemática de la interacción entre los usuarios (profesores y estudiantes) y la herramienta a desarrollar.
Ilustración 1: Vista Esquemática Virtual Scrum Lego
14
herramienta. Una vez que el profesor ha definido su requerimiento, define las
User Stories del requerimiento (3). Finalizada la definición de las mismas, los alumnos continúan seleccionando un conjunto de ellas para definir el Sprint Backlog, y luego proceder con la estimación de las mismas (4). De esta manera, los estudiantes seleccionarán las User Stories a desarrollar y las organizarán considerando su estimación de esfuerzo a lo largo del sprint (5). Esta fase se conoce como Sprint Planning. En el Sprint, los estudiantes comienzan el desarrollo de las User Stories mediante la construcción con bloques LEGO (6). Durante este Dailybuild, la herramienta o el profesor mismo dentro de ella, incentivará a los alumnos a llevar a cabo las reuniones diarias (Daily Meetings) para lo cual utilizarán un panel o un chat (7). Finalizando el
Sprint, los estudiantes plantean al profesor su incremento del producto llevándose a cabo el Sprint Review (8). Como último paso, el profesor guiará a los estudiantes en realizar el Sprint Retrospective, con el objetivo de mejorar de manera continua su productividad y la calidad del producto que están desarrollando (9). Finalmente, se vuelve a iterar en los sucesivos Sprints este proceso antes descripto, a partir del punto (2), hasta finalizar con el desarrollo total del producto solicitado.
1.3.
ESTRUCTURA DE LA TESIS
A continuación, se presenta la realización de la tesis, la cual está organizada en 6 capítulos.
En este primer capítulo, se presentó una introducción al tema sobre el cual se abordará el trabajo y se realizó un pequeño resumen sobre algunos conceptos importantes. Se explicaron los motivos que impulsaron a la realización de esta tesis y cuáles son los objetivos que se propusieron para la misma.
15
la enseñanza de la Metodología Ágil Scrum dentro de su plan de estudios. También se detallan las ventajas y desventajas de los diferentes métodos de enseñanza para Scrum. Además, se presentan conceptos de los mundos virtuales, y se mostrarán los trabajos relacionados existentes sobre ellos. Finalmente, la sección 2.4 presenta un análisis de los Trabajos Relacionados con esta tesis.
En el capítulo 3, se realiza un enfoque sobre la aplicación. Se muestra la herramienta desarrollada y cómo es utilizada en una clase real de enseñanza de
Metodología Scrum. Además, se describirá el objetivo de la herramienta y se exploraran las distintas funcionalidades de la misma.
En el capítulo 4, se puede observar el diseño y la implementación del trabajo realizado. Se hará una introducción describiendo los requerimientos funcionales y las tecnologías utilizadas para luego ingresar en la descripción del diseño general y de cada componente que forma parte del trabajo final.
En el capítulo 5, se presentan los resultados experimentales obtenidos sobre la utilización de la herramienta. Se analizarán las encuestas realizadas a cada uno de los miembros para ratificar o rectificar las mejoras en el desarrollo de software junto con la apreciación de cada uno de los usuarios.
16
17
2.
MARCO TEÓRICO
A lo largo de la realización de esta tesis, entraron en juego una gran cantidad de variados conceptos que no se deben pasar por alto; por ello, a continuación se realizará una descripción teórica sobres los mismos, de modo tal que sirvan como guía para la lectura de los siguientes capítulos.
Este capítulo se organiza de la siguiente manera: en la sección 2.1 se describen los métodos ágiles como alternativa de marco para el desarrollo de software, dándole mayor importancia al proceso ágil de Scrum. Luego, en la sección 2.2, se describen diferentes Métodos de Enseñanza de Scrum que permiten preparar a los estudiantes universitarios para hacer frente a su futuro contexto profesional. En la sección 2.3 se presentan algunos conceptos que tienen que ver con los Mundos Virtuales. Finalmente, la sección 2.4 presenta un análisis de los Trabajos Relacionados con esta tesis.
2.1.
METODOLOGÍAS AGILES
El reconocido especialista Martin Fowler en una oportunidad mencionó:
“Desde hace ya unos pocos años ha habido un interés creciente en las
Metodologías Ágiles. Caracterizadas alternativamente como antídoto a la burocracia,
han suscitado interés en el panorama del software.” Martin Fowler (Ferrer, 2003).
18
pequeño, pero a medida que el sistema comienza a crecer se torna cada vez más difícil agregar nuevos aspectos al mismo.
Este estilo de desarrollo ha sido llevado adelante por mucho tiempo de manera satisfactoria, pero surgió una alternativa desde hace muchos años: aplicar una Metodología de Desarrollo Ingenieril. Sin embargo, debido a entornos comerciales más competitivos, conducidos por la rapidez para producir y entregar servicios (Ridderstrale, 2002), el enfoque propuesto por estas metodologías tradicionales no resulta el más adecuado dando lugar a un nuevo grupo de metodologías desde los años 90, las “Metodologías Agiles”, a continuación se construye una definición de dichas metodologías.
2.1.1.
DEFINICIÓN DE METODOLOGÍAS ÁGILES
En el año 2001, miembros prominentes de la comunidad se reunieron en Snowbird, Utah, y adoptaron el nombre de Metodologías Agiles, definiendo además el manifiesto ágil. Poco después, algunas de estas personas formaron la Agile Alliance, una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones.
Dado que hay tantas prácticas asociadas al desarrollo ágil, una forma más simple de definir Ágil es hacerlo en término de beneficios. Poole define el desarrollo ágil como aquel que, en comparación con el desarrollo tradicional, provee beneficios de mayor flexibilidad, retorno de Inversión más alto, realización más rápida del retorno de Inversión, más alta calidad, mayor visibilidad, y paz sostenible (Damon & Poole, 2009).
19
desarrollo. Estas prácticas incluyen: Product Backlog, programación de a pares, cliente en el lugar, integración continua, refactorización, desarrollo dirigido por pruebas (TDD) y muchas otras. Mientras que todas estas prácticas han estado asociadas con las Metodologías Ágiles o fueron crea das como resultado de las Metodologías Ágiles, su aplicación y beneficios resultantes pueden aplicarse completamente independientes de cualquier metodología específica (Damon & Poole, 2009).
Por otro lado, según (Ferrer, 2003) (P. Letelier, 2003) (Giro, Leiva, & Mesa, 2001), se considera que un modelo es ágil o liviano cuando se emplea para su construcción una herramienta o técnica sencilla, que apunta a Metodologías Ágiles y Bases de datos del conocimiento desarrollar un modelo aceptablemente bueno y suficiente en lugar de un modelo perfecto y complejo. Un modelo es suficientemente bueno cuando cumple con los objetivos para los que fue creado, logra principalmente el propósito de la comunicación; es entendible por la audiencia para la que fue concebido; no es perfecto y puede presentar algunos errores e inconsistencias no esenciales; posee un grado de detalle adecuado; suma valor al proyecto; y es suficientemente simple de construir (Ambler, 2002; Agiles, 2002).
Muchos métodos ágiles fueron creados antes del 2000. Entre los más notables se encuentran: Scrum (1986), Crystal Clear (cristal transparente), programación extrema o XP (1996), desarrollo de software adaptativo, Dynamic Systems Development Method (Método de desarrollo de sistemas dinámicos) (1995).
Entre estas mencionadas y más metodologías aun, Scrum es la destacada, ya que ofrece muchos beneficios en comparación con las demás metodologías, basándose en un enfoque iterativo, donde cada iteración se denomina Sprint. La diferencia con las iteraciones en cascada es que al final de cada Sprint
obtenemos un producto entregable que se va incrementando en sucesivos
20
valor al dueño del producto. Además, es una metodología potencialmente favorable para pequeños equipos de desarrollo y orientándose a entregas rápidas de resultados y una alta flexibilidad.
2.1.2.
SCRUM
Scrum es actualmente uno de los métodos ágiles para el desarrollo de software de mayor difusión en la industria. La razón de su popularidad se basa en sus potenciales mejoras en la productividad, la calidad y la satisfacción del cliente (Maher, Kourik, & Chookittikul, 2011) para el manejo de proyectos en entornos cambiantes que exigen rapidez en los resultados y requieren flexibilidad como requisito imprescindible.
21
Ilustración 2: Encuesta Metodologías Utilizadas
Según HighSmith (Highsmith, 2004), la agilidad es la habilidad de crear y responder a los cambios en orden de salir favorecido en un contexto turbulento de negocio.
22
Ilustración 3: Estructura Proceso Scrum
Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades del mismo. Con esta visión general se consigue un análisis a alto nivel del alcance general del sistema. Será la guía a lo largo de todo el proceso de desarrollo. Luego, se plantean cuáles son los requerimientos que se solicitaron para el producto, ordenándose en una lista. Dicha lista es conocida como el Product Backlog, donde los ítems que contiene son priorizados y divididos en períodos de tiempos breves, que pueden llevarse a cabo en un periodo normalmente de 30 días, llamados Sprints. Cada lista perteneciente a un Sprint se conoce como Sprint Backlog.
23
fortaleciendo de esta manera la cultura organizacional y alimentando la estructura de trabajo auto-organizada.
De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y la inversión mediante la re planificación de objetivos del producto, que realiza durante la iteración con vista a las siguientes iteraciones.
El primer día de la iteración se realiza la reunión de planificación de la misma. Lo primero que se llevará a cabo será la selección de requisitos en donde el
Product Owner presenta al equipo la lista de requisitos, Product Backlog, priorizada del producto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, SprintBacklog, de manera que puedan ser entregados si el cliente lo solicita. Luego el equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se auto asignan las tareas.
Durante la iteración el Scrum Master se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.
Elimina los obstáculos que el equipo no puede resolver por sí mismo.
Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.
24
trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Scrum Master en esta reunión se encarga de fortalecer y alentar al equipo a seguir adelante y observar qué elementos del proceso pueden ser mejorados para lograr mayor eficiencia y comodidad en el trabajo diario.
2.1.3.
ROLES DE SCRUM
El equipo Scrum está formado por los siguientes roles:
Scrum master: Persona que lidera al equipo guiándolo para que cumpla las reglas y procesos de la metodología. Gestiona la reducción de impedimentos del proyecto y trabaja con el Product Owner para maximizar el ROI.
Product Owner (PO): Representante de los accionistas y clientes que usan el software. Se focaliza en la parte de negocio y él es responsable del ROI del proyecto (entregar un valor superior al dinero invertido). Traslada la visión del proyecto al equipo, formaliza las prestaciones en historias a incorporar en el Product Backlog y las re prioriza de forma regular.
Team: Grupo de
profesionales con los conocimientos técnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint. Los equipos son auto-manejados y auto-organizados, y son responsables de convertir, al finalizar la iteración, el
25
conjunto de requerimientos del Sprint Backlog en un incremento del producto final. Los miembros del equipo son colectivamente responsables del éxito o fracaso de cada iteración y del proyecto como un todo.
2.1.4.
LOS BENEFICIOS DE USAR SCRUM
El uso de Scrum presenta una serie de beneficios para el desarrollo de software. Estos beneficios han sido demostrados no solo en la práctica sino también por la investigación. De hecho, (Agiles, 2002) resalta que los principales beneficios de la adopción de Scrum son:
Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el ProductOwner establece su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.
Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.
Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo.
26 Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse.
Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.
Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog.
Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.
2.2.
METODOS DE ENSEÑANZA
La época en que nos está tocando vivir demanda que los profesores sean cada vez más competentes en el diseño de tareas colaborativas de aprendizaje mediadas por la tecnología. Los términos como la “sociedad en la red”, la “sociedad de la información”, y la “sociedad del conocimiento” (Lund & Rasmussen, 2010) presentan un aspecto del mundo donde los adelantos del conocimiento distribuido y colaborativo retan las tradicionales prácticas educativas, incluyendo la formación del profesorado.
27
filosofía, situando al participante en el centro del proceso de aprendizaje. Este proceso de aprendizaje también ha cambiado, dado que ahora es construido en mayor colaboración junto con sus pares, el profesor y el contexto entero que los rodea (Casamayor, 2008).
En estos nuevos modelos de aprendizaje, los educadores deben mantenerse en constante actualización, dedicando tiempo a experimentar con la nueva tecnología y la manera de aplicarla en clase. No todo el tiempo se podrá aplicar la tecnología, pero el estudiar qué se está haciendo y cómo en este campo, permitirá al profesor ir modificando su cátedra para proporcionar la formación que la sociedad demanda.
Además, la experiencia muestra la necesaria flexibilización de las estructuras docentes que implican nuevas concepciones en el proceso de enseñanza/aprendizaje (Ibánez, 2008). Ahora, el énfasis se traslada de la enseñanza al aprendizaje y esto supone nuevos alumnos-usuarios caracterizados por una nueva relación con el saber, por nuevas prácticas de aprendizaje y adaptables a situaciones educativas en permanente cambio.
El rol del docente también cambia, deja de ser fuente de todo conocimiento y pasa a ser guía de los alumnos para facilitarles el uso de recursos y herramientas que necesitan para explorar y elaborar nuevo conocimiento y destrezas y de este modo, el docente se convierte en gestor de recursos de aprendizaje y acentúa su papel de orientador.
28
En lo que respecta a la enseñanza de Scrum, existen diferentes métodos de enseñanza que van desde las clases tradicionales hasta la enseñanza basada en proyectos pilotos (Ver Sección 2.4 para más detalles). Sin embargo, en esta tesis nos centramos en la enseñanza a través de un juego, por lo que se explican conceptos relacionados con los juegos como método de enseñanza en la siguiente sección.
2.2.1.
EL JUEGO COMO MÉTODO DE ENSEÑANZA
El juego es una herramienta educativa que facilita el aprendizaje y la comunicación entre iguales. Existen numerosas propuestas pedagógicas que lo avalan en la práctica diaria (Piaget, 1979) (Vygotsky, 1933) (Bruner, 1986) (Garvey, 1983) (Garaigordobil, 1990). Entre otros, los beneficios inciden sobre el desarrollo cognitivo, afectivo, social, comunicativo y psicomotor. Por estas razones, se dice que el juego debe ser utilizado, ya no sólo en la Educación Formal, sino también en la No Formal, de la que forma parte el educador social (Toro, 2013). Entonces, el juego aparece como una alternativa interesante a explotar para la educación, aunque su inclusión en el aprendizaje no siempre resulte sencilla.
Al jugar, el alumno crea un contexto dentro del cual puede ensayar formas de responder a las preguntas con las que se enfrenta, y también construir conocimientos nuevos. “El juego ofrece a los alumnos oportunidades para el desarrollo de las capacidades representativas, la creatividad, la imaginación, la comunicación, ampliando la capacidad de comprensión del mundo para constituirse en miembro de una sociedad y una cultura” (Malajovich, 2000). Al mismo tiempo, el juego le permite comunicarse y cooperar con otros, ampliando el conocimiento que tiene del mundo social.
29
desee” (BROUGERE, 2008) y teniendo la posibilidad de ensayar diversas respuestas a situaciones complejas sin temor a fracasar.
Evidentemente, estas características convierten a los juegos en una alternativa prometedora para la enseñanza de Scrum. No obstante, es importante considerar qué tipo de juego, que objetivos tendrá dicho juego, y cuál presenta las mejores características que se adapten a la metodología de desarrollo de Software.
2.2.2.
LA CONSTRUCCIÓN USANDO LEGO PARA LA
ENSEÑANZA DE SCRUM
LEGO es una empresa de juguetes danesa reconocida principalmente por sus bloques de plástico interconectables. Al interconectar bloques, se pueden realizar diferentes figuras de cualquier tipo. Así, estos pequeños juguetes de construcción se encuentran en los hogares de todo el mundo, donde los niños pasan horas construyendo cualquier cosa que sus mentes puedan imaginar. Afortunadamente, todo ese tiempo dedicado a jugar con LEGOs no sólo es divertido para los niños, sino también beneficioso.
Construir con piezas de LEGO fomenta el razonamiento espacial y la conciencia de las proporciones y los patrones. Cuando un alumno construye, su mente está razonando sobre qué pieza funcionará mejor, cómo deben organizarse y qué tan grande o pequeña debe ser la creación. Los ladrillos básicos de LEGO
también enseñan fracciones y divisiones. Habilidades físicas y de ingeniería también están desarrollándose sigilosamente.
En este sentido, recientemente se ha explorado el uso de la construcción con bloques LEGO para enseñar Scrum en universidades (Paasivaara, Heikkilä, Lassenius, & Toivola, 2014), con prometedores resultados. De esta manera,
30
enseñanza del Proceso y Roles, la Gestión de Requerimientos y Colaboración del Cliente, la Estimación, el Trabajo en Equipo, y el Progreso del producto son una tarea sencilla que nos aporta el jugar y construir con piezas de LEGO.
A medida que el juego va ejecutando iteraciones, las etapas del proceso Scrum
empiezan a ser algo natural para los participantes. El juego tiene como objetivo mostrar la naturaleza iterativa del desarrollo, dejando en claro cómo se puede obtener retroalimentación del propietario en cada iteración. Además, los roles como el Product Owner, Scrum Master, Scrum Team, y sus responsabilidades están bien detalladas y claras durante el juego.
La gestión de Requerimientos es un tema fundamental para el aprendizaje de
Scrum. Jugando LEGO este tema es fácil de esclarecer. El profesor, jugando el papel de ProductOwner actúa como una persona de negocios reales, hablando de los objetivos de negocio, sin comprender las cuestiones técnicas. El Scrum Team discute los objetivos con el ProductOwner y empieza a realizar preguntas respecto del producto solicitado, lo que nos indica que están empezando a entender como el cliente puede colaborar en el desarrollo del producto. Al trabajar con el ProductOwner, los equipos aprenden la importancia de priorizar. Durante demos el ProductOwner prueba el producto, lo que muestra el equipo de la importancia de la pronta integración y las pruebas adecuadas.
El construir con piezas LEGO fomenta el trabajo en equipo ya que todos los miembros del mismo pueden colaborar en la construcción de una pieza. Toda persona sabe construir con piezas LEGO, por lo tanto, la participación en el trabajo en equipo no está limitado debido a los diferentes niveles de habilidad. Además, los equipos formados tienen la misma cantidad de personas que los verdaderos equipos de Scrum, de siete a ocho personas, todos ellos animan a participar activamente en la planificación y la comunicación dentro del equipo, saben que necesitan colaborar para su proyecto tenga éxito.
31
el backlog por escrito. El equipo tiene una reunión con el Product Owner y visualizan lo construido con piezas LEGO. El ProductOwner prueba la parte del modelo desarrollado y comenta sus impresiones al equipo.
Además, cuando un alumno construye con LEGOs, está utilizando habilidades
para resolver problemas. Tiene que averiguar qué bloque funciona para su edificio, a veces utilizando el método de ensayo y error. La planificación y organización son otros beneficios. La construcción con LEGOs requiere que el alumno tenga un plan antes de que construya, incluso si es sólo uno básico. También debe organizar sus pensamientos, así como las piezas de LEGO para llevar acabo su idea.
La creatividad es, tal vez, el más obvio de los beneficios que se aprende con los
LEGOs. Construir con los bloques fomenta la creatividad tanto en el juego individual como grupal, utilizando sólo las piezas de LEGO para crear cualquier cosa que sus mentes puedan imaginar. El juego libre y abierto estimula a pensar más allá y soñar con un sinfín de posibilidades. Por esto y muchas razones más, LEGO es el juego que mejor se adapta a la enseñanza de Scrum
(Krivitsky, 2009).
2.3.
MUNDOS VIRTUALES
32
virtual como VRML (Virtual Reality Modeling Language) o bien gracias a plataformas de desarrollo de videojuegos como Unity3D.
La deficiencia común de los primeros sistemas en 3D fue su falta de realismo visual. En la actualidad, los motores de juegos como Unity3D ofrecen los nuevos avances en informática gráfica en tiempo real por lo que son una buena alternativa a los sistemas actuales que los potencias para su uso en numerosos campos de aplicación (Eberly, 2000) (DeLoura, 2000) (Watt & Policarpo, 2000) (Möller & Hainer, 2008).
El origen de los que hoy se conocen como mundos virtuales fue muy diverso, algunos aparecieron como una extensión de los chats, para mostrar una imagen de cada uno de los participantes y hacer el espacio más interactivo. Otros fueron extensiones de juegos que lanzaron una versión para jugar en línea. El origen se remonta al inicio de la década de los 90, con las principales características de permitir la definición de objetos 3D en lugares remotos, la definición de animaciones, la inclusión de conexiones a otros mundos o sitios Web y, la modificación del entorno.
33
limitados en videojuegos, muchos de estos mundos virtuales son conocidos como videojuegos masivos en línea o MMO (Massively multiplayer online games).
Los antecesores de los mundos virtuales son los juegos de rol en línea conocidos por el acrónimo MMORPG) [MMORPG es un acrónimo de Massively Multiplayer Online Role Player Game.] que hace referencia a las principales características de un género de videojuego: un juego de roles en línea en el que participan masivamente muchos jugadores a la vez. Dos ejemplos típicos de los MMORPG son Everquest y World of Warcraft. En los mundos virtuales a diferencia de estos juegos, no existen reglas que cumplir, no tienen ningún objetivo que conseguir y no hay fases que se deban superar. Lo que los usuarios hacen en el mundo virtual está sujeto a sus propios intereses y pueden variar desde simplemente conocer personas, hacer negocios, promocionar productos o modelar mundos virtuales, entre otros (Barreiro, 2009).
34
Ilustración 5: Ingreso mensual a Second Life
35
Ilustración 6: Usuarios Activos en Mundos Virtuales
2.3.1.
MUNDOS VIRTUALES COMO HERRAMIENTA
DE ENSEÑANZA
36
La aplicación de los mundos virtuales para la docencia a través de Internet hace que el alumno pueda sumergirse en ambientes amigables que hacen más ameno el aprendizaje. Así, estos mundos se vuelven una tecnología especialmente adecuada para la enseñanza, debido a su facilidad para captar la atención de los estudiantes mediante su inmersión en mundos virtuales
relacionados con las diferentes ramas del saber, lo cual puede ayudar en el aprendizaje de los contenidos de cualquier materia.
Según afirma García Ruíz (1998), a partir de los experimentos llevados a cabo por Sherman y Judkins (1994) en la Universidad de Washington se puede llegar a la conclusión de que con esta tecnología los estudiantes "pueden aprender de manera más rápida y asimilar información de una manera más consistente que por medio del uso de herramientas de enseñanza tradicionales (pizarra, libros, etc.), ya que utilizan casi todos sus sentidos”. Los estudiantes no sólo pueden leer textos y ver imágenes sobre una pantalla, sino que además pueden escuchar narraciones, efectos de sonido y música relacionados con el tema que están aprendiendo.
Los Mundos Virtuales son un recurso didáctico del que los profesores se pueden servir para motivar y atraer la atención de los estudiantes a través de los gráficos tridimensionales de calidad y del alto grado de interactividad ofrecida por los sistemas virtuales. Cada vez es mayor el número de centros de enseñanza en los que se utilizan aplicaciones de este tipo.
37
distintos médicos de cualquier parte del mundo; esta información podría servir de aprendizaje para los estudiantes de medicina y también para otros médicos. Su utilidad también destaca en otros campos. Por ejemplo, en Canadá se ha desarrollado el sistema Mandala, con el que estudiantes de danza aprenden movimientos de baile, y practican y desarrollan su habilidad musical utilizando instrumentos "virtuales". En relación con el arte, en Internet se ofrece versiones virtuales de cualquier tipo de museo o galería de arte del mundo. De esta forma, cualquier estudiante puede acceder, no sólo a la imagen digitalizada de un cuadro y a explicaciones textuales, sonoras o audiovisuales sobre el mismo, sino también puede conocer las instalaciones de museo y recorrerlas virtualmente (ArgentinaVirtual, 1999). Los estudiantes de arquitectura también pueden beneficiarse, a través de programas educativos para el aprendizaje del diseño de diferentes tipos de edificios. Además, la integración de herramientas de diseño, como AutoCAD, con herramientas de animación tridimensional, como 3DStudio, permitiendo la construcción de edificios virtuales de gran complejidad en los que una persona puede introducirse para recorrerlos hasta el último rincón y observar hasta el mínimo detalle de su construcción y decoración.
Para García Ruiz (1998), una de las aplicaciones educativas más notorias es el entrenamiento técnico, especialmente el de pilotos de aeronaves. En este caso, con esta tecnología se evitan riesgos que se presentan en el entrenamiento real, tales como tormentas o vientos fuertes que pueden causar accidentes al avión real si el piloto no tiene la suficiente habilidad para salir adelante en estas situaciones. Pilotos de aerolíneas y del ejército utilizan simuladores de realidad virtual para medir sus reacciones en medio de circunstancias virtuales peligrosas (MacDonald, 1994).
38
tesis propone el uso de un Mundo Virtual que explota la construcción mediante bloques LEGO en un campo no antes explorado: la enseñanza de Scrum.
2.4.
TRABAJOS RELACIONADOS
A continuación, se ofrece un resumen de la literatura sobre enfoques que intentan enseñar Scrum en cursos de Ingeniería de Software. Todos los estudios hacen hincapié en que la enseñanza de Scrum no debe limitarse a las clases tradicionales, sino que la experiencia práctica es fundamental con el fin de reforzar la comprensión y lograr un aprendizaje profundo.
Un enfoque utilizado es la enseñanza de Scrum a través de trabajos prácticos, simulando proyectos complejos de desarrollo. Con el fin de aprender Scrum los estudiantes no necesitan extensas charlas, sino que deben aprenderlo, entenderlo y probarlo en la práctica. Al simular un proyecto de desarrollo se obtiene un entorno de trabajo profesional lo más similar al de la vida real, con lo cual estos cursos explotan principalmente el beneficio de tener un ambiente cuasi real. (Paasivaara, Lassenius, Damian, Raty, & Schroter, 2013)
Otro enfoque para la enseñanza de Scrum es mediante la utilización de juegos educativos. Este tipo de enfoques son particularmente adecuados cuando el curso no permite el tiempo suficiente para el desarrollo de un proyecto complejo. Los juegos por lo general requieren que los estudiantes sigan las reglas y prácticas de Scrum en el desarrollo de un producto sencillo en varias iteraciones (Paasivaara, Heikkilä, Lassenius, & Toivola, 2014).
39
razón, a continuación se detallan las características principales de estos enfoques.
2.4.1.
ENSEÑANDO SCRUM A TRAVÉS DE LA
SIMULACIÓN DE PROYECTOS
La simulación de proyectos reales dentro del curso de Ingeniería de software es uno de los métodos de enseñanza de Scrum más usuales. Este método ha sido reportado satisfactoriamente por varios educadores, aun cuando los enfoques difieren ligeramente entre ellos. Estos trabajos realizados por educadores se describen en las siguientes subsecciones.
Mahnič (Mahnic, A capstone course on agile software development using scrum, 2012) y Scharf y Koch (Scharf & Koch, 2013)utilizan un diseño similar que consiste en un Sprint de preparación y una secuencia de Sprints. Durante el primer Sprint, los estudiantes asisten a clases formales sobre Scrum, familiarizándose con el proyecto que se va a desarrollar y preparando el entorno de desarrollo. Luego, ya en los demás Sprints siguen estrictamente las reglas de Scrum, iniciando cada uno con la reunión de planificación de Sprint y terminando con la revisión Sprint y reuniones retrospectivas. Durante el Sprint, los miembros del equipo deben reunirse regularmente en las Daily Meeting
informándose sobre sus actividades actuales y los posibles impedimentos. Cada
Sprint debe proporcionar un incremento de la funcionalidad requerida que debe ser mostrado en la reunión de revisión de Sprint. Mahnič asume que el papel del
Product Owner es interpretado por un experto del dominio, ya sea personal docente o un representante de una empresa, mientras que el papel
40
A diferencia de Mahnič, Scharf y Koch, Kropp y Meier (Kropp & Meier)parten de la premisa de que la obtención de conocimiento necesario para el desarrollo ágil de software se puede dividir en tres categorías principales: prácticas de ingeniería, prácticas de gestión y los valores ágiles. En consecuencia, los cursos se dividen en dos partes, por un lado, las prácticas de ingeniería y por otro las prácticas de gestión de Scrum y valores ágiles. Scrum se introduce en la segunda parte, luego que los estudiantes han dominado las prácticas de ingeniería a través de Extreme Programming (XP) (K.). Los estudiantes se dividen en equipos de seis a ocho personas para el desarrollo de un juego. Se realizarán seis Sprints de una semana cada uno. El equipo vota seleccionando el Scrum Master y el profesor cumple el rol de Product Owner. Semana a semana los equipos realizan reuniones de planificación de Sprint y revisión de
Sprint siempre acompañados y entrenados por el profesor. Al finalizar los seis
Sprint se realiza una reunión retrospectiva mostrando lo desarrollado hasta el momento al ProductOwner.
Reichlmayr (Reichlmayr, 2011) utiliza los teléfonos móviles Android como el entorno de desarrollo para estudiantes que desean aprender y practicar Scrum
(Reichlmayr, 2011). El método de enseñanza está divido en dos partes, una dedicada a la descripción de Scrum, sus normas y prácticas. Por otro lado, ofrece una interesante descripción de cómo los estudiantes escriben las User Stories, como estiman mediante la planificación de Poker Planning, como identifican las pruebas de aceptación, y como descomponen las UserStories en pequeñas tareas.
El método realizado por Zorzo (Donizetti Zorzo, 2013, October) intenta combinar las partes teóricas y prácticas de un curso de ingeniería de software. La parte teórica se inicia con una descripción general de Scrum, preparación de
41
entregables de cada Sprint garantizando que las entregas se realicen a su debido tiempo.
2.4.2.
ENSEÑANDO SCRUM A TRAVÉS DE JUEGOS
EDUCATIVOS
Paasivaara (Paasivaara, Heikkilä, Lassenius, & Toivola, 2014) propone un juego de simulación Scrum basado en LEGO, como una alternativa a la enseñanza basada en las clases tradicionales. En este modelo de enseñanza los roles de
Product Owner y ScrumMaster son interpretados por profesionales con experiencia, mientras que los estudiantes se agrupan en equipos para trabajar en la construcción de un nuevo producto con bloques de LEGO. La simulación de
Scrum se inicia con la captura de requerimientos, para la cual los integrantes del equipo consultan al Product Owner todo lo que creen necesario. Luego realizan la planificación del desarrollo en conjunto con el Product Owner. Los equipos realizan de tres a cuatro Sprint en donde al comienzo de cada uno de ellos, se pone en práctica la planificación del mismo junto con una DailyMeeting
de no más de 5 minutos. Sobre el final de cada Sprint se llevan a cabo las reuniones retrospectivas y reuniones de demostración del producto al Product Owner. Cabe destacar que cada Sprint no dura más de 25-30 minutos. El juego tiene como objetivo alcanzar las metas de aprendizaje sobre el proceso y los roles de Scrum, gestión de requisitos y la colaboración del cliente, estimación, trabajar en equipo, y visualizar el trabajo y el progreso.
42
miembros del equipo de desarrollo. El Product Backlog se compone de User Stories que representan los pedidos del cliente como por ejemplo barcos de papel, sombreros, aviones, etc. La ejecución del juego consta de cinco pasos: estimación de las user stories, planificación del Sprint, ejecución del Sprint, revisión del Sprint y liberación. La ejecución del Sprint se divide en sub-etapas que comprenden una reunión inicial y una secuencia de tres períodos de trabajo, cada uno de ellos termina con una Daily Meeting. Después del juego, los estudiantes y el profesor llevan a cabo una sesión informativa para reflexionar y compartir su aprendizaje de Scrum.
Fernandes y Sousa (Fernandes & Sousa, 2010) proponen un juego en el que cada estudiante juega el papel de un ScrumMaster. El juego utiliza varios tipos de tarjetas, tarjetas ProductBacklog, tarjetas ProblemCards, tarjetas Concept
y tarjetas Developer. Las tarjetas del Product Backlog determinan las características del proyecto, las tarjetas de Problem Cards detallan los problemas que pueden ocurrir durante el desarrollo del proyecto, las tarjetas Concept contienen las posibles soluciones a cada uno de los problemas listados en las tarjetas previas y las tarjetas Developer corresponden a los miembros del equipo de desarrollo. Al comienzo del juego, se elige una tarjeta Product Backlog, con esta se define el número de Sprints que se ejecutaran y las tareas que deben completarse, además del costo de los artefactos y el presupuesto disponible para cada jugador. Luego, los jugadores intentan completar sus tareas jugando con las tarjetas Developer. El ganador es el jugador que primero complete todas las tareas definidas para el proyecto o aquel que tiene el mayor porcentaje de tareas totalmente terminadas después del final del último Sprint.
Ramingwong y Ramingwong (Ramingwong & Ramingwong, 2015) describen una variación del juego desarrollado por Krivitsky (Krivitsky, 2009). La diferencia con el juego de Paasivaara es que los autores no utilizan ladrillos de
43
Ramingwong sugiere el uso de la plastilina como el componente principal de desarrollo.
A continuación, la Tabla 1: Tabla comparativa de modelos planteados, muestra un cuadro comparativo resumiendo las literaturas abordadas sobre enfoques para enseñar Scrum en cursos de Ingeniería de Software.
Tabla 1: Tabla comparativa de modelos planteados
INSTRUCTORES Simulació n de Proyecto Juegos Educativo s Asignación de Roles a los estudiantes
Asignación de Roles al
Instructor Material
Especial Necesario Produ ct Owner Scrum Maste r Produ ct Owner Scrum Maste r
MAHNIČ X X X No
SCHARF Y KOCH X X X No
KROPP Y MEIER X X X No
REICHLMAYR X X X No
ZORZO X X X No
PAASIVAARA X X X Si (Piezas Lego)
VON WANGENHEIM X X X Si (Lápiz y
Papel) FERNANDES Y
SOUSA X X X Si (Tarjetas)
RAMINGWONG Y
44
2.5.
CONCLUSIONES
En este capítulo se realizó un análisis de los conceptos más importantes que se utilizan en el desarrollo de este trabajo. En primer lugar, se realizó una breve reseña histórica sobre la importancia de las metodologías agiles acompañando el crecimiento en el desarrollo de software. En la actualidad, la Metodología Ágil más popular para la gestión de proyectos es Scrum, debido a todas las ventajas detalladas en la sección 2.1.4. Considerando esto, las universidades están incluyendo la enseñanza de dicha metodología dentro de su plan de estudios.
Luego se explicó el concepto de mundo virtual y los mundos virtuales como herramienta de enseñanza, conceptos que son pilares fundamentales para comprender el objetivo de la herramienta desarrollada en un entorno 3D para mejorar el proceso de aprendizaje en la educación a distancia, además de minimizar el impacto de las restricciones mencionas en la sección 1.2 del Capítulo 1.
Finalmente se listaron y explicaron diferentes métodos de enseñanza por diversos instructores para la metodología Scrum. Algunos instructores optan por el uso de clases tradicionales, otros optan por centrar la clase en la puesta en práctica de un proyecto de Scrum, mostrando así las características de la metodología y permitiendo que los alumnos aprendan desde la experiencia. Actualmente también se están utilizando juegos para enseñar el método ágil
Scrum haciendo la clase más entretenida. El uso de mundos virtuales a través de internet para estos juegos permite a los estudiantes sumergirse en entornos amigables que hacen más ameno el aprendizaje. Los estudiantes pueden interactuar con el entorno de una forma realista. Por ello si se suma a las ventajas de estos mundos la ventaja de conectarse por internet, hace que el proceso de aprendizaje sea más fácil (Brodlie, El-Khalili, & Ying Li, 1999).
45
46
47
3.
LA TESIS
Scrum es actualmente uno de los métodos ágiles para el desarrollo de software de mayor difusión en la industria. La razón de su popularidad se basa en sus potenciales mejoras en la productividad, la calidad y la satisfacción del cliente (Maher, Kourik, & Chookittikul, 2011) para el manejo de proyectos en entornos cambiantes que exigen rapidez en los resultados y requieren flexibilidad como requisito imprescindible. Acompañando esta tendencia, las universidades están incluyendo la enseñanza de dicha metodología dentro de su plan de estudios (Scott, Rodriguez, Soria, & Campos, 2014). Dentro de dichos planes, los cursos que proponen enseñar Scrum utilizan diferentes estrategias. El uso de clases tradicionales donde el profesor dicta los conceptos y los alumnos toman notas resulta una buena opción. Sin embargo, algunos profesores optan por centrar la clase en la puesta en práctica de un proyecto de
Scrum, mostrando así las características de la metodología y permitiendo que los alumnos aprendan desde la experiencia (Mahnic, A capstone course on agile software development using scrum, 2012). La tendencia actual apunta también a enseñar el método ágil a través de juegos, como complemento a la enseñanza, para obtener una clase más flexible y entretenida.
48 Scrum. En este entorno, las personas se pueden vincular a pesar que no se encuentren en el mismo lugar físico. Esto permite escalar al grupo de trabajo en la cantidad de integrantes que se desee sin necesariamente localizarse en la misma ubicación geográfica (Boeham, 2001), también escalar la cantidad de piezas LEGO requeridas por cada equipo de estudiantes para llevar a cabo el juego. Además, la simulación del desarrollo del producto se encuentra fuera de riesgos a diferencia de un contexto real.
En el presente trabajo se busca dar solución a estas problemáticas y para ello, se propone minimizar el impacto de estas restricciones en el ambiente académico a la hora de enseñar Scrum mediante la utilización de un juego
LEGO en un mundo virtual. El enfoque propuesto en este trabajo se basa principalmente en la utilización de un juego que permita a los estudiantes experimentar con la metodología. Para esto, la utilización de bloques LEGO
aparece como una alternativa interesante a los métodos de enseñanza tradicionales, ya que la construcción con bloques permite simular el incremento del producto de software de manera análoga al mundo real. Para poder concretar reuniones de software, principalmente de Scrum, es necesario que la sala cuente con los artefactos necesarios para garantizar que se cumplan las prácticas y que haya comodidad a la hora de tomar parte de ella. Por tal motivo se ha decidido utilizar como ambiente virtual, la herramienta Virtual Scrum
49
Ilustración 9: Virtual Scrum Lego
3.1.
VISIÓN GENERAL
El enfoque propuesto se basa en el desarrollo de un juego de construcción con bloques LEGO en un ambiente virtual para la enseñanza de la metodología
Scrum, Virtual Scrum Lego. La ilustración 9 describe un esquema conceptual de nuestro enfoque, ilustrando la interacción entre los usuarios (profesores y estudiantes) y la herramienta desarrollada. El primer paso del enfoque, como se puede apreciar en el punto (1) de la Ilustración 9, es la organización de la clase en grupos de alumnos que representa a cada equipo de desarrollo (Scrum Team).
50
Contando ya con los Scrum Teams y el producto a desarrollar, se inicia el proceso de Scrum en el cual los grupos definen las User Stories (punto 3), estiman cada una de ellas (punto 4) utilizando Planning Poker y comienzan el proceso de construcción (punto 6). Finalizando este proceso, los estudiantes plantean al profesor su incremento del producto llevándose a cabo el Sprint Review (punto 8). El incremento del producto consiste de una porción del modelo, construida con bloques LEGO. Como último paso fuerte e importante en la enseñanza de Scrum, el profesor junto con los estudiantes deberá realizar el Sprint Retrospective (punto 9). Finalmente, se vuelve a iterar este proceso antes descripto, hasta finalizar con el desarrollo total del producto.
En el resto de las secciones utilizamos un ejemplo conducto para describir los pasos de Virtual Scrum Lego. En la Sección 4.2 se detalla el Plan de Proyecto del cual se obtendrá el grupo de alumnos que formara cada equipo y la lista de objetivos/requisitos priorizada del producto. En la Sección 4.3 Planificación del
Sprint, se explica la manera en la cual se planifica y se ejecuta una iteración en el desarrollo del producto. Por ultimo en la Sección 4.4 Ejecución del Sprint, se presenta la Inspección y Adaptación del desarrollo.
3.2.
DEFINICIÓN DEL PROYECTO
PILOTO
51
querrá desarrollen los Scrum Team, el cual le servirá como guía en el aprendizaje de la metodología.
Supongamos que el docente decide desarrollar como producto un avioncito. Para esto el profesor asumiendo el rol de Product Owner debe definir dos elementos básicos: una imagen representativa del modelo la cual servirá como guía de desarrollo a los alumnos (Ver Ilustración 10) y el modelo final deseado, el cual construirá mediante el uso de bloques LEGO (Ver Ilustración 11).28).
Ilustración 10: Agregado de Imagen a Modelo
52
Siguiendo con la metodología los grupos definen las UserStories necesarias con el apoyo del profesor en rol de ProductOwner. Para esto cuentan con un panel de Product Backlog en donde agregaran cada una de las User Stories (Ver Ilustración 12).
De acuerdo a Scrum, la generación de UserStories se lleva a cabo de manera colaborativa, para lo que se pueden usar el chat o video conferencia para soportarla, en donde cada alumno puede expresarse libremente dando su opinión en la definición del Product Backlog.
53
3.3.
PLANIFICACIÓN DEL SPRINT
Finalizada la definición del Product Backlog, los alumnos continúan hacia el aprendizaje de la estimación de las UserStories. Con indicaciones del profesor dentro del Virtual Scrum Lego, los estudiantes llevan a cabo el proceso de estimación, utilizando Planning Poker (Grenning, 2002), en donde todos los miembros del equipo participan activamente. La Ilustración 13 muestra una sesión de planning para la user story del ejemplo.
Una vez puesta en práctica y finalizada la estimación, entonces podrán continuar con el Sprint Planning, en donde todo el equipo de alumnos planificaran que tareas realizaran a lo largo de cada Sprint. Si bien un Sprint en un ambiente real de desarrollos de proyectos puede llegar a durar varias semanas, en Virtual Scrum Lego se toma como tiempo máximo una hora para cada sprint. El Scrum Team en este punto realizara todas sugerencias que
54
crean necesarias, pero la decisión de que elementos del Product Backlog
pueden formar parte del Sprint es responsabilidad del Product Owner, quien seleccionara cada una las US creadas considerando su duración a lo largo del
sprint. El Scrum Team identificara y comunicara al Product Owner cuánto del trabajo es probable que se realice durante el actual Sprint. La Ilustración 14 muestra un ejemplo natural del Task Board para el ejemplo aplicado.
55
3.4.
EJECUCIÓN DEL SPRINT
Ya dentro del sprint, comienzan el desarrollo de la US mediante la construcción con bloques LEGO. El equipo de desarrollo auto asigna cara tarea a realizar por cada alumno. Cada uno de estos dará comienzos en la construcción parcial del modelo con los bloques LEGOs virtuales. A pesar de que todos los alumnos tendrán una tarea asignada, cualquiera de ellos podrá pausar su tarea por un momento para dar soporte en la construcción de la US de un compañero, siempre y cuando se encuentre dentro del TeamRoom. En la Ilustración 15 se puede apreciar el trabajo colaborativo al momento de construir una porción del producto a desarrollar.
