Open Space de Educación

Desde la comunidad de métodos ágiles de Buenos Aires, estamos organizando un open space sobre esta temática. La idea es compartir técnicas/problemáticas/estrategias de enseñanza de cara me mejorar las clases, la llegada a los alumnos y el proceso de enseñanza/aprendizaje en general.

La cita es el próximo sábado 4 de agosto en las instalaciones de la UNTreF en el Centro Cultura Borges (Viamonte esq. San Martín 3 piso, Ciudad de Buenos Aires)

Como de costumbre el evento es totalmente gratuito pero con previa registración. Más info y registración aquí.

¡Nos vemos!

Anuncios

Cierre de cuatrimestre a puro TDD (algo3, 1c-2012)

Y se fué uno más, pero distinto y para bien. En líneas generales mantuvimos la misma modalidad que los cuatrimestres anteriores, pero creo que en esta ocasión hemos manejado mejor los tiempos y hemos resultado “más convincentes” en algunas cuestiones.

Entre los cambios del curso Jueves-tarde sumamos un nuevo colaborador docente: Diego Marcet, graduado de la casa, ex-alumno de la materia y ex-compañero mio de trabajo en Southworks.

Otro de los cambios implementados fue el uso del campus virtual (basado en Moodle) para la publicación del material de estudio. Yo personalmente fuí un poco más allá y lo utilicé para manejar la interacción con mis grupos vía los foros. La ventaja que le veo al uso de foros tiene que ver con que la resulta muy cómodo visualizar el hilo completo de la conversación.

A mi parecer la particularidad más destacada (al menos de nuestro curso) fue el fuerte incampié que hicimos en el uso de TDD, lo cual dió sus frutos en el trabajo final, donde varios alumnos desarrollaron gran parte de trabajo usando esta técnica.  Es más, la cantidad de pruebas unitarias de los TP finales fue record en el caso de los TPs que yo corregí: me entregaron TPs con más de 200 pruebas unitarias, llegando a niveles de cobertura llegando al 80%.

La última innovación a mencionar es la práctica de integración contínua. Si bien este tema lo vemos en la teoría desde hace varios cuatrimestres, este año fui más allá y levante un servidor de integración contínua para mis alumnos (lamentablemente no tenía una gran infraestructura, asi que solo lo pude hacer para los 3 grupos a mi cargo). El proceso de build incluyó: compilación, ejecución de pruebas y medición de cobertura.

Si bien no hicimos la dinámica de retrospectiva global, yo hice una más reducida con los alumnos de mis grupos y el feedback fué muy positivo: solo surgieron algunas cosas menores para mejorar que comentaré en un próximo post.

Retrospectiva de Ing. de Software, primer cuatrimestre 2012

Antes de entrar en detalle sobre los resultados de la retrospectiva, quiero destacar por qué hacemos restrospectivas. La respuesta es simple: para mejorar. La idea es revisar como se desarrolló la materia intentando identificar puntos positivos y negativos, y partir de su análisis definir: qué cosas mantener, qué cosas cambiar y que cosas probar. Ahora sí, vamos a la restrospectiva.

Para la retrospectiva, utilizamos la técnica del timeline, mi favorita para estos casos (cierre de cuatrimestre). Lamentablemente, solo participaron 5 de los 7 alumnos. De todos los items identificados, una cuarta parte estaba relacionada a cuestiones “de ambiente” ajenas a la materia y sobre las cuales prácticamente no tengo posibilidad de influencia (por ejemplo: fallas en la infrastructura informática de la universidad). Respecto del resto de los items, esto es lo relevante:

Items a mantener

  • Estructurada iterativa de la materia
  • Actividades de aplicación
  • Dictado de una clase en forma remota
  • Presentación de invitados de la industria
  • Dinámica de evaluación final
  • Restrospectiva al final de cada iteración y restrospectiva final

Cuestiones a mejorar

  • Dificultades varias con Sinatra
    • Recomendar un tutorial y darlo con anticipación suficiente
  • Evaluación online
    • Hacer revisar las preguntas por un tercero para asegurar que sean claras y evitar posibles ambigüedades
    • Hacer una al final de cada iteración
    • Resolver las dificultades técnicas de la herramienta para permitir ver el resultado y las respuestas correctas al finalizar la evaluación
  • Retos del profesor (si, yo, los sermoneo mucho cuando no cumplen con las tareas)
    • No calentarme tanto
    • Mejorar las formas
    • Automatizar la corrección y parte del feedback con alguna herramienta
  • Material utilizado en clase no disponible (en algunas clases utilicé ppts que luego no compartí)
    • Publicar el material utilizado o bien ser explícito de antemano que no será publicado
  • Poca visibilidad de las notas
    • Publicar las notas al final de cada iteración

