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

Tandil, Año 2016

 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.

¡Muchísimas Gracias!

2
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.

El enfoque fue evaluado a través de un experimento controlado que involucra

estudiantes avanzados. El experimento se basó en el desarrollo de un pequeño
proyecto pilo en dos contextos diferentes: utilizando el enfoque propuesto y en
una clase tradicional. Se tuvieron en cuenta aspectos de la usabilidad así como
del aprendizaje de los estudiantes. Los resultados obtenidos mostraron
mejoras del enfoque propuesto respecto al tradicional.

3
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
4. DISEÑO E IMPLEMENTACIÓN DE VIRTUAL SCRUM LEGO ......................................................... 60

4
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
5.3.1.4. Control y Supervisión del trabajo durante el Sprint ......................................................... 97

5
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
Bibliografía ................................................................................................................................. 142

6
Í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
Ilustración 40: Daily Meetings Virtual Scrum Lego................................................................................... 103

7
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 ................................................................................. 43
Tabla 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
Tabla 11: Estadísticos de Prueba. ............................................................................................................ 128

8
CAPÍTULO 1

9
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!
(TastyCupcakes, 2008), más conocido como “Jenga”. Este juego está dedicado
10
a aquellos que abordan un proyecto con Metodología Scrum 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.

Por lo tanto, en este contexto este trabajo explora los beneficios de los juegos
en la enseñanza de Scrum proponiendo una mejora al uso de Virtual Scrum en
el contexto educativo. Esta mejora se basa en incorporar un mecanismo de
juego con bloques LEGO que complemente la posibilidad de simular un entorno
11
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
Scrum. En particular, esta herramienta es un mundo virtual en 3D diseñada
para ser utilizada por estudiantes de ingeniería de software dispuestos a
12
aprender la Metodología Scrum. 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

La clase inicia con la organización de los grupos, en donde los alumnos deberán
auto-organizarse en grupos de 4-6 personas como lo sugiere Scrum (1). Luego,
el profesor seguirá con la construcción de su requerimiento mediante el uso de
bloques LEGO. De esta manera, se define un modelo del requerimiento, el cual
deberá ser llevado a cabo por los alumnos en su rol de desarrolladores. Además
se permitirá enriquecer el modelo agregando imágenes y otra información
descriptiva del requerimiento (2). Toda esta información enriquecedora será
mostrada en todo momento como parte del Product Backlog en un panel de la

13
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 Daily build, 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.

En el capítulo 2, se describen los métodos ágiles como alternativa de marco

para el desarrollo de software, y el por qué las universidades están incluyendo
14
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.

En el capítulo 6, se muestran las conclusiones finales del trabajo con las

posibles mejoras y trabajos futuros que se pueden realizar.

15
CAPÍTULO 2

16
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).

Esto apunta a que el desarrollo de software es una actividad desordenada,

caracterizada por la frase "codifica y corrige". Normalmente, el software se
escribe con un mínimo plan, y el diseño del sistema se arma con muchas
decisiones a corto plazo. Esto funciona realmente muy bien si el sistema es

17
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).

Poole hace notar que se habla de Metodologías Ágiles como un solo paquete: si
se adhiere a los principios del manifiesto ágil, se obtienen los beneficios. Pero,
hay otra forma de mirarlas y es pensar que las metodologías ágiles introducen
un conjunto nuevo y completo de prácticas al conjunto de herramientas de

18
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
Sprints. En cada Sprint se prioriza aspectos que aportan mayor funcionalidad y

19
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.
La última encuesta del Estado del Desarrollo Ágil realizada por VersionOne fue
desarrollada entre el 22 de julio y el 1 de noviembre de 2014. Esta encuesta fue
respondida por 6042 empresas. Más de la mitad de los encuestados dijo que
personalmente había seguido las prácticas ágiles desde hace 2 años, y una
tercera ha llevado la Metodología Ágil con ellos a otra empresa. En la ilustración
2 puede observarse las metodologías agiles más utilizadas.

20
 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.
Ken Schwaber (Schwaber, Agile Project Management with Scrum, 2004) afirma
que Scrum comienza con la premisa que el desarrollo de software es muy
complejo e impredecible para ser planeado exactamente de antemano. Sin
embargo, un proceso empírico debe ser aplicado para asegurar visión,
inspección y adaptación. Las diversas variables técnicas y ambientales deben
ser controladas constantemente con el objetivo de ser capaz de adaptarse a los
cambios en forma flexible. Esto es alcanzado a través de un proceso de
desarrollo iterativo e incremental. En la ilustración 3, puede observarse la
estructura del proceso de Scrum.

21
 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.

Cada uno de estos periodos de desarrollo, es una iteración que finaliza con la
producción de un incremento operativo del producto. Estas iteraciones son la
base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones
diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el
previsto para el día siguiente. Esta reunión se denomina Daily Meeting, las
cuales permiten “socializar el conocimiento” entre los miembros del equipo,

22
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, Sprint Backlog, 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.

El último día de la iteración se realiza la reunión de revisión de la iteración,

denominada Sprint Review Meeting. En donde el equipo presenta al Product
Owner los requisitos completados en la iteración, en forma de incremento de
producto preparado para ser entregado con el mínimo esfuerzo. En función de
los resultados mostrados y de los cambios que haya habido en el contexto del
proyecto, el Product Owner realiza las adaptaciones necesarias de manera
objetiva, ya desde la primera iteración, re planificando el proyecto. Por último el
equipo realiza una reunión retrospectiva analizando cómo ha sido su manera de
23
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
24
Ilustración 4: Roles De Scrum
 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 Product Owner 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.

Mayor calidad del software: La metódica de trabajo y la necesidad de

obtener una versión funcional después de cada iteración, ayuda a la obtención
de un software de calidad superior.

25
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.

En este contexto, se abren paso nuevos modelos de aprendizaje donde los

recursos de computacionales y de Internet son aplicados como una nueva

26
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.

Todas estas consideraciones son cruciales para entender el contexto de

enseñanza actual, y en el cual se enmarca esta tesis. Asimismo, numerosos
investigadores han demostrado que utilizar la tecnología en diferentes
actividades incrementa el nivel de interacción entre los alumnos, fomentando
así ambientes más creativos, necesarios para el trabajo colaborativo.

27
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.

Jugando suponemos la creación de un “mundo paralelo, de una situación ficticia

donde se utilizan elementos de la realidad al tiempo que el jugador sabe que lo
que se hace no es verdad, pudiendo entrar y salir de ese mundo cuando lo
28
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,
LEGO brinda soporte en el aprendizaje de las metas principales de Scrum. La

29
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 Product Owner 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 Product Owner 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 Product Owner, los equipos aprenden la importancia de priorizar.
Durante demos el Product Owner 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.

Finalmente, la última meta de aprendizaje es el Progreso del producto que se

logra con cada iteración en el juego. El trabajo y el progreso se visualizaron en
30
el backlog por escrito. El equipo tiene una reunión con el Product Owner y
visualizan lo construido con piezas LEGO. El Product Owner 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

La aparición de Internet como medio de comunicación ha supuesto que el
acceso a la información sea sencillo y rápido. La mayor parte de esta
información reside en las conocidas páginas Web, que suelen presentar texto e
imágenes en dos dimensiones. El mundo real es tridimensional, por lo que al
reducir el "mundo" Web a sólo dos dimensiones se está perdiendo información,
de ahí la conveniencia de la integración de una tercera dimensión que permita,
por ejemplo, recorrer las instalaciones de un museo o de una universidad hasta
llegar a la información que interese al visitante. Esto ya es una realidad que
puede conseguirse a través de diferentes lenguajes de modelado de realidad
31
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.

Por lo tanto, podemos definir un mundo virtual como un tipo de comunidad

virtual en línea que simula un mundo o entorno artificial inspirado o no en la
realidad, en el cual los usuarios pueden interactuar entre sí a través de
personajes o avatares, y usar objetos o bienes virtuales. Para ser un mundo
virtual, se requiere un mundo en línea persistente, activo y disponible 24 horas
al día y todos los días. Los mundos virtuales son hechos para que los usuarios
vivan e interactúen, generalmente en tiempo real. Los personajes, o avatares,
son representados por gráficos en 2D, 2,5D o 3D según el mundo virtual.

Poco a poco, las características y los potenciales beneficios de estos mundos

llevaron a un cambio de dirección en el uso de estos mundos virtuales. Así,
aparecieron mundos virtuales con fines profesionales de aprendizaje
(simuladores de vuelo), de enseñanza (MMOLE) o en el entorno medical, pero
en la actualidad está siendo llevado por las empresas de ocio electrónico, que
ven en esta tecnología una nueva era para videojuegos. Aunque no son
32
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).

A mediados de los años noventa aparecen los primeros mundos virtuales, pero
su difusión mundial ocurrió en la siguiente década con la popularidad ganada
por el mundo virtual Second Life y luego al ser incluida expresamente en la
bitácora “Medical Library Tech Trends” del 2007 como una de las diez
tendencias tecnológicas. Como consecuencia de lo anterior se produce el
ingreso de muchas personas y empresas a este mundo virtual, de acuerdo a la
información proporcionada por Second Life, tal como se muestra en la
Ilustración 5 (López Hernández, 2009, Junio).

33
 Ilustración 5: Ingreso mensual a Second Life

Es importante notar que Second Life es solo uno de los cientos de mundos
virtuales que existen en la actualidad (López Hernández, 2009, Junio). En los
últimos años se registra un aumento considerable de cuentas generadas en
diferentes mundos virtuales según la estadística proporcionada por la
consultora KZero, se puede apreciar en la Ilustración 6, donde se evidencia el
crecimiento anual de cuentas registradas en estos mundos virtuales, desde el
año 2009 al año 2013.

34
 Ilustración 6: Usuarios Activos en Mundos Virtuales

2.3.1. MUNDOS VIRTUALES COMO HERRAMIENTA

DE ENSEÑANZA

De la mano a que la aplicación de nuevas tecnologías en la enseñanza es cada

vez más habitual, aparece la propuesta de usar mundos virtuales como
herramienta de enseñanza. Hoy en día, nadie se extraña cuando un profesor
publica en una página Web el temario de sus asignaturas, los apuntes e incluso
los exámenes ya realizados. Ya existen en Internet las llamadas universidades
virtuales que permiten al alumno realizar cualquier tipo de estudios en un
ambiente virtual, sin una sede física donde se impartan esos estudios. La
mayoría sólo permite interactuar con la institución a través de páginas web en
dos dimensiones, sin considerar recursos tridimensionales que puedan
favorecer el aprendizaje de los conceptos de las distintas asignaturas.

35
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.

De acuerdo con Sherman y Judkins (1994), una de las principales aplicaciones

en el ámbito académico es la formación en facultades de medicina,
especialmente en las materias de anatomía y cirugía. En la Universidad de
Washington se experimenta todo el tiempo con clases demostrativas de cirugía
virtual. En esta universidad se ha creado un "cadáver virtual", donde los
estudiantes pueden tomar un bisturí virtual y practicar. En este sentido es fácil
imaginar un mundo virtual que represente un completo quirófano virtual
internacional, en el que se recogieran las mejores técnicas quirúrgicas de

36
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).

Además de su utilización en estos y otros campos del conocimiento, siempre

existe la posibilidad de aplicar la realidad virtual para la creación de los propios
centros de enseñanza a través de Mundos Virtuales. En este sentido, esta

37
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).

Tanto la enseñanza basada en proyectos como a través de juegos son dos

enfoques comúnmente utilizados para dictar Scrum en los cursos. Por esta

38
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
ScrumMaster es interpretado por los instructores (Mahnic, A capstone course
on agile software development using scrum, 2012). Por otro lado, Scharf y Koch
dejan el rol de Product Owner y las funciones ScrumMaster a los estudiantes
(Scharf & Koch, 2013).

39
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 Product Owner.

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 User Stories 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
Scrum, requisitos y análisis. La parte práctica del curso se ejecuta en equipos
de seis estudiantes con el fin de desarrollar un proyecto simple. El proyecto
consiste de un Sprint de preparación y ocho Sprints en donde pondrán en
práctica la planificación de cada uno de ellos, la estimación de tareas y los
40
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 Daily Meeting
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.

Otra alternativa es la propuesta por Von Wangenheim (Von Wangenheim, Savi,

& Borgatto, 2013), este autor presentar un juego de bajo costo en papel y lápiz
para enseñar Scrum en complemento a las clases teóricas. El juego se puede
aplicar durante una típica clase de la universidad ya que no toma más de 60
minutos su ejecución. Los estudiantes se agrupan en equipos de seis
integrantes, con el objetivo de planificar y ejecutar único Sprint. Cada grupo se
compone de un Scrum Master, un Product Owner, un Auditor (opcional), y tres
41
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 Product Backlog, tarjetas Problem Cards, 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
LEGO, ya que los autores dicen ser demasiado caros para el uso en clases
numerosas. Por esta razón, el modelo planteado por Ramingwong y

42
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.

Asignación de Asignación de
Roles a los Roles al
Simulació Juegos Material
estudiantes Instructor
INSTRUCTORES n de Educativo Especial
Proyecto s Produ Scrum Produ Scrum Necesario
ct Maste ct Maste
Owner r Owner 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)

Si (Lápiz y
VON WANGENHEIM X X X
Papel)
FERNANDES Y
X X X Si (Tarjetas)
SOUSA
RAMINGWONG Y
X X X Si (Plastilinas)
RAMINGWONG

Tabla 1: Tabla comparativa de modelos planteados

43
 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).

Hasta el momento los métodos propuestos tienen cada uno sus puntos a favor,

44
pero también varios en contra, como por ejemplo la necesidad de contar con
varias clases para introducir los conceptos básicos de Scrum en los alumnos o
el espacio físico necesario para realizar las prácticas de Scrum por los equipos
formados de desarrolladores. Por estas razones, nuestra propuesta presenta un
enfoque basado en un mundo virtual para la enseñanza de Scrum, lo que
resulta en una alternativa a todos los cursos propuestos hasta el momento.

45
CAPÍTULO 3

46
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.

En la actualidad la enseñanza de Scrum a través de juegos se ve afectada con

problemas de recursos para las universidades que incluyen esta práctica en la
enseñanza. El principal problema en contextos académicos es contar con los
recursos materiales necesarios. Además, el espacio físico necesario que pueda
albergar la gran cantidad de alumnos que asisten a estos cursos. Teniendo en
cuenta que cada equipo debería contar con un espacio de trabajo personalizado
para realizar Scrum con sus diferentes prácticas (Cohn, 2006) (Schwaber, Agile
Project Management with Scrum, 2004), como por ejemplo usar tarjetas de
planificación para la estimación de las US, contar con TaskBoards, Sprint
Backlogs, etc. En este contexto resulta razonable el uso de Mundos Virtuales
dado que los mismos nos aportan varios beneficios, como por ejemplo nos
permiten simular con mayor verosimilitud un entorno real de trabajo basado en
47
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
(VS) (Grenning, 2002) el cual es una herramienta que simula un ambiente de
trabajo característico de Scrum. Dentro de este mundo de VS, se desarrolla una
herramienta que de soporte a una clase para enseñar la metodología a través
del juego con bloques LEGO.

48
 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).

En paralelo, el profesor debe definir el producto (punto 2) que querrá que

desarrollen dichos equipos. En Virtual Scrum Lego el producto es definido
mediante un modelo de LEGO y una imagen representativa del mismo. El
modelo será construido utilizando los bloques LEGO que provee Virtual Scrum
Lego.

49
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
El profesor dentro de la herramienta cumple con dos roles fundamentales, uno
de ellos es su propio rol de profesor, en el cual deberá asistir a los alumnos
enseñando las prácticas de la metodología. El otro papel fundamental, también
llevado a la práctica por el profesor, es el del Cliente o Product Owner el cual es
el encargado de negociar con el equipo de desarrollo la prioridad del trabajo a
realizar en cada iteración de la metodología aplicada. El profesor decide los
miembros integrantes de cada grupo en base a diversos criterios elegidos por el
mismo. Los alumnos quienes ingresaron al salón (Team Room) donde se
encuentra el juego LEGO, deberán auto-organizarse en estos grupos armados
de 4-6 personas. Simultáneamente el profesor debe definir el producto que

50
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

51

Ilustración 11: Modelo Creado por Profesor

Siguiendo con la metodología los grupos definen las User Stories necesarias con
el apoyo del profesor en rol de Product Owner. Para esto cuentan con un panel
de Product Backlog en donde agregaran cada una de las User Stories (Ver
Ilustración 12).

