Estadísticas del nuevo cuatrimestre en MeMo2

Ya hemos completamos la segunda semana de clases. Tenemos 18 alumnos y un equipo docente con 2 profesores y 6 colaboradores, con lo cual deberíamos poder tener un flujo de seguimiento mejor que el cuatrimestre pasado.

Comparto aquí algunas estadísticas del perfil de alumnos que resultan llamativas:

  • Más del 70% de los alumnos ya están trabajando en alguna actividad afín a la carrera
  • Hay una variación muy grande en la cantidad de materias aprobadas: el alumno con más materias aprobadas tiene 33, mientras que el que tiene menos tiene 17

Condición laboral

Cantidad de materias aprobadas

Cantidad de materias aprobadas

Preparando MeMo2, 2019-2c

Luego un muy buen primer cuatrimestre tenemos la vara más alta para este segundo. A partir del feedback obtenido en las encuestas y las retros con alumnos y con el equipo docente tenemos en mente lo siguiente:

  1. Creemos que la dinámica general de la materia funciona muy bien, con lo cual la mantendremos y solo haremos pequeños ajustes en cuestiones puntuales.
  2. A pesar de que algunos ya confirmaron que no podrán, continuaremos con ex-alumnos en el equipo docente (se están sumando 4 nuevos colaboradores). Esto, además de ayudarnos con la carga de trabajo, también nos permite tener una mirada distinta dentro del equipo docente. Al mismo tiempo es un manera de formar futuros docentes.
  3. Mantendremos el stack de herramientas de soporte (eso es: Google Groups, Canvas Campus y GitLab) e intentaremos incorporar el uso de Kahoot.
  4. También mantendremos el stack de desarrollo con Ruby/Sinatra/Padrino, aunque actualizaremos a Ruby 2.5.1
  5. Renovaremos los ejercicios y el TP final, aunque muy posiblemente mantendremos el JobVacancy como TP1
  6. Vamos a realizar algunos ajustes en la dinámica de los ejercicios de programación individuales y en su corrección. Queremos que las correcciones y el feedback sean más uniformes. Para esto último tenemos que trabajar internamente para generar más guías y rubricas para las correcciones y también vamos a intentar implementar un mecanismo de revisión de correcciones entre los docentes.

Como para cerrar quiero destacar algunos puntos relevantes para quienes planeen cursar este segundo cuatrimestre de 2019:

  • La asistencia a clase es obligatoria y por ende la controlamos
  • La materia es intensa, require de una dedicación constante a lo largo de todo el cuatrimestre lo cual implica unas 8 horas semanales de trabajo extra-clase.
  • Si bien no tenemos el tradicional mecanismo de evaluaciones parciales en papel, el sistema de evaluación que utilizamos genera menos tensiones de parte de los alumnos, pero al mismo tiempo requiere mayor disciplina y dedicación.
  • Las clases comienzan 19.00 (puntual)
  • La primera clase será el Jueves 22/8, ¡no falten! la primera clase siempre es muy importante para setear expectativas)

Cierre MeMo2 2019-1

Se fue un cuatrimestre más y es momento de análisis. Comencemos por los fríos números:

  • 32 inscriptos (34 formalmente pero 2 nunca asistieron a clase)
  • 3 abandonos antes de la sexta semana
  • 23 alumnos completaron la materia con promoción
  • 5 alumnos pendientes de final
  • 19 tareas individuales (11 cuestionarios y 5 ejercicios de programación)
  • 2 TPs grupales
  • 1 visita de la industria
  • Evaluación general de la materia: 8.9 (según encuesta interna)
  • Opinión general de la materia: 4.6 (según encuesta del departamento)
  • Claridad de los docentes (según encuesta interna): 4.8 / 5
  • Conocimiento de los docentes (según encuesta interna): 4.9 / 5
  • Dinámica de clases (según encuesta interna): 4.5 / 5
  • Materiales de estudio (según encuesta interna): 4.3 / 5
  • Dedicación promedio extra clase (según encuesta interna): 8 hs. semanales

