Etiqueta: memo2

Cierre de cuatrimestre en FIUBA 2025-2

Como todos los cuatrimestre cerramos el curso con una actividad tipo retrospectiva y fue en ese actividad en la que un alumno destacó el hecho de que tratamos a los alumnos por su nombre. Claro, resulta que esta camada de alumnos es parte de la ola ingresó a la facultad a hace un par de años y que incrementó la matrícula de forma importante, como consecuencia de ello muchos de estos alumnos estuvieron en cursos multitudinarios (más de 60 alumnos) donde resulta prácticamente imposible para un docente retener el nombre de los alumnos. A esto hay que sumarle que una parte de las clases se realiza en forma virtual y la gran mayoría de los alumnos no enciende la cámara e incluso ni siquiera tiene foto de perfil. De esta forma los alumnos llegan a nuestro curso que no es tan masivo (este cuatrimestre terminamos con ~20 alumnos), donde una importante cantidad de clases son presenciales, donde les exigimos que pongan foto de perfil en todas las herramientas que utilizamos y donde los alumnos trabajan en vivo en equipos de 4, con un docente dedicado durante varias semanas. Esto habilita a que uno como docente pueda aprender el nombre de los alumnos y eso es lo que el alumno destacaba en contraposición a la gran mayoría de los cursos anteriores.

Al margen de esta curiosidad Tuvimos un cuatrimestre muy desafiante ya desde la previa con record de inscriptos. Como suele ocurrir en los últimos años en varias materias de fiuba, hay muchos alumnos se inscriben y luego ni siquiera asisten a la primera clase. Es así que a pesar del record, podemos decir que comenzamos el cuatrimestre con unos 46 alumnos que asistieron a la primera clase, de los cuales solo 25 completaron la primera parte de la materia. Finalmente 19 alumnos aprobaron el curso y están en condiciones de rendir el final oral.

Este cuatrimestre también empezamos a ver una consolidación del perfil de alumno de nuestro curso:

  • amplia mayoría sin experiencia laboral (~82%)
  • edad promedio de los alumnos: ~23 años
  • cantidad de materias aprobadas incluyendo CBC: ~23 (según el plan deberían llegar con 24)
  • cantidad de materias cursando este cuatrimestre: 3,7 (según el plan deberían cursar 4)

Algunos números concretos surgidos de nuestra encuesta:

  • Cantidad de respuestas: 17
  • Evaluación general del curso: 8,9 / 10 (desvío 0.8)
  • Claridad de los docentes: 4,6/ 5
  • Conocimiento de los docentes: 5 / 5
  • Dinámica de las clases: 4,9 / 5
  • Conformidad con la nota: 4,4 / 5
  • NPS: 71
  • Dedicación semanal extra-clase: ~11 horas

Entre los puntos a mejorar claramente destaca la necesidad de ajustar el esfuerzo requerido para completar el TP que en este cuatrimestre requirió en promedio por equipo de unas ~260 horas (con un desvío ~85) distribuido en 3 semanas. Una curiosidad que vemos en este punto es que la mayor dedicación no implica mejor calificación, de hecho pareciera ser al revés, un tema que da para el análisis.

Algunos comentarios anónimos que los alumnos dejaron en la encuesta:

«Me gusto mucho la modalidad de ver videos sobre un tema y luego en la clase de los lunes retomarlos pero con «intensidad». La organizacion es otro de los puntos fuertes.»

«Buena onda de las clases. Clases participativas. Se notan las intenciones de querer enseñar y de querer que los alumnos aprendamos.»

«Excelente dinámica y temas, salí de la materia con 10 veces más de experiencia que con la que entre, definitivamente una cursada muy enriquecedora.»

«Se siente como el cuerpo docente se involucra bastante con los alumnos para que se sienta una enseñanza más personal lo cual ayuda mucho a asimilar varios conceptos y práctica.»

Cierre de cuatrimestre 2025-1c @FIUBA

Se fue el primero de 2025 y no fue fácil. Los últimos cuatrimestres veníamos viendo una mejora en diversos aspectos que lamentablemente no continuaron este cuatrimestre.

