Experiencia Educativa en el aula: “Ávila en tapas”. (Capítulo 2: Metodología)

9 min readMar 25, 2022

Este artículo forma parte de una serie de artículos sobre cómo se ha desarrollado el proyecto “Ávila en tapas” en el ciclo formativo de Desarrollo de Aplicaciones Multimedia del IES Alonso de Madrigal. En esta web “Avila en tapas” puedes acceder al contenido del producto final.

Capítulos:

“Ávila en tapas”. Capítulo 1: Kickoff
“Ávila en tapas”. Capítulo 2: Metodología
“Ávila en tapas”. Capítulo 3: Desarrollo
“Ávila en tapas”: Capítulo 4: Evaluación y Calificación

Metodología aplicada al proyecto

En este artículo voy a describir la metodología seguida para la realización del proyecto. Aquí me voy a centrar en cómo han surgido las ideas, el cómo hemos propuesto las soluciones y el cómo trabajábamos semanalmente en el aula.

En el próximo artículo, me centraré en detallar cómo se ha trabajado desde el punto de vista del código.

Trabajar en equipo

Si algo tengo claro es que los alumnos deben saber trabajar en equipo. Creo que si desean progresar en el mundo laboral, deben saber trabajar de forma conjunta con el resto de compañeros. Los objetivos en las empresas son tan complejos que sólo pueden ser resueltos cuando se trabaja en equipo.

En las aulas es habitual hacer grupos pequeños de trabajo para resolver un mismo problema. En el proyecto “Ávila en tapas” sólo había un grupo y todos los alumnos trabajaban para resolver el mismo problema.

Debido a la pandemia de la Covid19 y a los desdobles que se produjeron, en el aula había diez alumnos. Por tanto, el grupo de trabajo estaba formado por diez alumnos y un profesor.

Como vimos en el anterior artículo, detectamos tres actores principales involucrados en el producto: organizador, restaurantes/bares y usuarios. Cada uno de estos actores tienen sus necesidades e intereses dentro del producto.

Decidí crear subgrupos relacionados con estos actores y ponerles el nombre de ‘squads’. Sé que el nombre dentro del entorno empresarial es más amplio, pero vi una oportunidad de explicarles a los alumnos qué eran las squads/verticales/horizontales… dentro de una empresa. Así que dividimos de forma equitativa a los alumnos en squads. Las squads eran:

Squad del organizador (growth/crecimiento). Esta squad tenía el foco en las ideas relacionadas con el organizador. Casi todas estaban con el incremento de el número de usuarios, métricas, redes sociales...
Squad del usuario (engagement/mantener al usuario). Esta squad tenía el foco en las ideas relacionadas con los usuarios. Básicamente eran aquellas que hacían que la aplicación fuera interesante para el usuario: votaciones, concurso, nuevos eventos, descripción de las tapas…
Squad del restaurante/bar (engagement/growth). Esta squad tenía como objetivo conseguir que los restaurantes sientan que las ideas propuestas son buenas para su negocio, dar métricas que les ayude a mejorar el producto en la siguiente edición, dar visibilidad al establecimiento…

Las squads fueron un éxito por los siguientes motivos:

Los alumnos nunca dejaron de trabajar como un único equipo. Tenían claro que el objetivo era ofrecer un producto que cubriera las necesidades detectadas.
Los alumnos tenían mucho contexto de un problema en concreto (squad al que pertenecía) y una visión más global del resto de problemas.
Con la rotación de alumnos en la squad se consiguió que todos los alumnos estuvieran alineados con los problemas a resolver. Manejábamos el mismo vocabulario: tapas, rating, events…
Los alumnos mejoraron la comunicación de sus ideas al resto de compañeros. Los alumnos comenzaron en una squad pero fueron rotando durante el curso, así que cuando un alumno se cambiaba a otra squad, el equipo debía “formarle” y ponerle en contexto.

