El jueves pudimos disfrutar de la presentación en la que David O. (aka. Cascabel) nos transmitía cual era su visión de cómo enseñar programación a nuestros alumnos de primero de Bachiller.
Para ello nos presentó sus objetivos fundamentales de la asignatura que eran:
 |
| Fuente: Presentación de David, puede consultarse aquí |
Creo que David dio en el clavo con estos objetivos, no podemos enseñarles a nuestros alumnos la programación como algo ajeno, complejo y tedioso, por ejemplo haciéndoles leerse un manual y empezando por un "hola mundo" sin sentido.
Es importante que asimilen en profundidad que la programación está en cada elemento cotidiano en la actualidad, y que entenderlo forma parte de un entendimiento global del mundo que les permitirá ser más libres y dueños de sus vidas.
Así que por ello coincido en clasificar como objetivos fundamentales los anteriores. Como objetivos necesarios, aquellos que necesitaran al finalizar bachiller, serán aquellos conceptos básicos y teóricos sobre la programación:
- Explicar los elementos comunes de un programa: datos, variables, bucles y condiciones
- Definir lenguaje de programación, compilador y entorno de desarrollo
- Implementar diagramas de flujo para resolver problemas sencillos
- Traducir algoritmos sencillos.
- Compilar sus propios programas.
- Defender cuándo y por qué es necesario implementar funciones.
- Diseñar programas sencillos que hagan llamadas a funciones, entre ellas funciones de entrada y salida.
- Usar un entorno de desarrollo con soltura
- Valorar la utilidad de los distintos entornos utilizados
- Implementar pequeños programas
 |
| A Grumpy Cat no le gustó leerse el manual de Turbo Pascal |
Como propuesta metodológica y de contenidos David nos propuso un complejo aunque interesante mapa de aprendizaje con distintas actividades que iban desde entender algoritmos y programar pequeñas lineas de código a buscar noticias sobre el impacto de la programación (y sus errores) en nuestra vida. Una propuesta cuyas principales pegas fueron el tiempo para prepararlo y después el tiempo en el aula, el que no parecía permitir a alumnos más de letras evitar trabajar con código tras un ligero contacto y que la programación que hacían al ser pequeños trocitos no terminaban de verlo concretado en algo más grande. Este último punto está relacionado con la crítica que hizo David al planteamiento antagónico, hacer un proyecto grande y cooperativo de programación que es lo que se suele hacer.
Mi propuesta entonces sería ir en un término medio de estas dos posiciones, crear un único proyecto incremental de programación. Esto es, empezamos con un programa pequeño que tiene funcionalidad y entidad propia y vamos incrementándolo hasta llegar a un proyecto más grande. Creo que ciertas tareas más satélites (documentación, investigación, multimedia...) a lo largo de este proyecto podrían ser cooperativas pero la programación en sí debería ser individual ya que es la manera de asimilar bien ciertos conceptos básicos. También tener en cuenta este perfil que comentábamos en el debate que puede no querer meterse de lleno en una programación más técnica, y para ello proporcionarles un proyecto más adecuado. Quizá que puedan ponerse en la piel de un periodista, buscar información con temas relacionados y generar contenido y debate sobre ello. Eso sí, me encantó la idea y apostaría por iniciarles en la programación con algún juego de mesa como el Potato Pirates, con el que todos podrán asimilar los primeros conceptos básicos de programación como los bucles o los condicionales.
Creo que esta es una de las unidades más complicadas por su complejidad y nivel de abstracción de los conceptos a aprender y debe conllevar por lo tanto un esfuerzo extra por parte de los docentes. Esta importancia creo que debe verse reflejada en la temporalización también, y por ello estoy de acuerdo con David en dedicarle un trimestre entero.
Sobre qué tipo de proyecto de programación y con qué lenguaje podríamos cumplir las características arriba presentadas y a la vez garantizar que sea abierto, flexible, del contexto del alumno... He estado explorando algunas opciones como un lenguaje llamado KPL (Kids Programming Language)[1] cuyos creadores dicen que es un lenguaje que ha simplificado los principales lenguajes de programación para acercarlo a niños y adolescentes en un entorno que potencia también la creación de proyectos atractivos como la programación de videojuegos o, a golpe de google, parece que (tras scratch) Python es una de las propuestas más populares para este propósito.
Dejo abierto a debate, interno y con mis compañeros, esta cuestión que necesita de un estudio mucho más riguroso. Todo ello para poder revelar con éxito la magia de la programación ;)
[1] Jon Schwartz, Jonah Stagner, and Walt Morrison. 2006. Kid's programming language (KPL). In ACM SIGGRAPH 2006 Educators program (SIGGRAPH '06). ACM, New York, NY, USA, Article 52
Hola Alba, coincido contigo en la necesidad de que haya un proyecto de fondo porque así se puede conseguir que los alumnos comprendan que ellos pueden ser capaces de hacer algo que sea útil, mientras que si sólo hacemos ejercicios sueltos e inconexos no van a llegar a hacerse esa idea. El problema que veo es cómo conseguir eso, creo que la cuestión implica un gran esfuerzo por nuestra parte para buscar algún proyecto que cumpla los requisitos y que a la vez resulte atractivo para los alumnos.
ResponderEliminarTambién has tocado otro de los aspectos que considero fundamentales como es qué lenguaje utilizar. Parece que hoy en día los docentes se decantan por lenguajes como Scratch aunque me da miedo que éstos puedan parecer lenguajes de "juguete" o incluso infantiles y no sean apropiados para 1º de Bachillerato. Yo aprendí a programar a esa misma edad en el instituto y utilizábamos C. Probablemente esa tampoco sea la mejor opción. En cualquier cosa es algo que me "atormenta" y para lo que no tengo la respuesta... todavía
En este artículo vemos perfectamente reflejado lo que vimos en clase, remarcando la importancia de que la programación no se quede en las aulas, que los alumnos vean la importancia de la programación fuera de estas. Por otro lado, como ya comenté en mi blog, no le daría un trimestre entero como indico David en su presentación, aunque Alba este de acuerdo en ello. Me parece una parte importante de la asignatura, pero al ser una optativa, implica que muchos alumnos, por ejemplo de letras, estén en ella por ser la asignatura menos mala, por lo que no es elegida por vocación y estar un trimestre entero, es excesivo. En cuanto a la metodología que plantea Alba, me quedo con ella totalmente, los alumnos tienen que hacer algo ellos, que vean de lo que son capaces, si parten de algo hecho, no ven lo que pueden llegar a hacer ellos y pierden gran parte de la motivación.
ResponderEliminarTras la edición, además de una buena reflexión y una buena propuesta explicas claramente la categorización de los objetivos de aprendizaje que propondrías a los alumnos.
ResponderEliminar