Por un lado la evaluación del curso por parte de los alumnos fue peor que lo que venía siendo en los últimos cuatrimestres: veníamos alrededor de nueve y con una dispersión mínima (todas evaluaciones 8,9 y 10), ahora tuvimos un evaluación de 8 con mucha dispersión (4, 6, 7, 8, 9 y 10).

Al mismo tiempo el desempeño de los alumnos fue también «más bajo», la nota promedio de evaluación que había sido de 7,3 ahora fue 6,9.

No tenemos una explicación certera de esta situación pero hay ciertos hechos que pueden haber influido:

  • Tuvimos una cantidad record de alumnos
  • Uno de los ayudantes colaboradores abandonó a mitad del cuatrimestre y eso nos trajo ciertas complicaciones
  • El reciente cambio del plan de estudio produjo, entre otras cuestiones, cambios de correlatividades lo cual a su vez produjo cambios en el perfil de los alumnos.

Al margen de los fríos números, en las encuestas nos encontramos con comentarios diversos casi todos muy positivos:

  • «Excelente materia. Top materias que he cursado. He visto cosas que me sirvieron para reafirmar conceptos y que también me sirvieron en el ámbito laboral»
  • «La dinamica que proponen da un golpe de realidad y un efoque en la integracion de los temas ya vistos de la carrera que me parece muy valioso. Ademas, para mi, los temas que tratan son clave para diferenciarse dentro del ambito laboral»
  • «Muy buenas las clases presenciales, muy dinámicas y las actividades ayudaron a entender mejor los temas de una manera divertida.»
  • «Pagás deuda técnica de materias anteriores»

Por otro lado, en la retrospectiva surgieron cuestiones habituales: la carga de trabajo, uso de otro lenguaje, más presencialidad, menos presencialidad. Pero algo que destacó fueron un par de menciones referentes al feedback y las devoluciones/correcciones. Aunque suene curioso, este es uno de los puntos en los que se expresa la falta de presupuesto: cuando la cantidad de docentes es menor a la apropiada cada docente debe dedicar más tiempo, eso hace que las devoluciones sean menos profundas y cuidadas. Según pudimos hablarlo, algunos alumnos sintieron que el feedback tenía una «carga negativa», de hecho alguien dijo literalmente «feedback duro, no cándido». Frases del tipo «este código no pasa de algo1» o «no se cómo llegaron hasta acá» no serían raras en mí. Reconozco que no son frases alentadoras pero tampoco me parecen tan duras. Por momentos pienso que puede haber alguna cuestión generacional, en mi época de estudiante recuerdo profesores con comentarios bastante menos corteses y en general nadie hacía problema por ello. Pero los tiempos cambian y uno debe adaptarse, en ello vengo trabajando. Sin embargo me queda la duda si no vamos a terminar formando «ingenieros de cristal».

La dificultad del trabajo final de Ingeniería de Software 2 @fiuba

El trabajo final de la materia consiste en resolver una problemática de negocio a partir de la implementación de una solución basada en software. Hasta aquí puede sonar como tantos otros trabajos de una materia de una carrera de sistemas. Pero en nuestro caso hay un par de cuestione (que tal vez tampoco son tan novedosas) que a los alumnos les cuestan bastante.

La primera cuestión es que no hay «un enunciado» ni una lista de funcionalidades, hay un «cliente» (rol ocupado por uno de los miembros del equipo docente) con un problema de negocio, los alumnos deben relevar el problema y plantear un proyecto para solucionarlo. Son los alumnos los que tienen que identificar las funcionalidades, darles forma de stories validarlas con el cliente, diseñar, codear, testear e implementar. Parece una desafío usual en una carrera de sistemas pero a pesar de eso muchos alumnos no saben por dónde empezar. Incluso cuando se supone que en materias anteriores ya vieron técnicas para lidiar con relevamiento y modelado de dominio.