Una vez se identificaron las squads con un nombre, en el aula se normalizó el concepto y empezamos a usarlo para clasificar las funcionalidades a desarrollar: “El owner de esta funcionalidad debería ser la squad de usuario”.

Design Thinking

En la parte 1: kickoff del artículo, obtuvimos varias ideas que podíamos implementar y que eran útiles para el organizador, el restaurante/bar y el usuario.

En estas ideas no se indicaba cómo iban a ser implementadas. Aun no hablábamos de aplicaciones móviles. Por ejemplo, una idea concreta era: “Creemos que para el usuario sería importante conocer dónde se encuentra el restaurante o bar de una tapa determinada así como su horario de cierre”.

Organizamos las ideas por orden de prioridades. Estas prioridades fueron establecidas por nosotros mismos. Inicialmente, escogimos una idea por cada una de las squads creadas.

Y ahora sí empezamos a pensar en la forma de implementar la idea. Muchas de estas ideas fueron descartadas porque su implementación estaban fuera de nuestro contexto: aplicación web… Tengo que reconocer que las soluciones propuestas estaban muy sesgadas a favor del desarrollo móvil, pero creo que es normal, los alumnos están cursando un ciclo formativo orientado al desarrollo de aplicaciones móviles :P

El proceso para llegar a una implementación final da para más artículos. Principalmente me basé en que los alumnos no estuvieran limitados en sus ideas, que propusieran libremente y poco a poco fuéramos escogiendo aquellas que estaban a nuestro alcance. De una idea podían salir dos formas de implementarlas, siempre escogimos la más sencilla.

Lo importante en este punto, era tener claro cómo íbamos a implementar la solución a un post-it o funcionalidad deseada.

Expongo un ejemplo de una idea y su primera aproximación a la implementación:

Idea: “A un restaurante o bar le gustaría poder indicar dónde se encuentra, horario, nombre del bar, dirección… para que el usuario puede localizarlo”.

Propuesta de implementación: “Añadir en Google Maps un marcador donde se pueda ver la posición del restaurante/bar así como su horario”.

Prototipo de la aplicación

Una vez hechas las primeras propuestas de implementación que cubrían las ideas principales, creamos un prototipo para hacernos una idea del flujo que podría tener la aplicación y su diseño.

Como podrás ver en el prototipo, el diseño inicial ha cambiado (estilos) con respecto al resultado final. ¡Y eso es maravilloso! Es decir, para mí fue una muy buena oportunidad para hacer ver a los alumnos que las cosas cambian constantemente y hay que ver los cambios como una oportunidad y no como un problema.

Os dejo aquí el link al prototipo de MarvelApp: ver link del mock (100% recomendado)

Backlog (listado de tareas )

Todas las propuestas de implementación se metían en un listado de tareas (backlog) a realizar. En nuestro caso, usamos Github para no salirnos del ecosistema elegido para el desarrollo del proyecto.

Captura del listado de tareas de “Ávila en tapas”

En este listado de tarea aparecía la siguiente información:

Título de la tarea a realizar.
Alumno asignado.
[Xpt] Número de “puntos” que estimaba el alumno. Los alumnos estimaban las tareas en base a su esfuerzo, donde 1sp es poco esfuerzo y 5sp requiere más complejidad. Cada semana, los alumnos se asignaban tareas por valor de 5sp. Aquellas tareas que superaban esa estimación, se subdividian para tener menos sp. Este proceso me encantó. El ver cómo se equivocaron estrepitosamente en la primera estimación y cómo fueron afinándola a medida que iban pasando las semanas.
Módulo involucrado en la tarea. Podían ser: PMDM, PSD y AAD. Así el alumno sabía con qué objetivos iba a trabajar.
Asignación. Cada tarea se asignaba a un alumno.
Milestone era el sprint en el que se iba a realizar la tarea.

Aquí puedes ver una tarea detallada:

Captura de pantalla del detalle de una tarea

En el detalle de tarea se especificaba:

