Los alumnos sobre Mob-Programming y TDD

En MeMo2 @ingenieriauba hacemos un primer TP grupal en el que los alumnos deben evolucionar una webapp existente siguiendo un proceso XP-like (iteraciones semanales, planning, review, retro, CI/CD, DDD, BDD/TDD, etc).

Entre las cosas que más énfasis hacemos y que más les cuesta (o que más resistencia le ponen) los alumnos está el desarrollar guiados por pruebas (bdd/tdd) y trabajar todo el tiempo haciendo Mob-Programming (o al menos pair-programming). También les pedimos que hagan Trunk-Based development.

TDD es algo que ya han visto en alguna materia anterior pero de una forma mucho menos profunda que lo que proponemos en MeMo2. En general los alumnos tiene una buena recepción porque nuestra propuesta de BDD+TDD ofrece una guía muy detallada de como transitar el proceso de construcción desde la intención del usuario hasta el código que implementa esa intención en un ambiente donde el usuario puede utilizar la pieza de software construida.

La propuesta de Mob/Pair-Programming les resulta más “rara”, sobre todo a los que ya vienen con experiencia laboral. Posiblemente varios de los que ya trabajan en desarrollo no tendrían el visto bueno de sus jefes si pretendieran trabajar todo el tiempo (o la mayor parte) haciendo Mob/Pair Programming. Por esto es que insistimos tanto en que hagan Mob-Programming, si no lo prueban en nuestra materia, es posible que tampoco lo puedan probar en sus trabajos.

Algo similar ocurre con el uso de Trunk-Based development. Muchos de los que ya trabajan suelen utilizar feature-branches (como creo que hace gran parte de los desarrolladores actualmente) y entonces “temen” trabajar todos simultáneamente sobre el mismo branch. La clave aquí de nuestra propuesta es que al trabajar haciendo mob-programming solo hay un único branch de desarrollo activo, con lo cual resulta natural hacer trunk-based development. Al mismo tiempo y más allá de hacer mob-programming, nosotros insistimos en trabajar en pequeños incrementos haciendo commits al trunk/master cada 20 o 30 minutos como máximo, con lo cual las chances y el tamaño de divergencia al trabajar se reduce mucho, llevando casi a cero el tiempo requerido en arreglar conflictos de merge.

El jueves pasado al finalizar la segunda iteración del trabajo grupal hicimos una actividad con los alumnos para relevar cuanto habían usando las técnicas recomendadas y cuán útiles les habían resultado.

Los siguientes gráficos muestran el resultado de la actividad.

Mi sensación es que la mayoría de los alumnos “compra” nuestra propuesta. Veremos que opinan al finalizar el siguiente TP que reviste una complejidad mucho mayor y donde creo que estas técnicas suman aún más valor.

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á…

A Flipped Classroom Experience Teaching Software Engineering

The paper will be presented at the 1st International Workshop on Software Engineering Curricula for Millennials (SECM2017)

Abstract: New teaching approaches like the flipped classroom are an interesting alternative to educate new generations but they represent new challenges for teachers. This paper describes our experience re-designing our classes and study materials in order to adopt a flipped classroom approach combined with some other non-traditional teaching techniques. This experience is focused on the Software Engineering course at Universidad Nacional de Tres de Febrero. In this paper we share details of our strategy, the positive results we obtained and the concerns we still need to address.

Keywords: experience report; flipped classroom; education; agile; software engineering

Download full-paper

Pase: de Algo3 a MeMo2

Pase: de Algo3 a MeMo2

Después de más 15 años como parte del equipo docente liderado por Carlos Fontela y a cargo de la materia Algoritmos y Programación 3, este año emprenderé un nuevo camino.

Resulta que a partir de la implementación del nuevo plan de estudios de la Licenciatura hay que empezar dictar nuevas materias y eso requiere del nombramiento de nuevos docentes o de la reubicación de los docentes existentes. Este segundo caso es el mío.

En particular en el segundo cuatrimestre de este año debe comenzar a dictarse la materia Métodos y Modelos en la Ingeniería de Software 2 (a.k.a. MeMo2). Como su nombre lo sugiere, esta nueva materia es la continuación de Métodos y Modelos en la Ingeniería de Software 1 (a.k.a. MeMo1) que es una materia (hoy en día) equivalente a la materia Análisis de la Información del plan anterior. MeMo1 empezó a dictarse hace un par de cuatrimestres y su equipo docente está liderado por Sergio Villagra. Para asegurar cierta consistencia entre MeMo1 y MeMo2, Sergio también estará involucrado en MeMo2. Por mi parte, durante este primer cuatrimestre estaré participando de MeMo1 y trabajando en el armado de MeMo2.

Debo admitir que dejar Algo3 no fue una cuestión fácil. Si bien el equipo docente de Algo3 ha ido variando a lo largo de todos estos años, somos varios los que llevamos más de 10 años trabajando juntos. Creo que justamente es esa combinación del “núcleo de veteranos” con “la sangre de los nuevos colaboradores” y el compromiso de mejora continua de todo el equipo, lo que ha motivado a que la materia este en una constante evolución. Al mismo tiempo armar y dictar MeMo2 representa un gran desafío y una importante oportunidad de crecimiento en mi carrera docente y es por ello que acepté el pase.

Me voy de Algo3 muy contento de haber trabajado con ese gran equipo docente e infinitamente agradecido a Carlos Fontela por haberme invitado a sumarme al equipo allá por el año 2000.