Enseñando prácticas DevOps

La semana pasada presenté en la conferencia ARGENCON 2022, IEEE Biennial Congress of Argentina un artículo formal (experience report) que describe la forma en que abordamos las cuestiones relacionadas a DevOps en el contexto de MeMo2

Este artículo junto con los publicados por Sergio Villagra (Teaching software engineering: an active learning experience) y Carlos Fontela (Learning Communication Skills in Software Development Management Courses: An Active Learning Experience), resume de forma bastante acabada el núcleo de Ingeniería de Software de la carrera de Licenciatura en Análisis de Sistemas de Universidad de Buenos Aires. En un par de semanas el artículo estará disponible en IEEE Explore.

Clases virtuales condicionadas

Luego de 2 años de clases obligadas en modalidad virtual, la mayoría de los alumnos siguen prefiriendo esa modalidad. De mi lado docente, si bien la virtualidad me resulta en cierto modo más cómoda (no tengo que trasladarme hasta la universidad) hay ciertas cuestiones que me resultan mucho más incómodas y que en el balance me llevan a elegir la presencialidad en varias casos.

Concretamente me genera una gran incomodidad dar clases virtuales para una audiencia «ausente»: gente con cámara apagada (o sin cámara) y con nula participación durante la clase. La participación «verbal» puede que no cambie en un esquema virtual o presencial (hay gente que incluso estando en el aula física, no aporta ni una palabra durante toda la clase), pero a pesar de eso, el poder ver las caras ofrece al menos cierto grado de feedback infinitamente más rico que una foto de perfil.

Es por eso que para este segundo cuatrimestre 2022 de MeMo2 vamos a regular la virtualidad acorde a la participación de los alumnos. Si los alumnos quieren clases virtuales entonces deben tener sus cámaras encendidas. En la medida que la mayoría de las cámaras permanezcan apagadas vamos a optar por más clases presenciales. Según la planificación que hicimos tenemos 6 clases que si o si serán presenciales y otras 2 que si o si serán virtuales. El resto de las clases, tenemos la flexibilidad de poder darlas en cualquiera de las dos modalidades.

Cambios en MeMo2 @ FIUBA

Para este segundo cuatrimestre de 2022 estamos considerando realizar varios cambios en la dinámica de la materia.

En primer lugar tenemos un cambio importante en el equipo docente. Emilio Gutter quien venía desempeñando funciones de JTP ya no estará en la materia. Su lugar lo tomará, al menos parcialmente, Hernán de la Fuente, ex-alumno de la materia, miembro del equipo hace ya varios años y muy próximo a graduarse. También tenemos algunos otras bajas, no todas ellas cubiertas, con lo cual el tamaño del equipo se verá disminuído.

Por otro lado vamos a cambiar el orden de algunos temas y la forma en que los damos. Vamos a mantener una modalidad híbrida en la apuntamos a realizar cambios significativos en la dinámica de las clases presenciales.

También tenemos la intención de «reenfocar» algunas cuestiones, concretamente vamos a quitar un poco de relevancia al modelado de objetos/clases para poner más foco en el proceso de construcción (BDD/TDD) y el trabajo en equipo. Esto implica que algunos de los ejercicio individuales de programación pasarán a ser ejercicios en grupales.

Finalmente el último cambio es tal vez el de mayor impacto, vamos a cambiar el mecanismo de evaluación. Hasta el momento no tomábamos parciales ni final. La evaluación de los alumnos era constante a partir de las distintas tareas semanales y proyecto de TP. La idea es mantener eso pero adicionalmente agregar una instancia de evaluación al final de la materia donde cada alumno individualmente tenga que desarrollar «en vivo» una funcionalidad sobre su proyecto. Cuando digo en vivo me refiero a una sesión tipo pairing, donde el alumno acompañado por un docente desarrolla una funcionalidad de acuerdo al proceso y técnicas estudiadas en la materia. Esto no debería representar ningún desafío para los alumnos ya que es lo que hacemos durante la materia. ¿Entonces por qué lo vamos a hacer? Porque tenemos la sospecha de que al trabajar en equipo no todos los miembros asimilan los conceptos, como que algunos «delegan» en sus compañeros.

Cierre de cuatrimestre en UBA: ¡volvimos!