Ilustración 12: Product Backlog en plena creación

De acuerdo a Scrum, la generación de User Stories 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.

52
 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 User Stories. 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.

Ilustración 13: Estimación de Tarea con Planning Poker

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
53
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.

Ilustración 14: Task Board de los Sprint creados

54
 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 Team Room. En la Ilustración 15 se
puede apreciar el trabajo colaborativo al momento de construir una porción del
producto a desarrollar.

Ilustración 15: Alumnos construyendo el producto

55
Este trabajo, en grandes proyectos diarios, se conoce como Daily Build, es
bueno aclarar que dentro del Virtual Scrum Lego, una Daily Build constara de no
más de 30 minutos. Durante este Daily build el profesor mismo dentro del VSL,
incentivará a los alumnos a llevar a cabo el Daily Meeting realizando reuniones
virtuales ya sea por chat o por videoconferencia. Para esto se deberán crear las
Dailys que se crean necesarias (Ilustracion 16), luego los alumnos podrán
visualizar el detalle de cada una de ellas (Ver Ilustración 17) y decidir si
asistirán o no a la reunión. La Ilustración 35 muestra un ejemplo concreto de un
chat entre dos personas.

Ilustración 17: Panel creación Daily Meeting

Ilustración 16: Detalle Daily Meeting 56

 Ilustración 18: Chat entre Alumno y Profesor

3.5. FINALIZANDO EL SPRINT

Finalizando cada sprint, los estudiantes plantean al profesor su incremento del

producto llevándose a cabo el Sprint Review. El profesor compara el producto
logrado por los alumnos contra su modelo de requerimiento, haciendo notar las
falencias y virtudes del mismo. En este punto, el profesor incentiva a
comprender la importancia del Sprint Review. En la revisión de Sprint, el Equipo
Scrum muestra las User Stories realizadas durante el Sprint. El objetivo de la
manifestación es examinar el trabajo realizado y obtener retroalimentación del
Product Owner y otras partes interesadas.

Como último paso fuerte e importante en la enseñanza de Scrum, nuevamente

el profesor en su propio rol de profesor motiva a los alumnos a realizar el Sprint
Retrospective, en donde el mismo será participe junto con los estudiantes. Esta
etapa se lleva a cabo con el objetivo de mejorar de manera continua su

57
productividad y la calidad del producto que están desarrollando. El equipo
analiza cómo ha sido su manera de trabajar durante la iteración, por qué se está
consiguiendo o no los objetivos a que se comprometió al inicio de la iteración y
por qué el incremento del producto que acaba de mostrar al cliente era o no lo
que él esperaba. Finalmente, se vuelve a iterar el proceso antes descripto,
comenzando desde una nueva planificación para un nuevo sprint, hasta
finalizar con el desarrollo total del producto.

58
CAPITULO 4

59
4. DISEÑO E IMPLEMENTACIÓN DE
VIRTUAL SCRUM LEGO
En el siguiente capítulo se detallará el diseño del Virtual Scrum Lego.
Inicialmente se mostrarán los requerimientos funcionales que soportan la
herramienta y los atributos de calidad que pretende. Posteriormente, se
detallarán la arquitectura y finalmente el uso de las herramientas y la
tecnología empleada.

Además se explicarán progresivamente las diferentes etapas del enfoque que

se presenta en esta tesis, abarcando desde la planificación del proyecto, inicio,
ejecución hasta la finalización del sprint, correspondiendo la lista de
requerimientos generados en el enfoque en componentes de la arquitectura.
Cada una de estas secciones incluye códigos de ejemplo, en donde se
profundizará a través de ejemplos el uso de la aplicación a través de diferentes
diagramas. Los diagramas de secuencia mostrarán la interacción de los objetos
en el tiempo, los Use Case Map permitirán apreciar la interacción dinámica de
los componentes arquitectónicos, y finalmente los diagramas de actividad
permitirán apreciar el proceso como un flujo de trabajo a través de una serie de
acciones.

4.1. REQUERIMIENTOS FUNCIONALES

DEL SISTEMA

Para la realización de este trabajo final, se desarrollaron una serie de

requerimientos funcionales sobre los cuales se diseñó e implementó para llegar
a lo que se conoce como Virtual Scrum Lego. Los requerimientos fueron:

 Desarrollar un aula virtual donde la misma permita a un profesor dictar

clases de la metodología Scrum con los artefactos propios de la
metodología.
60
 El aula virtual debe proveer un mecanismo de ingreso donde los alumnos
interesados en aprender la metodología puedan ingresar con un nombre
de usuario y una contraseña asignada.

 Para facilidad del profesor en la enseñanza de la metodología Scrum,

permitir llevar adelante una partida de juego LEGO VIRTUAL.

 Dentro del aula, permitir el juego colaborativo entre todos los

integrantes que están dentro de la misma.

 Permitir la creación de modelos con piezas LEGO, asociándole

opcionalmente una imagen y un conjunto de piezas (representando el
producto final al que debería llegar a desarrollar los alumnos).

 Proveer de una cierta cantidad de piezas con formas estándar, simulando

las piezas originales del juego real.
 Posibilitar la creación de piezas con la forma que los usuarios deseen
(con posibilidad de mover, rotar, etc.).
 Se debe dar soporte para el almacenamiento de las piezas creada para
luego visualizarla en el menú de piezas y poder seleccionar la misma
para su uso.
 Es necesario contar con un mecanismo de eliminación de piezas a través
de un sencillo evento (por ejemplo, click derecho mouse).
 Permitir la estimación de una tarea.
 Asociación de un conjunto de bloques a una tarea.
 Permitir la modificación del color de una pieza o modelo o conjunto de
piezas seleccionado.
 Visualización de reloj, iniciando en el estado DOING (comienzo de la
creación de la tarea), finalizando en TO DO y así conocer el tiempo total
que llevará la tarea cuando finalice.
 Comparación de resultados obtenidos entre el modelo creado por el
profesor y el producto final generado por los alumnos.
 Notificar y persistir cambios a los demás usuarios conectados a la sala
virtual.
61
 4.2. ATRIBUTOS DE CALIDAD

Los requerimientos para un sistema usualmente se dividen en requerimientos

funcionales y en requerimientos no funcionales, también llamados Atributos de
Calidad. Todos estos requerimientos son tomados en cuenta al momento de
decidir aspectos arquitectónicos, como los componentes del sistema y sus
responsabilidades, y no arquitectónicos, como los algoritmos que se utilizarán
para resolver cierto problema.

Luego de un análisis de las necesidades para realizar Virtual Scrum Lego, se

llegó a la conclusión que debía cumplir con ciertos atributos de calidad para
garantizar el éxito del sistema.

El sistema será utilizado por distintos grupos de alumnos, por lo que debe tener
una buena usabilidad: debe ser fácil de utilizar, con menús claros e información
al alcance de la mano. Con motivo de solo enfocarse en la enseñanza de la
metodología Scrum.

La Escalabilidad y la Performance son primordiales, ya que deberá existir una

comunicación clara durante las reuniones, conexión simultanea durante la
creación de tareas colaborativas y visualización en tiempo real a los diferentes
cambios generados durante el movimiento de bloques, rotación, cambios de
color y eliminación desde los diferentes clientes conectados al mismo servidor.
El sistema recibe datos provenientes de los demás usuarios online y envía a
estos usuarios, los datos deben ser procesados en un lapso menor a un
segundo después de haber sido recibidos con una buena performance.

Una persona deberá registrarse en el sistema para hacer uso del mismo. Al
intentar utilizarla sin estar registrado, no podrá acceder a la misma. De esta
manera se podrá controlar de manera segura que usuarios ingresan a la
herramienta con el objetivo de tomar clases de Scrum.

62
En caso de que el ingreso de información crezca de forma exponencial y que se
requiera alterar la forma de manipular la información, el sistema debe proveer
la facilidad de modificar la base de datos utilizada.

4.3. ARQUITECTURA DE VSL

El Diseño Arquitectónico del software es el diseño del nivel más alto, que guía y
estructura como serán tomadas las decisiones en los niveles inferiores. En esta
sección se representará los distintos componentes del sistema, las relaciones e
interacción entre ellos, la estructura de los datos y finalmente algunos de los
diagramas representativos de sus funcionalidades más importantes (L. Bass,
2003).

4.3.1. COMPONENTES

En la Ilustración 19 se puede visualizar los componentes de alto nivel que

forman parte del sistema complejo el cual se basa en el estilo arquitectónico
“Cliente-Servidor” (L. Bass, 2003). Como es común en este tipo de sistemas, se
utilizan mensajes para comunicar ambas partes. A continuación, se detallará la
funcionalidad de c/componente:

 Cliente: realiza las solicitudes entrantes al servidor y para ello utiliza el

componente Virtual Scrum Lego quien da soporte al procesamiento de
ladrillos (movimiento, eliminación, rotación, cambio de color), asociación
de US/bloques, creación de modelos, etc. Para el desarrollo del aplicativo
se utilizó el framework Unity.

 Servidor: recibe las peticiones, las atiende y envía una respuesta al/los
cliente/s.

o Smart Fox Server: recibe las peticiones del/los cliente/s.

63
o u3dextension: proporciona servicios integrados para la
separación adecuada de solicitud, controladores de eventos y
liberación automática

o Cola de Mensajes: recibe o envía peticiones hacía el cliente.

o DB: soporte de conexión con el motor de base de datos para

obtener/persistir la información relevante.

o Finalmente existe la relación con las zonas existentes con sus

respectivos rooms (Lobby, Aulas comunes y Virtual Scrum Lego).

Ilustración 19: Diagrama de Componentes Alto Nivel

64
 4.3.2. VISTA ESTÁTICA

Como Virtual Scrum Lego extiende de la funcionalidad de U3D, respeta el estilo

arquitectónico del mismo, siendo este un sistema complejo el cual se basa en el
estilo “Cliente-Servidor”

Donde U3D es una aplicación de juego educativo en 3D desarrollado por

estudiantes de la Universidad UNICEN que simula un campus virtual,
permitiendo a los estudiantes recorrer las instalaciones del campus y de forma
interactiva a aprender sobre las diferentes áreas académicas.

En la Ilustración 20, puede apreciarse el diseño cliente-servidor de Virtual

Scrum Lego y los componentes de los cuales extiende del u3d (coloreados en
verde). También se puede observar la separación de los componentes que se
encuentran ubicados en el cliente y lo que está en el servidor.

Ilustración 20: Vista Estática

65
 4.3.3. MATERIALIZACIÓN DE LOS COMPONENTES
A continuación, en la Ilustración 21 se detallarán los principales elementos
referidos al diseño de clases. En este punto se utilizó herencia para reutilizar y
evitar duplicidad de código, además se utilizaron patrones de diseño, en donde
se aplicaron conocimientos previamente aplicados y originado por expertos en
el tema, lo cual evitará la toma errónea de decisiones.

En el siguiente diagrama de clases se muestra la relación entre cada una de

ellas, la abstracción, el uso y el contenido de las mismas para dar soporte a la
funcionalidad del Virtual Scrum Lego.

66
 Ilustración 21: Diagrama de Clase

A continuación, vamos a describir una parte del diagrama de Clases anterior

que se encuentra en la Ilustración 22, en donde se puede observar el
mecanismo de herencia que facilita la modificabilidad y reutilización de código,
de este modo se dará soporte para registrar y utilizar las relaciones
conceptuales existentes entre las clases. También se podrá visualizar el patrón
composite (E. Gamma, 1995) utilizado en nuestro diagrama, que sirve para
construir objetos complejos a partir de otros más simples y similares entre sí,
67
en nuestro caso serán requeridos para los bloques. Para ello se definen las
siguientes clases:

 Bloque: clase padre que implementa métodos comunes en los hijos,

utilizando relaciones conceptuales existentes entre las clases
BloqueSimple y BloqueCompuesto.

 BloqueSimple: extiende de la clase Bloque y se compone de un objeto

(bloque).

 BloqueCompuesto: extiende de la clase Bloque y se compone de un

objeto (conjunto de bloques) reutilizable desde el inicio hasta la
finalización del sprint.

 BloqueReutilizable: extiende del BloqueCompuesto, esta estructura

será persistida para utilizarse en cualquier momento, para ello tiene una
variable tecla, la cual será de utilidad para utilizarla cuando se disponga.

 Modelo: al igual que la clase BloqueReutilizable extiende de

BloqueCompuesto y tiene en su estructura una imagen asociada e
identificador del proyecto asociado.

68
 Ilustración 22: Herencia y Composite

4.4. IMPLEMENTACIÓN DE LAS FASES

DEL ENFOQUE
A partir del enfoque derivaremos los componentes los cuales permiten el
desarrollo de un juego construidos con bloques LEGO en un ambiente virtual
para la enseñanza de la metodología Scrum. En esta sección se detallará la
relación entre el enfoque, los requerimientos asociados y los componentes
utilizados en c/u de los siguientes puntos:

 Planificación del Proyecto Piloto.

 Planificación del Sprint.
 Ejecución del Sprint.
 Finalización del Sprint.

69
En cada uno de los puntos anteriores, se podrá visualizar diferentes puntos de
vistas e interacción entre los componentes involucrados desde un mayor nivel
de abstracción hasta el nivel más bajo, para ello se aplicarán diferentes
escenarios de calidad, en donde se utilizarán y detallaran los siguientes
diagramas que se listan a continuación:

 Use Case Map (UCM): para mostrar vista estática (componentes) y así
mismo sus interacciones a un nivel alto de arquitectura.
 Diagrama de Secuencia: para vistas más detalladas de menor nivel de
abstracción y mostrar la interacción de un conjunto de objetos a través
del tiempo.
 Diagrama de Actividad: muestra la serie de actividades que deben ser
realizadas durante un proceso u operación, así como las distintas rutas
que pueden irse desencadenando.

4.4.1. PLANIFICACIÓN DEL PROYECTO

Durante la planificación, el profesor que enseña la metodología creará un

modelo con una imagen representativa que los alumnos deberán imitar. Para
esto, deberá existir un acceso a las salas virtuales que los alumnos y el profesor
utilizarán. Los requerimientos asociados en esta etapa serán:

 El aula virtual debe proveer un mecanismo de ingreso donde los

alumnos interesados en aprender la metodología puedan ingresar
con un nombre de usuario y una contraseña asignada.
 Desarrollar un aula virtual donde la misma permita a un profesor
dictar clases de la metodología Scrum con los artefactos propios
de la metodología.
 Proveer de una cierta cantidad de piezas con formas estándar,
simulando las piezas originales del juego real.

70
  Permitir la creación de modelos con piezas LEGO, asociándole
opcionalmente una imagen y un conjunto de piezas
(representando el producto final al que debería llegar a desarrollar
los alumnos).

A continuación, se detallará el escenario donde se apreciará la interacción

dinámica de los componentes arquitectónicos durante la creación de un
modelo, se explotará la misma seleccionando imagen y bloque a asociar a
través de un diagrama de actividad y finalmente por medio de un diagrama de
secuencia se profundizará como se persisten los datos y se notifica el cambio a
los demás usuarios conectados en la sala.

4.4.1.1. Creación de modelo

Escenario de calidad: El profesor con el rol de Product Owner crea un modelo.
Contexto: El profesor crea una modelo a partir de un conjunto de bloques y le
asocia una imagen representativa.
Problema: La actualización del modelo, imagen y pantalla de todas las
personas conectadas en la sala.
Solución: Se persiste toda la información y se notifica a cada persona
conectada a la sala virtual.

En la Ilustración 23 se puede observar el diagrama Use Case Map donde se

muestra las acciones desempeñadas por los componentes involucrados en la
creación del modelo.

71
 Ilustración 23: Diagrama Use Case Map Crear Modelo

Explotando la creación de un modelo, vamos a detallar la asociación de una

imagen y bloque a través de un diagrama de actividades para observar con más
detalles los procesos que se llevarán a cabo lógicamente. Como veremos en la
Ilustración 24, se comienza con la elección de imagen, posteriormente se elige
el bloque que representará parte o producto completo, el rombo es un indicador
de condición para validar el tipo o tamaño del archivo que será la imagen, de
cumplirse satisfactoriamente se asocia la imagen al modelo, y finalmente se
genera la asociación del bloque.

72
 Ilustración 24: Diagrama de Actividad

En la ilustración 25 se puede apreciar el diagrama de secuencia en el que se

