Scrum

Definición y aplicación

Esta es una de las muchas definiciones (opens in a new tab) que se pueden encontrar en Internet sobre Scrum:

Scrum es un enfoque ágil para el desarrollo de productos, especialmente el desarrollo de software, que es aplicable a cualquier proyecto con plazos agresivos, requisitos complejos y que sea relativamente único.

Probablemente nos hemos quedado igual... No pasa nada. Esta es la parte de CoDAvant que más se aleja de las metodologías educativas. Y es que proviene de otro mundo. Proviene del mundo de la empresa. Scrum en un marco de trabajo que se usa mucho en las empresa de desarrollo de software. CoDAvant nació como Som Divers@s, un proyecto para la FPB de Informática de Oficina, por lo tanto, el profesorado del ciclo era informático en una gran parte. Por eso, decidimos traernos el Scrum a las aulas y ver si nos ayudaba a gestionar todas las piezas del puzzle que queríamos montar.

Y lo cierto es que sí que ayuda, y mucho.

Aquí tenemos un libro llamado Scrum y XP desde las Trincheras. Cómo hacemos Scrum, pero, a menos que seas informático o tengas un especial interés, no te recomendamos su lectura. Bastante información hay en esta web como para profundizar en el Scrum más de lo necesario.

No somos los únicos a los que se les ha ocurrido usar Scrum en el aula. Existen bastes artículos en Internet sobre el tema. Al fin y al cabo, no es más que una forma de gestionar proyectos y por lo tanto puede encajar muy bien para organizar el Aprendizaje Basado en Proyectos, u otros tipos de aprendizaje no clásicos. Nosotros no somos partidarios de usar Scrum para todo, como promueven algunos de estos métodos. En CoDAvant hemos seleccionado la mínimo imprescindible que nos ayuda a organizarnos y a mejorar las habilidades del alumnado.

En esta sección vamos a contar cómo recomendamos su aplicación en CoDAvant.

Conceptos básicos

Grupos

En Scrum se trabaja en grupos. Dado que nosotros ya disponemos de nuestros grupos de base por trabajar de forma cooperativa, ya tenemos este trabajo hecho.

Sprints

Los sprints son periodos de una duración determinada en los que hay que hacer unas tareas concretas. En CoDAvant recomendamos sprints de 2 semanas (aproximadamente) de duración.

• Sesiones del sprint: En teoría, si en un día tenemos 6 sesiones de clase y un sprint son 10 días lectivos (dos semanas), cada sprint tendrá 60 horas o sesiones asignadas. Si en un sprint hay días no lectivos, habrá que restar esas horas de la duración del sprint.
• Inicio de sprint: Se recomienda, para mayor claridad del alumnado, que los sprints comiencen en lunes o primer días lectivo de la semana.
• Identificación: Se le suele asignar un número a cada sprint (S1, S2, etc.), pero, si se trabaja de forma transversal, intentando hacer coincidir tareas sobre temas concretos en sprints concretos, se les podría poner también un nombre (p.e. si usamos los ODS como hilo conductos, podría ser algo como S5: La paz mundial, S6: El hambre en el mundo, etc.).
• Sprints de evaluación: Como se explica en el apartado de evaluación, existen un tipo de sprint llamado sprint de evaluación que tiene una duración de una semana y en el que se trabaja de otra manera. Consulta esa sección para más datos.

Tareas

Tenemos un apartado completo dedicado a las tareas, por lo que aquí tan solo daremos la información básica para poder entender el Scrum.

• Las tareas son los trabajos que debe hacer el alumnado en un sprint.
• Pueden ser transversales (más difícil y exige más coordinación) o de una sola materia o módulo. En este último caso, habrá una de ciencias, una de ofimática (p.e.), una de historia, una de FOl, etc.
• Las tareas las elabora el profesorado y tiene un enunciado, una rúbrica, recursos, etc.
• Cada tarea tiene asignadas un número de sesiones: es el tiempo que piensa el profesorado que va a tardar el alumnado en acabar la tarea (incluye tiempo de trabajo, mejora, etc.). Se debe especificar, del número de sesiones totales de cada tarea, cuantas son fijas y cuantas son flexibles.
• Las sesiones fijas de cada tarea se incluirán en el calendario del sprint.
• Las tareas pueden ser individuales o grupales.
• Además de las tareas propiamente dichas, existen otras actividades, que normalmente se indican en otro color en el calendario del sprint, que no se consideran tareas: asambleas, scrum inicial, charlas externas, etc. pero que también son importantes.

Calendario