Otra cuestión es que el proyecto deben desarrollarlo en 3 semanas, con iteraciones semanales al estilo XP. Eso implica planificar el trabajo a alto nivel (release plan) y también semana a semana, ejecutar dando visibilidad en un esquema de entrega continua y al final de la semana revisar lo realizado tanto a nivel producto como a nivel proceso. Insistimos en que el trabajo sea time-boxed lo cual implica que en caso de retrasos negocien/gestionen alcance. No hay problema en que no logren completar el plan de la semana siempre y cuando lo gestionen. No puede ocurrir que prometan X y luego caigan sorpresivamente a la revisión con menos de X. Seguir este proceso les cuesta muchísimo, en parte porque no tienen práctica en planificación, es un tema que tal vez vieron en alguna materia anterior pero casi sin práctica. Lo otro que suele constarles mucho es la negociación/gestión del alcance. En general si planifican X, hacen lo imposible por cumplir con X cuando muchas veces sería mucho más conveniente gestionar un recorte de alcance o simplemente avisar el cliente que no llegarán a cumplir con el plan. Incluso en ocasiones dejan de lado las buenas prácticas (modularización, testing, convenciones, etc, etc) lo cual no hace más que aumentar/generar deuda técnica que deberán pagar en el corto plazo.

Una de las cuestiones más novedosas para los alumnos es tener que lidiar con dos ambientes cloud, uno de pruebas y otro de producción. Esto en general no lo han hecho en ninguna materia. Esto por momentos se convierte en un gran desafío cuando algo les funciona localmente pero no en los ambientes cloud. Si bien les damos la infraestructura pre-armada y acceso a un log centralizado, muchas olvidan escribir mensajes de log con cual es como si estuvieran a ciegas. Esta cuestión de «build for operations» es uno de los temas de la materia y no esperamos que traigan conocimientos previos.

Finalmente lo que más me llama la atención es cuando los alumnos no aplican los conceptos que hemos estudiado durante toda la materia. El trabajo final juega un rol de trabajo integrador, previo a eso los alumnos trabajan en tareas individuales donde ponen en práctica diversos conceptos. Luego en el trabajo final deben volver a aplicar los conceptos ya estudiados pero ahora en un problema más complejo y trabajando en grupo. Una y otra vez vemos grupos que parecen haberse olvidado por completo de todo lo estudiado.

Notas de un cuatrimestre atípico @fiuba

Atípico básicamente por dos cuestiones: un cambio en plan de estudios de la carrera y una situación de movilización y defensa de la educación pública. Vamos por parte.

La situación sin precedentes de emergencia presupuestaria y ataque constante a la educación pública nos llevo a realizar varias acciones de visualización y apoyo, que entre otras cuestiones, nos llevó a realizar clases públicas.

Por otro lado, y al igual que en UNTreF, este cuatrimestre «estrenamos» curso en FIUBA a partir de la implementación del nuevo plan de Ingeniería Informática.

En este sentido, el curso que dicto actualmente está «homologado» como Métodos y Modelos en la Ingeniería de Software 2 (9521 para la carrera de Licenciatura en Sistemas) y como Ingeniería de Software 2 (TA049 para la carrera de Ingeniería Informática).

En lo formal el cambio de plan de Ingeniería Informática tiene un impacto menor en términos de contenidos, pero en la práctica vivimos dos impactos:

  1. Si bien la materia sigue ubicada en cuarto año, hay un cambio en la correlativas que hace que los alumnos puedan llegar habiendo recorrido un camino distinto de materias.
  2. Al mismo tiempo, como la materia no es correlativa de ninguna otra, es posible que esta materia sea la última de la carrera. De hecho este cuatrimestre tuvimos 3 alumnos para quienes esta fue su última materia.

Adicionalmente, debido a el proceso de transición entre planes, tuvimos gente gente en situaciones particulares respecto de las materias cursadas previamente.