Descripción de la tarea a realizar.
Subtareas.
Recursos como el prototipo, diseño, iconos, textos…
Alumno asignado.
Pull Request creada para esta issue.
Módulos involucrados.
Criterios de evaluación que intervenían en la funcionalidad.

Flujo completo: Idea + Propuesta + Issue + Resultado final

Voy a exponer un ejemplo sobre el flujo completo que seguíamos desde que escogíamos una idea propuesta en los días iniciales del curso hasta su implementación al final del mismo.

Idea: “A un restaurante o bar le gustaría poder indicar dónde se encuentra, horario, nombre del bar, dirección… para que el usuario puede localizarlo”.

Propuesta de implementación: “Añadir en Google Maps un marcador donde se pueda ver la posición del restaurante/bar así como su horario”.

Funcionalidad añadida a Github (ticket): Adjunto captura. En el ticket se detalla lo que se pide, cómo se va a implementar, el diseño que hay que realizar, quién va a realizar la tarea, qué módulos del Ciclo Formativo intervienen (PDMD, PSP), la squad a la que pertenece, el número de sprint donde se va a realizar, la Pull Request asociada…

Resultado: Se adjunta captura final de su implementación en la aplicación:

Un sprint del proyecto

Como dije en el anterior artículo, nosotros hemos cogido la base de Scrum, Kanban y Extreme Programming pero hemos acabado adaptándola a la realidad del aula. Hemos eliminado muchas cosas que no funcionan. Básicamente todo aquello que no era útil para el proyecto (y para el aprendizaje del alumno) se eliminaba o se modificaba.

Un sprint para nosotros era una semana de trabajo donde realizábamos la siguiente rutina:

Todos los días, nada más comenzar las clases hacíamos una daily que no duraba más de 5 minutos. Esta daily consistía en que cada alumno iba diciendo “qué hizo ayer”, “qué va a hacer hoy” y si tenía o no algún bloqueo. Si lo había, se hablaba después de la daily. El objetivo de esto era estar alineados y saber qué estaba haciendo cada uno de los compañeros. Además, ayudaba a los alumnos tener un guión de tareas a seguir.
Sprint Planning. Los lunes empezábamos con la asignación de tareas a realizar esa semana. Básicamente se asignaban por squads y por alumno. Teníamos en cuenta la estimación a la hora de asignar las tareas.
Sprint review. Los viernes era el último día del sprint. Revisamos las tareas realizadas, contamos los puntos conseguidos y los comparamos con la semana anterior. Los puntos conseguidos nos permite saber la velocidad a la que vamos. Si bajamos en puntos, debemos preguntarnos que ha pasado, analizar dónde ha estado el problema. A modo de ejemplo, en un sprint hicimos 10 puntos menos que en el anterior. Vimos que el problema fue que una tarea bloqueó a otras tres y no se pudieron completar. Propusimos una solución a la hora de asignar tareas dependientes.
Product review. Lo realizábamos los lunes. La idea aquí era exponer al resto de compañeros las funcionalidades añadidas en el sprint anterior. Cómo funcionan, qué ofrecen, etc. Además, explicábamos cómo se había implementado. Se ejecutaba en un emulador la aplicación y se proyectaba. Los alumnos salían y exponían las funcionalidades implementadas por ellos mismos.
Nuevas tareas. Durante la semana vamos añadiendo al backlog las nuevas tareas que van surgiendo de otras tareas. El viernes los alumnos las estiman y el lunes estaran listas para el sprint planning.
Release (deploy). Todos los viernes, generábamos una release de la aplicación. En cada sprint realizado siempre ofrecíamos alguna funcionalidad que aportaba valor. Las release eran creadas semanalmente por un alumno y se subían al Play Store (pruebas internas).
Retrospectivas. Cada 3 o 4 semanas o si algo había ido mal, hacíamos una retrospectiva para intentar detectar qué cosas hacíamos bien y qué cosas deberíamos mejorar.