Categoría: academia

¿Cómo enseñamos a programar?

Cada vez estoy más convencido que la programación es un oficio y como todos los oficios se aprende haciendo. Pero no haciendo en soledad sino con un maestro. Pensemos en un carpintero ¿cómo se forma? ¿leyendo libros? Tal vez, si, es posible que lea algún libro, pero no es su principal formación. Su principal formación es trabajando la madera junto a un carpintero ya experimentado, quien le va enseñando los gajes del oficio. Pero si miramos la forma en que suele enseñarse a programar lejos está de esto.

No hay diferencia entre universidades, institutos terciarios o centros de capacitación privados, en general todos siguen el mismo esquema. El alumno asiste a un curso donde el docente ofrece algún tipo de explicación inicial y luego le dá a los alumnos ejercicios para que resuelvan. Luego se hace una resolución general en el pizarrón o usando un proyector. Puede que también se entregue algún material de lectura. Pero sentarse a programar con el alumno, no, nunca. En el mejor de los casos, mientras los alumnos trabajan en la resolución de los ejercicios, puede que un docente se acerque para responder alguna consulta o para destrabar a un alumno que no logra avanzar en la resolución.

¿Por qué es esto así? no lo sé a ciencia cierta. Creo que puede haber diversos motivos.

En sus comienzos la programación surgió vinculada a la matemática y por ello puede que haya heredado su didáctica. También puede ser que los docentes no vean la programación como un oficio. En algunos casos podría argumentarse que la masividad de algunos cursos hace imposible que el docente se siente a programar con los alumnos. En fin, cada cual tendrá sus argumentos. En lo que a mi respecta, estoy convencido que la programación es un oficio y si bien en Algo3 tenemos cursos masivos y recursos acotados, intentamos programar con los alumnos haciendo dojos en clase o incluso algo de «community-programming» al desarrollar el trabajo final, donde cada docente puede sentarse con grupos de 3 o 4 alumnos a programar conjuntamente.

Caso de éxito: sistema de gestión de trabajos prácticos

Hace un tiempo comenté sobre el sistema de gestión que estábamos por estrenar en Algo3. Bueno, lo estrenamos y fue un éxito rotundo. El sistema nos permitió corregir en forma automática más de 150 entregas.

Básicamente el trabajo práctico tenia como objetivo que los alumnos se familiazaran con el entorno de Pharo y la sintáxis de Smalltalk. Para ello les dimos un script con un conjunto de pruebas unitarias y los alumnos debían escribir todo el código necesario para que dichas pruebas se ejecuten exitosamente. Una vez escrito el código, los alumnos tenian que registrase en el sistema y subir el código escrito. Entonces el servidor se encargaba de correr el script de prueba e informar el resultado de la entrega via mail. Luego, una vez completada exitosamente la corrección automática, los docentes teniamos la posibilidad de navegar el código de los alumnos y realizar una corrección manual enfocada en cuestiones de diseño.

Con este hito, los alumnos que desarrollaron el sistema de corrección, obtuvieron la aprobación de su trabajo profesional de ingenieros en informática (aún restan ajustar algunas cosillas menores y algunos trámites administrativos, pero la parte «dura» ya está).

En las próxima semanas estaremos trabajando en ajustar algunos detalles del producto de cara a liberarlo formalmente como herramienta open source. Al mismo tiempo, ya estoy trabajando en armar un nuevo backlog para continuar trabajando con otros alumnos que quieran recibirse haciendo un aporte a esta herramienta.

Inclusión de métodos ágiles en las carreras de informática

En este post quiero tratar un tema que estuve trabajando la semana pasada en los talleres que participé en Medellín.
Según mi visión, a la hora de diseñar una carrera de informática existen distintas alternativas para incluir los métodos ágiles. En una simplificación extrema podriamos hablar de un enfoque conservador y otro innovador.

El enfoque conservador podria consistir simplemente en agregar una materia sobre métodos ágiles (posiblemente hacia el final de la carrera) y mantener el resto del plan sin mayores modificaciones.