• Calendario del curso: Se debe realizar un calendario del curso con las fechas de inicio y fin de cada sprint. Si algún sprint queda demasiado corto, o hay que hacer ajustes, se pueden cambiar estas reglas sin problemas. Podemos hacer que un sprint acabe un poco antes para compensar otro que coincide con inicio de fiestas o similar. Al final, se trata de tener sprints más o menos equilibrados.
• Calendario del sprint: Cada sprint tendrá un calendario en el que se indicará cuando son las sesiones fijas, dejando en blanco el resto (sesiones flexibles).

Es fundamental que el alumnado tenga acceso al calendario del curso y al de cada sprint para que pueda organizarse. Se recomienda usar una hoja de cálculo compartida o un sistema similar para tal fin.

Scrum Master

El Scrum Master es uno de lo roles que usamos en nuestros grupos. Este alumno o alumna es el encargado de coordinar las reuniones del Scrum, revisar el panel, hablar con el profesorado de los problemas del grupo, etc. No es un jefe. Aunque al alumnado a veces le cuesta ver la diferencia, es un coordinador/a.

Para saber cómo asignamos y gestionamos este cargo, ver la sección sobre cooperativo, apartado de roles.

Fichas de tarea y Panel de Scrum.

Las fichas de tarea son unas pequeñas fichas de papel en las que se incluyen los datos básicos de cada tarea:

• Nombre.
• Profesorado responsable
• Sesiones
• Grupo/individual
• etc.

Estas fichas pueden desecharse en cada sprint o estar plastificadas para poder reutilizarse. Se deben rellenar en el Scrum Inicial (ver más adelante) por cada grupo.

Las fichas se colocan en el Panel de Scrum o del Sprint. Cada grupo tiene su propio panel colgado en la pared junto a él. Puede ser una hoja Din A3 o A2 plastificada, una pizarra blanca o incluso una pizarra magnética. En el panel hay 4 columnas:

• Pendientes: Es dónde se colocan todas las fichas al principio del sprint. Son las tareas sin comenzar.
• En proceso: Son las tareas que ya se han empezado.
• A Corregir: Aquí se colocan las fichas de las tareas que el grupo piensa que ha finalizado.
• Terminado: Aquí van las que el profesorado ha corregido y ha dado por buenas.

Hay que resaltar que las columnas A Corregir y Terminado son importantes. Cuando el alumnado llama al profesorado para que le corrija una tarea pueden ocurrir dos cosas:

• Que esté casi perfecta o que ya no quede más tiempo de sprint para mejoras, es decir, el profesorado la da por entregada y corregida y se lleva la rúbrica. En ese caso el grupo la debe colocar en Terminado.
• Que la tarea se pueda mejorar y que haya tiempo para ello. En este caso el profesorado le deja la rúbrica a medio corregir al grupo para que vea lo que ha de mejorar y este devuelve la tarea a En proceso para seguir trabajando en ella. Esto se puede repetir varias veces en un sprint.

Toda esta gestión se puede realizar con una aplicación, como puede ser Trello (opens in a new tab), pero preferimos este sistema ya que es importante que el alumnado tenga siempre a la vista el panel y que el profesorado pueda ver de un vistazo, o paseando por el aula, cómo va cada grupo.

Queda por resolver un pequeño problema: ¿Qué hacemos con fichas de las tareas individuales? Existen dos opciones:

• Incluir en cada ficha una parte, abajo, en la que se puedan poner los nombres de los 4 miembros del grupo para marcar si está acabada o no por cada uno. La ficha solo se mueve a la columna siguiente si todos los miembros del grupo la tienen lista. Por ejemplo, para pasar a Terminado, deben de habérsela corregido a todos. El inconveniente de este sistema es que es menos gráfico.
• Tener una ficha por tarea individual para miembro del grupo. Lo recomendable es que cada alumno/a tenga asociado un color diferente, lo cual permite ver, de un vistazo, si las las individuales retrasadas son una sola persona. El inconveniente de este sistema es que puede llegar a haber una cantidad enorme de fichas en el panel y, por lo tanto, hará falta un panel muy grande.

Productos, Historias y Tareas

En el Scrum, cada tarea pertenece a un producto y a una historia. Nosotros hemos conservado la terminología, pero se podría cambiar la nomenclatura. En nuestro caso, no son más que dos niveles de agrupación de tareas, para mantener las cosas un poco organizadas:

• Producto: En el Scrum original, un producto sería, p.e., una aplicación móvil para reservar apartamentos. En nuestro caso pueden ser los módulos o asignaturas, proyectos transversales o cualquier otra cosa que decida el equipo docente.
• Historia: En el Scrum original es una característica o un módulo de la aplicación que queremos desarrollar, p.e. módulo para realizar los pagos de las reservas. En nuestro caso puede ser una agrupación dentro del producto, como temas o unidades didácticas, bloques de contenidos, partes de un proyecto o cualquier otra cosa.
• Tarea: Cada Historia tiene una o varias tareas asociadas. En el Scrum original, las Historias deben acabar en un solo Sprint, pero en nuestro caso se permite que una historia ocupe los Sprints que se desee.