refleja el comportamiento a un bajo nivel donde se persistirá (inserción de la
imagen y bloque en DB) y notificará a los demás usuarios que existe un cambio
para que estos puedan ver en sus pantallas los detalles del modelo.
73
 Ilustración 25: Diagrama de Secuencia Crear modelo

4.4.2. PLANIFICACIÓN DEL SPRINT

Una vez finalizado el Product Backlog, los alumnos estimaran las tareas que
posteriormente planificaran (Sprint Planning), en este punto se toma la
decisión de que tareas realizaran a lo largo de cada Sprint, por lo que en este
punto se deberá tener soporte para la asociación de bloque-tarea y estimación
de tareas. Los requerimientos asociados en esta etapa serán:

 Permitir la estimación de una tarea.

 Asociar conjunto de bloques a una tarea.
 Notificar y persistir cambios a los demás usuarios conectados a la
sala virtual.

74
A continuación, se detallará el escenario donde se apreciará la interacción
dinámica de los componentes arquitectónicos durante la estimación de una
tarea, se explotará la misma seleccionando las tarjetas de puntuación a través
de un diagrama de actividad y finalmente por media de un diagrama de
secuencia se profundizará la persistencia de los datos y notificación del cambio
a los demás usuarios conectados en la sala.

4.4.2.1. Estimación de una tarea

Escenario de calidad: Los alumnos estiman una tarea.
Contexto: Cada alumno con el rol de desarrollado estimará una tarea que
determinará en su momento el tiempo total promediado por el equipo.
Problema: La actualización de la carta en el panel y en la pantalla de todas las
personas conectadas en la sala.
Solución: Se persiste toda la información y se notifica a cada persona
conectada a la sala virtual.

En la Ilustración 26 se puede observar el diagrama Use Case Map donde se

muestra las acciones desempeñadas por los componentes involucrados en la
estimación de una tarea.

Ilustración 26: Diagrama Use Case Map Estimación de tarea

75
Explotando la estimación de una tarea, vamos a detallar la puntuación de la
misma a través de un diagrama de actividad. Se comienza con la puntuación de
una US, acto seguido se elige la tarjeta, y se valida que la misma sea una
puntuación correcta, de cumplirse satisfactoriamente se asocia la tarjeta a la
US, posteriormente se genera la asociación, en paralelo se persiste la
información necesaria (inserción de la tarjeta-tarea en DB) y notifica a los
demás usuarios conectados que existe un cambio para que estos refresquen el
cambio en sus pantallas. En la Ilustración 27 se puede observar la iteración
donde puntuaran un US dada todos los alumnos.

Ilustración 27: Diagrama de secuencia Estimación de tarea

76
En la ilustración 28 se puede apreciar el diagrama de secuencia en el que se
refleja el comportamiento a un bajo nivel donde se persistirá y notificará la
estimación de una tarea, también se detallará la información recibida y
procesada por el servidor.

Ilustración 28: Diagrama de secuencia Estimación de tarea

4.4.3. EJECUCIÓN DEL SPRINT

En esta etapa el equipo tiene un conjunto de tareas del sprint actual y cada
integrante seleccionará una por una las tareas asignadas y comenzará con la
construcción parcial de modelo con los bloques LEGOs virtuales. Por lo que los
requerimientos asociados en esta etapa serán:

 Permitir el juego colaborativo entre todos los integrantes que

están dentro de la sala virtual.

77
  Posibilitar la creación de piezas con la forma que los usuarios
deseen (con posibilidad de mover, rotar, etc.).
 Permitir la modificación del color de una pieza o conjunto de piezas
seleccionado.
 Soporte para el almacenamiento de las piezas creada para luego
visualizarla en el menú de piezas y poder seleccionar la misma
para su uso.
 Contar con un mecanismo de eliminación de piezas a través de un
sencillo evento (por ejemplo, click derecho mouse).
 Visualización de reloj, iniciando en el estado DOING (comienzo de
la creación de la tarea), finalizando en TO DO y así conocer el
tiempo total que llevará la tarea cuando finalice.

A continuación, se detallará la creación de una tarea por medio de diagrama de

interacción dinámica, profundizando se ejemplificará por medio de un diagrama
de secuencia el movimiento de una pieza y finalmente se pone en muestra el
desplazamiento específicamente sobre el eje X mediante un diagrama de
secuencia.

4.4.3.1. Comenzar una tarea

Escenario de calidad: El alumno comienza una tarea.
Contexto: Cada alumno con el rol de desarrollado comenzará a realizar una
tarea determinada.
Problema: La actualización de los bloques en pantalla por cada movimiento
realizado de todas las personas conectadas en la sala.
Solución: Se persiste toda la información y se notifica a cada persona
conectada a la sala virtual la actualización.

En la Ilustración 29 se puede observar el diagrama Use Case Map donde se

muestra las acciones desempeñadas por los componentes involucrados durante
el inicio de una tarea.

78
 Ilustración 29: Diagrama Use Case Map Iniciación de una tarea

Explotando la creación de una tarea, vamos a detallar el movimiento de una

pieza a través de un diagrama de actividades representa el proceso que lleva un
usuario al realizar el movimiento de una pieza. En la Ilustración 30 se puede
observar el comienzo de la creación de una pieza, posteriormente se persiste la
información necesaria de dicha pieza (inserción de la pieza en DB), luego de
realizar cualquier tipo de movimiento izquierda - derecha - arriba - abajo -
rotar, se chequea si es posible desplazar la pieza hacia la dirección elegida. Si
cumple la condición satisfactoriamente se actualiza la información necesaria en
la DB (posición actual de la pieza) y luego se notifica a los demás usuarios
conectados que existe un cambio para que estos refresquen tal pieza en sus
pantallas. En caso de que no cumpla la condición para el movimiento elegido,
entonces no se realizará desplazamiento alguno.

79
 Ilustración 30: Diagrama de Actividades de movimiento de pieza

En la Ilustración 31 se puede apreciar el diagrama de secuencia en el que se

refleja el comportamiento a un bajo nivel durante el movimiento en el eje
horizontal de una pieza, donde la información es recibida y procesada por el
servidor.

80
 Ilustración 31: Diagrama de Secuencia de movimiento de pieza

4.4.4. FINALIZACIÓN DEL SPRINT

En esta etapa los estudiantes plantean al profesor su incremento del producto

llevándose a cabo el Sprint Review, se examina el trabajo realizado y se obtiene
retroalimentación del Product Owner y otras partes interesadas. Por lo que los
requerimientos asociados en esta etapa serán:

Comparación de resultados obtenidos entre el modelo creado por

el profesor y el producto final generado por los alumnos.

A continuación, se detallará la comparación del modelo creado por el profesor

con respecto al de los alumnos por medio de diagrama de interacción dinámica,
profundizando se ejemplificará por medio de un diagrama de actividad la tabla

81
comparativa detallando los resultados finales donde se llevará a cabo el
proceso de obtener los resultados de ambas partes (modelo profesor y el
producto realizado por los alumnos) hasta finalmente llegar visualizar una tabla
comparativa de resultados.

4.4.4.1. Comparación de modelos

Escenario de calidad: comparación de modelos.
Contexto: El alumno compara su modelo con respecto al realizado por el
profesor, detallando la cantidad de ladrillos utilizados, cantidad de
movimientos, etc.
Problema: La actualización en pantalla de los modelos y panel comparativo de
las personas conectadas en la sala.
Solución: Se notifica a cada persona conectada a la sala virtual la actualización
del modelo y panel comparativo.

En la Ilustración 32 se puede observar el diagrama Use Case Map donde se

muestra las acciones desempeñadas por los componentes involucrados en la
finalización del sprint.

Ilustración 32: Diagrama Use Case Map finalización de Sprint

82
En la Ilustración 33 se puede apreciar el diagrama de secuencia en el que se
refleja el comportamiento a un bajo nivel durante la obtención de los modelos
y comparación de resultados.

Ilustración 33: Diagrama de Secuencia Comparar Modelos

Explotando la comparación de los modelos, vamos a detallar el proceso a través

de un diagrama de actividades representando el proceso que lleva a cabo un
usuario al realizar la comparación de los modelos. Esto se puede apreciar en la
Ilustración 34.

Se comienza con la solicitud de comparar modelos, en este punto se obtienen

los datos de ambos (tanto del profesor como del alumno), en particular del
modelo profesor se visualizará en un panel la imagen asociada al modelo,
posteriormente se compararán resultados (cantidad de movimientos
izquierda-derecha-arriba-abajo, cantidad de ladrillos utilizados, etc.) y
finalmente en uno de los paneles de visualizará una tabla comparativa de
ambos modelos.

83
Ilustración 34: Diagrama de actividad Comparar Modelos

84
 4.5. MODELO DE DATOS

Durante la extensión del modelo de datos, fue definida como sería la

composición de la base de datos del sistema, las entidades existentes y la
relación entre ellas, en donde se agregaron las tablas necesarias para dar
soporte a las funcionalidades, tales como pieza, modelo (tarea, alumno y
profesor), celda, ETC.

En las siguientes secciones se explicarán cuáles son las tablas que intervienen
y cuáles fueron agregadas para dar soporte a las nuevas funcionalidades. En la
Ilustración 35 se muestra el diagrama completo de entidad relación.

4.5.1. TABLA PIEZA

Esta tabla está relacionada íntegramente con datos para dar soporte al usuario
al momento de guardar una pieza desde la escena de creación. Tendrá la
información necesaria (tamaño, ancho, alto, colores asociados, posición en la
grilla, movimientos generados antes de soltarlo en la grilla, proyecto asociado,
tecla de asociación, descripción, etc.). El Id es generado automáticamente por
el motor de la base de datos.

4.5.2. TABLA CELDA

Contiene toda la información necesaria para dar soporte a cada pieza. Posee:
ubicación física de la celda, donde se irá actualizando la información
constantemente para luego notificar a los diferentes alumnos conectados de la
misma sala, material asignado a la misma (el material contiene un color
asociado), nombre, etc. El Id es generado automáticamente por el motor de la
base de datos.

85
 4.5.3. TABLA MODELO

Contendrá los atributos del modelo creado por el profesor, donde se tiene la
imagen asociada a la pieza que se utilizará como guía para aquellos alumnos
que estén en proceso de construcción del producto final que el cliente desea, un
control de la cantidad de bloques que se usaron, todo esto será de utilidad para
finalmente comparar resultados obtenidos por los alumnos con respecto a lo
que el profesor deseaba con el rol del cliente.

4.5.4. TABLA MODELO TAREA

Contiene la información necesaria de los modelos que se van creando para una
determinada Tarea. Existe una asociación con la tabla task. Finalizadas todas
las tareas, las mismas se ensamblarán formando el modelo alumno
(referenciando a una US).

4.5.5. TABLA MODELO ALUMNO

Contiene los atributos del modelo creado por los alumnos y una relación con la
tabla Modelo, estos atributos son de utilidad para la comparación con el modelo
creado por el profesor (con rol del cliente). Está relacionada con una US, ya que
forma parte del producto final que los alumnos realizaron en el Sprint actual.

86
Ilustración 35: Diagrama Entidad Relación

87
 4.6. CONCLUSIÓN
Finalmente, para concluir este capítulo, se implementó el juego Virtual Scrum
Lego, en donde se lograron generar todos los componentes necesarios para
completar el flujo completo de Scrum (desde el inicio hasta la finalización del
sprint), el proyecto integró herramientas que permiten cumplir una serie de
requerimientos (desde el ingreso a una sala virtual hasta entregar el producto
final). Por otro lado, se utilizaron estilos, patrones de diseño para la
abstracción, reutilización de código, como consecuente lograr una mejora a
nivel funcional.
Se detalló la estructura de datos existentes que sirven para complementar la
funcionalidad y finalmente todas las tecnologías utilizadas para este proyecto.

88
CAPITULO 5

89
5. EXPERIMENTOS Y RESULTADOS
En el siguiente capítulo se mostrará una evaluación de nuestro enfoque, junto
con su preparación, requerimientos y resultados obtenidos. En la evaluación se
analizaron tres puntos específicos, uno de ellos fue la funcionalidad, la cual se
refiere a si el enfoque propuesto proporcionado tanto a alumnos como a
profesores cumplen con su fin específico, dando la posibilidad de aplicar el flujo
completo de Scrum en un entorno sin problemas de espacio ni comunicación,
proveyendo todos los artefactos de la mitología. Otro punto analizado fue la
usabilidad donde se detallaron los conceptos más relevantes que refieren a la
usabilidad general de la aplicación. Como toda aplicación de software, lleva un
tiempo aprender a utilizarla (lo que se conoce como curva de aprendizaje), es
por esto que Virtual Scrum Lego está diseñado de manera que al usuario le
resulte sencillo familiarizarse con la misma. Y por último se analizó la
percepción en los estudiantes, refiriéndonos a la impresión que causó la
aplicación a estos en la experiencia realizada, la percepción que tienen los
estudiantes acerca de lo aprendido y las conclusiones que sacaron.

A continuación, en la sección 6.1 se explican los objetivos del experimento,

luego en la sección 6.2 se encuentran los preparativos del experimento
detallando información de las personas que fueron parte del mismo, el
conocimiento de ellos, lugar donde fue realizado el experimento y demás. Hacia
la sección 6.3 se podrá ver el experimento en plena etapa de actividad con
imágenes de los grupos ejecutando el flujo Scrum y construyendo con piezas
LEGO. La configuración de los equipos utilizados para el experimento se
encuentra detallada en la sección 6.4 mientras que en la sección 6.5 se puede
apreciar el detalle de la encuesta realizada. Luego en la sección 6.6 se
encuentra un análisis estadístico de los resultados obtenidos y finalmente una
conclusión en base a estos sobre la sección 6.7.

90
 5.1. OBJETIVO

El experimento que diseñamos consta de darle a dos grupos de desarrolladores

un determinado requerimiento. A un grupo se les pidió que desarrollen este
requerimiento haciendo uso de piezas LEGO reales y aplicando la metodología
Scrum dentro de un aula. Al segundo grupo de desarrolladores, se les pidió que
desarrollen el mismo requerimiento, pero usando el enfoque propuesto, Virtual
Scrum Lego.

El requerimiento solicitado consto de lo siguiente: “Armar un avión con

piezas LEGO. El avión deberá tener dos alas y diversos colores. Se
solicita que el mismo represente un avión a escala”.

La simulación del juego con bloques LEGOs introduce a los conceptos básicos de
las Metodologías Ágiles. Los participantes ejecutarán realmente su primer
proyecto con Scrum.

5.2. PREPARACION DEL EXPERIMENTO

Virtual Scrum Lego puede ser utilizada por dos tipos de usuarios distintos
(profesores y alumnos), con lo cual para la realización del experimento se
solicitó la participación de un docente y veinte alumnos de Ingeniería de
Sistemas de entre 25 y 35 años. Estos estudiantes tenían conocimientos
previos en la metodología Scrum ya que todos cursaron la materia optativa
Metodologías Agiles durante el año 2012. En tal materia fueron miembros de un
equipo de Scrum, y además, algunos de ellos cumplieron el rol de Scrum
Master. El docente participo del experimento cumpliendo el rol de docente y
además de cliente para ambos grupos de desarrollo.

Entre ellos formaron dos equipos de desarrollo de software. Un equipo fue el

encargado de desarrollar el producto aplicando la metodología de manera
convencional, es decir utilizando piezas LEGO reales para la construcción del
91
producto, pizarras y papeles identificando tareas, realizando dailys cara a cara
y demás actividades que a menudo se emplean en la metodología. El segundo
grupo también debió realizar el desarrollo del mismo producto, pero este
utilizando la aplicación Virtual Scrum Lego.

El tamaño de los equipos fue el que proponen los teóricos, es decir, 7±2
integrantes. (Schwaber, Agile Project Management with Scrum, 2004)
(Schwaber & Beedle, Agile software development with scrum, 2002). A pesar
de sus conocimientos previos, de igual modo se les realizó una encuesta
personal para percibir los mismos, además se agregó a la encuesta datos
demográficos como por ejemplo, Edad, Trabajo, Lugar de estudio, etc.

El experimento fue realizado en la Biblioteca Central Unicen ubicada en el

