Índice:

Jus�ficación e introducción 3

Desarrollo 6

Contextualización 6

Competencias y contenidos didác�cos a desarrollar 9

Metodología 10

2.3.1 Fase de aprendizaje individual 11

2.3.2 Fase de desarrollo en equipo 14

Infraestructura 18

Materiales didác�cos 20

Evaluación 20

2.8.1 Trabajo individual 20

2.8.2 Trabajo en grupo 22

Retrospec�va y debates 24

Conclusiones y propuestas de futuro 25

Referencias bibliográficas 26

Anexo 27

1. Jus�ficación e introducción “La ingeniería del so�ware ha cambiado para siempre” dice Javier Garzás en su

libro Ges�ón de proyectos ágil (Garzás, 2014). Las metodologías de desarrollo ágil

llevan algunos años abriéndose paso en las empresas de so�ware como respuesta a las

metodologías clásicas. Éstas estaban basadas en el flujo de trabajo de otro �po de

ingenierías o disciplinas, como el desarrollo en cascada. Además, generaban una serie

de problemas en el desarrollo de so�ware, como retrasos interminables y parches de

úl�ma hora que intentan solucionar problemas y, en muchas ocasiones, creaban más

errores de los que arreglaban.

Las metodologías ágiles de desarrollo están ampliamente implantadas en las

empresas de so�ware y han supuesto una revolución en la forma en la que se crean los

programas, impulsando la adopción de nuevas formas de trabajar en el sector de la

programación.

En 2001, un grupo de grandes nombres dentro del desarrollo de so�ware,

firmaron el llamado Agile Manifesto (Benck K., et al, 2001) donde se establecen los

puntos de lo que debía ser el desarrollo de so�ware y que se resumen en estos 4

pilares:

- Individuos e interacciones sobre procesos y herramientas.

- So�ware funcionando sobre documentación extensiva.

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

- Respuesta ante el cambio sobre seguir un plan.

Para poder llevar a cabo estas premisas se desarrolla una metodología de

trabajo que pretende tener un contacto directo con el cliente y realizar avances

durante pequeños periodos de �empo, llamados sprints, en los que, al final de los

mismos, se tenga una funcionalidad nueva o un incremento significa�vo del producto

so�ware.

Además, el código, independientemente del lenguaje de programación, debe

ser limpio, elegante, entendible y mantenible en el �empo (Mar�n, R., 2009). El

desarrollo debe estar guiado por test que garan�cen el buen funcionamiento y que nos

permitan crear el programa con la seguridad de que, superando los test, no se van a

producir errores colaterales

¿Pero qué ocurre con la enseñanza de la programación? Si grandes nombres del

desarrollo de so�ware, como los que firmaron el Manifiesto Ágil, recomiendan la

implantación de estas metodologías en las empresas de so�ware ¿por qué no empezar

desde las aulas?

Entre los valores que aporta el desarrollo ágil (Mar�n, R., 2020) se destacan 3:

la comunicación del equipo, el feedback y la simplicidad. Estos 3 valores coinciden

plenamente con algunas de las competencias transversales que se deben adquirir en

las aulas por lo que, aplicar metodologías ágiles en la enseñanza consigue que , de

forma inconsciente, el alumnado adquiera habilidades que le serán de gran valor en

su carrera personal y laboral.

Según la taxonomía de Bloom que hemos podido ver a lo largo del máster, y

que jerarquiza acciones según su efec�vidad en el aprendizaje, comprobamos que

Analizar, Evaluar y Crear están en lo alto de la pirámide. Por lo que, si enseñamos al

alumnado a analizar el problema, evaluar las opciones y crear el so�ware, el

aprendizaje de la programación será mucho más efec�vo que si realizamos

explicaciones magistrales en base a unos apuntes. De nuevo las metodologías ágiles

nos aportan una estrategia para organizar el flujo de trabajo que nos permita llevar a

cabo estas acciones, facilitando con ellas la comprensión de los contenidos.

Imagen 1: taxonomía de Bloom. Fuente: h�p://marian81fc.blogspot.com/2016/11/taxonomia -de-bloom.html

La propuesta de implantar en educación metodologías de desarrollo Ágiles,

como Scrum, se encuadra en las llamadas Metodologías Ac�vas de Aprendizaje , en las

que el alumnado es el protagonista, situándose en el centro de la acción, y adquiriendo

habilidades transversales además de conocimientos. En defini�va, el alumnado

aprende más y mejor, (Mosquera, I., 2020)

Podemos encontrar ya aplicaciones de Scrum en diferentes lugares, como las

clases ágiles que propone Gema Albaladejo en Cataluña (Albaladejo, G., 2021), que

aplica Scrum para que los grupos de estudiantes creen y organicen las tareas del

temario. De esta forma ellos eligen los contenidos por los que quieren empezar. Los

grupos se forman favoreciendo la diversidad, tal y como se puede ver en la Imagen 2.

Su metodología la aplica en alumnos de primaria y secundaria y las principales

adaptaciones que ha hecho es que las figuras del Product Owner y el Scrum Master se

fusionan en el profesorado.

Imagen 2: Organización de los grupos y tareas de Gema Albaladejo Fuente: h�ps://www.youtube.com/watch?v=_uZKpDKd0Gc

En EEUU encontramos los trabajos de Jochen Krebs (Krebs, J., 2018) y Pam

McMar�n (Mar�n, P., 2019) que de nuevo aplican el trabajo en grupo y la división de

tareas para ir desarrollando los obje�vos de aprendizaje.

En el presente trabajo se expone cómo aplicar la metodología Scrum para la

enseñanza de la programación, planteando que el rol de Product Owner sea llevado a

cabo por el profesorado y el de Scrum Master por el alumnado . Además, el

aprendizaje de la programación se compagina con otros contenidos , muy importantes

dentro del desarrollo ágil de so�ware, como es el aprendizaje de Clean Code, los