Por otro lado, el enfoque innovador sería repensar la carrera completa incluyendo temas de agilismo en diversas materias. De esta forma se podría incluir Scrum en la materia de gestión de proyectos, TDD en las materias de diseño/programación, BDD y User Stories en las materias de análisis/requerimientos y así sucesivamente.

Si bien el enfoque innovador puede parecer más difícil de implementar, la realidad es que no siempre es así. Un claro ejemplo es lo que ocurre en FIUBA. Si bien los planes de estudio actuales no hacen referencia explícita a métodos ágiles, varios profesores han incluido temas de métodos ágiles en sus respectivas materias por iniciativa propia. Claro está, que esto es pura informalidad ya que la inclusión de los temas está sujeta por completo a la iniciativa de cada docente. Pero también es cierto que es una implementación «rápida», ya que no require de todo el trámite burocrático que puede implicar el modificar un plan de estudios. En FIUBA los temas de agilismo se empezaron a dictar hace ya más de 6 años por iniciativa de algunos docentes. Hoy por hoy, más docentes se han sumado a esta iniciativa y los nuevos planes de estudio (que están en proceso de aprobación) ya incluyen formalmente estos temas que en la realidad se vienen dictando hace varios años.

Agilizando Medellín

Por estos dias me encuentro en Medellín dictando un par de talleres sobre adopción de métodos ágiles en la academia. Esta actividad es una iniciativa de Ruta N, un organismo creado conjuntamente por la alcaldía de Medellín y otras organizaciones (tanto del sector público como privado) para promover el desarrollo de negocios innovadores basados en tecnología.

Esta iniciativa tiene como objetivo promover/facilitar la inclusión de los métodos ágiles en los planes de estudio de las carreras de informática. De la iniciativa estan participando 6 universidades entre las que se encuentran la Universidad Nacional de Colombia, la Universidad de Medellín y el Politécnico Colombiano.

Continuará…

Sistema de gestión de trabajos prácticos

A mediados del año pasado se me acercaron dos alumnos de FIUBA, con la intención de que los dirigieran en el desarrrollo de su trabajo profesional de fin de carrera. La propuesta que traían no me convenció, pero en lugar de decirles que no, les hice una contra oferta y trabajar en una idea que tenia en mente desde hace un tiempo: una herramienta de gestión para de trabajos prácticos de programación. La idea no era del todo novedosa, pues ya había en nuestra misma facultad dos materias que ya tenian un sistema similar. Al mismo tiempo, puse una seria de condiciones respecto del producto final y de la forma de trabajo:

En cuanto al producto, pedí las siguientes cuestiones

  • Pruebas unitarias y de aceptación automatizadas
  • Alto porcentaje de cobertura
  • Cumplimiento de las convenciones de código del lenguaje utilizado
  • Implementación con tecnologias abiertas

Respecto de la forma de trabajo les pedí:

  • Enfoque iterativo incremental con iteraciones semanales
  • Proceso de trabajo tipo Scrum
  • Visibilidad contínua

Con buen criterio los muchachos se tomaron un par de dias para pensarlo y finalmente aceptaron.

Hoy al cabo de 21 iteraciones, estamos a punto de salir en producción. Estamos arrancando el cuatrimestre y vamos a utilizar el sistema para gestionar los dos primeros trabajos prácticos de este cuatrimestre.

En próximos post compartiré más detalles del proyecto.

Agile en la academia, mi experiencia

En este tema tenemos dos cuestiones:

  1. La aplicación de técnicas agile en la enseñanza (más allá de cual sea la materia de estudio)
  2. La enseñanza de agile como un enfoque de la ingeniería de software.

En mi caso tengo experiencia en ambas cuestiones.

En Algoritmos y Programación 3 (Universidad de Buenos Aires) nuestro foco de estudio es la programación orientada a objetos pero incluimos en el programa de la materia algunas prácticas comunes en el movimiento agile como ser TDD e integración contínua. Esto se debe a que en la actualidad no concebimos la construcción de software orientado a objetos sin el uso de estas prácticas.