Por otro, más allá de los números la sensación es muy positiva. Basado en el feedback recibido tanto en las encuestas como en las retrospectivas creo este resultado es consecuencia de 3 puntos destacados:

  • Un cambio de orden en los temas de la materia poniendo más foco inicialmente en cuestiones de programación. Esto a mi parecer facilitó en entendimiento de los temas de proceso y el desarrollo de los TP grupales.
  • La incorporación de ex-alumnos al equipo docente. Si bien una ex-alumna había colaborado en algunas cuestiones el cuatrimestre anterior, esta vez con contamos con varios ex-alumnos que colaboraron a lo largo del todo el cuatrimestre.
  • La temática del TP final que incluyó el desarrollo de un Bot de Telegram. Creo que esto generó cierta motivación entre los alumnos.

No están en la foto los ex-alumnos que participaron como colaboradores: Jessica, Josefina, Anarella, Facundo, Pablo y Martín.

Notas Retro, memo2@Fiuba

De cara a identificar oportunidades de mejora en la dinámica de la materia, ayer hicimos la primera retrospectiva del cuatrimestre. Hicimos el clásico keep-fix-try. Comparto algunos de los ítems más destacados:

Keep:

  • Dinámica de trabajo con GitLab
  • Bibliografía propuesta
  • Videos
  • Dinámica de interacción en la lista de correo de la materia

Fix:

  • Algunos ejercicios llevaron más tiempo de lo que se esperaba.
    • Es cierto, puntualmente 2 de las 8 tareas realizadas hasta el momento, insumieron más de las 6 horas estimadas.
    • Realmente es difícil saber cuanto tiempo le llevará a los alumnos completar un ejercicio, lamentablemente nos equivocamos en la estimación.
    • No hay mucho que podamos hacer al respecto de esto más que intentar estimar mejor.
  • Las consignas de algunos ejercicios fueron publicadas sin estar lo suficientemente pulidas, lo cual implicó que se fueran refinando mientras los alumnos ya estaban trabajando.
    • Es cierto que hubo algunos errores en las consignas, pero al mismo tiempo nos parece bien ir refinando las consignas en forma colaborativa a medida que se trabaja pues es lo que ocurre en el mundo real.
    • Nos llevamos como tarea, hacer algún mecanismo de review previo a la publicación para intentar que las consignas lleguen a la publicación estando más pulidas.

Try:

  • Que la retrospectiva la facilite alguien externo a la materia
    • Lo evaluaremos
  • Proveer una configuración Docker (como alternativa al vagrant que ya compartimos)
    • Lo evaluaremos
  • Hacer revisiones de código entre estudiantes
    • Lo evaluaremos

Al finalizar les pedimos a los estudiantes que evalúen a modo de termómetro los temas y la dinámica de la materia. Los resultados fueron muy positivos, ambas cuestiones dieron en promedio por encima de 8 (imagen adjunta)

Preparando MeMo2 2019

La primera novedad que tenemos es la extensión del equipo, 5 ex-alumnos de la materia se suman como colaboradores. Esperamos que esto nos ayude a mejorar los tiempo de corrección y tener una mirada del curso más cercana a los alumnos.

Por otro lado estamos ajustando la planificación y el contenido para hacer hacer más foco en cuestiones diseño y programación.

Según nos indica el sistema de inscripción parece que este cuatrimestre tendremos record de alumnos, hay momento hay 27 inscriptos.

En términos de herramientas seguiremos trabajando con Ruby y GitLab pero extendemos el uso de GitLab, o sea, más allá de la funcionalidad de repositorios e integración continua, utilizaremos también las funcionalidades de issue tracking.

Cierre del segundo cuatrimestre 2018 en MeMo2