principios SOLID y el uso de repositorios .

La adquisición de estos conocimientos y buenas prác�cas desde el principio

propiciarán que su aprendizaje sea mucho mejor y eviten vicios que entorpecen el

desarrollo ágil. Se puede encontrar más información en el Anexo I.

2. Desarrollo

A con�nuación, se definen los diferentes términos que se usan a lo largo del

trabajo, las competencias que se adquieren, la metodología y evaluación, como los

aspectos más destacables.

2.1. Contextualización

Antes de plantear la metodología ágil es conveniente definir los términos con

los que vamos a trabajar. En nuestro caso, nos vamos a basar concretamente en el

funcionamiento de Scrum.

- Historias de Usuario: son las acciones que realiza un usuario al ejecutar un

programa. Se definen mediante la frase “yo como usuario quiero…” y se

completa con la acción que se quiere desarrollar. Está acción es una nueva

funcionalidad del so�ware, por tanto, definir una Historia de Usuario es

equivalente a definir una nueva funcionalidad. En nuestro caso, durante la fase

de aprendizaje, las Historias de Usuario representan las Unidades de Trabajo ya

que añaden un conocimiento más a la asignatura, como lo haría una

funcionalidad a un programa. En la fase de desarrollo, las Historias de Usuario

corresponden a las funcionalidades que deberá tener el proyecto propuesto.

- Producto Mínimo Viable (MVP en inglés): es el so�ware con el mínimo número

de funcionalidades que el equipo considera que va a tener. A par�r de ese MVP,

el resto de las funcionalidades serán nuevas mejoras que tendrá el programa.

Consideraremos Producto Mínimo Viable a los contenidos mínimos que se

deben tratar en la Unidad de Trabajo y a los obje�vos mínimos que tendrán que

alcanzar el alumnado.

- Sprint: es el periodo de �empo en el que se realizan las tareas. Lo establece el

equipo de desarrollo y suele ser fijo, normalmente de 2 semanas. De esta forma

organizan el trabajo alrededor de esas 2 semanas y establecen las tareas que se

van a llevar a cabo, siempre teniendo en cuenta que al final, el producto debe

haber sido incrementado con alguna funcionalidad nueva. En el caso de una

Unidad de Trabajo, el sprint se define como el �empo que cada Unidad de

Trabajo �ene programado.

- Tareas: son las diferentes partes que habrá que programar para completar una

funcionalidad nueva. Para una nueva Unidad de Trabajo se definen las tareas

como las diferentes secciones del contenido de esa unidad.

- Test: es la prueba que �ene que pasar una tarea para considerarla terminada.

Durante el curso, los test son las pruebas de evaluación del so�ware que

necesita pasar el alumnado para considerar superada la unidad de trabajo en

curso.

- Product owner: normalmente se define así a la persona que representa al

cliente o usuario del programa. El Product Owner es el encargado de escoger,

entre las diferentes Historias de Usuario pendientes, las que se van a realizar en

el siguiente sprint. En nuestro caso, el papel del Product Owner lo desempeña

el propio profesor, ya que es el que establece las Unidades de Trabajo que se

dan en cada momento, o las funcionalidades que �ene el proyecto que se

proponga en la fase de desarrollo.

- Scrum Master: es la persona del equipo que �ene relación con el Product

Owner y realiza la comunicación entre éste y los desarrolladores, para agilizar la

elección de nuevas Historias de Usuario, valorando el coste que el equipo de

desarrollo establece. Además, es la encargada de facilitar y solucionar los

problemas que puedan surgir a lo largo del sprint y mantener al equipo de

desarrollo contento y mo�vado. Al empezar el sprint, se escoge a una persona

para este rol entre los miembros de cada grupo . Serán las personas encargadas

de asegurarse de que el resto de los compañeros y compañeras, como si de un

equipo de desarrollo se tratara, están realizando de forma correcta las

diferentes tareas, y ejercerán de interlocutores entre el alumnado y el

profesorado. Paralelamente, prestará atención al estado de ánimo del equipo y

proporcionará facilidades para mantener un buen estado de ánimo y la

realización de las tareas.

- Tablero Scrum de tareas: aunque hay muchas variantes, en este caso vamos a

definir un tablero con una columna con las tareas pendientes (TO DO), otra

columna con las tareas que se están realizando en ese momento (DOING) y las

tareas completadas (DONE). Este tablero permite ver de una vez la evolución

del sprint y la situación de cada tarea.

- Sprint Planning: es la reunión que se realiza al principio del sprint y �ene como

obje�vo definir y explicar la nueva Historia de Usuario que se va a desarrollar,

desglosarla en las tareas que se van a realizar y definir los test que deberán

superarse al final del sprint. Además, se rellena el tablero Scrum, mencionado

anteriormente, con las diferentes tareas.

- Reunión Retrospec�va: se realiza en la úl�ma clase de cada sprint y su obje�vo

es evaluar cómo ha ido la UT, las dificultades que se han encontrado, las cosas

que se pueden mejorar y qué medidas hay que tomar en cada caso. Además, se

realizará una evaluación de la labor del profesorado con el fin de mejorar en

cada sprint.

- Calendario Niko - Niko : es un calendario en el que cada persona del equipo de

trabajo dibuja una cara, al empezar la sesión y al terminar, en el día

correspondiente. Esa cara refleja su estado de ánimo siendo sonriente si se

encuentra muy bien, neutra si está normal o triste si no se encuentra bien de

ánimo. El obje�vo de este calendario es mostrar cómo se siente el equipo y la

evolución que �ene a lo largo de la clase y de las semanas. Una de las labores

del Scrum Master es interpretar y comentar los aspectos destacables del estado

de ánimo de los miembros del equipo y buscar soluciones que mejoren la

situación o que la mantengan, si es posi�vo.

2.2. Competencias y contenidos didác�cos a