Resumiendo, no son más que dos niveles jerárquicos para agrupar las tareas y su uso es totalmente opcional. En cualquier caso, pueden ser muy utiles para organizar las tareas de un proyecto ABP complejo, por ejemplo.

Forma de trabajo

Scrum inicial

El Scrum inicial es el proceso que se realiza al principio del sprint para que el el alumnado conozca las tareas y se organice. Lo mínimo que se debe hacer en este proceso es:

• Que el alumnado lea todas las tareas para saber qué va a tener que hacer en los próximos días y así, pueda planificarse. Es imposible elegir que tarea hacer en cada momento si no se sabe de que van.
• Que preparen las fichas de cada tarea y las coloquen en el panel del sprint (en la columna de Pendientes).

Scrum diario

Cada día, a las 8 de la mañana, cada grupo debe realizar la reunión de Scrum Diario. Esta reunión se debe realizar de pie, junto al panel, aunque deben tener abierto, en un ordenador cercano, el calendario del sprint y poder acceder a los enunciados de las tareas por si tienen alguna duda.

El Scrum Master es el responsable de que se realice la reunión y de coordinarla, pedir opinión y mediar. No es el que debe decidir que se hace en cada momento, eso lo debe hacer todo el grupo junto. Es habitual que la reunión degenere en esto último: uno o una, normalmente el Scrum Master, decide y a los demás les da igual. Hay que vigilar para esto no ocurra, ya que si no el alumnado no aprende a planificar. Precisamente, el aprender a planificarse, es una delas principales ventajas de esta forma de organizarse.

El alumnado dispone de una ficha de Scrum Diario, que no es más que un papel con un horario en blanco de una semana por una cara y de la siguiente semana por la otra. En cada día hay 6 casillas, una por sesión de clase.

En la reunión, mirando el panel, el calendario y el horario de profesorado (dónde se indica que profesores hay en cada sesión) deben decidir qué hacer en cada hora en función de:

• Qué tareas quedan por hacer.
• Qué profesorado viene a cada hora: si a 3ª hora viene el de ciencias, igual es mejor empezar su tarea a 2ª hora para poder preguntar dudas.
• Qué les apetece a cada hora: ¿prefieren empezar con individuales y luego pasar a grupales? ¿O quizás prefieren primero las más difíciles?
• Qué sesiones fijas hay: Lo primero que hacen es copiar las horas fijas en la hoja de Scrum Diario. En esas sesiones, no se puede planificar nada ya que todo el alumnado hace lo mismo. Los huecos que quedan después de copiar las fijas, son las sesiones flexibles disponibles para planificar.
• Qué tareas tienen plazos parciales: ¿Hay que prepararse para la práctica de mañana? ¿Hay que entregar un borrador del trabajo el viernes y estamos a jueves?
• Y muchos otros factores objetivos y subjetivos que se les puedan ocurrir.

Es recomendable que el alumnado muestre el Scrum Diario al profesorado para que este les pueda dar consejos de planificación.

No vamos a decir que el alumnado se planifica de una manera excelente, pero si que va mejorando su forma de planificar y, con el tiempo, saben si van bien o mal, si deben apretar en algo, si es mejor poner esto o aquello antes, etc. No es perfecto, pero, al fin y al cabo, ¿cuanto adultos conocemos que no se planifican ni la mitad de bien?

Actualización de los Paneles

A medida que una tarea cambia de estado, el Scrum Master debe ir actualizando el panel, moviéndola de columna. Es importante que el panel sea una foto fija del estado del sprint en cada grupo. A veces se les olvida y es misión del profesorado recordárselo frecuentemente. Basta preguntar en voz alta: "¿Están actualizados los paneles?" para que se levantes 2 o 3 Scrum Master a mover fichas.

Gestión del tiempo y responsabilidad

Es importante que tengan claro que se deben haber entregado todas las tareas en un sprint. Si tienen alguna No Presentada, se les realiza una bajada de karma importante por cada una de ellas. Obviamente, esto hace que quieran entregarlas todas a tiempo, aunque no siempre lo hagan, pero no es este el único motivo. Llegado un momento, quieren acabarlo todo por iniciativa propia. El asunto es que, sea por las notas, por costumbre,por el karma o por motivo que sea, les preocupa entregarlo todo. Esa es otra de las cosas que llaman la atención del profesorado visitante: que el alumnado se preocupa, y mucho, por acabar las tareas.

Otra cosa es que les cueste mucho dar el 100% y vayan a mínimos en lo que a calidad se refiere. Este es un problema habitual que debemos tratar por los medios habituales, utilizando los recursos normales del profesorado y otros de CoDAvant como premios de Karma, privilegios, etc.