A pesar de estos cambios creemos que el curso salió muy bien. Inicialmente parecía que sería más complicado pero luego la cuestión mejoró. Comenzamos el cuatrimestre con un record de inscriptos, según nos informó el departamento: 51 alumnos. Sin embargo, varios nunca aparecieron y en la segunda clase ya teníamos 33. Como de costumbre, durante el cuatrimestre se fueron bajando algunos más y finalmente terminamos la materia con 22 alumnos. Algunos otros números de nuestra encuesta:

  • La encuesta fue contestada por 18 alumnos
  • La evaluación general de la materia: 8,9 / 10
  • La nota promedio de aprobación fue 7,3/10 lo cual representa un mínimo histórico pero al mismo tiempo la conformidad con la nota fue 4,4 / 5.
  • Dinámica de clases fue 4,7/5 lo cual iguala el máximo histórico. Curiosamente algunos alumnos destacaron que lo mejor de la materia fueron las clases presenciales.
  • Respecto del porcentaje de presencialidad/virtualidad, 15/18 indicaron que les pareció indicado mientras que 2 hubieran preferido más virtualidad y 1 más presencialidad.
  • La dedicación semanal extra-clase, según reportaron en la encuesta, fue de 9 horas, sin embargo en el tracking de tareas ese número da 7,9.
  • El NPS nos dió 44

Por otro lado, en la actividad de cierre destacaron dos items accionables hacía adelante:

  • Proveer más material sobre Arquitectura Hexagonal, un tema central de la materia y que este cuatrimestre costó mucho.
  • Revisar la configuración de las reglas de code quality ya que algunas resultaron incómodas, sin sentido y/o demasiado exigentes.

Cierro con algunos comentarios de feedback libre de la encuesta:

«Excelente la materia, por momentos la odie, pero ya al haber terminado, puedo observar que la dureza y el nivel de exigencia valieron la pena y me enriquecieron en todo sentido.»

«Fue la materia en la que más aprendí en lo que va de la carrera»

«Me pareciero muy util el contenido dado y la forma de dictarlos. Me da lástima recién a esta altura de la carrera toparme con esta materia que siento que me hubiera servido mucho en otro momento. Me gustó mucho que se recomienden autores para leer sobre ciertos conceptos, que utilicemos TDD (por más que personalmente no me gusta, ahora le encuentro un gran valor) y sobre todo que hayamos tenido clases presenciales.
Me voy de la materia sintiéndome motivada a mejorar, queriendo investigar y profundizar sobre los temas que aprendí. Muchas gracias por a todo el equipo docente de la materia, me pareció muy bueno todo!»

Clase abierta bancando la #EducaciónPública

A partir del veto de la Ley de Financiamiento Universitario se están desarrollando diversas actividades en las universidades nacionales.

Es por eso que hoy, luego de más de 20 años de docencia universitaria, di por primera vez una clase pública. Luego de hablarlo con mi equipo docente decidimos que era el momento y la forma más apropiada de hacer visible nuestra posición y nuestro apoyo al reclamo universitario.

Configuramos el aula pública con una pizarra móvil y los escalones de explanada a modo de asiento. Con el ruido ambiente de la Avenida Paseo Coló, nuestra clase de Ingeniería de Software 2 comenzó a las 8:00 AM. Éramos los únicos en la explanada de la facultad pero hacia las 9:00 AM se fueron sumando otros cursos.

En la clase me acompañaron Kevin, Joaquin y Alejo, miembros de mi equipo docente. El tema que abordamos fue medio conceptual y bastante polémico: hablamos de modelos de branching, integración continua, trunk-based development y monorepos.

Creo que a pesar de la constante amenaza de lluvia, la clase salió muy bien en parte porque no llovió.

Como la situación no mejore, me temo que volveremos a repetir la experiencia.

Cambios en el perfil de alumnos de MeMo2 @ FIUBA

En MeMo2@fiuba comenzamos la primera clase con 24 alumnos, al poco tiempo solo teníamos 22 y en este momento tenemos 21. Una curiosidad de este cuatrimestre es que nos ha cambiado de forma sensible el perfil de los alumnos:

  • Tradicionalmente la mayoría de los alumnos que llegaba a la materia tenia un promedio de edad de 25 años pero este cuatrimestre el promedio de edad es 23 años.
  • Al mismo tiempo vemos un cambio en la condición laboral de los alumnos, históricamente la mitad de los alumnos llegaba con alguna experiencia laboral en sistemas (en 2019 el 70% de los alumnos ya estaba trabajando en la actividad, mientras que en 2021 ese número fue de 76%). Este cuatrimestre el 83% de los alumnos no tiene experiencia laboral en sistemas.