desarrollar

El elemento más importante de las metodologías ágiles es el equipo de

desarrollo , por ese mo�vo se pone mucho esfuerzo en el bienestar de sus miembros.

Un equipo mo�vado es un equipo produc�vo y muchas de las prác�cas que se realizan

están orientadas a fomentar el trabajo y el buen ambiente de las personas.

Por otra parte, las reuniones de final de sprint y retrospec�vas deben ser

momentos de puesta en común tanto de revisión y evaluación del trabajo realizado

como para manifestar cómo se han sen�do durante el sprint o los problemas que se

han encontrado. En esta reunión en concreto, el Scrum Master debe preguntar al

equipo y tomar nota de los comentarios que se hagan. Éste es un buen momento para

que el equipo responda a estas preguntas :

- ¿Qué ha ido bien durante el sprint?

- ¿Qué ha ido mal?

- ¿Qué se puede cambiar?

- ¿Qué se debe mantener?

Por tanto, aplicar metodologías ágiles desarrolla en el alumnado

competencias transversales como:

- el trabajo colabora�vo.

- la comunicación entre personas con diferentes opiniones.

- la organización del trabajo en tareas.

- la crí�ca construc�va.

- la autocrí�ca.

- el compromiso de mejorar en cada sprint.

2.3. Metodología

Se desarrollan dos fases dentro de la metodología: por una parte, la fase de

aprendizaje individual de nuevos contenidos y por otra, la fase de desarrollo en

equipo de esos contenidos, aplicados a la producción de un proyecto. La primera fase

está orientada al trabajo individual y la introducción a la programación. Durante este

periodo, el código del alumnado tendrá que superar los diferentes test propuestos y

aplicar, en la medida de lo posible, los principios SOLID y Clean Code que se explicarán

durante las clases, y son también parte fundamental del desarrollo ágil. Durante esta

fase, consideramos que el grupo de trabajo y desarrollo es toda la clase, aunque las

tareas serán individuales.

El obje�vo de la primera fase es que adquieran los fundamentos teóricos básicos de

la programación de forma individual, y comiencen a familiarizarse con la metodología

de trabajo ágil. Por este mo�vo se considera a la clase como el grupo de desarrollo y se

divide al alumnado en grupos más pequeños con un Scrum Master, para que de esta

forma se habitúen a las labores de este rol y a la comunicación en grupo.

La segunda fase tendrá como obje�vo el desarrollo de un proyecto en el que el

alumnado deberá trabajar en equipos, dividiendo las diferentes tareas entre los

miembros de cada equipo, y poniendo especial cuidado en la integración de cada

parte. El so�ware desarrollado de nuevo deberá superar los test propuestos, y se

podrán hacer sugerencias de mejoras que podrán realizar a lo largo de los sprints, y

que favorezcan la experiencia de usuario y el rendimiento del programa.

La metodología se desarrolla en los apartados siguientes pero queda resumida de

la siguiente forma:

Fase de aprendizaje individual

- El equipo de desarrollo es la clase completa. - Se eligen los Scrum Master. - Se eligen los compañeros y compañeras de cada Scrum Master. - Se definen las historias de usuario según las Unidades de Trabajo, que serán

comunes para todo el mundo, y deberán realizarse de forma individual. - Cada alumno o alumna tendrá su tablero Scrum.

2.3.1 Fase de aprendizaje individual

Las Unidades de Trabajo se organizan como Historias de Usuario para las que hay

que definir unas tareas. Éstas se irán realizando durante las clases y los contenidos

mínimos forman lo que, en metodologías ágiles llamamos Producto Mínimo Viable.

Consideramos que el alumnado al completo es un mismo equipo de desarrollo, que

trabajará siguiendo la metodología Scrum, pero teniendo en cuenta que el trabajo será

individual.

Al empezar cada Unidad de Trabajo se realiza una primera clase, o sprint

planning, para organizar el siguiente sprint. En esta primera reunión, se definen y

explican las tareas que debe realizar el alumnado para completar esa Unidad de

Trabajo - Historia de Usuario, y se escoge al alumnado que representará el papel de

Scrum Master .

Estas personas tendrán asignadas a otros compañeros y compañeras, a los que

harán un seguimiento, viendo la evolución de su trabajo individual y asegurándose de

que lo desarrollan correctamente. Además recogerán las diferentes inquietudes o

problemas que puedan surgir y tratarán de buscar una solución o lo comentarán con el

profesorado - Product Owner. El rol de Scrum Master rotará entre el alumnado en cada

nuevo sprint.

- Se establecen los test que deberá superar el so�ware que creen. - En la Retrospec�va, los y las Scrum Master recogerán los comentarios de sus

grupos y se compar�rán con el resto. - Se evalúa el trabajo del alumnado.

Fase de desarrollo en equipo

- Se divide al alumnado en equipos siguiendo la metodología DISC. - Se propone un proyecto para todos los equipos - Se definen las Historia de Usuario, tareas del proyecto y los test que deberán

superar. - Cada equipo tendrá su tablero Scrum. - El rol de Scrum Master rota entre los integrantes de los equipos. - Se recogen los comentarios a través del Scrum Master y se ponen en común en

la Retrospec�va. - Se evalúa el trabajo del grupo.

Para aportar dinamismo al sprint planning, y relajar la reunión, el alumnado deberá

escoger el nombre que tendrá el sprint que van a realizar. Tendrán 5 minutos para

ponerse de acuerdo y escoger un nombre de algún tema que les pueda gustar: música,

cine, equipos depor�vos, etc. Pasados los 5 minutos, si no han llegado a un acuerdo, el

Product Owner pondrá nombre al sprint, pero señalando que es tarea del alumnado

ponerse de acuerdo la próxima vez.

Además, para llevar un control visual de cómo va el sprint, las tareas se sitúan en

