En esta entrada voy a hablar sobre las metodologías ágiles de trabajo y cómo he introducido algunas características de una de ellas en mis clases de tecnología. El tema daría para escribir un libro, por lo que estaré encantado de ayudar a cualquiera que quiera profundizar en alguna cuestión o tenga preguntas tras leerlo.
Empecemos hablando de SCRUM...
Imaginad que una empresa tiene que desarrollar un producto de software pero el cliente no tiene del todo claro lo que quiere o tiene ideas poco definidas. Para afrontar los procesos de creación de este tipo de productos muchas empresas acuden a metodologías ágiles de trabajo. Mediante las mismas pueden ir creando un producto mano a mano con el cliente, verificando en periodos cortos de tiempo la idoneidad del mismo y dejando cierto margen a redefinir sus características.
Las metodologías ágiles han demostrado tener una gran utilidad en muchos procesos de creación de productos, especialmente en el mundo de la tecnología. Fruto de mi (corta) experiencia usándolas surgió en mí la inquietud de trasladar lo aprendido al entorno educativo y he estado probado y meditando sobre una metodología concreta: SCRUM.
Antes de comenzar diré que no voy a profundizar en cómo es SCRUM a nivel profesional, para ello recomiendo leer alguna de las muchas entradas que existen en internet explicando sus características y cómo llevarlo a cabo.
SCRUM es un modelo de trabajo basado en una serie de prácticas y roles que tratan de ayudar a la realización de un proyectos. Por resumir de una forma muy sencilla sus características podríamos enumerar por un lado las prácticas y por otro los roles:
Roles
- Product Owner: es el dueño del producto. En un entorno profesional será el cliente que encarga el producto o un representante de la empresa que encarga el producto.
- SCRUM Máster: persona que, siendo parte del equipo de trabajo, se encarga del contacto con el Product Owner y trabaja en pro de la eliminación de los obstáculos que dificulten el avance del equipo de trabajo. Es un rol sumamente importante porque busca aislar al equipo de trabajo y protegerlo del cliente.
Prácticas
- Todo el camino hasta la realización de un proyecto se divide en etapas más cortas de trabajo, denominadas sprints. En el entorno laboral un sprint suele tener una duración de un par de semanas.
- Al comenzar un sprint se realiza una reunión, llamada planificación del sprint, en la que se organiza el trabajo que se acometerá en el sprint. En la misma el equipo SCRUM decide cuales de todas las características que tendrá el proyecto acometerán durante el sprint.
- Cada día se realiza una reunión breve, llamada daily, en la cual el equipo, en no más de 15 minutos, debe hablar sobre lo que se va a hacer, lo que se hizo en la jornada anterior y los problemas aparecidos.
- Al terminar un sprint se realiza una revisión del sprint para ver el cumplimiento del trabajo que se había comprometido en la reunión de inicio del sprint y se entrega el trabajo realizado al product owner.
- Por último, existe una reunión denominada retrospectiva del sprint que busca una mejora contínua del proceso analizando los problemas surgidos y buscando que no ocurran en futuros sprints.
Lo interesante de los sprints es que no se asemejan a los hitos clásicos de un proyecto, es decir, no son fases significativas en las que se termina alguna tarea o parte de un proyecto. El objetivo de los sprints es que terminen con un producto que pueda ya ser entregado al cliente. El primer sprint debe terminar con algo que pueda ya ser probado o entregado al cliente y que tenga algunas características claves del producto encargado.
Una vez terminado el primer sprint, el resto de sprints son iteraciones del producto en las cuales se trata de introducir mejoras o nuevas funcionalidades y van haciendo crecer el producto con un continuo feedback del Product Owner.
Este proceso permite que el cliente pueda estructurar mucho mejor el producto que quiere y conocer cuales son sus necesidades reales, probándolo, trabajando con él, viendo cuales de las características iniciales eran acertadas y cuáles no eran tan necesarias, cambiandolas por otras más necesarias que no habían tenido en cuenta.
Es importante destacar que los productos que van a ser creados usando SCRUM son definidos por sus características (por así decirlo, sus funcionalidades), a las cuales se les añade un valor o nota que trata de marcar su relevancia. Esto permite ver cuales son las características que, acometiéndose primero, permiten mayor progreso sobre el total del producto. Puede que dos características acaparen el 80% del valor de un producto y el 20% restante lo formen un grupo mayor de características. No vamos a hablar más sobre ello, pero en SCRUM a nivel profesional es un elemento muy importante.
Y si hablamos de educación… ¿cómo usamos SCRUM?
Para empezar es importante entender que SCRUM es una metodología ágil de trabajo que busca mejorar los procesos para concluir un proyecto que no está muy definido o claro. El objetivo es conseguir un proceso de trabajo que facilite un proyecto mutable que pueda convertirse en algo que realmente satisfaga las necesidades que iniciaron todo el proceso de creación.
Por lo tanto, trasladar la esencia de SCRUM a educación puede ser buena idea como forma de trabajar en el aula para proyectos que no están claramente definidos. Esto quiere decir que no es útil si queremos realizar un proyecto del cual ya se ha trasladado a los alumnos todo aquello que necesitamos del mismo de una forma clara y no hay mucho margen a los cambios. Sin embargo, puede ser una gran ayuda en proyectos que buscan satisfacer una necesidad o resolver un problema pero en los cuales no está muy clara la forma en la que se va a conseguir ni las características idóneas que debe tener el proyecto.
El grado en que se aplique SCRUM viene determinado por la edad de los alumnos, la experiencia trabajando en equipo de los mismos, sus habilidades de trabajo por proyectos y la propia destreza del docente gestionando un trabajo por proyectos.
Procedo a comentar brevemente cómo he organizado el trabajo con alumnos de últimos cursos de secundaria en mis clases de tecnología:
Para comenzar, suelo hacer grupos de trabajo de 4 o 5 alumnos. Lo habitual es que haga equipos aleatorios, aunque existen muchas maneras de agrupar a los alumnos.
Roles
- Product Owner: este rol lo adquiere el profesor. Es el cliente que encarga a un grupo de alumnos el proyecto y el encargado de verificar en las revisiones de los sprints cómo va el proceso.
- SCRUM Máster: este rol debe tomarlo uno de los miembros del equipo de trabajo (uno de los alumnos) y será el facilitador del proceso. Esto no quiere decir que tome las decisiones, quiere decir que será el que busque soluciones si hay algo que no está saliendo bien, el que acuda a pedir ayuda (habitualmente al profesor).
Prácticas
- Sprints: el tiempo destinado a crear el proyecto debe ser dividido en parcelas temporales más cortas. Inicialmente, en un proceso de diseño del proyecto, los alumnos deben definir las tareas que hay que hacer hasta concluir el proyecto. Posteriormente, al iniciar cada sprint, deberán decir cuales de todas las tareas llevarán a cabo, intentando satisfacer la idea de que desde el primer sprint hay que conseguir algo terminado y mostrable al product owner. Es muy habitual que, especialmente si los alumnos no han trabajado gestionando su propio trabajo, se les olviden muchas tareas que deberán incluir cuando se den cuenta que son necesarias. Una buena práctica es pedir, con un sprint cero, una entrega con el diseño del proyecto y una descripción de todas las tareas que hay que hacer, para poder ayudar en caso de detectar que faltan tareas o están poco definidas.
- Definición del sprint: al comenzar cada sprint se debe dejar un tiempo para cada equipo organice el sprint, vea qué tareas se comprometen a realizar y quienes van a realizarlas. Obviamente las primeras veces suelen tener dificultades serias para cuantificar lo que pueden hacer, por lo que asumirán que son capaces de hacer más de lo que realmente pueden hacer o bien se quedarán cortos en su estimación.
- Daily: la reunión inicial de cada clase en la que se va a trabajar en el proyecto debe tener una duración definida. Personalmente, una vez ya tienen definido el sprint, les doy cinco minutos (poniendo un cronómetro en marcha) para hablar de lo que está hecho y lo que se va a hacer y trasladar al SCRUM Máster los problemas que han surgido. Hasta que no terminan esos cinco minutos no pueden coger material para trabajar.
- Revisión del sprint: cuando acaba un sprint deben presentar (o, mejor dicho, presentarme) el trabajo realizado y es ahí donde se debe ir reconduciendo el proyecto si no va en buen camino o dando sugerencias de mejora si todo sigue el rumbo correcto. También es un muy buen momento para evaluar el trabajo e ir obteniendo notas parciales que puedan ayudar a calificar el proceso seguido.
Todo lo anterior es un marco, un modelo de trabajo que puede favorecer la finalización de un proyecto, pero que requiere mucho trabajo para adaptarlo a cada situación concreta, a cada proyecto y a cada aula.
Mis objetivos a la hora de utilizar SCRUM en mis clases de tecnología son, principalmente, acostumbrar a mis alumnos a autogestionarse, a saber establecer sus propios ritmos de trabajo y a mejorar la forma en que se relacionan con sus compañeros para mejorar el trabajo en equipo.
Mi experiencia ha sido positiva, aunque reconozco que hacen falta varios años para que un grupo de alumnos logre adquirir esta filosofía y pueda trabajar con soltura según estas directrices.