Estas dos cuestiones impactan diversos aspectos del curso: los alumnos al ser más jóvenes tienen menos «maduración» de la vida universitaria lo cual a su vez impacta en sus hábitos de organización y estudio. Al mismo tiempo al tener menos experiencia laboral, se encuentran menos «duchos» en cuestiones de programación y sobre todo en cuestiones de troubleshooting. Estas cuestiones las confirmamos en las métricas del curso: por un lado vemos que la resolución de los ejercicios de programación les lleva más de lo habitual (saben concretamente cuanto les lleva pues les pedimos que lo reporten al completar las tareas) y al mismo tiempo vemos que el desempeño es inferior (lo cual se refleja en las calificaciones). Para equipo docente esto impacta en que aumenta la cantidad de alumnos que se inscriben en curso y al mismo tiempo aumenta el esfuerzo que los docentes deben dedicar, no solo porque hay más alumnos sino porque esos alumnos requieren más atención/asistencia/seguimiento.

Este cambio en el perfil de alumnos creemos que se debe principalmente a dos cuestiones:

  • Por un lado, el horario de cursada: el año pasado cambiamos el horario del curso, veníamos dictando el curso durante la tarde/noche (de 19 a 22) y pasamos a la mañana (de 8 a 11)
  • Por otro lado, el cambio de plan de estudio: en el nuevo plan de ingeniería informática la materia se mantiene en el octavo cuatrimestre pero requiere de una combinación distinta de correlatividades que a mi parecer es más flexible.

La cuestión es que el perfil de alumnos cambió y eso nos está llevando a hacer algunos ajustes en la dinámica del curso.

PD: he estado ausente de este espacio por tiempo record. Pasé de publicar 1 o 2 artículos por semanas a no publicar nada durante 6 semanas. Resulta que comenzó el cuatrimestre y las dos materias que tengo a mi cargo sumadas a un cliente de mi actividad privada, redujeron mucho mi tiempo disponible para escribir. En fin, I ‘am back.

Perspectivas del inicio de clases 2024 @ fiuba

Tal vez el lector esté esperando algún comentario sobre la situación crítica que afronta la UBA (y la educación pública en general en Argentina), lamento decepcionarlo. No es que la situación me sea ajena o no despierte mi interés, pero por el momento intento mantener una de las premisas de este espacio: nada de política, fútbol o religión. No estoy seguro de cuánto mantendré esta idea, porque sinceramente la situación es preocupante y es definitivamente un tema de política y visión de país. En fin, vamos a la cuestión académica que es lo que quiero compartir.

Según indica el sistema de inscripción parece que este cuatrimestre tendremos record de alumnos tanto en la materia de grado (memo2@fiuba) como en postgrado (entrega_continua@untref).

En FIUBA tenemos 36 inscriptos, record histórico, el máximo anterior había sido 32. Esta cantidad de alumnos representa nuestro primer desafío para este 2024: mantener la calidad del cursos con más del doble de alumnos que los que veníamos teniendo (el cuatrimestre pasado tuvimos 13 alumnos).

A esto se suma un segundo desafío: alumnos del nuevo plan de estudio de Ingeniería Informática que vienen con una formación distinta por haber cursado materias distintas. Por lo que estuve relevando, son alumnos que vieron más cuestiones de diseño/programación y menos de proceso de desarrollo (usuarios, requisitos, scm/ci, ambientes, etc).

El primer impacto de esta situación está en la carga de trabajo del equipo docente, por suerte contamos con varios colaboradores (ex-alumnos de la materia) que serán un factor clave en el manejo de la carga de trabajo. Es por eso que a pesar de estos dos desafíos, estamos planificando el cuatrimestre igual que el cuatrimestre anterior, que consideramos nos dio muy buenos resultados. Eventualmente ajustaremos sobre la marcha si lo vemos necesario.

Sobre el uso y la enseñanza de Mob/Pair Programming