una tabla según estén pendientes ( to do ), se estén realizando en ese momento ( doing )

o se hayan terminado ya ( done ). Al estar en la fase de trabajo individual, cada alumno o

alumna tendrá su propio tablero Scrum, donde se refleja la evolución de sus tareas.

Por otra parte, en este �po de metodologías aplicadas al desarrollo de so�ware, al

mismo �empo que se definen las tareas, también se crean los test que el código �ene

que pasar durante el sprint. De forma análoga, se plantea al alumnado las pruebas de

evaluación que deberán pasar al final de la unidad de trabajo. Así los alumnos y

alumnas saben de antemano qué requisitos tendrán que superar y, puesto que la

programación es una materia eminentemente prác�ca, las competencias que deben

adquirir durante la unidad de trabajo, llegando así a los obje�vos deseados.

Por úl�mo, al final de la unidad de trabajo se realizará una reunión equivalente a lo

que en una empresa sería la Retrospec�va, donde el alumnado podrá expresar lo que

piense sobre esa unidad de trabajo, evaluando los puntos fuertes y débiles y si

necesitan que se profundice en alguna de las tareas que no ha sido bien entendida o

resuelta. Hay que tener en cuenta que en esta fase de trabajo individual, consideramos

que, aunque las tareas han sido realizadas por cada alumno o alumna, el conjunto de la

clase es el equipo de desarrollo. De este modo, los Scrum Master se juntarán con los

compañeros y compañeras que tenían asignados en el sprint y recogerán sus

impresiones. Por úl�mo, compar�rán sus conclusiones con el resto.

Como hemos dicho anteriormente, en las metodologías ágiles, el estado anímico

del equipo de desarrollo es muy importante y durante las reuniones retrospec�vas se

comentan los aspectos que el alumnado quiera destacar, incluida la crí�ca

construc�va a la labor realizada por el profesorado / Product Owner.

Ejemplo prác�co:

Una vez explicada la metodología didác�ca, se expone un ejemplo prác�co de

cómo se desarrollará un sprint. Para ello se escoge la Unidad de Trabajo relacionada

con las Funciones, y se define la siguiente Historia de usuario:

“Como usuario/a – alumnado, quiero estructurar mi código en funciones de forma

correcta .”

La unidad de trabajo �ene un �empo definido por lo que se organiza para que

ese �empo se corresponda con el �empo de sprint. Por tanto, siguiendo la

metodología Scrum, se define un sprint de 2 semanas para ella.

La Historia de Usuario se descompone en las siguientes tareas:

- Entender en qué consiste una función en C# (o el lenguaje que se imparta).

- Comprender la importancia de su uso.

- Definir una función sin parámetros de entrada.

- Definir una función sin parámetros de salida.

- Definir una función con parámetros de salida.

- Definir una función con parámetros de entrada.

- Descomponer un programa en funciones.

Y, por otra parte, se definen las ac�vidades, o test, que el alumnado tendrá que

superar durante la Unidad de Trabajo:

- Crear una función que recibe dos números enteros A y B y comprueba y

devuelve True en caso de que A sea mayor que B o False en caso nega�vo.

- Crear una función que recibe como parámetro un array de 10 números enteros

y los ordena de menor a mayor.

- Crear una función que recibe dos parámetros, un array de enteros y un número

entero. La función debe devolver el valor -1 si no encuentra ese número en el

array o, si el número está en el array, devolver su posición.

- Crear una función que recibe un array de enteros y un número entero y debe

devolver un nuevo array con el número incluido en él.

Y estos son los resultados de los test que deberán obtener en sus funciones, con

unas entradas determinadas:

- Función que compara dos números A y B y devuelve true si A > B y false en otro

caso:

o Parámetros de entrada: A == 5, B == 3. Resultado: true

o Parámetros de entrada: A == 3, B == 5. Resultado: false.

o Parámetros de entrada: A == 5, B == 5. Resultado: false

- Función que ordena un array de enteros de menor a mayor

o Parámetros de entrada: [5,3,1,2,4]. Resultado: [1,2,3,4,5]

- Función que comprueba si un número está incluido en un array y devuelve su

posición si lo encuentra o devuelve -1 si no lo encuentra.

o Parámetros de entrada: [5,3,1,2,4], 1. Resultado: 2

o Parámetros de entrada: [5,3,1,2,4], 6. Resultado: -1

- Función que recibe un array de números y un número entero y devuelve un

nuevo array, con el número incluido en él.

o Parámetros de entrada: [5,3,1,2,4], 6. Resultado: [5,3,1,2,4, 6]

Tras definir los test, se sitúan las tareas en el tablero Scrum para que puedan ser

vistas por todo el mundo y comprobar su evolución durante el sprint. Cuando un

contenido de la Unidad de Trabajo sea dado en clase, se realicen las ac�vidades

asociadas y se pase el test correspondiente, la tarea se situará en la columna DONE y

se considerará superada. El obje�vo, al final del sprint, es tener todas las tareas en esa

columna o, por lo menos, el máximo número posible.

2.3.2 Fase de desarrollo en equipo

Cuando el alumnado adquiera los contenidos básicos para poder realizar

programas sencillos, y conozca los fundamentos de la programación (variables, �pos,

funciones, etc.), se plantea el desarrollo de un producto concreto en el que puedan

poner en prác�ca los conocimientos que están adquiriendo y además, trabajar en

equipo para adquirir otras competencias: comunicación, compañerismo, integración de

tareas, llegar a consenso, respetar otras opiniones, etc.

La división del alumnado en equipos de trabajo se realiza siguiendo el método

DISC , basado en el trabajo del psicólogo William Marston y que describe David Rubiato

en su blog (Rubiato, D., 2019). Marston divide las personalidades humanas en 4 grupos

según una serie de rasgos:

- Decisión [D]. Se trata de aquellas personas que toman decisiones rápidas y se