Campus Universitario de Tandil perteneciente a la Universidad Nacional del
Centro de la Provincia de Buenos Aires. Para el equipo que se le solicito usar
Virtual Scrum Lego, cada alumno contaba con su computadora personal
conectada a la red Internet, a modo de simular la distribución geográfica. Luego
de entrenarse con la herramienta, aprender la ubicación de los distintos
elementos dentro del mundo virtual y comunicarse mediante la herramienta de
chat, los miembros se consolidaron como grupo. También se brindó una breve
explicación de las diferentes funcionalidades que tiene la herramienta Virtual
Scrum Lego (en dónde y cómo se generan bloques, como mover bloques una
vez seleccionados, rotarlos, cambiar el color de los mismos, ubicación y utilidad
de c/u de los menús, generación de los diferentes modelos: profesor, alumno y
tarea, etc.).

92
 5.3. NARRATIVA DEL EXPERIMENTO

Finalizada la breve introducción a la herramienta Virtual Scrum Lego, se les

propuso a los estudiantes realizar un proyecto simulando que un importante
cliente solicitaba el mismo. En el experimento se construyó un único producto,
el cual como ya fue mencionado previamente fue la creación de un Avión que
contenga dos alas lo suficientemente grandes como para representar un avión
a escala y diversos colores en su construcción.

El docente al cual se le pidió la participación para el experimento, ocupó la

función de Product Owner mientras el alumnado seleccionado jugo las
funciones de Scrum Master y equipo Scrum. La función de Scrum Master estuvo
asignada a los estudiantes con mayor conocimiento en Metodologías Agiles con
objetivo de preservar la correcta auto-organización del equipo.

Utilizamos dos métodos para enseñar y aplicar la Metodología Scrum, Virtual

Scrum Lego y el método de enseñanza tradicional, con lo cual dividimos al azar
el grupo de personas en dos equipos.

Un equipo realizo el experimento de manera convencional utilizando piezas

LEGO reales y construyendo con sus propias manos, este grupo aplico la
metodología en un espacio de trabajo real y con artefactos tangibles. Este
equipo cumplió el rol de grupo de control, con el cual podremos corroborar si
VSL introduce mejoras en la enseñanza de la metodología. Luego el segundo
equipo realizo el mismo desarrollo de producto, con las mismas User Stories
involucradas (las cuales fueron recomendadas por el docente), pero utilizando
la herramienta Virtual Scrum Lego.

En todo el proceso de desarrollo para ambos grupos, el profesor en rol de

Product Owner se encontró disponible para responder preguntas y proporcionar
información a los miembros de cada equipo. Además él fue el único que tomo
decisiones principales sobre la construcción del mismo.

93
 5.3.1. EXPERIMENTO REALIZADO CON MÉTODO
TRADICIONAL
La construcción del producto solicitado para este equipo, se ejecuta aplicando
la Metodología Scrum de manera convencional, utilizando por ejemplo
papelitos pequeños identificando las User Stories y tableros o pizarra de tareas
que actuaron como radiadores de información. Por cuestiones de espacio, los
tableros y pizarras se realizaron en hojas tamaño A4 pegados en las paredes. A
continuación se muestran imágenes donde se puede apreciar el desarrollo del
producto en cada paso Scrum.

5.3.1.1. Carga y priorización de las User Stories

El primer paso en el desarrollo del producto es la carga y priorización de las
User Stories al Product Backlog, el cual contiene la lista principal de las
características deseadas del producto. Para esto se utilizó una hoja A4 en
blanco dibujando una tabla con las columnas Id, Requisitos, Descripción,
Prioridad y Sprint, la cual cumplió con las necesidades del Product Backlog.
La misma fue pegada en la pared a modo de radiador de información para todos
los integrantes de equipo.

El profesor que también juega el rol de Product Owner prioriza las User Stories
en el Product Backlog, y cada miembro del equipo Scrum realiza preguntas
claves cara a cara al Product Owner para obtener la información que creyeron
necesaria para llevar a cabo la construcción del producto.

En la ilustración 34 se puede apreciar la hoja Product Backlog que utilizo el

equipo para la ejecución Scrum.

94
 Ilustración 34: Product Backlog

5.3.1.2. Planificación del Sprint Backlog

El Sprint inicia con la especificación de las User Stories esperadas ser finalizas
en tal Sprint. Por lo cual, el equipo Scrum realizo una reunión de planificación
para estimar un conjunto de User Stories y llegar a una decisión para dar inicio
a las actividades del Sprint. Teniendo en cuenta las recomendaciones de la
revisión de la literatura (Cohn, 2006) (Mahnic, Teaching scrum through team‐
project work: Student’s perceptions and teacher’s observations, 2010), la
alternativa más fuerte en Scrum a la hora de estimar es la denominada Póker
Planning y es guiada por el Scrum Master.

95
 5.3.1.3. Estimación de User Stories
Cada participante dispone de un juego de cartas, y en la estimación de cada
tarea, todos vuelven boca arriba la carta que representa el esfuerzo estimado
para cada uno de ellos. Cuando se considera que éste es mayor de 10 horas (o
del tamaño máximo considerado por el equipo para una tarea), se levanta la
carta infinito.

En la ilustración 35 se puede apreciar el juego de cartas utilizado en la

estimación de las tareas.

Ilustración 35: Cartas Póker Planning

Aquí, un punto en la carta de Planning Póker representa una hora de trabajo
ininterrumpido. El modelo consta de 10 cartas con los números representados
más abajo, los cuales los equipos emplean como unidad de esfuerzo, es decir,
como horas de trabajo de cada programador. Se decidió utilizar la siguiente
secuencia Fibonacci 0; 1/2; 1; 2; 3; 5; 8, 13, 20, 40, 100 (también existe la

96
posibilidad de utilizar la carta “infinito”) para el valor de las cartas involucradas
en el Planning Póker.

Los miembros del equipo seleccionan sus tarjetas simultáneamente. Aquellos

miembros que votaron con puntos altos y bajos deberán justificar sus
estimaciones y luego todos los miembros del equipo volverán a votar
nuevamente. El proceso de estimación para cada miembro se repite hasta que
se llegue a un consenso o el Scrum Master decida terminar el proceso después
de tres iteraciones y entonces, se calcula el promedio de puntos de la User
Story.

Los miembros del equipo realizaron la estimación para cada User Story
perteneciente al Sprint a desarrollar. Luego todas las User Story estimadas
fueron distribuidas entre los integrantes del equipo Scrum, por lo cual cada uno
inicio su desarrollo con piezas LEGO reales. Entiéndase en este contexto, por
desarrollo a la construcción con piezas LEGO de una parte del producto.

5.3.1.4. Control y Supervisión del trabajo durante el Sprint

Siguiendo con las prácticas de Scrum, se decidió realizar Dailys Meetings cada
una hora para revisar y discutir el progreso de cada tarea iniciada. En una
reunión de no más de 15 minutos, cada miembro del equipo respondió algunas
preguntas claves cara a cara con sus compañeros: ¿Qué he hecho desde la
última reunión de sincronización? ¿Pude hacer todo lo que tenía planeado?
¿Cuál fue el problema? ¿Qué voy a hacer a partir de este momento? ¿Qué
impedimentos tengo o voy a tener para cumplir mis compromisos en esta
iteración y en el proyecto?

Después de responder a las preguntas, el equipo Scrum actualizo el estado de

las tareas dentro del Task Board. Este panel fue realizado con una hoja A4 y
pegado a media altura en una de las paredes del aula donde se realizó la
prueba, con intenciones de que sea visible para todo el equipo de trabajo. A
medida que el desarrollo de las tareas evolucionaba, estas se fueron moviendo

97
a través de esta hoja que cumplió el papel de Task Board, modificando su
estado de desarrollo.

Cada vez que un miembro del equipo finalizaba una tarea en la cual estaba
asignado, entonces este procedía a avanzar el estado de dicha tarea de Doing
hacia el estado Done dentro del Task Board. Cabe destacar que se tenía un reloj
de pulsera cronometrador por cada tarea a realizar, con cada uno de ellos se
tomó el tiempo que se tardó en el desarrollo de cada tarea.

A continuación, en la ilustración 36 se pueden observar las tareas y el estado de

cada una de ellas dentro del Task Board.

Ilustración 36: Task Board

Observe que el Task Board es una herramienta muy poderosa, genera con
facilidad una comunicación entre los miembros del equipo, ya que puede echar
98
un vistazo a él y revisar el desarrollo en progreso, el desarrollo completo, o el
desarrollo pendiente. Este tablero de Tareas ayuda a los miembros del equipo a
visualizar el estado de las mismas, mostrando lo que han logrado, y
animándolos a seguir adelante en las nuevas tareas por desarrollar. Es una
ayuda útil para adoptar los valores ágiles como la transparencia, la
colaboración, el enfoque y la auto-organización, entre otros.

5.3.1.5. Cierre del Sprint

El Sprint finalizo con una Sprint Review realizada dentro del aula con todos los
miembros del equipo presentes, se vio un avance claro y tangible el cual fue
presentado al Product Owner. Durante esta Review, el equipo Scrum mostro los
objetos armados con piezas LEGO reales, las cuales responden a las User
Stories realizadas durante el Sprint. El objetivo fue examinar el trabajo
realizado y obtener retroalimentación del Product Owner. Durante la
demostración, el equipo hizo hincapié en cómo las características desarrolladas
pasan las pruebas de aceptación.

Luego, en una reunión Sprint Retrospective, también presencial, el equipo

reviso los objetivos cumplidos del Sprint terminado. Se tomó nota de lo bueno
y lo malo, para no volver a repetir los errores. Esta etapa sirvió para
implementar mejoras desde el punto de vista del proceso del desarrollo.
Además esta reunión dio la posibilidad de reflexionar sobre lo ocurrido durante
el Sprint, e identificar los problemas que pudieran impedir una mejorara en la
productividad del equipo. Para ello, cada miembro del equipo menciono los
problemas que deben abordarse.

En el cierre del último sprint, el equipo presento físicamente el producto final

con piezas LEGO al Product Owner. En este punto se evaluó la forma en que los
estudiantes siguieron la Metodología Scrum durante el desarrollo del producto,
se evaluó el trabajo cooperativo de los estudiantes, el mantenimiento del Task
Board, cumplimiento de los plazos, etc.

99
 5.3.2. EXPERIMENTO REALIZADO CON VIRTUAL
SCRUM LEGO

El equipo que realizo la prueba con la herramienta Virtual Scrum Lego, al igual
que el equipo anterior (equipo sin VSL) también desarrollo un producto el cual
era un avión con las características ya mencionadas. El profesor solicito la carga
de las mismas User Stories que al equipo sin VSL, luego de esto, respondidas
todas las preguntas a los miembros del equipo con respecto a las características
del producto, el equipo comenzó con la construcción del avión dentro del
ambiente virtual Virtual Scrum Lego.

5.3.2.1. Carga y priorización de las User Stories

Para la carga y priorización de las User Stories, este quipo utilizo el panel
Product Backlog de Virtual Scrum Lego, el cual da soporte a esta actividad
dando la posibilidad de agregar una descripción, prioridad, tiempo estimado de
desarrollo y el sprint en el cual se desea desarrollar cada User Story.

En este caso cada miembro del equipo Scrum mediante el uso del artefacto
Panel de Chat realizo las preguntas claves al Product Owner para obtener la
información creyeron necesaria para llevar a cabo la construcción del producto.
En la ilustración 37 y 38 se puede apreciar momento en el cual los miembros del
equipo están dentro de Virtual Scrum Lego junto al Product Owner generando el
Product Backlog.

100
 Ilustración 37: Product Backlog Virtual Scrum Lego

Ilustración 38: Product Backlog (Creando Tareas) Virtual Scrum Lego

5.3.2.2. Planificación del Sprint Backlog

Virtual Scrum Lego proporciona el componente de Planificación para realizar la
técnica Planning Póker (Oliveira & Lima, 2011) (Paasivaara, Durasiewicz, &
Lassenius, 2009).

101
 5.3.2.3. Estimación de User Stories
En este equipo cada participante dispone de un juego de cartas virtual, y en la
estimación de cada tarea, todos vuelven boca arriba la carta que representa el
esfuerzo estimado para cada uno de ellos. En la ilustración 39 se puede apreciar
momento en el cual los miembros del equipo están realizando una estimación
para la User Story: Creación de Avión.

Ilustración 39: Estimación con Póker Planning en la sesión de planning

.
En Virtual Scrum Lego, al igual que el método tradicional, se decidió que un
punto en la carta de Planning Póker representa una hora de trabajo
ininterrumpido. El modelo consta de 10 cartas con los números representados
más abajo, los cuales los equipos emplean como unidad de esfuerzo, es decir,
como horas de trabajo de cada programador. Se decidió utilizar la siguiente
secuencia Fibonacci 0; 1/2; 1; 2; 3; 5; 8, 13, 20, 40 y 100 (también existe la

102
posibilidad de utilizar la carta “infinito”) para el valor de las cartas involucradas
en el Planning Póker.

Los miembros del equipo realizaron la estimación para cada User Story
perteneciente al Sprint a desarrollar. Luego todas las User Story estimadas
fueron distribuidas entre los integrantes del equipo Scrum, por lo cual cada uno
inicio su desarrollo en Virtual Scrum Lego. Cabe destacar que gracias a la
conexión en red que ofrece Virtual Scrum Lego, algún miembro del equipo
puede dejar su actual desarrollo por un momento para ayudar a cualquier
compañero que lo necesite.

5.3.2.4. Control y Supervisión del trabajo durante el Sprint

Al igual que con la prueba del método tradicional, también se decidió realizar
Dailys Meetings de no más de 15 minutos cada una hora, para revisar y discutir
el progreso de cada tarea iniciada. Cada miembro del equipo respondió las
preguntas claves a través del artefacto Panel de Chat o Vista Daily Meeting. En
la ilustración 40 se puede ver momento en el cual el equipo realizaba una Daily.

Ilustración 40: Daily Meetings Virtual Scrum Lego

103
Después de responder a las preguntas, el equipo Scrum actualizo el estado de
las tareas dentro del Task Board como se puede apreciar en la ilustración 41.

Ilustración 41: Task Board Virtual Scrum Lego

Seleccionada la tarea a desarrollar, cada miembro del equipo empieza con la

construcción de dicha tarea con piezas LEGO Virtuales. La ilustración 42
muestra momento en el que se está desarrollando la solución de la tarea
seleccionada.

104
 Ilustración 42: Desarrollo Tarea con Virtual Scrum Lego
En la ilustración 43 se puede apreciar como Virtual Scrum Lego ofrece la
posibilidad del trabajo colaborativamente entre todos los miembros del equipo
Scrum.

Ilustración 43: Desarrollo Colaborativo Virtual Scrum Lego

105
Además Virtual Scrum Lego ofrece un reloj automático para cada tarea, el cual
se inicia, se pausa y se finaliza automáticamente mientras la tarea es
desplazada por el Task Board. Este reloj es capaz de controlar los minutos y las
horas trabajadas para cada tarea.

Cada vez que un miembro del equipo finalizaba una tarea en la cual estaba
asignado, entonces este procedía a avanzar el estado de dicha tarea de Doing
hacia el estado Done dentro del Task Board. Ver ilustración 44

Ilustración 44: Finalización Tarea Virtual Scrum Lego

5.3.2.5. Cierre del Sprint

El Sprint finalizo con una Sprint Review a través del panel de chat ofrecido por
Virtual Scrum Lego, en donde los alumnos revisaron los entregables, se vio un
avance claro y tangible el cual fue presentado al Product Owner. Durante esta
Review, el equipo Scrum a través de una demo mostro las User Stories
realizadas durante el Sprint. En la ilustración 45 se puede apreciar momento en
el cual el equipo presenta el requerimiento finalizado. El objetivo fue examinar
el trabajo realizado y obtener retroalimentación del Product Owner. Durante la
demostración, el equipo hizo hincapié en cómo las características desarrolladas
pasan las pruebas de aceptación.

106
 Ilustración 45: Requerimiento finalizado Virtual Scrum Lego

Luego, en una reunión Sprint Retrospective, también realizada a través del

panel de chat, el equipo reviso los objetivos cumplidos del Sprint terminado. Se
tomó nota de lo bueno y lo malo, para no volver a repetir los errores. Esta etapa
sirvió para implementar mejoras desde el punto de vista del proceso del
desarrollo. Además esta reunión dio la posibilidad de reflexionar sobre lo
ocurrido durante el Sprint, e identificar los problemas que pudieran impedir una
mejorara en la productividad del equipo. Para ello, cada miembro del equipo
menciono los problemas que deben abordarse. Virtual Scrum Lego apoya la
lista impedimento artefacto, para el que los miembros del equipo a identificar
soluciones y miembros responsables de su ejecución. El Scrum Master es el
encargado de supervisar la adopción efectiva de las soluciones para reducir la
lista de impedimentos.