Por otro lado, en Elementos de Ingeniería de Software (Universidad Nacional de Quilmes) el enfoque de ingeniería que enseñamos es el enfoque Agile. Es necesario mencionar que el objetivo de esta materia es proveer, a un técnico en programación, herramientas suficientes para llevar adelante el desarrollo de un sistema de software. La discusión de porqué el enfoque Agile y no otros, es tema de otro post. Al mismo tiempo la forma en que se dicta la materia tiene varias técnicas de agiles como ser:

  • La materia se encuentra dividida en iteraciones, al final de cada una los alumnos presentan un entregable y se realiza un retrospectiva sobre la forma en que se ha dictado la materia
  • El entregable puede ser un informe, software, un documento de diseño o una evaluación
  • Los alumnos se auto organizan para llevar adelante las distintas asignaciones
  • Cada alumno lleva un backlog de sus tareas, que es priorizado por el docente y estimado por cada alumno
  • Si al final de la iteración el entregable de un alumno no cumple con el criterio de done previamente acordado, entonces el docente puede decidir:
    • «cancelar el proyecto», lo que básicamente significa que el alumno ha pedido la materia)
    • agregar al backlog items distintos o adicionales para compensar/suplir el entregable incompleto

Asimismo hay dos cuestiones que nos parecen centrales más allá del enfoque agile:

  • Los proyectos de software se desarrollan dia a dia y eso mismo hacemos en la materia. Hay que trabajar todas las semanas. Esto resulta en ocasiones «chocante» para los alumnos que muchas veces están acostumbrados a simplemente asistir a clase y sólo trabajar/estudiar la semana previa a un exámen. 
  • Un factor importante para el éxito de cualquier proyecto es la comunicación y el manejo de expectativas. Durante toda la materia hacemos mucho incapié en esto. Por eso, si un alumno piensa no asistir a una clase, tiene la obligación de avisar previamente al resto de la clase. No hace falta que dé explicaciones, simplemente decir «No asistiré a clase». Esto permite que el docente puede planificar mejor las actividades de la clase sabiendo con cuantos alumnos contará.

Aqui dejo algunos links a posts anteriores que agregan más información sobre lo mencionado aquí:

Nota: este post surgió a partir de una consulta de mi colega Juan Gabardini quien me mencionó una iniciativa de gobierno de Medellín para la enseñanza de método ágiles en las universidades. Gracias Juan.

Cierre de cuatrimestre en UNQ, tercera promoción

El lunes pasado tuvimos la última clase de Elementos de Ingeniería de Software la cual como de costumbre estuvo dedicada a la retrospectiva. Pero antes de entrar en las conclusiones de la retrospectiva, les comparto algunos números:

  • Alumnos anotados: 8
  • Alumnos aprobados: 7
  • Alumnos pendientes de aprobación: 1
  • Nota final promedio: 8,14
  • Fueron un total de 27 clases
  • Tuvimos la visita de un profesional de la industria (¡gracias Emilio!)
  • Trabajamos exhaustivamente con Ruby, Sinatra y Cucumber
  • Desarrollamos varias aplicaciones, las cuales publicamos en heroku y algunas incluso con dominio propio

Personalmente estoy muy conforme con como resultó el curso. A diferencia de cuatrimestres anteriores, puse mucho menos foco en cuestiones de arquitectura/diseño y más énfasis en cuestiones de análisis y especificación (Visual Story Mapping, BDD, etc).

 Respecto de la retrospectiva, los puntos destacados fueron:
  • Mantener:
    • Dinámica de las clases
    • Lecturas
    • Resumenes
    • Herramientas
    • Invitados
    • Clase remota
  • Probar/incrementar:
    • Actividades de relación previas al comienzo de la clase
    • Clases al aire libre
  • Mejorar:
    • La forma de feedback >> Action Item: ser más explicíto al setear expectativas de los entregables y ser  más cuidados con el tono