preocupan más por los resultados que por la forma de alcanzarlos.

- Interacción [I]. Para todos aquellos que son comunica�vos, extrover�dos,

op�mistas.

- Serenidad [S]. Son individuos que saben escuchar y �enen la capacidad de

trabajar bajo mucha presión. Al contrario de los primeros, les preocupa más el

cómo que los resultados.

- Cumplimiento [C]. Siguen las reglas y son analí�cos, es decir, analizan hasta el

más mínimo detalle hasta dar con la solución que mejor les parece.

Para que el alumnado se iden�fique con alguno de estos rasgos se les

proporciona una lista de caracterís�cas de cada grupo. Deberán anotar el número de

ellas que creen que les representan, siendo el grupo que tenga el número más alto, el

que tomaremos como personalidad representa�va primaria. El listado de

caracterís�cas de cada grupo es el siguiente:

Grupo decisión [D]

Grupo interacción [I]

Una vez que el alumnado ha escogido las caracterís�cas que le definen y se ha

seleccionado su grupo de personalidad primario, se crean los equipos de trabajo,

escogiendo a un estudiante de cada �po de personalidad, para crear equipos

equilibrados. Además, se tendrán en cuenta los resultados de la primera fase de

aprendizaje, el trabajo individual , para balancear los equipos de forma que los

integrantes con mejores notas queden repar�dos y puedan ayudar a los que peores

resultados tuvieron .

Estos equipos tendrán un número ideal de 4 integrantes, pudiendo ser 3 o 5 si

el número de alumnos y alumnas nos obliga a ello. De esta forma, los equipos estarán

compuestos en cada sprint por 3 personas realizando tareas de desarrollo

exclusivamente, y una que hará de Scrum Master. y deberá compaginar esta función de

ges�ón del equipo con otras tareas de desarrollo, de menor peso que las de sus

colegas.

El rol de Scrum Master rotará entre los componentes de cada grupo a lo largo

de los diferentes sprints. Su función será asegurarse del bienestar del equipo y de

poner los medios para que las tareas planteadas en el sprint se desarrollen según lo

planificado. En caso de surgir problemas tendrán que buscar la mejor solución o

tenerlo en cuenta para los siguientes sprint. En la prác�ca, la labor del Scrum Master es

la de persona facilitadora de soluciones para que el equipo pueda completar los sprint

con éxito y, además, ser capaz de mantener el ritmo del equipo y prestar atención a su

estado de ánimo.

Grupo serenidad [S]

Grupo cumplimiento [C]

Imagen 3: Caracterís�cas de los grupos según el método DISC. Fuente: Blog de David Rubiato h�ps://davidgscom.blogspot.com/2019/07/formar-equipos.html

Para poder llevar una relación del estado del equipo, pueden usar el sistema

que les parezca más adecuado, aunque en caso de duda, se recomienda usar los

Calendarios Niko Niko. Estos calendarios consisten en una tabla, con los componentes

del equipo y los días de la semana y en él se dibujan 3 �pos de cara (sonriente, neutra

o triste), en función del estado de ánimo de cada integrante. Lo ideal es dibujar una al

entrar a clase y otra al salir, para comprobar si a lo largo de la sesión de trabajo ha

mejorado el estado de ánimo de esa persona.

Para la fase de desarrollo se propone , como proyecto para todos los equipos,

realizar una calculadora . Para ello se definen las historias de usuario que se desean y

que cada grupo escoge en sus sprint . Recordemos que estas historias de usuario

comienzan siempre por la frase “Como usuario quiero…”:

- realizar la suma de 2 números.

- realizar la resta de 2 números.

- realizar la mul�plicación de 2 números posi�vos

- realizar la mul�plicación de 2 números nega�vos.

Imagen 4: Ejemplo de calendario Niko - Niko. Fuente: h�ps://agiletrail.com/wp-content/uploads/niko-niko_calendar.png

- realizar la mul�plicación de un número posi�vo y otro nega�vo.

- realizar la división de 2 números posi�vos.

- realizar la división de 2 números nega�vos.

- realizar la división de un número posi�vo y otro nega�vo.

- realizar operaciones con más de 2 números.

- realizar raíces cuadradas.

- realizar operaciones exponenciales.

- realizar logaritmos.

- corregir el número anterior en la operación actual.

- cancelar la operación actual y empezar de cero.

- guardar el úl�mo resultado en la memoria de la calculadora.

- calcular el porcentaje de un número

Si el nivel de aprendizaje del alumnado lo permite, se definirán también

historias de usuario relacionadas con la creación de la interfaz gráfica.

Por lo tanto, a lo largo del sprint escogen las historias de usuario que van a

realizar, la dividirán en tareas, evaluando su complejidad, y las repar�rán entre los

componentes del equipo. El desarrollo del sprint se desarrolla de forma análoga a lo

explicado anteriormente, moviendo las tareas a lo largo del tablero Scrum y realizando

las diferentes reuniones.

2.4. Infraestructura

Entorno �sico:

Uno de los obje�vos de las metodologías de desarrollo ágil es mantener al

equipo mo�vado y finalizar los proyectos con éxito. Por esta razón el aula debe

favorecer la comunicación entre el profesorado y el alumnado, y entre los propios

estudiantes, cuando hagan trabajos en grupo. Para ello, se dispondrán las mesas con

diferentes configuraciones dependiendo del temario y de los proyectos que se estén

realizando. Con el fin de favorecer las explicaciones, los días en los que predomine la

teoría, las mesas se orientarán hacia el profesor para que, de esta forma, se pueda

tener una buena visión de las explicaciones. Sin embargo, los días donde deban

programar código se escogerán otras disposiciones más dinámicas, que permitan

agrupar al alumnado en el caso de realizar proyectos colabora�vos o que favorezcan su

concentración.

Es necesario disponer de un ordenador por alumno, con conexión de alta