Luego de dos años de completa virtualidad, en marzo de 2022 volvimos a las aulas. Pero dado que descubrimos que algunas cuestiones funcionaban mejor en modo virtual, la vuelta fue mixta. La facultad habilitó un esquema híbrido con un cierto porcentaje obligatorio de clases presenciales y el resto a criterio de cada docente. En el caso de MeMo2, hicimos principalmente presencial la primera parte de la materia y principalmente virtual la segunda parte.

Para ser «el primer cuatrimestre del regreso» creo que estuvo bien y confío en que aún podemos mejorar algunos aspectos. De todas formas tengo la sensación de que gran parte de los alumnos (¿casi todos?) prefiere quedarse en la virtualidad total. Al margen de la vuelta parcial a la presencialidad, este cuatrimestre tuvimos 2 cambios relevantes respecto de cuatrimestres anteriores: 1) dedicamos una clase a hacer el setup de la infraestructura del TP2 (creación del clúster de kubernetes, configuración del pipeline, etc), cosa que previamente lo veníamos haciendo los docentes «tras bambalinas» y 2) Reciclamos un TP2 existente (hasta el momento, cada cuatrimestre «inventábamos» un nuevo TP). Creo que ambos cambios fueron positivos.

En lo referente al desempeño de los alumnos notamos una disparidad importante en la dedicación del TP2. Contexto: el TP2 tiene un alcance fijo (negociable) y dadas las capacidades de cada equipo puede que el tiempo requerido para completarlo sea distinto para cada uno. Lo que vimos es que en términos de calificación todos los equipos tuvieron notas muy similares (menor dispersión de notas que cuatrimestres anteriores), pero al ver la dedicación tenemos en un extremo equipos que completaron el TP2 en ~80 horas mientras que otros dedicaron ~170 horas. Mi explicación de esto tiene que ver con 2 cuestiones: 1) afinidad de los miembros de equipo y 2) experiencia / «habilidad» técnica (no necesariamente en este orden):

  1. No es lo mismo un equipo cuyo miembros son amigos y vienen trabajando juntos en varias materias que un equipo cuyos miembros recién se conocen y que tal vez no se llevan muy bien.
  2. No es lo mismo un equipo cuyos miembros ya tienen experiencia profesional programando y están familiarizados con el stack de herramientas que un equipo donde no todos sus miembros tienen experiencia profesional programando y que desconocen completamente el stack de herramientas. Aquí también entra en juego «la maña» que cada uno se puede dar para resolver dificultades técnicas.

Respecto de 1) no veo que como docentes podamos hacer mucho más allá de permitir que los alumnos armen los equipos a su parecer y de forma temprana en la materia como para que se vayan conociendo. Respeto de 2) lo que intentamos hacer es contestar muy rápidamente las consultas de indole técnicas y proveer a los alumnos con guías/videos para facilitar las cuestiones técnicas/tooling.

Las encuesta interna del curso nos arrojó los siguientes números:

  • Evaluación general de la materia: 8.1 / 10
  • Conformidad con la nota de aprobación: 4.8 / 5
  • Dedicación semanal extra-clase: 8.6 horas
  • Materiales de estudio: 4.0 / 5
  • Claridad de los docentes: 4.3 / 5
  • Conocimientos de los docentes: 4.9 / 5
  • Dinámica de las clases: 4.1 / 5
  • Net Promoter Score: 37.5 (métrica que puede oscilar entre -100 y +100)

Comenzamos el cuatrimestre con 22 alumnos, 2 abandonaron en las primeras semanas y los restantes 20 aprobaron la materia. Lo nota promedio de aprobación fue 8 lo cual es lo mismo que el cuatrimestre anterior pero en este caso la dispersión fue menor.

Como de costumbre cerramos el cuatrimestre con una retrospectiva pero esta vez entre barbijos (que solo algunos nos los sacamos para la foto final)

Y un día volvimos al aula…

Todos con tapabocas, con menos distanciamiento que el recomendado pero con puertas y ventanas abiertas, el pasado lunes 21 de marzo volvimos al aula. Si bien creo que nos adaptamos muy bien a las clases online no hay como la interacción dentro del aula.

Algunas clases de MeMo2 claramente conviene que sean virtuales, principalmente aquellas que incluyen actividades de programación. En esos casos resulta muy conveniente que el alumno pueda trabajar sobre su propia computadora. Del mismo modo, hay otras clases en las que la presencialidad es un valor diferencial. Un claro ejemplo de esto es la primer clase de curso, donde conocemos y comenzamos a intentar generar una relación de confianza que facilite el proceso de enseñanza-aprendizaje.