Para cerrar el post, quiero agradecer a Natalia, una ex-alumna de la materia que colaboró conmigo durante todo el cuatrimestre.

unq-promocion3

Nota: el ícono representa una alumna que estuvo ausente el día de la retrospectiva.

 

Academia e Ingeniería de software

Desde que empecé a dictar la materia de Ingeniería de Software en UNQ, comencé a prestar mayor atención a los diferentes enfoques para enseañar esta disciplina. En Agiles 2012 y luego en mi reciente viaje a Venezuela pude hablar con gente de diversas instituciones y confirmar la teoría que aquí expongo.

El enfoque utilizado para enseñar Ingenieria de Software depende de carrera que uno analice, ya que cada carrera le da distinta relevancia al tema. Hay carreras en las que simplemente hay una o dos materias de Ingeniería de Software, mientras que otras tienen una materia por cada disciplina de la Ingeniería de Software. En este sentido la Tecnicatura en Programación de UNQ pertenece al primer grupo, ya que solo tiene una materia del tema (la que dicto yo ;-)). Por su parte, la Ingeniería informática de UBA está en el otro extremo, tiene una materia por cada disciplina: Análisis, Diseño, Administración de Proyectos, Arquitectura, Calidad, etc, etc.

El enfoque utilizado influye, como es de esperar, en los contenidos impartidos. Si uno cuenta con varias materias, es posible tratar distintos enfoques y técnicas con un nivel de profundidad interesante, pero si uno cuenta con sólo 1 o 2 materias, entonces se ve en un dilema: estudiar un único enfoque con cierta profundidad o bien ser más generalista y estudiar varios enfoques de forma más superficial. En la tecnicatura de UNQ solo tenemos una materia de Ingenieria de Software y la estrategia elegida fue centrarnos en un sólo enfoque (el de los métodos ágiles) aunque hacia el final de la materia hacemos una breve mención de waterfall y UP. Esta decisión estuvo motivada por el hecho de que pretendemos que al finalizar la carrera, el alumno pueda llevar adelante un proyecto de punta a punta y para ello creemos más valioso conocer un enfoque en detalle que conocer varios enfoques de forma superficial.

En base a lo que he hablado, leido y compartido con colegas de distintas instituciones, me da la impresión que en la actualidad la mayoría de las instituciones (en América del Sur) enseñan Ingeniería de Software utilizando un enfoque «tradicional» basado en los clásicos de Somerville y Pressman o bien se inclinan a un enfoque un poco más concreto y se basan en el Proceso Unificado. Adicionalmente en algunos casos se dictan materias complementarias (optativas generalmente) donde se ven enfoques alternativos (agile, waterfall, etc, etc).

Si algún lector no comparte esta visión, me gustaria que expusiera su opinión.

15 GB gratuitos en Dropbox…

Dropbox está llevando a cabo un concurso entre instituciones académicas. Cada institución gana puntos por cada alumno que se registra en DropBox y al mismo tiempo esos puntos se traducen en espacio para los alumnos de la institución. Desconozco cuales son las instituciones que participan ni tampoco como es el proceso para sumar una institución, pero se que la UBA está participando.

Si eres alumno de la UBA y quieres ganar 15 GB, entonces puedes registrarte aqui: https://www.dropbox.com/spacerace. Si ya tienes una cuenta en Dropbox, no importa también puedes reclamar tus 15 GB asociando tu cuenta fiuba a tu cuenta actual de Dropbox.

 

Publicidad FIUBA

Es común al transitar por la ciudad encontrarse con publicidades de universidad privadas, sobre todo en los periodos de inscripción. Recuerdo incluso haber visto una publicidad de una universidad privada en televisión (quienes hayan visto los Simpson en canal Fox seguramente sepan a que me refiero :-)).

Pero con las universidad públicas es distinto (al menos en Argentina), generalmente no hacen ningún tipo de publicidad a menos que se trate de actividades de extensión o de posgrado. Por eso es que el viernes pasado me sorprendí cuando a la salida del subte me encontré con un afiche publicitando las carreras de grado de Fiuba.