velocidad a internet. Por úl�mo, se necesitará una pizarra digital, o proyector para

realizar presentaciones y poder visualizar mejor los ejemplos que se expliquen en clase

para que se en�enda mejor el contenido.

Entorno virtual:

Repositorio: Ya que es una herramienta muy u�lizada en las empresas y

proyectos so�ware, y aprovechando que permite hacer un seguimiento de las

diferentes actualizaciones de código, se usa un repositorio (GitHub, GitLab, BitBucket,

etc.) para almacenar el código del alumnado. Además, de esta forma se favorece que

los alumnos y alumnas se habitúen a la comunidad de desarrolladores, publicando

proyectos que puedan ser actualizados por la comunidad e incluso colaborando y

par�cipando ellos mismos en otros proyectos.

Trello o Jira: para la definición y seguimiento de las tareas se emplea so�ware

para la organización de equipos, como Trello o Jira. En el caso de Trello, es un un

tablero más sencillo de ges�onar, pero con funcionalidades más limitadas y es una

buena opción para equipos menos experimentados. Por otra parte, Jira �ene más

complejidad, pero aporta más opciones de ges�ón y configuración de los tableros. En

ambos se trata de opciones válidas, simplemente se debe usar la que mejor se es�me

en cada caso.

Aules: Debido a las ventajas que suponen las TIC en el aprendizaje colabora�vo,

se u�lizará el portal Aules, de la Generalitat Valenciana, que permite al alumno acceder

desde cualquier si�o a la plataforma, para acceder al contenido teórico.

2.5. Materiales didác�cos

Los materiales didác�cos serán complementarios a las clases teóricas y servirán

de apoyo en caso de que el alumnado necesite aclaraciones extra o profundizar en un

tema. El obje�vo de las clases teóricas es que éstas sean cortas, concisas y claras.

Deben estar ajustadas a las tareas definidas y concretar el contenido según la unidad

de trabajo que se esté impar�endo.

Algunos conceptos que se trabajan durante todas las unidades de trabajo, como

Clean Code, metodología Ágil o principios Solid, pueden ser algo di�ciles de

comprender al principio por lo que se recomendarán materiales adicionales que

complementen lo visto en clase.

2.6. Evaluación

La evaluación del alumnado se repar�rá entre el trabajo realizado

individualmente y el realizado en equipo. En cada caso se tendrán en cuenta diferentes

aspectos a los que se otorgará una puntuación que, al sumarse, conformará la nota

final. Ésta tendrá un valor máximo de 100 puntos y para considerar que se superan los

obje�vos mínimos, el alumnado deberá superar 60 puntos.

2.8.1 Trabajo individual

Como se explica en el punto 2.3.1, el aprendizaje de los diferentes

contenidos de programación estará dirigido por la superación de diversos test

que se les proporcionarán al comienzo del sprint. El obje�vo de estos test es

que el alumnado realice los diferentes ejercicios conociendo el resultado que su

código debe dar a la salida, garan�zando así que cumple el obje�vo marcado.

Además, se valorará posi�vamente que se hayan aplicado, en la medida

de lo posible, otros aspectos del desarrollo ágil como los principios Solid y de

Clean Code. De esta forma, se evaluarán diversos aspectos que favorezcan la

adquisición de competencias, por encima de la memorización de contenidos.

El trabajo individual tendrá una puntuación total máxima de 40 puntos y

una mínima de 12, siempre y cuando el alumnado no falte a clase. Su

evaluación se realizará siguiendo la siguiente rúbrica:

Excelente: 10 puntos

Bien: 7 puntos

Regular 5 puntos

Bajo 3 puntos

Test: Los test proporcionados se pasan al código del alumnado.

El código ha superado al menos el 85% de los test

El código ha superado al menos el 50% de los test

El código ha superado al menos el 30% de los test

El código no supera el 30% de los test

Scrum: El alumnado ha seguido la metodología.

Ha par�cipado en las reuniones y la retrospec�va, ha planificado las tareas y ha hecho un seguimiento del trabajo realizado en el tablero.

Ha par�cipado en las reuniones y en la retrospec�va, pero en ocasiones el tablero no se ha actualizado correctamente.

Ha par�cipado muy poco en las reuniones y la retrospec�va y el tablero apenas se ha actualizado.

No ha par�cipado en las reuniones y la retrospec�va y el tablero no se ha actualizado nunca.

Clean Code: Se aplican las directrices para realizar un código simple, limpio y fácilmente mantenible en el �empo.

Su código es muy claro, usa nombres descrip�vos, funciones pequeñas y variables bien declaradas.

Su código es bastante claro, los nombres son correctos, las funciones se pueden reducir y sus variables están bien declaradas.

El código es correcto pero los nombres no son descrip�vos, las funciones excesivamente largas y las variables confusas.

El código no es correcto, realiza operaciones innecesarias, los nombres no son descrip�vos, las funciones son muy largas y las variables están mal usadas.

Principios Solid: se aplican los principios adaptados a su nivel de conocimiento de la programación

Ha aplicado correctamente al menos los principios de: responsabilidad única, abierto a ampliación pero cerrado a modificación y de segregación de interfaces

Ha aplicado al menos: responsabilidad única, abierto a ampliación pero cerrado a modificación.

Ha aplicado al menos uno de estos principios: responsabilidad única o abierto a ampliación pero cerrado a modificación

No se cumplen ninguno de los principios Solid

De este modo, el alumnado que cumple todos los obje�vos de forma

excelente tendría 40 puntos de la nota total. Por otra parte, el alumnado que

tuviera un bajo rendimiento, pero asis�era a clase tendría 12 puntos, que

podría sumar al trabajo realizado en grupo, teniendo todavía oportunidad de

mejorar su puntuación y superar el curso.

2.8.2 Trabajo en grupo

La evaluación del trabajo en grupo se realizará teniendo en cuenta varios

factores:

