Dinámica del taller online de Docker/Kubernetes

La semana pasada un publiqué artículo contando mi intención de hacer un taller online sobre Docker y Kubernetes. Resulta que hubo varios interesados y por ello ahora quiero compartir algunos detalles sobre la dinámica del taller.

La idea taller es aprender haciendo, con lo cual no bastará con asistir a las sesiones online para aprender. Las sesiones online estarán centradas en 2 cuestiones: presentación/explicación de conceptos y discusión/consultas. Luego, entre sesión y sesión, habrá actividades de estudio y prácticas que es donde espero se produzca el aprendizaje

El taller constará de 4 sesiones online de 2 horas. Cada una de esas sesiones será complementada con  un conjunto de ejercicios, lecturas y evaluaciones de nivel que según mi estimación requerirán de unas 2 o 3 horas de trabajo por semana. La duración calendario del taller será 4 semanas.

Los participantes trabajarán localmente en sus máquinas y para algunos ejercicios específicos utilizarán servicios en la nube. Al final de taller los participantes dispondrán de las diapositivas utilizadas, una serie de materiales de estudio y obviamente el código de los ejercicios que hayan resuelto.

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).

Fin de cuatrimestre en MeMo2 @ FIUBA

Y así pasó el primer cuatrimestre de Métodos y Modelos en la Ingeniería de Software 2 (a.k.a. MeMo2). Hay mucho por mejorar pero para ser una primer corrida de una materia armada de cero, creo que estuvo muy bien.

Comparto algunos números concretos para la estadística:

  • Se inscribieron 3 alumnos pero uno abandonó en la semana 4. Los otros dos completaron la  materia.
  • La nota promedio de aprobación fue 8.5
  • La evaluación general del curso por parte de los alumnos fue 9
  • Los alumnos dedicaron en promedio unas 5 horas semanales de trabajo extra clase

Entre los puntos a considerar para futuras ediciones:

  • Como escalar la dinámica de clases para más alumnos (la dinámica actual, con un solo docente puede andar hasta unos 8 alumnos)
  • Agregar videos sobre algunos temas faltantes
  • Mejorar el flujo de entrega/devolución de tareas

Selfie de cierre de cursada

Cierre de cuatrimestre en Ingeniería @ UNTreF

La semana pasada cerramos el cuatrimestre en la materia Ingeniería de Software en UNTreF. Fue mi tercer cuatrimestre en la materia y personalmente estoy muy conforme con el resultado. Algunas particularidades de este cuatrimestre fueron:

  • Tuvimos un cambio en el equipo docente, Diego Marcet (@diemarcet) reemplazó a Pablito Tortorella (@pablitux)
  • Cambiamos el campus virtual que usamos como herramienta de soporte, pasamos de Eliademy a Canvas.
  • Hicimos algunos ajustes en el programa, incluyendo algunos temas nuevos relacionados principalmente a cuestiones de control de calidad y gestión de la operación
  • Tuvimos dos clases especiales: una sobre modelos de calidad dictada por Sergio Villagra y otra dictada por Fernando Pelliccioni quien compartió la forma de trabajo de su equipo de desarrollo en Bitprim

En términos estadísticos:

  • 8 inscriptos, 1 abandono, 7 aprobados
  • La nota promedio de cierre de cursada fue 8,9
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue 8,3

Entre los puntos a mejorar que identificamos en el cierre de la materia destacamos:

  • Mejorar la consigna de la tarea de performance testing
  • Agregar un video introductorio a JMeter
  • Revisar el envió de notificaciones del campus (varios reportaron que la notificaciones les llegaban con mucho retraso)
  • Repetir el ejercicio del elefante carpaccio que fue de las mejores actividades de la materia
  • Comenzar antes con el desarrollo del trabajo final
  • Intentar que las tareas individuales se hagan sobre la misma base de código que el trabajo final
  • Hacer una introducción técnica a Padrino
  • Probar haciendo que las iteraciones del trabajo final sean de 2 semanas