Llevamos 2 semanas de clase y hasta el momento tengo en claro que la primera clase debería ser presencial (por lo que mencioné previamente) mientras que la segunda debería ser virtual, para que los alumnos puedan hacer el setup de sus computadoras durante el tiempo de clase y que eventualmente podamos asistirlos en vivo.

Como de costumbre, en la primera clase les pedimos a los alumnos que completen la encuesta de perfil. Una vez más nos encontramos con situaciones incómodas como ser el tener alumnos con cantidades muy dispares de materias aprobadas: en un extremo 15 y en el otro 32.

También tenemos disparidad en la edad: gente de 21 y gente de 42.

Un rubro en el que notamos un cambio respecto del histórico de la materia es en el laboral. Este cuatrimestre tenemos que el 81% de los alumnos ya trabaja en un actividad afín de la carrera, porcentaje que tradicionalmente estaba en torno al 70%.

Cierre de 2021 en MeMo2 @ FIUBA

Y se nos fue un cuatrimestre más en modalidad virtual. Ya el cuarto. Personalmente estoy muy contento debido principalmente a 3 cuestiones, paso a enumerar en orden aleatorio.

Una de las cuestiones destacadas es que me parece que logramos transmitir de forma efectiva la propuesta de Desarrollo Guiado por Pruebas (TDD ourside-in). Este es un tema que venimos dando desde que comenzamos a dictar la materia pero que creo que este cuatrimestre en particular logramos transmitir esta técnica de forma efectiva. Digo esto basado en ciertas charlas que se dieron con los alumnos, en los trabajos realizados y en el resultado de una actividad de relevamiento que hicimos en clase que se puede apreciar en la figura 1.

Figura 1. Resultado de la actividad de relevamiento de TDD

Otra cuestión destacada son ciertos ajustes internos en la dinámica del TP2. La forma en que presentamos el problema, el mecanismo de seguimiento y tutoría que implementamos para guiar a los alumnos y un conjunto de checklist que implementamos como herramientas de soporte para los docentes. Creo que esto nos permitió mejorar la experiencia de docentes y alumnos en el desarrollo del TP2.

Finalmente, un objetivo que nos habíamos propuesto a partir del feedback del cuatrimestre anterior, fue disminuir la carga de trabajo del TP2. Este objetivo lo logramos con éxito aun cuando esa carga de trabajo es importante, este cuatrimestre fue menor que el cuatrimestre anterior.

Creo que directa o indirectamente todas estas mejoras se reflejan en los resultados de la encuesta final del curso:

  • Evaluación general de la materia: 9.1 / 10
  • Dedicación semanal extra-clase: 9.1 horas
  • Materiales de estudio: 4.1 / 5
  • Claridad de los docentes: 4.5 / 5
  • Conocimientos de los docentes: 4.6 / 5
  • Dinámica de las clases 4.5 / 5
  • Nota promedio de aprobación: 8
  • Conformidad con nota de aprobación: 4.7 / 5
  • Net Promoter Score: 79 (métrica que puede oscilar entre -100 y +100)

De estas 10 métricas, 9 tienen mejores valores que el cuatrimestre anterior. Al mismo tiempo la Evaluación general de la materia tiene un máximo histórico (9.1 vs. el máximo anterior de 8.9). El otro valor record es el NPS que marca 79 vs. el máximo anterior de 42.
Un punto a mencionar es que no todos los alumnos contestaron la encuesta (tenemos 19 respuestas sobre un total de 26 alumnos), este es un tema recurrente, como la encuesta es anónima y como la hacemos una vez terminada la materia no hemos encontrado un mecanismo para asegurar que todos los alumnos la completen. Pero dado que este es tema recurrente de todos los cuatrimestres creemos que la igualmente la encuesta sigue siendo un elemento válido para medir el curso.

Finalmente, para dar un poco más de contexto comparto algunos otros números del curso:

  • Cantidad de inscriptos: 30
  • Abandonos: 4
  • Aprobados: 26
  • Tareas individuales: 42
  • Trabajos grupales: 2
  • Visitas de la industria: 1

Percepciones de mis alumnos sobre TDD y otras prácticas de desarrollo

En MeMo2 estudiamos diversas prácticas de desarrollo que luego pedimos a los alumnos utilizar durante el desarrollo de los trabajos grupales. En la clase de ayer, a punto ya de terminar el cuatrimestre, hicimos una muy breve actividad para relevar cómo les resultó el uso de esas prácticas.