- la realización de las historias de usuario programadas.

- la organización de las tareas y su seguimiento en el tablero y las reuniones.

- la coordinación del equipo para conseguir los obje�vos.

- la integración de las diferentes tareas para desarrollar el programa.

- la calidad del código.

En este caso, la rúbrica se ha dividido en cinco aspectos evaluables y tendrá un

valor máximo de 60 puntos y un mínimo de 20. Esta puntuación será la misma para

todos los miembros del equipo.

Excelente: 12 puntos

Bien: 10 puntos

Regular 6 puntos

Bajo 4 puntos

Historias de usuario: corresponden a las funcionalidades de la aplicación

Se han realizado al menos el 85% de las historias de usuario

Se han realizado al menos el 60% de las historias de usuario

Se han realizado al menos el 30% de las historias de usuario

No se han realizado al menos el 30% de las historias de usuario

Scrum: El alumnado ha seguido la metodología.

Ha par�cipado en las reuniones y la retrospec�va, ha planificado las tareas y ha hecho un seguimiento del trabajo realizado en el tablero.

Ha par�cipado en las reuniones y en la retrospec�va pero en ocasiones el tablero no se ha actualizado correctamente.

Ha par�cipado muy poco en las reuniones y la retrospec�va y el tablero apenas se ha actualizado.

No ha par�cipado en las reuniones y la retrospec�va y el tablero no se ha actualizado nunca.

Las puntuaciones de ambas rúbricas está diseñada para que queden

equilibradas y, el alumnado que haya terminado alguna de las fases con una

puntuación excelente, ya tenga la seguridad de que aprobará la asignatura .

Ejemplos:

Trabajo en equipo: se evalúa la capacidad del alumnado para trabajar en grupo y en la resolución de conflictos

El grupo ha sabido organizar el trabajo entre los diferentes componentes, en más de un 80% de los sprints, y ha sido capaz de encontrar soluciones, en las reuniones retrospec�vas, a los problemas que se han encontrado.

El grupo ha organizado el trabajo en más del 50% de los sprints y ha sido capaz de encontrar soluciones, durante las reuniones retrospec�vas, a los problemas que se han encontrado.

El grupo ha organizado el trabajo en al menos el 30% de los sprints y ha tenido algún problema para encontrar soluciones en las reuniones retrospec�vas, a los problemas que se han encontrado.

El grupo no ha sabido organizar el trabajo en al menos el 30% de los sprints y no ha sido capaz de encontrar soluciones, durante las reuniones retrospec�vas, a los problemas que se han encontrado.

Clean Code: Se aplican las directrices para realizar un código simple, limpio y fácilmente mantenible en el �empo.

Su código es muy claro, usa nombres descrip�vos, funciones pequeñas y variables bien declaradas.

Su código es bastante claro, los nombres son correctos, las funciones se pueden reducir y sus variables están bien declaradas.

El código es correcto pero los nombres no son descrip�vos, las funciones excesivamente largas y las variables confusas.

El código no es correcto, realiza operaciones innecesarias, los nombres no son descrip�vos, las funciones son muy largas y las variables están mal usadas.

Principios Solid: se aplican los principios adaptados a su nivel de conocimiento de la programación

Ha aplicado correctamente al menos los principios: de responsabilidad única, abierto a ampliación / cerrado a modificación, y de segregación de interfaces

Ha aplicado al menos: responsabilidad única y abierto a ampliación / cerrado a modificación.

Ha aplicado al menos uno de estos principios: responsabilidad única o abierto a ampliación pero cerrado a modificación

No se cumplen ninguno de los principios Solid

- una persona saca 40 puntos en el trabajo individual, pero en el trabajo en

equipo el grupo no consigue realizar bien ninguno de los apartados de la

rúbrica, pero ha asis�do a todas las clases, por lo que su puntuación en grupo

es 20. La puntuación total de esa persona será 60 y aprobará la asignatura.

- una persona �ene muchos problemas para entender la teoría y realizar

correctamente los ejercicios propuestos, pero asiste a todas las clases, sacando

la mínima puntuación, 12 puntos. Sin embargo, durante el trabajo en grupo

consigue ponerse al día, con la ayuda de los compañeros y compañeras, y el

equipo acaba teniendo una puntuación global de bien, equivalente a 50 puntos.

Al final tendrá en total una puntuación de 62 puntos, con lo que la asignatura

estará aprobada.

3. Retrospec�va y debates

Al finalizar cada sprint, tanto durante la fase del trabajo individual como

durante la del trabajo en equipo, se realizarán reuniones retrospec�vas. Estas

reuniones estarán dirigidas por el alumnado que desarrolle en ese momento la labor

de Scrum Master y tendrán como obje�vo evaluar el desarrollo del sprint. Además,

será el momento en el que el alumnado exprese qué cosas le preocupan o cómo

solucionar los problemas que hayan podido aparecer durante el sprint.

Los Scrum Master dirigen la reunión y deben recoger las ideas clave que

contesten a las siguientes preguntas:

- ¿Qué ha ido bien durante el sprint?

- ¿Qué ha ido mal?

- ¿Qué hay que mantener para el próximo sprint?

- ¿Qué hay que mejorar?

El profesorado, como Product Owner, también responde a esas preguntas,

analizando la evolución de cada estudiante durante la fase de trabajo individual, o del

grupo, a lo largo de cada sprint. Además, como el código estará disponible en un

repositorio, el Product Owner hace un seguimiento del mismo para poder hacer

valoraciones e indicaciones de mejora.

Con esta retrospec�va se recoge el feedback del alumnado para poder

evolucionar a lo largo de los siguientes sprints, y mejorar la calidad del proceso de

enseñanza - aprendizaje.

Por otra parte, tras recoger las impresiones de todas las partes, se realizará un

debate sobre los diferentes problemas que se han encontrado y las soluciones que