En el cierre del último sprint, el equipo presento el producto final al Product

Owner. En este punto se evaluó la forma en que los estudiantes siguieron la
Metodología Scrum durante el desarrollo del producto, se evaluó el trabajo

107
cooperativo de los estudiantes, el mantenimiento del Task Board, cumplimiento
de los plazos, etc.

5.4. REQUERIMIENTOS DE HARDWARE

Y SOFTWARE
En esta sección se describirán las características principales de las notebooks
que formaron parte del experimento. Se analizará el sistema operativo, el
procesador, RAM y placa gráfica. Es importante aclarar que para correr la
aplicación con una performance aceptable es necesario tener 2 Gb de memoria
RAM.

En la tabla 2 se visualizara la configuración de las notebooks utilizadas por un

equipo Scrum. Los cuatro equipos usaron notebooks similares, las cuales
contaban con las siguientes características:

Tipo Máquina Sistema RAM Placa Gráfica Procesador

Operativo
Servidor Windows 7 2GB Nvidia Gforce 8500 AMD athon X2

Cliente Windows 7 3GB GB Intel GMA Intel core 2 duo

(Alumno) 4500 MHD
Cliente Windows 7 4GB Nvidia Gforce 9300 AMD atlhon X2
(Alumno)
Cliente Windows 7 2GB Nvidia GForce 9800 Intel core 2 duo
(Alumno)
Cliente Windows 7 2GB Nvidia Gforce 7300 Intel core 2 duo
(Alumno)
Cliente Windows XP 2GB Intel(R) G41 Express Pentium Dual-Core
(Alumno) Chipset CPU
Cliente Windows XP 2GB Nvidia Gforce 7300 AMD athon x2
(Alumno)

Tabla 2: Configuración de Equipos

108
En lo que respecta a requerimientos de software se tuvo en cuenta que las
computadoras que funcionaron como cliente o servidor tuvieran una máquina
virtual de java con versión 1.6.11 o superior. Para la compilación de la
aplicación se utilizó Unity3D. En el servidor se instaló el servidor independiente
de plataforma y de software libre, llamado XAMPP (el nombre proviene del
acrónimo de X; porque es para cualquiera de los diferentes sistemas
operativos, Apache, MySQL, PHP y Perl). Para la transferencia de datos
correspondiente al contenido de las clases se utilizó Tortoise SVN, el cual es
un cliente Subversion, implementado como una extensión al Shell de Windows.
Es de software libre liberado bajo la licencia GNU GPL. Luego en cada cliente
basto solo con correr la aplicación desarrollada sin la necesidad de instalar
ninguna aplicación.

5.5. ENCUESTA
En esta sección se detallara la encuesta realizada luego de la experiencia. Se
realizó una encuesta para obtener datos acerca de la funcionalidad y
usabilidad de nuestro enfoque y además de la percepción que tienen los
estudiantes acerca de lo aprendido.

Fue una encuesta anónima que se centró en evaluar si la aplicación de Virtual

Scrum Lego facilita el aprendizaje de la Metodología Scrum, además de evaluar
si soluciona los inconvenientes encontrados en las clases tradicionales, como
por ejemplo contar con los recursos materiales necesarios considerando la gran
cantidad de estudiantes que asisten a los cursos de enseñanza de Scrum. Entre
los recursos materiales requeridos se encuentra un recurso fundamental que
son las suficientes piezas de LEGO (ladrillitos), ya que sin ellas, el juego no
tendría sentido. Además, el espacio físico necesario que pueda albergar la gran
cantidad de alumnos que asisten a estos cursos.

La encuesta contenía cuarenta preguntas en una escala de Likert (Deshpande,

2011) de seis puntos. El uso de una escala de tamaño par obtiene mejor las
109
opiniones de los estudiantes ya que, por ejemplo, en un ítem de solo 5 puntos,
los encuestados suelen evitar las 2 opciones extremas, obteniendo muy poca
variación, problema conocido como central tendency bias (Gingery, 2009). A
diferencia de las preguntas dicotómicas con respuesta sí/no los estudiantes
podían responder por totalmente de acuerdo, de acuerdo, algo de acuerdo, algo
en desacuerdo, en desacuerdo o totalmente en desacuerdo. Totalmente en
desacuerdo representa la opinión más negativa (puntuación 1) y totalmente de
acuerdo en el más positivo (puntuación 6).

Las cuarenta preguntas fueron agrupadas en diferentes aspectos para para

cada uno de los ítems de Usabilidad, Percepción y Funcionalidad de Virtual
Scrum Lego. En lo que respecta a Usabilidad se obtuvieron tres aspectos,
dividiendo todas las preguntas en: Entorno de Trabajo, Disponibilidad de
Recursos y Aspectos Generales del Sistema. Luego para la Usabilidad se
tuvieron en cuenta preguntas que engloben las siguientes características:
Flexibilidad y Eficiencia de Uso, Accesibilidad y Aspectos Generales del Sistema.
Finalmente para la Percepción de los estudiantes respecto a lo aprendido con
Virtual Scrum Lego, nos centramos en los aspectos: Organización de las User
Stories, Planificación de las Tareas para un Sprint, Desarrollo de las Tareas del
Sprint y Cierre del Sprint.

110
 5.6. ANALISIS ESTADISTICO: CASO DE
ESTUDIO

En el experimento planteado queremos demostrar que Virtual Scrum Lego es

más efectivo que el método tradicional para enseñar la Metodología Scrum;
para ello, medimos la satisfacción de Usabilidad y Funcionalidad de los dos
grupos de usuarios con respecto a cada método utilizado, y la percepción que
tuvieron estos usuarios acerca de lo aprendido.

En esta sección se analizarán descriptiva y estadísticamente los resultados

obtenidos, remarcando las ventajas y desventajas de la aplicación luego de
realizada la experiencia. Cada uno de los miembros completó una encuesta
que, luego en conjunto, fueron procesadas para obtener información útil y
adecuada para ser analizada. Para un mejor análisis de los resultados, se
agruparon las preguntas en tres grupos: Usabilidad, Percepción y Funcionalidad
ya que la encuesta fue pensada y diseñada agrupando tales ítems. A
continuación se hará el mismo análisis a cada grupo, y por cada uno de ellos se
hará un análisis cualitativo y cuantitativo de los resultados obtenidos.

Una vez que se tuvieron todas las encuestas completadas, se hizo uso de
distintas operaciones estadísticas para poder realizar la validación
correspondiente a la encuesta, llevando a cabo un análisis cualitativo y
cuantitativo sobre los resultados obtenidos. Las operaciones para el análisis
cuantitativo que se utilizaron son:

 La Mediana (representa el valor de la variable de posición central en un

conjunto de datos ordenados).
 La Moda es el valor o los valores (en caso que haya varios valores de
igual frecuencia) con una mayor frecuencia en una distribución de datos.

111
  Test de hipótesis (procedimiento para juzgar si una propiedad que se
supone en una población estadística es compatible con lo observado en
una muestra de dicha población).

Se utilizó la puntuación de Likert en cada pregunta para cuantificar las

opiniones de los usuarios. En primer lugar, con dichos valores se calculó la
mediana y la moda por cada ítem (grupo de preguntas) analizado. Hay que
remarcar que, hubo preguntas narradas en forma inversa (para evitar sesgar al
usuario que conteste siempre de la misma manera, forzándolo así a leer
conscientemente la pregunta) dentro de la encuesta, y para poder realizar este
análisis se invirtieron los valores de negativos a positivos con la siguiente
fórmula: Vp = 6 - Vn + 1, Donde Vp es el valor positivo y Vn es el valor
negativo.

De la ejecución del experimento, se obtuvieron dos muestras de 10 individuos

cada una, las mismas contienen las respuestas de esos individuos a la encuesta
que realizaron. Estas son consideradas muestras aleatorias independientes de
poblaciones diferentes, a partir de esto deseamos detectar diferencias entre las
dos poblaciones en base a estas muestras tomadas, con lo cual el test que
mejor se adapta a estas condiciones es el test U de Mann-Whitney el cual se
usa para comprobar la heterogeneidad de dos grupos de muestras ordinales. En
estas circunstancias, para contrastar si el comportamiento de ambas
poblaciones es semejante se contrasta la hipótesis nula de que "la probabilidad
de que una observación aleatoria de la primera población supere a una
observación aleatoria de la segunda población es 0,5" frente a la alternativa de
que está probabilidad es distinta a 0,5.

Por lo tanto, fijamos la hipótesis nula (H0) que indica que la usabilidad,
percepción de aprendizaje y funcionalidad para los usuarios del sistema es
neutral, que es similar a decir que, en promedio, todos los usuarios del sistema
contestan con un valor de Likert igual a 3. Lo que se entiende como que no hubo

112
diferencias estadísticamente significativas en el nivel de aprendizaje de la
metodología en función de la asistencia al curso con Virtual Scrum Lego.
En caso de que se rechace la hipótesis nula, se acepta la hipótesis alternativa
(H1) planteada, que en este experimento es que la usabilidad, percepción de
aprendizaje y funcionalidad para los usuarios del sistema es positiva, es decir
que todos los usuarios del sistema, en promedio, contestan con un valor de
Likert mayor a 3. Lo que se entiende como que hubo diferencias
estadísticamente significativas en el nivel de aprendizaje de la metodología en
función de la asistencia al curso con Virtual Scrum Lego.

5.6.1. ANÁLISIS FUNCIONALIDAD

Al analizar la funcionalidad nos referimos a si el enfoque propuesto

proporcionado tanto a alumnos como a profesores, cumplen con su fin
específico, dando la posibilidad de aplicar el flujo completo de Scrum en un
entorno sin problemas de espacio ni comunicación, proveyendo todos los
artefactos de la metodología.

5.6.1.1. Resumen respuestas de Funcionalidad para grupo con

Virtual Scrum Lego
En la tabla 3 se pueden observar los resultados de las encuestas sobre las
preguntas de funcionalidad para el grupo que utilizo la herramienta Virtual
Scrum Lego.

113
 Pregunta Totalmente De Algo de Algo en En Totalmente