La práctica de Pair-Programming es un caso que me llama poderosamente la atención:

  1. Es una práctica que formalmente tiene ~25 años (o tal vez incluso más) [1].
  2. Hay numerosos estudios que respaldan sus beneficios [2,3] y por ello es que la utilizo en mis proyectos y también la enseño en mis cursos.
  3. Pero curiosamente es una práctica muy poco utilizada [4].
  4. Finalmente es una práctica mal interpretada, o sea: hay gente que cree que Pair-Programming es simplemente sentar dos programadores a trabajar en una máquina cuando en realidad hay mucho más que eso. (de esto no tengo pruebas pero tampoco dudas).

Este es un tema que en MeMo2 le damos bastante importancia por varias cuestiones:

1. Los beneficios que trae la convierten en una práctica importante.

2. «El ruido» y malas interpretaciones que hay sobre esta práctica.

3. Creemos fundamental que los alumnos prueben usar la práctica: si no la prueban en nuestra materia creemos muy poco probable que tengan chance y ganas de probarla en otros contextos.

Este cuatrimestre en MeMo2 pedimos a los alumnos que en el primer trabajo grupal nadie escriba código en solitario, o sea: estaban obligados a trabajar todo tiempo haciendo mob/pair programming. Obviamente antes de esto explicamos la dinámica de esta práctica.

En el segundo trabajo grupal cambiamos la consigna, les sugerimos que hagan mob-programming durante toda la primera iteración y que luego de eso trabajen de la forma que consideren más apropiada en las dos iteraciones siguientes. Pero fue solo una sugerencia y como tal no había obligación que la siguieran.

Una vez finalizado el segundo trabajo hicimos una actividad donde les pedimos a los alumnos que individualmente evaluaran la experiencia con cada una de las técnicas, solo-pair-mob, considerando: 1) cuánto utilizaron cada técnica y 2) cúan útil/cómodo que les resultó.

A continuación comparto los resultados para que el lector saque sus propias conclusiones. Yo hace mucho que me convencí que el camino no es solo, parece que no soy el único.

Referencias

[1] Beck, K. (1999). Extreme Programming Explained: Embrace Change. United Kingdom: Pearson Education.

[2] L. Williams, R. R. Kessler, W. Cunningham and R. Jeffries, «Strengthening the case for pair programming,» in IEEE Software, vol. 17, no. 4, pp. 19-25, July-Aug. 2000, doi: 10.1109/52.854064.

[3] Chong, Jan & Plummer, Robert & Leifer, Larry & Klemmer, Scott & Eris, Ozgur & Toye, George. (2005). Pair programming: When and why it works.

[4] Paez, N., Fontdevila, D., Gainey, F., Oliveros, A. (2018). Technical and Organizational Agile Practices: A Latin-American Survey. In: Garbajosa, J., Wang, X., Aguiar, A. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2018. Lecture Notes in Business Information Processing, vol 314. Springer, Cham. https://doi.org/10.1007/978-3-319-91602-6_10

Cierre de cuatrimestre 2023-2 en MeMo2 @ FIUBA

Terminamos el cuatrimestre y me alegra tener la sensación de que seguimos mejorando. Continuamos con el horario matutino de 8 a 11, excelente. Y mantuvimos el mismo porcentaje de clases presenciales/virtuales.

Como siempre hicimos un par de ajustes respecto del cuatrimestre anterior, algunos de ellos basados en el feedback de los alumnos y otros surgidos del equipo docente.

  • Uno de los ajustes más importantes fue ser más explícitos sobre la «programación colaborativa» (mob y pair programming), por momentos pedimos explícitamente que no programen en solitario. Esto generó cierta «incomodidad» entre algunos alumnos por verse obligados a coordinar horarios con sus compañeros para hacer algunas tareas. Pero creemos que el resultado fue muy positivo ya que percibimos que se trabaron menos con cuestiones técnicas lo que les permitió terminar las tareas en menos tiempo y con menos grado de «frustración».
  • Una novedad fue que para los trabajos grupales, agregamos un facilitador «externo» para las retrospectivas al final de cada iteración iteración. O sea: cada grupo ya tenia un docente en el rol de Product Owner y a eso agregamos un segundo docente que solo se sumaba para facilitar las retrospectivas.
  • Otro de los ajustes, no tan visible para los alumnos, tuvo que ver con la infraestructura que utilizamos para el trabajo final debido a algunos cambios en Okteto. Básicamente dejamos de utilizar Okteto y directamente pusimos (casi) todo a correr en nuestro propio cluster Kubernetes en Digital Ocean.
  • También pusimos un poco más de foco en las cuestiones relacionadas a la operación o mejor dicho lo que suele llamarse «build for operations»
  • Finalmente, estrenamos un nuevo trabajo final que nos trajo renovados desafíos para el equipo docente.