cada grupo ha propuesto. En este caso, no se trata de buscar la mejor solución sino de

aportar ideas que puedan ayudar a los equipos que están atascados. El obje�vo de los

debates no es la compe�ción sino fomentar la colaboración tanto dentro del equipo

como entre el resto de grupos.

4. Conclusiones y propuestas de futuro

La enseñanza de la programación, independientemente del lenguaje que se

imparta, debe incluir la adquisición de competencias transversales y so� skills, como la

comunicación, organización de tareas, trabajo en equipo, etc. Estas son muy

demandadas en el mercado laboral y, cuanto antes las adquieran, mejor.

Por ello las clases no se deben limitar a impar�r la teoría de la sintaxis y los

detalles de un lenguaje en concreto, contenido muy importante, sin duda. Las clases

deben también enseñar a trabajar según los estándares de la industria, y las

metodologías ágiles son actualmente muy importantes en el desarrollo de so�ware.

Además, aportan valores y capacidades que son muy posi�vas para el

alumnado, no solo de cara a su incorporación al mercado laboral, sino también en su

desarrollo como personas. Por este mo�vo considero que hay que introducir estas

metodologías lo antes posible para que estas so� skills se adquieran desde las aulas.

5. Referencias bibliográficas

- Albaladejo, G., (2021), Clases Ágiles, h�ps://clasesagiles.wordpress.com/

- Benk, K., et al., (2001), Agile Manifesto, h�ps://agilemanifesto.org/

- Garzás, J., (2014), Ges�ón de proyectos ágil , 233gradosdeTI

- Krebs, J., (2018), Scrum in classroom, Time for change ,

h�ps://www.scrum.org/resources/blog/scrum-classroom-part-1-�me-change

- Mar�n, P., (2019), Using Scrum in the Classroom,

h�ps://threeteacherstalk.com/2019/01/25/using-scrum-in-the-classroom/

- Mar�n, Robert C., (2000), Design Principles and Design Pa�erns .

- Mar�n, Robert C., (2009), Código limpio. Manual de es�lo para el desarrollo ágil

de so�ware., Anaya.

- Mar�n, Robert C., (2020), Desarrollo Ágil. Vuelta a las raíces., Anaya

- Mosquera, I. (2020), ¿Qué son las metodologías ac�vas? Cuatro docentes nos

las explican ,

h�ps://www.unir.net/educacion/revista/que-son-las-metodologias-ac�vas-cuat

ro-docentes-nos-lo-explican/

- Rubiato, D., (2019), Métodos para formar eq uipos en el aula ,

h�ps://davidgscom.blogspot.com/2019/07/formar-equipos.html

6. Anexo

- Clean Code : Robert C. Mar�n escribió un libro con el mismo nombre que

definió como el “Manual de es�lo para el desarrollo ágil de so�ware” (Mar�n,

R., 2009). A lo largo del libro, y con la colaboración de varios autores, se

describen buenas prác�cas de programación que facilitan la comprensión y

actualización del código. A lo largo del libro se revisan algunas reglas

tradicionales que, según Mar�n ya no �enen mucho sen�do, y se enumeran

nuevas para tratar de hacer código algo menos críp�co y mucho más

mantenible en el �empo.

Entre estas prác�cas se incluyen:

- La u�lización de nombres descrip�vos para variables y funciones que

expliquen su función por sí mismas.

- La compar�mentación de las funcionalidades en funciones métodos

muy pequeños con responsabilidades únicas.

- La división de clases grandes y complejas en otras mucho más pequeñas

y con una única responsabilidad.

- El uso de patrones de programación.

- La eliminación de los comentarios para aclarar código ya que este debe

ser claro por sí mismo.

- El procesado de errores que no traten de ocultarlos sino de ges�onarlos

bien.

- Principios Solid: fueron definidos también por Rober C. Mar�n en su ar�culo

Design Principles and Design Pa�erns y �enen como obje�vo sentar las bases

de una arquitectura de so�ware. Solid es un acrónimo formado por la primera

letra de cada principio. Son los siguientes:

- S: Single responsibility principle o Principio de responsabilidad única.

- O: Open/closed principle o Principio abierto/cerrado. Esta regla

establece que el código debe ser abierto a ampliación pero cerrado a

modificación. Es decir, la estructura de clases debe permi�r que se

puedan añadir funcionalidades nuevas, pero sin que esto afecte a todo

lo anterior.

- L: Liskov subs�tu�on principle o Principio de sus�tución de Liskov. Una

subclase debe poder ser sus�tuida por su superclase sin que el

programa deje de funcionar.

- I: Interface segrega�on principle o Principio de segregación de la

interfaz. Si una interfaz es demasiado general y hace que no todas las

clases que las usan empleen todas las funciones de esa interfaz, debe

ser dividida para que usen sólo las funcionalidades que necesitan.

- D: Dependency inversion principle o Principio de inversión de

dependencia. Se establece que las implementaciones deben depender

de abstracciones, no de concreciones ni de detalles.

Estos principios pueden ser complejos para alguien que está

aprendiendo a programar, por lo que, aplicar algunos de ellos depende del nivel

del alumnado. Sin embargo, siempre que los conocimientos sean suficientes, se

debe fomentar su uso y valorarlo posi�vamente.

- Repositorios: el uso de repositorios de so�ware ha supuesto un gran avance en

el desarrollo informá�co ya que permite desarrollar funcionalidades en

diferentes ramas e integrarlas con bastante más facilidad que con los métodos

del pasado. Ahora mismo es una tecnología imprescindible en cualquier

empresa por lo que considero que debe ser enseñada lo antes posible. Aunque

al principio puede resultar una herramienta algo confusa, su uso es tan

mecánico que rápidamente se convierte en algo co�diano por lo que, si se

enseña en las propias clases, el alumnado adquirirá muy rápidamente los

conocimientos demandados en el mundo laboral.