de acuerdo acue acuerdo desacuerdo desacuerdo en
rdo desacuerdo
1 - El entorno de trabajo me
resultó cómodo para llevar a 4 (80 %) 1 (20%) 0(0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
cabo Scrum.
2 - El entorno de trabajo me
pareció completo. 1 (20%) 3 (60%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
3 - Es posible aplicar la
Metodología Scrum con 2 (40%) 2 (40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
todas sus características.
4 - Fue sencillo llevar
adelante la construcción de 0(0,0%) 5 (100%) 0(0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
un producto con piezas
LEGO dentro del entorno de
trabajo.
5 - Las reuniones diarias,
realizadas cada 40 minutos, 0 (0,0%) 0 (0,0%) 0(0,0%) 3 (60%) 1 (20%) 1 (20%)
no fueron una tarea sencilla.
6 - En general, el entorno de
trabajo facilitó llevar a cabo 2 (40%) 3 (60%) 0(0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
Scrum.
7 - Todos los artefactos
necesarios para llevar acabo 2 (40%) 3 (60%) 0(0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
correctamente las prácticas
de Scrum se encontraron
disponibles.
8 - Me fue difícil encontrar
las piezas LEGO que 0 (0,0%) 0 (0,0%) 0(0,0%) 2 (40%) 2 (40%) 1 (20%)
necesitaba.
9 - Fue fácil reusar algunas
piezas LEGO previamente 4 (80 %) 0 (0,0%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
construidas.
10 - Si tuviese que realizar
un proyecto de mayor 2 (40%) 3 (60%) 0(0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
envergadura, sería fácil
incorporar nuevas piezas
LEGO.
11 - Me pareció satisfactoria
la experiencia de 1 (20%) 3 (60%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
aprendizaje utilizando
juegos de construcción en la
Metodología Scrum.
12 - Comprendí la
Metodología Scrum 2 (40%) 2 (40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
fácilmente.
13 - El curso me resulto
satisfactorio teniendo en 2 (40%) 2 (40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
cuenta otros cursos
realizados. Solo responda si
ha participado de otros
cursos.
14 - El curso no contribuyo a
mi trabajo actual, ni 0 (0,0%) 0 (0,0%) 0(0,0%) 0 (0,0%) 1 (20%) 4 (80%)
tampoco a mi carrera
profesional.

Tabla 3: Respuesta a encuesta sobre Funcionalidad con Virtual Scrum Lego.

114
Analizando las distintas preguntas, se puede observar que en las preguntas 1,
2, 3, 4 y 6, las cuales tienen que ver directamente con la funcionalidad del
Entorno de Trabajo para la puesta en práctica de Metodología Scrum dentro
de la aplicación, se pudo apreciar que Virtual Scrum Lego es de gran ayuda
obteniendo el 80% de las respuestas entre “De acuerdo” o “Totalmente de
acuerdo” dejando en claro que el entorno de trabajo fue cómodo, sencillo y
completo para llevar la metodología adelante, facilitando la construcción del
producto y las reuniones diarias, esta última se puede apreciar en las
respuestas a la pregunta 5.

Las preguntas de 7 a 10 son particulares sobre la Disponibilidad de

Recursos. Aquí se puede apreciar que los usuarios no presentaron problemas
en cuanto a las piezas de LEGO a utilizar o reutilizar las mismas, tampoco han
presentado problema alguno para hacer uso de los artefactos de Scrum dando
como resultado en sus respuestas un 100% de ellas distribuidas entre “Algo de
Acuerdo”, “De acuerdo” o “Totalmente de acuerdo”.

Finalizando con la encuesta sobre Funcionalidad vemos las últimas cuatro

preguntas, las cuales hacen hincapié en los Aspectos Generales del Sistema
aquí las respuestas también están algo distribuidas, pero siempre
positivamente en su totalidad, dejando en claro que se comprendió fácilmente
la metodología utilizando juegos como estrategia de aprendizaje, y finalmente
apoyando el mismo como una experiencia satisfactoria, esto nos indicó que
para todos los usuarios que realizaron el experimento es una herramienta que
puede resultar muy útil y productiva para la educación de la Metodología Scrum
en línea a través de juegos.

5.6.1.2. Resumen respuestas de Funcionalidad para grupo con

método estándar
En la tabla 4 se pueden observar los resultados de las encuestas sobre las
preguntas de funcionalidad, para el grupo que realizo la prueba con el método
tradicional.

115
 Pregunta Totalmente De Algo de Algo en En Totalmente
de acuerdo acuerdo acuerdo desacuerdo desacuerdo en
desacuerdo
1 - El entorno de trabajo me
resultó cómodo para llevar a 3 (60 %) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
cabo Scrum.
2 - El entorno de trabajo me
pareció completo. 1 (20%) 2 (40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
3 - Es posible aplicar la
Metodología Scrum con todas 1 (20%) 2 (40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
sus características.
4 - Fue sencillo llevar adelante la
construcción de un producto con 2 (40%) 2 (40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
piezas LEGO dentro del entorno
de trabajo.
5 - Las reuniones diarias,
realizadas cada 40 minutos, no 0 (0,0%) 0(0,0%) 0 (0,0%) 1 (20%) 2 (40%) 2 (40%)
fueron una tarea sencilla.
6 - En general, el entorno de
trabajo facilitó llevar a cabo 1 (20%) 4 (80%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
Scrum.
7 - Todos los artefactos
necesarios para llevar acabo 1 (20%) 2 (40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
correctamente las prácticas de
Scrum se encontraron
disponibles.
8 - Me fue difícil encontrar las
piezas LEGO que necesitaba 0 (0,0%) 0(0,0%) 0 (0,0%) 1 (20%) 2 (40%) 2 (40%)
9 - Fue fácil reusar algunas
piezas LEGO previamente 2 (40%) 3 (60%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
construidas.
10 - Si tuviese que realizar un
proyecto de mayor 1 (20%) 2 (40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
envergadura, sería fácil
incorporar nuevas piezas LEGO.
11 - Me pareció satisfactoria la
experiencia de aprendizaje 1 (20%) 3 (60%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
utilizando juegos de
construcción en la Metodología
Scrum.
12 - Comprendí la Metodología
Scrum fácilmente. 1 (20%) 2 (40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
13 - El curso me resulto
satisfactorio teniendo en cuenta 1 (20%) 2 (40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
otros cursos realizados. Solo
responda si ha participado de
otros cursos.
14 - El curso no contribuyo a mi
trabajo actual, ni tampoco a mi 0 (0,0%) 0(0,0%) 0 (0,0%) 2 (40%) 2 (40%) 1 (10%)
carrera profesional.

Tabla 4: Respuesta a encuesta sobre Funcionalidad para la prueba realizada a través del
método tradicional.

116
 5.6.1.3. Análisis Comparativo sobre Funcionalidad
Ítems Mediana Moda Mediana Moda
Aritmética Aritmética Aritmética Aritmética
(VSL) (VSL) (MT) (MT)
Entorno De Trabajo 27 27 24 24,27
Disponibilidad de 22 24 20 18,19,20,21,
Recursos 23
Aspectos Generales 21 21 19 19,21

Tabla 5: Opiniones cuantificadas de las preguntas sobre Funcionalidad.

Las hipótesis a constatar son las siguientes:

 H1: Existen diferencias estadísticamente significativas acerca de las

opiniones del Entorno De Trabajo entre el grupo de alumnos que usaron
Virtual Scrum Lego y el grupo que usó el método tradicional.

 H2: Existen diferencias estadísticamente significativas acerca de la

Disponibilidad De Recursos entre el grupo de alumnos que usaron
Virtual Scrum Lego y el grupo que usó el método tradicional.

 H3: Existen diferencias estadísticamente significativas acerca de las

opiniones en Aspectos Generales entre el grupo de alumnos que usaron
Virtual Scrum Lego y el grupo que usó el método tradicional.

Ítems Entorno Disponibilidad Aspectos

Variables U-Test de de Recursos Generales
Trabajo
U de Mann-Whitney 23,000 22,000 20,000
W de Wilcoxon 78,000 77,000 75,000
Z -2,097 -2,317 -2,380
Sig. Asintótica (bilateral) 0,036 0,033 0,017
Significación Exacta U 0,043 0,035 0,023
Tabla 6: Estadísticos de Prueba.
Las puntaciones de Likert en cada pregunta fueron utilizadas para cuantificar
las opiniones de los miembros del experimento. Se corrió una prueba U de
Mann-Whitney ya que es la que mejor se adapta para muestras independientes
menores a 30 datos. La tabla 5 muestra los resultados, donde las columnas

117
representan la mediana aritmética, y la moda aritmética. Finalmente en la tabla
6 observamos el resultado del test de hipótesis U (U de Mann-Whitney).
Cuando el valor de significación U es inferior a 0,05 debemos quedarnos con la
hipótesis alternativa (H1, H2, H3). De acuerdo a los valores obtenidos,
podemos concluir que se verifican las hipótesis H1, H2 y H3. Según la tabla 6,
para el Entorno De Trabajo, se puede ver que la mediana de VSL (27) es
superior al MT (24), para la Disponibilidad de Recursos la mediana de VSL
(22) es superior al MT (20) y para los Aspectos Generales también la
mediana de VSL (21) es superior al MT (19), con lo cual, concluimos que VSL
introduce mejoras positivas en el Entorno De Trabajo, en la Disponibilidad
de Recursos y en los Aspectos Generales respecto a un enfoque tradicional
MT.

Finalmente, podemos decir que hay evidencia suficiente para establecer que el
método Virtual Scrum Lego es significativamente diferente y superior que el
Método Tradicional.

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)

Ilustración 48: Histograma Aspectos Generales (Izquierda VSL – Derecha Método

Tradicional)

En cuanto a la percepción general de los estudiantes sobre la funcionalidad de

que ofrece Virtual Scrum Lego se calculó la puntuación de Likert por estudiante
119
para cada ítem analizado. El primero de ellos fue el Entorno de Trabajo, el cual
contenía 5 preguntas realizadas en la encuesta, esto implica que nuestra escala
de Likert se encontraba en el rango entre 5 y 30, siendo 5 un “totalmente
desacuerdo” y 30 un “totalmente de acuerdo”. La Ilustración 46, a su izquierda
muestra un histograma de las puntuaciones obtenidas por Virtual Scrum Lego y
donde cada barra indica la cantidad de alumnos que tenían la misma
puntuación. En este gráfico se puede observar que los resultados tendieron
hacia una distribución normal. El segundo ítem analizado fue la Disponibilidad
de Recursos, el cual contenía 4 preguntas realizadas en la encuesta, esto
implica que nuestra escala de Likert se encontraba en el rango entre 4 y 24,
siendo 4 un “totalmente desacuerdo” y 24 un “totalmente de acuerdo”. La
Ilustración 47 a su izquierda muestra un histograma de las puntuaciones
obtenidas por Virtual Scrum Lego y donde cada barra indica la cantidad de
alumnos que tenían la misma puntuación. En este gráfico se puede observar
que los resultados tendieron hacia una distribución normal. El ultimo ítem
analizado fueron los Aspectos Generales, el cual contenía 4 preguntas
realizadas en la encuesta, esto implica que nuestra escala de Likert se
encontraba en el rango entre 4 y 24, siendo 4 un “totalmente desacuerdo” y 24
un “totalmente de acuerdo”. La Ilustración 48 a su izquierda muestra un
histograma de las puntuaciones obtenidas por Virtual Scrum Lego y donde cada
barra indica la cantidad de alumnos que tenían la misma puntuación. En este
gráfico se puede observar que los resultados tendieron hacia una distribución
normal.

5.6.2. ANÁLISIS DE USABILIDAD

En esta sección se detallan los conceptos más relevantes que refieren a la

usabilidad general de la aplicación. Como toda aplicación de software, lleva un
tiempo aprender a utilizarla (lo que se conoce como curva de aprendizaje), es

120
por esto que el entorno virtual y la aplicación están diseñados de manera que al
usuario le resulte sencillo familiarizarse con la misma.

5.6.2.1. Resumen respuestas de Usabilidad para grupo con

Virtual Scrum Lego
En la tabla 7 se pueden observar los resultados de las encuestas sobre las
preguntas de usabilidad, para el grupo que utilizo la herramienta Virtual Scrum
Lego.

Pregunta Totalment De Algo de Algo en En Totalmente

e de acuerd acuerd desacuer desacuerd en
acuerdo o o do o desacuerdo
1 - El curso me ofreció una
interfaz clara y concisa al 2 (40%) 1 (20%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
momento de desarrollar.
2 - Me resultó fácil la
construcción del producto con 0 (0,0%) 5 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
(100%)
piezas LEGO.
3 - Me resulto sencilla y clara la
interacción con el juego. 1 (20%) 4 (80%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
4 - Fue fácil aprender a usar la
herramienta. 4 (80%) 0 (0,0%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
5 - No surgieron errores durante
el uso de la herramienta. 3 (60%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
6 - Las acciones disponibles
dentro del entorno estaban 3 (60%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
claramente señaladas.
7 - No hubo errores de
ejecución. 2 (40%) 1 (20%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
8 - La herramienta no impidió
que realice cada paso de Scrum 2 (40%) 2 (40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
satisfactoriamente.
9 - La generación de bloques 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 1 (20%) 4 (80,0%)
necesarios en la construcción
para una determinada tarea, fue
un problema constante.

Tabla 7: Respuesta a encuesta sobre Usabilidad con Virtual Scrum Lego

Diversos autores han propuesto diferentes conjuntos de heurísticos o principios

de usabilidad a través de los cuales evaluar la usabilidad. Nielsen (Nielsen,
1994 April) propone los siguientes:

 Lenguaje común entre sistema y usuario

121
  Es mejor reconocer que recordar

 Flexibilidad y eficiencia de uso

 Diseño minimalista

Hassan Montero y Martín Fernández (Montero & Fernandez, 2003) proponen el

siguiente modelo de evaluación heurística:

 Aspectos generales
 Elementos multimedia
 Accesibilidad

Analizando las respuestas a las preguntas 2, 3 y 6 las cuales hacen referencia a

los Aspectos Generales de la Usabilidad del sistema, podemos altamente
destacar que el 100% de los estudiantes están “De acuerdo” o “Totalmente de
acuerdo”, indicando que con Virtual Scrum Lego fue realmente sencillo
construir el producto, además de ofrecer una interacción sencilla y clara y
destacando el señalamiento correcto de todas las acciones disponibles dentro
del salón de juego. Luego el 80% de los encuestados respondió “Totalmente de
acuerdo” dejando a la vista que aprender a utilizar la aplicación fue realmente
fácil. Por último, no tan favorables fueron las respuestas para la primera
pregunta en donde el 40% de los encuestados están solo “Algo de Acuerdo” con
respecto a cuestiones de interfaz del curso, un punto importante en el cual se
deberá trabajar en un futuro.

Las preguntas 7 y 8 están relacionadas con la Flexibilidad y eficiencia de

uso, un punto realmente interesante de analizar. Estas preguntas dejaron en
claro que Virtual Scrum Lego es altamente fiable de usar ya que el 100% de los
encuestados respondieron “Algo de acuerdo”, “De acuerdo” o “Totalmente de
acuerdo” indicando que no hubo errores en la ejecución del juego y que el
mismo no impidió que realice cada paso de Scrum satisfactoriamente.

122
Por último la pregunta 9 se refiere a la Accesibilidad de la herramienta, aquí
se debe aclarar que Hassan Montero y Martín Fernández (Montero & Fernandez,
2003) destacan a la Accesibilidad como que cualquier persona pueda utilizar la
herramienta independientemente del dispositivo que use (hardware o
software). Los alumnos respondieron 100% “En desacuerdo” o “Totalmente en
desacuerdo” ya que es una pregunta negativa, dando a entender que no fue un
problema la generación constante de bloques.

5.6.3. ANÁLISIS DE PERCEPCIÓN

En este caso particular al analizar percepción, nos referimos a la percepción que
tuvieron los estudiantes sobre lo aprendido en la Metodología Scrum luego de
realizada la experiencia.

5.6.3.1. Resumen respuestas de Percepción para grupo con

Virtual Scrum Lego
En la tabla 8 se pueden observar los resultados de las encuestas sobre las
preguntas de percepción, para el grupo que utilizo la herramienta Virtual Scrum
Lego:

123
 Pregunta Totalmente De acuerdo Algo Algo en En Totalmente en
de acuerdo de desacuerdo desacuerdo desacuerdo
acuer
do
1 - Resulto fácil cargar las
Tareas en el Panel General de 1 (20%) 3 (60%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
Tareas a realizar.
2 - Fue complicado
comunicarme con el cliente 0 (0,0%) 0 (0,0%) 0 (0,0%) 1 (20%) 2 (40%) 2 (40%)
para obtener información
acerca de sus requerimientos.
3 - En el comienzo del
desarrollo, me resultó difícil 0 (0,0%) 0 (0,0%) 1 (20%) 2 (40%) 2 (40%) 0 (0,0%)
establecer los artefactos, tales
como: el panel con la lista de
todo lo que podría necesitarse
en el producto, el panel de
tareas a atacar en un sprint, el
panel de estimación de tareas
y demás.
4 - Fue claro asociar el
requerimiento del cliente a las 1 (20%) 3 (60%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
tareas definidas.
5 - Me resultó sencilla la
estimación de las Tareas. 2 (40%) 2 (40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
6 - Fue difícil realizar la
planificación de la iteración. 0 (0,0%) 0 (0,0%) 0 (0,0%) 2 (40%) 3 (60%) 0 (0,0%)
7 - Resulto sencilla la
distribución de Tareas en los 1 (20%) 4 (80%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
miembros del equipo.
8 - La comunicación necesaria
para realizar la planificación 2 (40%) 2 (40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
fue ordenada y suficiente.
9 - Me fue sencilla llevar a
cabo las tareas con piezas 2 (40%) 1 (20%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
Lego.
10 - La comunicación con mis 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 2 (40%) 2 (40%)
compañeros de equipo en las
reuniones diarias fue una
tarea complicada.
11 - No fue difícil mostrar y/o
modificar el estado de mis 0 (0,0%) 3 (60%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
tareas para con mis
compañeros.
12 - Me resulto sencillo
visualizar el estado de las 2 (40%) 1 (20%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
tareas de mis compañeros.
13 - Fue sencillo para el
equipo mostrar el avance del 1 (20%) 4 (80%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
desarrollo al cliente.
14 - Me fue sencilla la
comunicación con el cliente a 1 (20%) 2 (40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
fin de obtener feedback sobre
el producto desarrollado.
15 - Fue fácil desarrollar una
reunión de retrospectiva al 2 (40%) 2 (40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
final del Sprint.
16 - No hubo dudas sobre los
temas a desarrollar en dicha 1 (20%) 4 (80%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
reunión de retrospectiva.
17 - Me resulto sumamente 0 (0,0%) 0 (0,0%) 0 (0,0%) 1 (20%) 2 (40%) 2 (40%)
difícil la integración de cada
tarea en un solo producto
final.

Tabla 8: Respuesta a encuesta sobre Percepción con Virtual Scrum Lego

124
Analizando las primeras cuatro preguntas, las cuales corresponden a la
Organización de las User Stories podemos destacar las actividades carga de
la tareas y la asociación de una tarea a un requerimiento (pregunta 1 y 4), ya
que estas actividades obtuvieron el 100% de las repuestas de manera “Algo de
acuerdo”, “De acuerdo” o “Totalmente de acuerdo”. Luego de la pregunta 2
podemos afirmar que la herramienta provee de un mecanismo adecuado
soportando una buena comunicación con el cliente. Finalmente al 20% de los
encuestados le resulto difícil establecer los artefactos de Scrum dentro del
juego.

En las siguientes cuatro preguntas se hizo hincapié en la Planificación de las

Tareas para un Sprint en donde las respuestas estuvieron algo más
distribuidas. Todos los encuestados estuvieron “Algo de acuerdo”, “De acuerdo”
o “Totalmente de acuerdo” en que la estimación de tareas fue sencilla dentro de
la herramienta y en que se tuvo una buena y ordenada comunicación para la
Planificación de las mismas. No así fue la Planificación de la Iteración en donde
no se vio satisfechos en su totalidad a los encuestados. Algo para destacar en
esta sección fue que todos estuvieron de acuerdo en que la actividad de
distribuir tareas en todos los miembros del equipo resulto una actividad
sencilla.

También se tuvieron en cuenta preguntas orientadas al aspecto Desarrollo de

las Tareas del Sprint, gracias a ellas se pudo detectar que Virtual Scrum Lego
provee de buenos y correctos paneles con la funcionalidad adecuada para
mostrar a los demás compañeros del equipo el estado actual de cada tarea
asignada a un miembro y además visualizar el estado actual de las tareas de los
demás miembros del equipo. Algo que no se puede dejar de mencionar es que
el 20% de los encuestados estuvo “Totalmente de acuerdo” en opinar que la
herramienta le resulto complicada para la comunicación con sus compañeros al
momento de construir una determinada tarea.

125
Finalmente podemos apreciar las respuestas para las últimas cinco preguntas,
las cuales están orientadas al Cierre del Sprint. Aquí el equipo encuestado
mostro una alta satisfacción con la manera que ofrece la herramienta en
mostrar el avance de la construcción del producto, obteniendo el 100% de las
respuestas entre “De acuerdo” y “Totalmente de acuerdo”. Resultados similares
se obtuvieron con la comunicación del cliente a fin de obtener feedback sobre el
producto desarrollado, solo que con un 20% de los encuestados “Algo de
acuerdo”. Luego las actividades relacionadas con reuniones retrospectivas
también obtuvieron el 100% de la aprobación de los encuestados, con los cual
podemos afirmar que la herramienta provee de mecanismos factibles para el
cierre de los sprint a ejecutar. Y finalmente un resultado realmente interesante,
es que el 80% de los encuestados opino que la herramienta le fue de gran
utilidad para la integración de cada tarea en un solo producto final, con lo cual,
esto nos indicó que para todos los usuarios que realizaron el experimento es
una herramienta que puede resultar muy útil y productiva para la educación de
la Metodología Scrum en línea a través de juegos.

5.6.3.2. Resumen respuestas de Percepción para grupo con

método estándar
En la tabla 9 se pueden observar los resultados de las encuestas sobre las
preguntas de percepción, para el grupo que realizo la prueba con el método
tradicional.

126
 Pregunta Totalmente De Algo de Algo en En Totalmente
de acuerdo acuerdo acuerdo desacuerdo desacuerdo en
desacuerdo
1 - Resulto fácil cargar las
Tareas en el Panel General de 1 (20%) 2(40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
Tareas a realizar
2 - Fue complicado
comunicarme con el cliente 0 (0,0%) 0(0,0%) 0 (0,0%) 2 (40%) 1 (20%) 2 (40%)
para obtener información
acerca de sus requerimientos
3 - En el comienzo del
desarrollo, me resultó difícil 0 (0,0%) 0(0,0%) 0 (0,0%) 1 (20%) 1 (20%) 3 (60%)
establecer los artefactos, tales
como: el panel con la lista de
todo lo que podría necesitarse
en el producto, el panel de
tareas a atacar en un sprint, el
panel de estimación de tareas y
demás
4 - Fue claro asociar el
requerimiento del cliente a las 1 (20%) 4(80%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
tareas definidas
5 - Me resultó sencilla la
estimación de las Tareas 2 (40%) 3(60%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
6 - Fue difícil realizar la
planificación de la iteración 0 (0,0%) 0(0,0%) 0 (0,0%) 1 (20%) 2 (40%) 2 (40%)
7 - Resulto sencilla la
distribución de Tareas en los 1 (20%) 2(40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
miembros del equipo
8 - La comunicación necesaria
para realizar la planificación fue 2 (40%) 2(40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
ordenada y suficiente
9 - Me fue sencilla llevar a cabo
las tareas con piezas LEGO 2 (40%) 3(60%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
10 - La comunicación con mis 0 (0,0%) 0(0,0%) 0 (0,0%) 0 (0,0%) 2 (40%) 3 (60%)
compañeros de equipo en las
reuniones diarias fue una tarea
complicada
11 - No fue difícil mostrar y/o
modificar el estado de mis 1 (20%) 2(40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
tareas para con mis
compañeros
12 - Me resulto sencillo
visualizar el estado de las tareas 1 (20%) 3(60%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
de mis compañeros
13 - Fue sencillo para el equipo
mostrar el avance del desarrollo 1 (20%) 3(60%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
al cliente
14 - Me fue sencilla la
comunicación con el cliente a 1 (20%) 2(40%) 2 (40%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
fin de obtener feedback sobre el
producto desarrollado
15 - Fue fácil desarrollar una
reunión de retrospectiva al final 1 (20%) 4(80%) 0 (0,0%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
del Sprint
16 - No hubo dudas sobre los
temas a desarrollar en dicha 2 (40%) 2(40%) 1 (20%) 0 (0,0%) 0 (0,0%) 0 (0,0%)
reunión de retrospectiva
17 - Me resulto sumamente 0 (0,0%) 0(0,0%) 0 (0,0%) 0 (0,0%) 3 (60%) 2 (40%)
difícil la integración de cada
tarea en un solo producto final

Tabla 9: Análisis Comparativo sobre Percepción

127
 Ítems Mediana Moda Mediana Moda
Aritmética Aritmética Aritmética Aritmética
(VSL) (VSL) (MT) (MT)
Organización de las User 21 21 20 20
Stories
Planificación Tareas Sprint 22 22 19.5 18
Desarrollo Tareas Sprint 21 23 18.5 19
Cierre Sprint 26 26 25.5 24

Tabla 10: Opiniones cuantificadas de las preguntas sobre Percepción

Las hipótesis a constatar son las siguientes:

 H1: Existen diferencias estadísticamente significativas sobre la

Organización de las User Stories entre el grupo de alumnos que usaron
Virtual Scrum Lego y el grupo que usó el método tradicional.

 H2: Existen diferencias estadísticamente significativas acerca de la

Planificación De Tareas entre el grupo de alumnos que usaron Virtual
Scrum Lego y el grupo que usó el método tradicional.

 H3: Existen diferencias estadísticamente significativas sobre el

Desarrollo de Tareas entre el grupo de alumnos que usaron Virtual
Scrum Lego y el grupo que usó el método tradicional.

 H4: Existen diferencias estadísticamente significativas acerca del

Cierre de Sprint entre el grupo de alumnos que usaron Virtual Scrum Lego
y el grupo que usó el método tradicional.

Organización US Planificaci Desarrollo Tareas Cierre

Ítems ón Tareas Sprint
Variables U-Test
U de Mann-Whitney 15,500 23,500 19,500 30,000
W de Wilcoxon 70,500 78,500 74,500 85,000
Z -2,752 -2,025 -2,320 -1,576
Sig. Asintótica 0,006 0,043 0,020 0,115
(bilateral)
Significación Exacta U 0,007 0,043 0,019 0,143
Tabla 11: Estadísticos de Prueba.

128
Las puntaciones de Likert en cada pregunta fueron utilizadas para cuantificar
las opiniones de los miembros del experimento. Se corrió una prueba U de
Mann-Whitney ya que es la que mejor se adapta para muestras independientes
menores a 30 datos. La tabla 10 muestra los resultados, donde las columnas
representan la mediana aritmética, y la moda aritmética. Finalmente en la tabla
11 observamos el resultado del test de hipótesis U (U de Mann-Whitney).
Cuando el valor de significación U es inferior a 0,05 debemos quedarnos con la
hipótesis alternativa (H1, H2, H3, H4). De acuerdo a los valores obtenidos,
podemos concluir que se verifican las hipótesis H1, H2, H3 y H4. Según la tabla
11, para la Organización de las User Stories, se puede ver que la mediana
de VSL (21) es superior al MT (20), para la Planificación de Tareas del
Sprint la mediana de VSL (22) es superior al MT (19,5), para el Desarrollo de
Tareas del Sprint la mediana de VSL (21) es superior al MT (18,5) y para el
Cierre del Sprint también la mediana de VSL (26) es superior al MT (25,5),
con lo cual, concluimos que VSL introduce mejoras positivas en la
Organización de las User Stories, en la Planificación de Tareas del
Sprint, en el Desarrollo de Tareas del Sprint y en el Cierre del Sprint
respecto a un enfoque tradicional MT.

Finalmente, podemos decir que hay evidencia suficiente para establecer que el
método Virtual Scrum Lego es significativamente diferente y superior que el
Método Tradicional.

129
Ilustración 49: Histograma Organización de las US (Izquierda VSL – Derecha Método
Tradicional)

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)

Ilustración 52: Histograma Cierre del Sprint (Izquierda VSL – Derecha Método
Tradicional)

En cuanto a la percepción general de los estudiantes sobre la percepción que

ofrece Virtual Scrum Lego se calculó la puntuación de Likert por estudiante para
131
cada ítem analizado. El primero de ellos fue la Organización de las US, el cual
contenía 4 preguntas realizadas en la encuesta, esto implica que nuestra escala
de Likert se encontraba en el rango entre 4 y 24, siendo 4 un “totalmente
desacuerdo” y 24 un “totalmente de acuerdo”. La Ilustración 49 a su izquierda
muestra un histograma de las puntuaciones obtenidas por Virtual Scrum Lego y
donde cada barra indica la cantidad de alumnos que tenían la misma
puntuación. En este gráfico se puede observar que los resultados tendieron
hacia una distribución normal. El segundo ítem analizado fue la Planificación de
Tareas del Sprint, el cual contenía 4 preguntas realizadas en la encuesta, esto
implica que nuestra escala de Likert se encontraba en el rango entre 4 y 24,
siendo 4 un “totalmente desacuerdo” y 24 un “totalmente de acuerdo”. La
Ilustración 50 a su izquierda muestra un histograma de las puntuaciones
obtenidas por Virtual Scrum Lego y donde cada barra indica la cantidad de
alumnos que tenían la misma puntuación. En este gráfico se puede observar
que los resultados tendieron hacia una distribución normal. El tercer ítem
analizado fue el Desarrollo de las Tareas, el cual contenía también 4 preguntas
realizadas en la encuesta, esto implica que nuestra escala de Likert se
encontraba en el rango entre 4 y 24, siendo 4 un “totalmente desacuerdo” y 24
un “totalmente de acuerdo”. La Ilustración 51 a su izquierda muestra un
histograma de las puntuaciones obtenidas por Virtual Scrum Lego y donde cada
barra indica la cantidad de alumnos que tenían la misma puntuación. En este
gráfico se puede observar que los resultados tendieron hacia una distribución
normal. Finalmente para el ítem Cierre Del Sprint se contó con 5 preguntas
realizadas en la encuesta, esto implica que nuestra escala de Likert se
encontraba en el rango entre 5 y 30, siendo 5 un “totalmente desacuerdo” y 30
un “totalmente de acuerdo”. La Ilustración 52 a su izquierda muestra un
histograma de las puntuaciones obtenidas por Virtual Scrum Lego y donde cada
barra indica la cantidad de alumnos que tenían la misma puntuación. En este
gráfico se puede observar que los resultados tendieron hacia una distribución
normal.

132
 5.7. CONCLUSIONES

Finalizadas las pruebas y analizados los resultados se pudo llegar a la

conclusión que la herramienta Virtual Scrum Lego fue de gran utilidad en la
enseñanza y aprendizaje de la Metodología Scrum para los dos tipos de
usuarios involucradas en el experimento.

A partir de las respuestas obtenidas, se pudo apreciar que el profesor quien fue
el que llevo la clase adelante, se sintió cómodo al notar que Virtual Scrum LEGO
facilita el aprendizaje para los alumnos de la Metodología Scrum, solucionando
los inconvenientes que presentan estas clases, ya mencionados en el capítulo.

133
CAPITULO 6

134
6. CONCLUSIONES
En este trabajo final se presentó Virtual Scrum Lego, una herramienta que
apunta a enseñar y poner en práctica la Metodología Scrum.
Este capítulo se organiza de la siguiente manera: En la sección 6.1 se exponen
las contribuciones del proyecto. Luego en la sección 6.2 se describen las
limitaciones de la herramienta y finalmente hacia la sección 6.3 se listan los
posibles trabajos futuros.

6.1. CONTRIBUCIONES DEL PROYECTO

Este proyecto presenta varias contribuciones. En primer lugar, y como
contribución más importante, el desarrollo de una herramienta que permite
llevar a cabo y enseñar a estudiantes las prácticas propuestas por el framework
de Scrum de forma completa, abarcando desde la captura de requerimientos
hasta la entrega final del producto. Además de esto, se obtuvieron las
siguientes contribuciones:

 Permitir a los estudiantes realizar reuniones virtuales que son

especialmente útiles en contextos distribuidos.
 Permitir al docente/cliente realizar una comparación entre el producto
desarrollado por el alumno y el producto requerido por el
docente/cliente.
 Virtual Scrum Lego permite el trabajo en equipo sin necesidad de estar
en la misma ubicación geográfica.
 Virtual Scrum Lego permite desarrollar el producto final sin gastos y sin
riesgos reales, por ser una simulación del producto.

Es notable destacar que entre estas contribuciones, una de las más relevantes
es la de evitar contener al equipo de trabajo en un mismo espacio físico, ya que
135
con la herramienta propuesta se podrá mantener la comunicación y trabajar en
equipo desde diferentes zonas geográficas, evitando costos y tiempo. Esto se
debe a que las reuniones son un factor fundamental para el correcto
desempeño del equipo de trabajo cuando utiliza una Metodología Scrum, e
incluso aún más importantes en contextos de desarrollo distribuido de
software.

Otra contribución relevante que cabe destacar, es la posibilidad de mostrar los

resultados obtenidos del desarrollo utilizando Scrum, que parte de una
comparación entre el producto solicitado por el cliente y el producto
desarrollado por los estudiantes.

Por otro lado, mediante la experimentación detallada en el Capítulo 6, se

pudieron apreciar resultados satisfactorios al comparar la herramienta Virtual
Scrum Lego con el método tradicional, dado que Virtual Scrum Lego mostró
introducir mejoras en el aprendizaje de la Metodología Scrum. Además, se
mostró que el profesor logró dar clases sin inconvenientes a pesar de su
distribución geográfica y que los alumnos aplicaron los pasos completos de la
Metodología Scrum. Durante el seguimiento de estos pasos, los estudiantes se
mostraron realizarlos de manera agradable, sin necesidad de materializar cada
componente (ladrillos LEGOs, pizarrón, etc.) y adquiriendo el aprendizaje de la
metodología.

136
 6.2. LIMITACIONES DE LA
HERRAMIENTA
Refiriéndonos a aspectos como la usabilidad, unas de las principales
limitaciones es la comunicación ya que constituye un gran desafío replicar las
misma comunicación que sucede en un entorno “cara a cara” tradicional. Por
este motivo, es importante complementar el uso de la herramienta con video
conferencias, ya que permite una comunicación más fluida entre los
participantes.

Otra limitación con respecto a la Usabilidad, es la que surge de la manipulación

de los bloques de LEGO a través del teclado o el mouse. Esta constituye un
desafío para la construcción de piezas y/o modelos. Es por ello que atacar este
punto en un futuro será una mejora significativa para la herramienta.

Por otro lado, si bien el flujo Scrum se pudo aplicar en su totalidad, notamos
que al momento de estimar las tareas con Poker Planning, no resulto muy
agradable para el usuario en términos de usabilidad, con lo cual nos da la pauta
de que esto constituye actualmente una limitación de la herramienta.

Otros aspectos fueron la complejidad en los requisitos de instalación como ser

el problema de incompatibilidad con placas gráficas que no sean Intel. Sin
embargo, la solución a este problema se da con la actualización de los drivers
de la placa gráfica (previa desinstalación).

6.3. TRABAJOS FUTUROS

Existen distintos aspectos de la herramienta que pueden ser extendidos para

obtener un mejor provecho de su utilización.

137
Actualmente el almacenamiento de los bloques y las celdas persistidas (para
soporte colaborativo) se realiza con una estructura que tiende a degradar
significativamente el aplicativo para bloques demasiado grandes y con escalas
muy pequeñas. Se piensa que a futuro se podría realizar un cambio en este
aspecto para mejorar la performance de la herramienta.

Otro punto, será extender la aplicación agregando la manipulación de bloques

a través de una cámara que lea movimientos corporales. De esta manera la
cámara podría interpretar los movimientos de las manos de los participantes y
así manipular las piezas LEGO como en la vida real.

Otro aspecto a tener en cuenta a futuro, será realizar un aplicativo externo que
consuma la información persistida de la db y obtenga estadísticas de todo tipo,
entre ellas podría ser cantidad de piezas utilizadas, movimientos, etc., estos
resultados podrían ser generados a nivel persona o grupalmente (por
proyecto).

Y por último, se podría realizar una mejora en el tablero de Poker Planning,

simulando la técnica real de la estimación. En nuestro desarrollo se ofreció un
mazo de cartas simples. Aquí es donde se puede mejorar ofreciendo diferentes
tipos de tarjetas, como por ejemplo una secuencia de Fibonacci incluyendo un
cero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 o también otras progresiones similares.

138
 APÉNDICE A
La siguiente encuesta fue presentada a los miembros que participaron del
experimento. La misma se centró en evaluar si la aplicación de Virtual Scrum
Lego facilita el aprendizaje de la Metodología Scrum. También de evaluó si
soluciona los inconvenientes encontrados en las clases tradicionales, como por
ejemplo contar con los recursos materiales necesarios considerando la gran
cantidad de estudiantes que asisten a los cursos de enseñanza de Scrum. Entre
los recursos materiales requeridos se encuentra un recurso fundamental que
son las suficientes piezas de LEGO (ladrillitos), ya que sin ellas, el juego no
tendría sentido. Además, el espacio físico necesario que pueda albergar la gran
cantidad de alumnos que asisten a estos cursos.

Datos Personales

Nombre y Apellido* Require

Edad* Required

 < 20 Años
 Entre 20 y 25
 Entre 26 y 30
 > 30 Años

Sexo*

 M/F

Profesión* R

Conoce la Mitología Scrum* R

 SI / NO

Solo responder en caso de haber sido afirmativa la respuesta anterior.

 Solo ha escudo hablar de la Metodología.

 Ha realizado cursos de la Metodología.
 Trabaja a diario aplicando la Metodología.

139
Preguntas de tipo Likert
( 1 = completamente en desacuerdo ; 6 = completamente de acuerdo)

1 - El entorno de trabajo me resultó cómodo para llevar a cabo Scrum.* Required

2 - Me fue difícil encontrar las piezas Lego que necesitaba.* Required

3 - Me resultó sencilla la estimación de las Tareas.* Required

4 - Me fue sencilla llevar a cabo las tareas con piezas Lego.* Required

5 - Fue difícil realizar la planificación de la iteración.* Required

6 - No fue difícil mostrar y/o modificar el estado de mis tareas para con mis compañeros.* Required

7 - Resulto fácil cargar las Tareas en el Panel General de Tareas a realizar. * Required

8 - El curso me resulto satisfactorio teniendo en cuenta otros cursos realizados. Solo

responda si ha participado de otros cursos.* Required

9 - El entorno de trabajo me pareció completo.* Required

10 - Me fue sencilla la comunicación con el cliente a fin de obtener feedback sobre el

producto desarrollado.* Required

11 - La comunicación con mis compañeros de equipo en las reuniones diarias fue una tarea
complicada.* Required

12 - El curso me resulto útil.* Required

13 - Fue sencillo llevar adelante la construcción de un producto con piezas Lego dentro del
entorno de trabajo.* Required

14 - En el comienzo del desarrollo, me resultó difícil establecer los artefactos, tales como:
el panel con la lista de todo lo que podría necesitarse en el producto, el panel de tareas a
atacar en un sprint, el panel de estimación de tareas y demás.* Required

15 - Me pareció satisfactoria la experiencia de aprendizaje utilizando juegos de

construcción en la Metodología Scrum.* Required

16 - Fue complicado comunicarme con el cliente para obtener información acerca de sus
requerimientos. * Required

17 - Comprendí la Metodología Scrum fácilmente.* Required

18 - Todos los artefactos necesarios para llevar acabo correctamente las prácticas de
Scrum se encontraron disponibles.* Required

19 - Es posible aplicar la metodología Scrum con todas sus características.* Required

140
20 - Si tuviese que realizar un proyecto de mayor envergadura, sería fácil incorporar nuevas
piezas Lego.* Required

21 - La generación de bloques necesarios en la construcción para una determinada tarea,

fue un problema constante.* Required

22 - Me resulto sumamente difícil la integración de cada tarea en un solo producto final.* Required

23 - La comunicación necesaria para realizar la planificación fue ordenada y suficiente.* Required

24 - No hubo dudas sobre los temas a desarrollar en dicha reunión de retrospectiva.* Required

25 - Fue fácil reusar algunas piezas Lego previamente construidas.* Required

26 - Las reuniones diarias, realizadas cada 40 minutos, no fueron una tarea sencilla.* Required

27 - Fue claro asociar el requerimiento del cliente a las tareas definidas.* Required

28 - Fue fácil desarrollar una reunión de retrospectiva al final del Sprint. * Required

29 - En general, el entorno de trabajo facilitó llevar a cabo Scrum.* Required

30 - Me resulto sencillo visualizar el estado de las tareas de mis compañeros.* Required

31 - Fue sencillo para el equipo mostrar el avance del desarrollo al cliente. * Required

32 - El curso no contribuyo a mi trabajo actual, ni tampoco a mi carrera profesional.* Required

33 - Resulto sencilla la distribución de Tareas en los miembros del equipo.* Required

141
Bibliografía
Agiles, P. (2002). Obtenido de http://proyectosagiles.org/

Ambler. (2002). When Is a Model Agile? New York: John Wiley & Sons Publishing.

An, Kim, & Kim. (2008). Teacher perspectives on online collaborative learning: Factors perceived
as facilitating and impeding successful online group work.

ArgentinaVirtual. (1999). Obtenido de http://argentinavirtual.educ.ar/localhost/index.html

Barreiro, E. &. (2009). Experiencias en la Docencia con Mundos Virtuales. Actas del Congreso
FINTDI. Presented at the Congreso FINTDI (Fomento e Innovación con Nuevas
Tecnologías en la Docencia de la Ingeniería). Vigo, España.

Béatrice, M. (July 2008). Another Time, Another Space: Virtual Worlds, Myths and Imagination.

Beetham. (2000). Rethinking Pedagogy for a Digital Age: Designing and Delivering E-Learning.
London: Routledg.

Boeham, B. P. (2001). "Developing Groupware for Requeriments Negotiation: Lessons Learned

Learned," IEEE Sofware.

Boehm. (1976). Software Engineering, IEEE Transactions on Computers, 25(12).

Borges. (2009). Profcast: Aprender y enseñar con podcast. Barcelona: Editorial UOC.

Botia, & Alfonso. (2005). An iterative and agile process model for teaching software engineering.
In: 18th Conf. Softw. Eng. Train., pp.9-16 .

Brodlie, El-Khalili, & Ying Li. (1999). Using Web-Based Computer Graphics to Teach Surgery.
Position Paper for GVE99. Coimbra, Portugal.

BROUGERE, G. (2008). Jogo e Educação. Porto Alegre: Artes Médicas.

Bruner. (1986). Juego, pensamiento y lenguaje. Perspectivas. V, XVI, 1, 79-85.

Carey, & Bell. (1997). The VRML 2.0 Reference Manual.

Casamayor. (2008). La Formación online. Una mirada integral sobre el e-Learning, b-Learning.
Graó. Barcelona.

Castells. (1996). The Rise of the Network Society. The Information Age: Economy, Society and
Culture. pp. 412-23.

Castells. (2000). "Internet y la Sociedad Red". Lección inaugural del programa de doctorado
sobre la sociedad de la información y el conocimiento en la Universidad Oberta de
Catalunya (UOC).
142
Castronova. (2001). Virtual Worlds: A First-Hand Account of Market and Society on the Cyberian
Frontier.

Cohn. (2006). Agile estimating and planning. RC Martin Series, Prentice Hall PTR, Englewood
Cliffs.

Damon , & Poole. (2009). Do It Yourself Agile.

DeLoura, M. (2000). Game Programming Gems.

Deshpande, A. A. (2011). Simulation games in engineering education: A state of the art review.
Computer Applications in Ingineering Education, 19(3), 399-410. doi10.1002/cae.203223.

Donizetti Zorzo, S. d. (2013, October). Using scrum to teach software engineering: A case study.
In Frontiers in Education Conference, 2013 IEEE (pp. 455-461). IEEE.

E. Gamma, R. H. (1995). Design Pattem.

Eberly. (2000). Game Engine Design: A Practical Approach to real-Time Computer Grapchics. CA:
Morgan Kaufmann, 2000. San Francisco.

Fainholc. (2008). PROGRAMAS, PROFESORES Y ESTUDIANTES VIRTUALES. Una sociología de la

educación a distancia. Buenos Aires: Santilhana.

Fernandes, & Sousa. (2010). PlayScrum - a card game to learn the Scrum agile method.

Ferrer. (2003). Metodologías Ágiles. Sitio

http://libresoft.dat.escet.urjc.es/html/downloads/ferrer- 20030312.

Foundation, A. T. (2007). Obtenido de www.apache.org/

Fowler. (2000). The New Methodology. http://martinfowler.com/articles/newMethodology.html.

Freitas, S. D. (2008). Serious virtual worlds. A scoping study, Prepared for the JISC e-learning
programme. Document No 480 Version 1.1.

Garaigordobil. (1990). Juego y desarrollo infantil. Madrid. Seco-Olea.

Garvey. (1983). El juego infantil. Madrid, Morata (Trabajo original publicado en 1977).

Gingery, T. (2009). Survey Research Definitions: Central Tendency Bias.

Giro, Leiva, & Mesa. (2001). Consideraciones acerca de XP.

Grenning. (2002). Planning poker or how to avoid analysis paralysis while release planning.
White Paper, Renaissance Sotware Consulting.

143
Gubern. (1996). "Del bisonte a la realidad virtual: La escena y el laberinto". El flujo comunicativo
de maquina a máquina. Barcelona: Anagrama.

Highsmith. (2004). Agile Project Management: Creating Innovative Products (2nd Edition).

Iabg. (2001). IABG. Obtenido de The VModel: www.vmodell.iabg.de

Ibánez, S. (2008). Innovación Educativa y Uso de las TIC. Sevilla: Universidad Internacional de
Andalucía. ISBN: 978-84-7993-055-4.

Imbernon, F. (2007). 10 ideas clave. La formación permanente del profesorado. Nuevas ideas
para formar en la innovación y el cambio.

ISISTAN, U. (2010). Obtenido de taller.isistan.unicen.edu.ar/U3D/WebPlayer.html

Jimenez Diaz, G. C. (2011). Role-play virtual worlds for teaching object-oriented design: the
ViRPlay development experience.

Jones. (1995). Virtual reality applications. London: Academic Press.

K., B. (s.f.). Extreme Programming Explained: Embrace Change. San Francisco: Addison-Wesley.
Obtenido de http://argentinavirtual.educ.ar/localhost/index.html

Krivitsky. (2009). Product-Oriented Scrum Simulation with LEGO Bricks. lego4scrum.com.

Kropp, & Meier. (s.f.). Teaching agile software development at university level: values,
management, and craftsmanship. 26th Conference on Software Engineering Education
and Training. CSEE&T ’13, San Francisco, CA, US.

Krueger. (1983). Los orígenes artísticos de la realidad virtual. España, Madrid: Soc. Ed. Electa, pp.
19-20.

L. Bass, P. C. (2003). Software Architecture in Practice.

Lea, & Matsuda. (1996). Java for 3D and VRML Worlds. Berkeley, Calif.: New Riders Publishing.

Lipponen. (2002). Exploring foundations for computer-supported collaborative learning.

Department of Psychology, University of Helsinki P.O. Box 13.

López Hernández, F. L. (2009, Junio). ¿Cómo pueden aprovechar las bibliotecas los mundos
virtuales como second life? Boletín de la Asociación Andaluza de Bibliotecarios.
24(94/95), 47–57.

Lund, & Rasmussen. (2010). Tasks 2.0: Education Meets Social Computing and Mass.

Lynch, & Herold. (2011). Using a LEGO®-Based Active Game to Ground Agile Development
Principles. Rapid City, SD.
144
MacDonald. (1994). Interacting with virtual environments. Chichester: Wiley ISBN 0 471 93941.

Maher, Kourik, & Chookittikul. (2011). Reducing the gap between academia and industry: The
case for agile methods in Thailand. The Case for Agile Methods in Thailand. ITNG 2011:
239-244.

Mahnic. (2010). Teaching scrum through team‐project work: Student’s perceptions and teacher’s
observations. Eslovenia: Faculty of Computer and Information Science, University of
Ljubljana, Trzaska 25, 1000 Ljubljana.

Mahnic. (2012). A capstone course on agile software development using scrum. Slovenia IEEE
Transactions on Education (Impact Factor: 0.84): Fac. of Comput. & Inf. Sci., Univ. of
Ljubljana, Ljubljana.

Malajovich. (2000). Recorridos didácticos en la educación inicial.

Millard, & Essex. (2007). Web 2.0 Technologies for Social and Collaborative E-Learning. In T.
Bastiaens & S. Carliner (Eds.).

Möller, & Hainer. (2008). Real-Time Rendering. CRC Press, ISBN 1439865299, 9781439865293.

Montero, & Fernandez. (2003). Guía de Evaluación Heurística de sitios web. No Solo Usabilidad,
nº 2, 2003. <nosolousabilidad.com>. ISSN 1886-8592.

Nielsen. (1994 April). Ten Usability Heuristics. Boston, MA,: Proc. ACM CHI'94 Conf, 152-158.

Oliveira, & Lima. (2011). State of the art on the use of scrum in distributed development
software. Revista de Sistemas e Computação, 1(2), 106-119.

P. Letelier, J. H. (2003). Metodologías Ágiles en el desarrollo de software. Alicante - España, pp.

1-8.

Paasivaara, Durasiewicz, & Lassenius. (2009). Using scrum in distributed agile development: A
multiple case study.

Paasivaara, Heikkilä, Lassenius, & Toivola. (2014). Teaching students Scrum using LEGO blocks.
ICSE Companion: 382-391.

Paasivaara, Lassenius, Damian, Raty, & Schroter. (2013). Teaching students global software
engineering skills using distributed Scrum. Finland: Helsinki University of Technology.
P.O.Box 9210 FIN-02015 TKK.

Piaget. (1979). La formación del símbolo en el niño. México: Fondo de Cultura Económica. ISBN:
9789681602703.

145
Prendes, & Cabero. (2007). Internet aplicado a la educación: estrategias didácticas y
metodológicas. Nuevas Tecnologías Aplicadas a la Educación. Madrid: McGraw-Hill; p.
205-22.

Ramingwong, & Ramingwong. (2015). Plasticine Scrum: an alternative solution for simulating
Scrum software development. Lecture Notes in Electrical Engng. 339, 851-858.

Reichlmayr. (2011). Working towards the student Scrum - developing agile Android applications.
Canada: Proc. 118th ASEE Annual Conf. and Exposition, Vancouver.

Ridderstrale. (2002). Business:Talent Makes Capital Dance. Financial Times/Prentice Hall.

0273659073, 9780273659075.

Rodriguez, Soria, & Campo. (2012). Virtual Scrum A Teaching Aid to Introduce Undergraduate
Software Engineering Students to Scrum.

Roehl, Couch, Ballerich, & Reed. (1997). Late Night VRML 2.0 with Java, Ziff-Davis Press,
Emeryville.

Ruiz, G. (1998). Panorama General de las Aplicaciones de la Realidad Virtual en la Educación.

Obtenido de http://www.cogs.susx.ac.uk/users/miguelga/espaniol.htm

Rumbaugh, G. B. (1999). The Unified SoftwareDevelopment Process. Addison-Wesley

Professional, ISBN 0-201-57169-2.

Saenz. (2007). Una experiencia de capacitación del profesorado para la nueva formación. Revista
Iberoamericana de Educación. Obtenido de
http://www.rieoei.org/deloslectores/1766Castro.pdf

Scharf, & Koch. (2013). Scrum in a software engineering course: an in-depth praxis report. San
Francisco, USA: Proc. 26th Conf. on Software Engng. Educ. and Training.

Schneider. (2011). Goals of Educational Technology.

Schwaber. (2004). Agile Project Management with Scrum. Microsoft Press; 1 edition. ISBN-10:
073561993X, ISBN-13: 978-0735619937.

Schwaber, & Beedle. (2002). Agile software development with scrum. Prentice Hall. ISBN-10:
0130676349, ISBN-13: 978-0130676344.

Scott, Rodriguez, Soria, & Campos. (2014). Are learning styles useful indicators to discover how
students use Scrum for the first time? Computers in Human Behavior, 36, pp. 56-64.

SFS2X. (1999). Obtenido de smartfoxserver.com/

146
Sherman, & Judkins. (1994). Glimpses of heaven, visions of hell: virtual reality and its
applications. London: Hodder and Stoughton.

Shin, Y. (2002). Virtual Reality Simulations in Web-Based Science Education, Computer

Applications in Engineering Education. 10(1), 18-25. doi:10.1002/cae.10014.

Soria, A., & Rodriguez, E. (2010). Virtual Scrum: Un groupware para dar soporte a reuniones
virtuales en Métodos Ágiles. Buenos Aires: SADIO.

TastyCupcakes. (2008). Obtenido de

http://tastycupcakes.org/2013/03/the-high-risk-airplane-factory/

TastyCupcakes. (2008). Obtenido de

http://tastycupcakes.org/2014/01/scrum-roles-and-responsibilities-game/

TastyCupcakes. (2008). Obtenido de http://tastycupcakes.org/2013/04/the-risk-is-in-the-blocks/

TastyCupcakes. (2008). Fuel for invention and learning.

Toro, A. D. (2013). El juego como herramienta educativa del Educador Social. Consejo General de
Colegio Oficiales de Educadoras y Educadores Sociales RES. Revista de Educación Social.
ISSN: 1698-9097.

Tortoise-SVN. (2003). Obtenido de tortoisesvn.net/

Von Wangenheim, Savi, & Borgatto. (2013). SCRUMIA - an educational game for teaching
SCRUM in computing courses. Journal of Systems and Software, 86(10).

Vygotsky. (1933). El juego y su función en el desarrollo psíquico del niño. Instituto Pedagógico
Estatal de Hertzsn en 1933, Leningrado, en R. Grasa, Cuadernos de Pedagogía, 85, 39-49.

Walsh, Bourges, & Sevenier. (2000). Core Web 3D. Prentice Hall PTR, 2000. ISBN 10: 0130857289
/ ISBN 13: 9780130857286.

Warwick. (1993). Realidad Virtual en Ingeniería, Peter Peregrinus.

Watt, & Policarpo. (2000). 3D Games Volume 1: Real-timeRendering and Software Technology.

WEB3D. (1997). Obtenido de http://www.web3d.org

Wrzesien, & Alcañiz Raya. (2010). Learning in serious virtual worlds: Evaluation of learning
effectiveness and appeal to students in the E-Junior project, Computers & Education. In
Frontiers in Education Conference, 2013 IEEE (pp. 455-461). IEEE.

147
148