Pero lo cierto es que les preocupa acabar. En las asambleas es habitual oir que están estresados o preocupados por que no saben si les va a dar tiempo a acabar, por que ha faltado muchos días un compañero y les está retrasando. Esto es un indicador de que, con este sistema, se preocupan por tener resultados, después de años en los que no les ha importado lo más mínimo si entendían las tareas o si hacían o no los deberes.

Es una forma muy práctica de ir aprendiendo a gestionar su tiempo y de empezar a ser responsables. No es magia, pero sí que les deja en una buena situación para cuando se enfrenten a un Ciclo Formativo de Grado Medio y tengan que empezar a funcionar solos. De hecho, aunque el nivel académico en los ámbitos sea menor, muchos y muchas llegarán mejor preparados en estos aspectos que alumnado procedente de una ESO clásica.

Labores del profesorado

Planificación previa del sprint

Antes del comienzo del sprint (preferiblemente con 2 o 3 semanas de antelación), se debe planificar el sprint siguiente en la reunión de coordinación del equipo docente.

En esta reunión previa, el profesorado debe llevar preparadas las tareas que quiere incluir en el sprint. Si las tareas aún no está finalizadas, lo cual puede ocurrir sobre todo al principio o si son de nueva creación, al menos cada profesor/a debe saber las sesiones que tendrá asignadas.

Las tareas se irán incluyendo en un listado (p.e. en una hoja de cálculo compartida), indicando las sesiones de cada una. también se incluirán las otras actividades que comentamos anteriormente (asambleas, scrum inicial, etc.) con las sesiones previstas. El total de las sesiones del sprint debe sumar lo mismo que las sesiones del sprint (60 en un sprint normal).

En caso de pasarse del total, habrá que eliminar o modificar tareas o actividades y, en caso de no llegar, habrá que añadir o ampliar tareas para que cubran todo el horario.

El decidir las sesiones que puede llevar una tarea no es algo fácil, al principio. Esta estimación es algo que se va aprendiendo poco a poco. No hay que tener miedo de equivocarse al principio, pero es importante recoger información sobre cuanto les ha llevado la tarea para poder afinar en el fututo.

No es conveniente que el alumnado se quede sin tareas a mitad de un sprint, cosa que nos ocurre a veces con algunos grupos. Si esto ocurre hay que pedirles que mejoren las tareas. Se les suele preguntar: "¿Tenéis un 10 en todas las tareas?". Si la respuesta es no, tienen que mejorarlas. En caso de no tener nada más que hacer, no está de más tener actividades de refuerzo o proyectos que puedan ir realizando.

Tampoco interesa que tengan tantas tareas que no las puedan acabar, ya que se desmoralizan.

Lo normal es que la mayoría de los grupos tenga todas o casi todas las tareas acabadas al finalizar el sprint pero que algunos no lo hayan conseguido.

Otra cuestión a tener presente es que se deben intentar equilibrar los distintos tipos de tareas:

• Grupales / Individuales: No les gusta que todas sean de un tipo ni todas de otro. Necesitan los dos tipos de trabajo para poder desarrollar distintas habilidades y no saturarse.
• Cantidad de sesiones fijas y flexibles: Hay que intentar que no tengan más de 2 o 3, como mucho fijas cada día. Este perfil de alumnado no funciona bien con las clases tradicionales. Si las fijas son prácticas y no son demasiado pasivas, podrán haber más en día de forma excepcional. Pero hay que intentar que no hay mucho días con muchas fijas. Hay más detalles sobre esto en la sección correspondiente a cuantas fijas y flexibles planificar.
• Intentar hacer alguna salida, aunque sea cerca, caminando, en cada Sprint.
• Incluir una asamblea semanal, alguna hora de dinámicas para facilitar la cohesión de pequeño grupo y gran grupo.
• Incluir tertulias.
• Etc.

Todo este trabajo de planificación se realiza los dos primeros años. En los siguientes cursos se suele reutilizar las planificaciones y las tareas de cursos anteriores en mayor o menor medida. Para más datos sobre esto, consultar las secciones de tareas y sobre cómo organizar los contenidos.

El día a día

Se debe controlar:

• Que se lean las tareas al comenzar el Sprint.
• Que se realice correctamente el Scrum Diario.
• Que se actualicen los paneles.
• Que las tareas evolucionen de forma correcta a lo largo del sprint: basta ir echando un vistazo a los paneles e ir preguntando a los grupos.

Además conviene:

• Ir recordando a los grupos aspectos importantes de nuestras tareas.
• Ir corrigiendo lo antes posible para dar la oportunidad de que presenten mejoras.