Para probar

  • Lecturas voluntarias: compartir algunas lecturas/videos opcionales que les permitan sumar “puntos adicionales” al presentarlos al resto de la clase
  • Proveer una guia de lectura para todas las lecturas, asi leen más enfocados
  • Dedicar los primeros 10 minutos de la primer clase de la semana para repasar los puntos destados de la lectura realizada

Bueno, esto es todo, voy a intentar incorporar todas estas cuestiones el próximo cuatrimestre.

Cierre de cuatrimestre en UNQ, segunda promoción

El jueves pasado realizamos la restrospectiva de cierre del cuatrimestre. Comparto aqui algunos números:

  • Este cuatrimestre se anotaron 7 alumnos
  • Los 7 completaron la materia
  • La nota final promedio fue 7,42
  • Tuvimos 30 clases organizadas en 4 iteraciones
  • Tuvimos 2 visitas de profesionales de la industria
  • Leimos más de 12 artículos
  • Hicimos varios ejercicios de BDD y TDD con Ruby
  • Desarrollamos 3 aplicaciones trabajando en grupo, utilizando Scrum, user stories, cucumber, sinatra y github.
  • Hicimos varias actividades para ejercitar diferentes prácticas: pajarraco scrum, fábrica de aviones, estimación de subastas, etc.

Creo que este segundo cuatrimestre ha sentado las bases para lo que pretendo que sea la materia, con lo cual el próximo cuatrimestre será muy parecido.

En el siguiente post, compartiré los resultados de la retrospectiva.

Nota: los iconitos representan a los alumnos ausentes el día de cierre que fue cuando tomamos la foto.

Nuevos cursos interesantes en Coursera.org

Ayer me llegó un mail de Coursera.org anunciando nuevas 12 nuevas universidades que sumaron cursos a la oferta de la plataforma. Con un rápido vistazo identifiqué algunos cursos que me resultaron interesantes:

Lamentablemente, no tengo suficiente tiempo en este momento, pero en verdad que me gustaria tomarlos todos.

Si tienen tiempo, no lo duden, creo que no se van a arrepentir.

Cómo enseñar/aprender a estimar

Tengo la impresión de que este es un tema muy pobremente tratado en los contextos académicos. Digo esto basado en mi experiencia personal y en lo que he hablado con varios colegas.

En mi caso vi la temática estimación en una clase en una materia, donde el docente realizó una explicación de diversos métodos. Nada más, sólo una explicación teórica. Nada de práctica para pudieramos entener mejor los métodos. Lamentablemente creo que esto no fué una situación aislada, pues he hablado con varios colegas de diversas casas de estudios y la situación no es muy distinta.

Personalmente creo que la estimación, al igual que varias de las actividades de la ingenieria de software, es una actividad que se aprende a partir de la práctica.

Cuando tuve que preparar el tema estimaciones para la materia que dicto en UNQ, determiné utilizar el siguiente enfoque:

  1. Explicar algunas generalidades sobre estimación (quien, cuando, para que, etc)
  2. Comentar brevemente los métodos más difundidos
  3. Explicar en detalle dos métodos
  4. Hacer un ejercicio grupal de estimación en clase
  5. Darles un apunte para lean y refuercen lo explicado en clase
  6. Pedirle a los alumnos que estimen cada tarea de la materia antes de realizarla
  7. Hacer un segundo ejercicio grupal de estimación en clase

El punto (6) lo hemos hecho a lo largo de todo casi toda materia, estimando y planificando cada tarea (esto es: cada alumno lleva un excel donde registra cuando va realizar la tarea de la materia y cuando tiempo estima decicarle). Luego de realizada la tarea, deben registrar también el tiempo real insumido. Con esto apunto a que los alumnos no solo hagan el ejecicio de estimar, sino que también se acostumbren a planificar.

Obviamente este enfoque me lleva más de una clase, pero creo que bien vale la pena.

Mi dream team

Estaba preparando mi clase de Ingeniería de software de mañana, cuando me vino a la mente la idea que quiero compartir con este post.

Resulta que esta clase va a tener dos partes: revisión de las  evaluaciones y visita de un invitado. Estaba pensando en como presentar al invitado cuando decidí que con una simple oración debería ser suficiente:

“Si tuviera que armar un dream team para llevar adelante un proyecto de desarrollo de software, este individuo seria la primer persona que incluiria”

Tal vez alguien lea esto y piense que la persona merecedora de esta frase debe ser un excelente programador, muy habilidoso, muy productivo, etc, etc. Un groso en una palabra. Y en parte sí, lo considero un groso, pero… ¿es un excelente programador? Mmm, si pero no es el mejor que conozco ¿es muy productivo? mmm…si nada nada del otro mundo.

Entonces…¿por qué he de incluirlo en mi dream team? Porque es un profesional capaz de adaptarse al contexto, tiene una sólida formación, es criterioso pero sobre todas las cosas: es una persona en la que tengo absoluta confianza y con la que sé que puedo trabajar armónicamente.

¿Y tú? ¿que cuestiones tendrías en cuenta para armar tu dream team?