Tanto en la retrospectiva final como en la encuesta de cierre, tuvimos feedback muy positivo de los alumnos. Comparto algunos números de la encuesta:

  • La encuesta fue contestada por la totalidad de los alumnos que completaron el curso (11)
  • La evaluación general de la materia (en promedio) dio 9.0, lo cual es mayor que el cuatrimestre anterior (8,8).
  • Respecto del porcentaje de clases presenciales/virtuales, 10 alumnos lo consideraron apropiado mientras que solo 1 hubiera preferido más virtualidad.
  • Las otras dimensiones de evaluación de la materia también resultaron muy positivas: claridad de los docentes: 4,7/5; Conocimientos de los docentes: 5 /5; Dinámica de las clase: 4,6/5; Materiales de estudio: 4/5.
  • La dedicación semanal a la materia extra clase dio un promedio de 8,7 lo cual me parece puede estar un poco distorsionado por la últimas semanas en las que los alumnos trabajaron en el trabajo final.
  • El NPS nos dio 63 (esta es una métrica que puede tomar valores en el rango -100 +100)

Algunos otros números del cuatrimestre:

  • Comenzamos la materia con 13 alumnos dos de los cuales abandonaron aproximadamente a mitad de cuatrimestre. Finalmente completaron la cursada 11 alumnos. Luego todos aprobaron el final.
  • Tuvimos 40 tareas individuales que incluyeron: lecturas, videos, cuestionarios y ejercicios de programación
  • Tuvimos 1 tarea para trabajar en parejas y dos trabajos grupales con grupos 3 o 4 alumnos
  • La calificación promedio de aprobación fue 7,1

Resulta curioso que si bien los números de la encuesta dieron mejor que el cuatrimestre anterior, la calificaciones fueron más bajas, un fenómeno para analizar.

Respecto de la dedicación, el análisis de la información reportada por los alumnos nos indica que:

  • La dedicación promedio extra-clase por persona sin considerar los trabajos grupales fue de 65 horas
  • La dedicación promedio extra-clase por persona para los trabajos grupales fue tp1: 6 horas y tp2: 14 horas
  • En términos generales la dedicación extra-clase promedio por persona a lo largo de toda la materia fue de 7,7 horas semanales.

Impresiones a mitad de cuatrimestre

Ya estamos promediando el cuatrimestre y tanto en la materia de fiuba como en la untref ya hicimos la retro de mitad de curso. Tengo la sensación que en ambos casos las materias vienen fluyendo muy bien. Digo esto en base a dos cuestiones: lo hablado en las retrospectivas y también el desempeño de los alumnos.

Un factor fundamental en esto creo que es el tamaño del curso. En ambos casos estamos hablando de cursos chicos lo cual nos permite hacer un seguimiento bastante personalizado de los alumnos: feedback constante y detallado.

Curiosamente, a diferencia de cuatrimestres anteriores, no hubo en las retrospectivas mención a la carga de trabajo ni a las tecnologías utilizadas. Hasta ahora era típico que los alumnos hicieran mención a utilizar otro stack de tecnologías y alguna «queja» a la carga de trabajo. Pero este cuatrimestre no ocurrió. Tal vez porque son dos cuestiones que explicamos bien explícitamente al comienzo de cada curso.

En el caso de fiuba hicimos 3 actividades en la retrospectiva. La primera un chequeo de «realidad vs. expectativas». Les pedimos a los alumnos que indicaran si lo que efectivamente encontraron en la materia era mejor, igual o peor de lo que esperaban inicialmente.

Luego, en la segunda actividad pedimos feedback sobre distintos aspectos de la materia.

Finalmente, en la tercera actividad, hicimos un clásico keep-fix-try donde obtuvimos feedback más específico.