Comienzo de MeMo2 @ FIUBA

El lunes pasado comenzamos las clases de Métodos y Modelos en la Ingeniería de Software 2 en FIUBA (aka MeMo2). Tan solo 3 alumnos inscriptos, lo cual está bien para una primera edición de la materia, creo que nos va a permitir experimentar y pivotear a nivel planificación y dinámica de clases. Más allá de esto, debo decir que en los casi 20 años que llevo en FIUBA, nunca estuve en un curso con tan pocos participantes.

Los tres alumnos tienen experiencia laboral en el rubro informático, un detalle que me parece importante dados los temas que pensamos abordar en la materia. Si los alumnos no tuvieran experiencia laboral, se corre el riesgo de que no vean el valor de los temas abordados. Es como si uno les estuviera explicando soluciones a problemas que ellos aún no imaginan.

Continuará…

Cierre de AyDOO 2017 en UNTreF

Se fue otro cuatrimestre y como de costumbre es momento del informe de cierre.

El primer punto a destacar es que, incorporando el feedback de la edición anterior, ajustamos la carga de trabajo y ampliamos el equipo docente. En la edición anterior yo fui el único docente, mientras que en este caso, también participaron de la materia Facundo Arcieri y Diego Fontdevila. Personalmente creo que esta extensión del equipo fue muy positiva. Más allá de esta cuestión contextual, las métricas del curso fueron:

  • 14 inscriptos, 2 abandonos, 8 aprobados y 4 desaprobados.
  • La nota promedio de cierre de cursada fue 8/10.
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue de 7,9/10.

Como siempre cerramos la materia con una retrospectiva. Entre los puntos a probar/mejorar surgieron:

  • El tiempo de corrección, en varios casos nos demoramos más de una semana en entregar las correcciones de las tareas semanales
  • Cambiar el campus, pues el que usamos tuvo varias caídas y algunas de las funcionalidades ofrecidas no están muy logradas
  • Hacer más ejercicios con Ruby y/o empezar a trabajarlo antes
  • Armar el calendario de entregas de forma tal de tener 2 semanas de trabajo entre la fecha de publicación de cada tarea y la fecha de vencimiento

Por otro, entre los puntos positivos de la materia los alumnos identificaron:

  • El uso del campus virtual
  • El stack de herramientas utilizado
  • La dinámica de cursada con evaluación constante

 

 

MeMo2 @FIUBA: planeado la dinámica de cursada

MeMo2 @FIUBA: planeado la dinámica de cursada

La primera edición de la materia va a ser bastante particular porque esperamos alrededor de 5 alumnos. Esto nos va a permitir dar algunas libertades poco habituales como que podamos tener la clase sentados todos juntos en una mesa sin siquiera necesitar pizarrón y/o proyector.

Pero más allá de esta primera edición, la idea es que a mediano/largo plazo la materia tenga una dinámica similar a la materia Ingeniería de Software que dicto en UNTREF y que no dista mucho de la dinámica de MeMo1. Siendo más concreto la idea es:

  • Clase invertida y “desde el fondo del aula”: la mayoría de los contenidos teóricos serán provisto en video para que los alumnos los puedan ver en sus casas. De esta forma el tiempo en el aula se dedica a actividades interactivas donde los alumnos toman más protagonismo y el docente pasa a un segundo plano poniéndose “al fondo del aula”. Para esta primera edición tendremos algunos pocos videos.
  • Tareas semanales y evaluación continua: al igual que ocurre en los proyectos de desarrollo, hay que trabajar de forma continua y sostenida. Ese trabajo continuo se evalúa de forma continua sin necesidad de los tradicionales parciales en papel. Esto ya lo estaremos haciendo en la primer edición.
  • Aula extendida: más allá de trabajo en clase, utilizaremos una plataforma virtual que nos permita compartir el contenido y extender la interacción más allá de aula física. La plataforma que vamos a utilizar es CanvasLMS.

Continuará…