Completamos la tercera edición de MeMo2. El resultado es raro, por un lado nuestra sensación como equipo docente es que la materia fluyó mucho mejor que el cuatrimestre anterior (lo cual en cierto modo se refleja en mejores notas de aprobación) pero otro lado, las encuestas incluyeron algunos puntos negativos. Hubo alumnos que manifestaron que el contenido de la materia no les resultó interesante. Es poco lo que podemos hacer sobre esto, pues el contenido viene principalmente dado por el plan de estudio. Personalmente me resulta curioso porque el contenido de la materia tiene mucho que ver con el ejercicio profesional y de hecho todos los encuestados indicaron que el contenido les pareció actualizado. Por otro lado hubo quejas respecto de las interacciones con los alumnos lo cual se debió en gran medida al hecho de que todas las comunicaciones las hacemos por medio de la lista de correo de la carrera, incluso las que implican aplazos en la materia. A esto se suma el uso de algunas expresiones/frases que han sonado poco amables. Ya hemos hecho nuestra retrospectiva interna de cátedra y hemos identificado algunos puntos de acción para mejorar este tema el próximo cuatrimestre. Adicionalmente, yo personalmente voy a trabajar en intentar mejorar mis expresiones. Más allá de estas cuestiones, estos son los números fríos para la estadística:

  • Evaluación general del curso (según encuesta interna): 7.8 / 10
  • Opinión general de la materia (según encuesta del departamento): 3.5 / 5
  • Claridad de los docentes (según encuesta interna): 4.6 / 5
  • Conocimiento de los docentes (según encuesta interna): 4.6 / 5
  • Dinámica de clases (según encuesta interna): 4.5 / 5
  • Materiales de estudio (según encuesta interna): 3.6 / 5
  • Dedicación promedio extra clase (según encuesta interna): 6 hs. semanales

Repensando los trabajos prácticos

Si analizamos los trabajos prácticos que suelen hacerse en las carreras de informática como si fueran proyectos, veríamos que en general están planteados en términos de:

  • Alcance fijo: el docente define todo lo que hay que hacer y no negociable
  • Tiempo fijo: el docente indica la fecha de entrega, la cual generalmente tampoco es negociable
  • Esfuerzo variable: el docente no fija el esfuerzo que debe invertirse para completar el trabajo. Esto suena razonable, ya que habiendo fijado las otras dos variables es de esperar que esta sea ajustable.

Todos los trabajos prácticos que hice durante mi carrera de grado y postgrado fueron así y por lo que suelo hablar con mis alumnos, esto sigue siendo así. Duramente mucho años en las materias que estuve como docente también usábamos esta estrategia pero desde hace unos años hemos cambiado.

Actualmente en las dos materias de ingeniería de software que dicto utilizamos una estrategia distinta:

  • Esfuerzo fijo: les pedimos a los alumnos una dedicación semanal de 6 horas efectivas, extra clase por persona
  • Tiempo fijo: trabajamos durante 3 iteraciones, cada una de 1 semana de duración
  • Alcance variable: hay una lista de ítem/funcionalidades priorizadas y cada equipo estima y asume un compromiso en base a lo que consideran que podrán completar. Incluso si llegan a completar el compromiso, no tienen “penalización” de nota

Y particularmente en este cuatrimestre hicimos un primer trabajo práctico con las modalidad previamente descripta y tenemos un segundo trabajo práctico planteado de forma distinta:

  • Alcance fijo: está definido el conjunto de funcionalidades a completar
  • Tiempo variable: cada equipo decide cuando tiempo tomará para completar las funcionalidades. Trabajamos en iteraciones de duración fija, pero equipo decide la cantidad de iteraciones que utilizará. Idealmente creemos que el trabajo puede completarse 2 iteraciones, pero les damos a los alumnos la posibilidad de utilizar 4 o incluso 5 iteraciones
  • Esfuerzo variable: cada equipo elige cuanto esfuerzo pondrá en cada iteración. De esa forma en una iteración dada que coincida con fecha de examen de otra materia podrían poner poco esfuerzo y luego compensarlo en una iteración posterior.

Personalmente estoy muy convencido y contento con la estrategia TEfAv (tiempo y esfuerzo fijos, alcance variable). Y tengo mucha expectativa con este nuevo experimento de AFTEV (alcance fijo, tiempo y esfuerzo variable).