Nos centramos en 3 prácticas concretas: Test-Driven Development (outside-in style), Mob-Programming y Trunk-Based Development. Para cada una de estas prácticas les pedimos que se ubiquen en lo que seria un «cuadro cartesiano» donde un eje horizontal representa cuánto utilizaron la práctica y el eje vertical representa el grado de confort/utilidad que sintieron con esa práctica.

En el caso de Mob-Programming las respuestas estuvieron bastante dispersas y sin extremos.

Pero para Trunk-Based Development y Test-Driven Development las respuestas resultaron mucho más categóricas: la gran mayoría indicó haber utilizado mucho lás prácticas con un grado positivo de confort/utilidad.

Personalmente estoy muy contento con estos resultados, que los alumnos perciban utilidad en lo que enseñamos resulta muy reconfortante. La gran duda (habitual en el ámbito académico) es cuanto finalmente terminan «comprando» estas prácticas los alumnos, o sea: fuera del contexto de la materia ¿seguirán utilizando estas prácticas?…..

Cierre de cuatrimestre en MeMo2@fiuba

Se fue un cuatrimestre más, el noveno desde que estoy a cargo de la materia. Comencemos por los números:

  • 16 inscriptos, 2 abandonos, 1 desaprobado, 13 alumnos aprobaron la cursada
  • 41 tareas individuales incluyendo 9 cuestionarios, 7 ejercicios de programación, 12 lecturas y 11 videos
  • 2 TPs grupales
  • 1 visita de la industria
  • La evaluación general promedio de la materia nos dio 8.2, la cual es la segunda más baja en el histórico (el máximo que teníamos era 8.9). 
  • Curiosamente, contrastando con la métrica anterior, nota promedio de aprobación fue 8.3 (máximo histórico) y la conformidad con la nota fue 4.5 (máximo histórico)
  • La dedicación extra clase promedio dio 12.3, el máximo histórico (el anterior máximo era 9.7). Esto está claramente por encima de nuestra expectativa. Nuestra intención es que como máximo los alumnos dediquen unas 10 horas semanas extra clase.

Adicionalmente, este cuatrimestre medimos por primera vez el Net Promoter Score (NPS): De 1 a 10 ¿Cuán probable es que recomiendes la materia a un compañero?). No voy a entrar en detalle de cómo se calcula el NPS al procesar las respuestas, solo diré que el cálculo nos arrojó un NPS de +42 (en una escala de -100 a +100), lo que representa una calificación favorable.

Entre los temas a mejorar hay 1 que particular se destaca: la gran carga de trabajo requerida por el TP2. A nuestro parecer el TP2 de este cuatrimestre era más simple y acotado que los de los cuatrimestre anteriores, pero creemos que la mayoría de los alumnos tuvieron complicaciones al implementar la persistencia de objetos en una base de datos relacional. En este sentido estamos considerar agregar más soporte sobre esta temática, ya sea generando documentación/videos, código de ejemplo e incluso algunos ejercicios para resolver en clase.

¿Qué significa calificar con un 10?

Ayer por la tarde estaba cerrando las calificaciones de MeMo2 y mientras lo hacía se me cruzaron algunas ideas que quiero compartir.

De entrada, dado que 10 suele ser la calificación máxima, uno podría pensar que un 10 equivale a haber hecho todo bien. Sin embargo no siempre es así.

En mi época de estudiante en mi carrera de grado recuerdo haber cursado una materia en la que el algoritmo de calificación era: al que mejor resolvió el problema un 10 (y luego de ahí para abajo) incluso esa solución no sea la mejor solución conceptual. Personalmente no comparto este criterio pero simplemente lo menciono como un ejemplo de que un 10 no siempre implica haber hecho todo bien.

El problema o mejor dicho la limitación que tiene el reservar el 10 solo para el caso en que «está todo bien», no da lugar a la equivocación, al error, el cual es en muchos casos una oportunidad de aprendizaje. Es por esto que cuando decido calificar con un 10 no es un hecho que el alumno haya hecho todo bien. O sea, si el alumno hizo todo bien, no hay duda: tendrá un 10. Pero puede también que el alumno haya cometido algunos errores y aún así tenga un 10. Al fin y al cabo lo que uno pretende evaluar es el aprendizaje y en ese sentido uno podría pensar que haberse equivocado y aprendido de esa equivocación termina siendo un aprendizaje más significado que haber hecho todo bien de entrada.

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.