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

Sobre la investigación en Informática

En estos tiempos en que la educación y sistema científico Argentino están sometidos a desfinanciamiento y cuestionamientos varios, quiero compartir un poco de información general y algunas cuestiones de mi caso.

Al hacer investigación, en primer lugar uno debe encontrar un tema de investigación y debe empezar a estudiar para encontrar algún punto concreto donde potencialmente hacer un aporte. Ya estudiar un tema implica recursos, de mínima hay que leer publicaciones científicas, las cuales en su gran mayoría no son de acceso gratuito. En general los centros de investigación y universidades suelen tener suscripciones pagas para poder dar acceso a sus investigadores. En Argentina, hay ciertas suscripciones cuyo acceso lo gestionaba el ministerio de ciencia y técnica y lo disponibilizaba para diversas instituciones públicas. En este momento, varias de esas suscripciones han caído (no las renovaron). En fin, de alguna forma el investigador estudia, encuentra una idea dónde hacer un aporte y comienza entonces «el camino hacia el aporte». Esto que describo aquí de forma lineal puede no ser tan así, dependiendo del caso puede ser una cuestión más «iterativa», con idas y vueltas.

Ya teniendo un tema (o al menos una pista de por dónde ir) hay que poner manos a lo obra, lo cual puede implicar actividades muy distintas dependiendo del área de investigación. En mi caso, yo trabajo en Ingeniería de Software Empírica, lo cual no suele requerir ningún equipamiento particular, ni compuestos químicos, ni tampoco un laboratorio. Nos basta con una computadora. En este sentido podríamos pensar que para mi caso esta parte del trabajo es relativamente «barata» en términos comparativos con otras disciplinas. Básicamente trabajamos con gente y con datos. Puede que necesitemos de algunas herramientas no gratuitas (software licenciado, algún servicio online, etc), pero en general de costo bastante accesible (algunos cientos de dólares). Es importante destacar que dentro de la informática hay otras temáticas muy distintas (por ejemplo todo lo relacionado a Inteligencia Artificial) y que pueden tener necesidades de recursos/infraestructura también muy distintas.

No voy a entrar en detalles pero básicamente aplicamos el método científico y en algún punto llegamos algún hallazgo que consideramos que agrega valor y «expande la frontera del conocimiento». Es momento de publicar, pues según las reglas del sistema la real medida de avance es la publicación. Escribimos un artículo y lo enviamos a una conferencia o a una revista. La publicación tiene dos objetivos: validación y difusión. Para publicar, ya sea en una conferencia o en una revista, hay que pasar por un proceso de revisión por pares. Los revisores evaluarán nuestro artículo considerando diversas dimensiones que obviamente incluyen el valor de nuestro aporte, pero también la rigurosidad del proceso de investigación y la presentación (o sea, qué tan bien escrito está el artículo). En el «caso feliz», nuestro artículo será aceptado para publicación lo cual nos pondrá muy contentos pero traerá seguramente aparejado un desembolso de dinero. En el caso de las conferencias tendremos que afrontar los gastos de la participación en la conferencia que básicamente son la inscripción y la logística de participación (traslado, alojamiento, viáticos, etc). Simplemente a modo de ejemplo: en agosto participé del CLEI 2024, una conferencia internacional que se realizó en Bahía Blanca. Tuve que viajar a Bahía Blanca y alojarme allí 2 noches. Asimismo la inscripción me costo 260 dólares. Redondeando tuve un gasto total de 400 dólares, de los cuales 340 salieron de mi bolsillo. La universidad solo me pudo aportar unos 60 dólares. Claro que hay conferencias más económicas pero también las hay más caras. Personalmente he participado en conferencias de 100 dólares y en conferencias de más de 1.000. Asimismo he participado en conferencias en Argentina, Brazil, Bolivia, Escocia, España y Finlandia y en todos los casos la mayor parte de los costos los afronte de mi bolsillo. A diferencia de lo que suele ocurrir con las conferencias de industria, donde los speakers tienen la entrada bonificada y en ocasiones también algunos viáticos, en las conferencias académicas hay que pagar, sobre todo los autores deben pagar pues el proceso de publicación no es gratuito. Publicar en una revista, puede en algunos casos, resultar menos oneroso, pues no hay costos de logística ni inscripción, pero en general hay que pagar a la revista. Si bien hay revistas en las que puede publicase gratuitamente, hay muchas otras en las que el costo publicación requiere un desembolso. Un costo implícito en todo este proceso es el tiempo que deben dedicar los investigadores, un tiempo que hoy en día en Argentina es remunerado muy pobremente.

City Building Game @ UNTreF

El martes pasado en mi curso de Ingeniería de Software hicimos este juego como actividad para poner en práctica un proceso «Scrum-like». Este juego fue diseñado por mis colegas Alejandra Alfonso y Emilio Gutter.

En general veníamos usando el juego del Pajarraco Scrumero porque teníamos grupos chicos (no más de 10 alumnos), pero este cuatrimestre tenemos 30 alumnos y nos pareció que el City Building escalaba mejor que el Pajarraco. Y creo que no nos equivocamos. Si bien en alguna conferencia hemos hecho el Pajarraco con unas ~80 personas, en ese caso contábamos con muchos materiales y varios facilitadores. El Pajarraco requiere de materiales muy específicos (ladrillitos tipo Rasti) mientras que el City Building básicamente requiere de elementos de librería (tijeras, papel y pegamento) que son más fáciles de conseguir.

Lamentablemente Emilio y Alejandra no hay publicado el juego aún. Sin embargo cuando le comenté a Emilio que estaba escribiendo este post, me prometió en breve publicar todos los detalles del juego, así que los interesados pueden contactarlo directamente a él.

Cierro con algunas modificaciones que hicimos al guión original del juego:

  1. Descartamos el papel glase, lo reemplazamos por papeles de colores (tipo los de taquitos de oficina), hojas blancas y lápices.
  2. De la mano de lo anterior agregamos un nuevo rol a los equipos: el pintor.
  3. Solo 4 minutos de iteración nos pareció muy poco, creemos que sería mejor hacer iteraciones de 5 o 6 minutos.
  4. Redujimos el número de tijeras por equipo, creemos que salvo el cortador de círculos, los otros cortadores se pueden arreglar para cortar «a mano».

Y un día un alumno uso ChatGPT y desaprobó

Ya desde el año pasado empecé a encontrarme con alumnos usando ChatGPT para resolver ciertas cuestiones de las materias que curso. Las situaciones que he visto son diversas.

En algunos casos alumnos ha usado chatGPT para resolver problemas técnicos (hacer troubleshooting), en algunos otros para resolver cuestiones de algoritmia y en otros para contestar preguntas teóricas. Asimismo en algunos casos los propios alumnos lo han dicho mientras que en otros casos lo descubrió algún miembro del equipo docente. En todos estos casos no tuvimos inconvenientes.

Pero esta semana nos encontramos con una nueva situación. Dimos a los alumnos un cuestionario online sobre un tema que veníamos trabajando desde hace varias semanas. Los alumnos tuvieron material de lectura, videos, actividades en clase y también oportunidades de aplicación en un TP. Luego de todo esto les dimos el cuestionario que tenia preguntas de tipo selección múltiple y también preguntas a desarrollar. Fue precisamente en estas preguntas de desarrollo donde encontramos respuestas distintas a lo esperado. Hablando con el grupo docente sobre esta situación, un docente descubrió que la respuesta había sido generada por ChatGPT. El alumno resultó desaprobado, pero no por haber usado ChatGPT sino por haber dado una respuesta incorrecta.

Esto me llevó a reflexionar de cara a aclarar algunas ideas pues el uso de herramientas de Inteligencia Artificial será cada vez más común y me parece importante sentar posición y dar visibilidad a los alumnos. Sinceramente no veo problema en que los alumnos usen ChatGTP (o herramientas por el estilo) ya sea para mejorar la redacción, resolver problemas técnicos o incluso contestar preguntas teóricas. La cuestión será, como casi siempre, ser criterioso. No tomar como infalibles las respuestas obtenidas, analizarlas críticamente y verificar su corrección. Adicionalmente la «calidad» de las respuesta obtenidas dependerá en gran medida de que las preguntas sean las apropiadas, con lo cual quienes quieran utilizar estas herramientas tendrán que aprender a utilizarlas con cierta «destreza».

Curso online de Extreme Programming

En enero comencé con un experimento, desarrollar una aplicación real (para un cliente mio) en sesiones online, abiertas y de 15 minutos. Como de costumbre, el desarrollo lo hice aplicando prácticas de Extreme Programming como ser Specification by Example, Test-Driven Development, Continuous Integration, Entrega Incremental, Story Slicing, etc., y utilizando algunas técnicas de diseño/programación como ser arquitectura hexagonal, mocks, etc.

Fueron en total 20 sesiones (unas 5 horas) en las que completé 2 mini-releases de la aplicación en cuestión. Luego, edité los videos de las sesiones, los complementé con algunos videos más y con ello le di forma un video-curso en la plataforma Udemy. La versión actual del curso tiene más de 7 horas de video y durante marzo repetiré la experiencia para agregar más funcionalidades y con ello sumar al menos otras 10 horas de video.

Los interesados en el curso lo pueden en la plataforma Udemy (aquí).

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

Resultado de la segunda edición del curso de Prácticas Técnicas para Scrum Masters

Hace un par de semanas completé el dictado de la segunda edición de este curso. Quedé muy conforme con los ajustes realizados luego de la primera edición y considero que el formato utilizado será el mismo en la siguiente edición: 5 encuentros de 2 horas cada uno.

En esta segundo edición, además de agregar un quinto encuentro, también agregué varias actividades para sumar así un total de 20 actividades extra clase. Según reportaron los mismos participantes, la dedicación promedio semanal fue de 3 horas lo cual hace que la dedicación total del curso ascienda a 25 horas (10 horas de encuentros online y 15 horas de actividades extra clase).

La evaluación del taller por parte de los participantes fue muy positiva.

Sin duda que hay algunas cuestiones que mejorar pero en términos generales estoy muy conforme y contento con el resultado. Comparto algunas frases que los participantes dejaron en el formulario de feedback:

«Me encantó el curso, me fue de mucha utilidad para comprender conceptos de los cuales no tenía conocimiento y que me permiten comunicarme mejor con los equipos a los que acompaño«

«Me gusto mucho el curso, la parte de devops fue la más esclarecedora junto con el mapa de las formas de quebrar o realizar slicing de una Historia de Usuario, fue excelente.«

Para aquellos interesad@s en participar de la próxima, ya tenemos fecha y está abierta la inscripción, pueden ver más info aquí.

11 alumnos, 2 docentes, educación pública y gratuita

Aula espaciosa, luminosa, con ventanas que pueden abrirse. Mesas altas y bancos que pueden acomodarse a gusto. Pizarra blanca con marcadores de 4 colores en perfecto estado y borrador. Sin aire acondicionado pero con ventilador. Proyector modelo 2019 con entrada HDMI y muy buena definición. Conexión WIFI de buena velocidad y bastante estable. Y posiblemente lo más importante: 11 alumnos y dos docentes nombrados (y algunos otros colaboradores informales/sin nombramiento).

No todo es perfecto, por supuesto: paredes con pintadas y con manchas de humedad, un edificio que literalmente se está cayendo a pedazos, un sueldo demasiado discreto (para los que tenemos sueldo) y una burocracia infinita e ineficiente.

Así es la situación de contexto para las clases de MeMo2 que estoy dando este cuatrimestre los lunes por la mañana (8:00 am) en la Facultad de Ingeniería de UBA. Si, la UBA, esa institución tan grande, tan politizada y con espacios tan distintos. A mi mismo me cuesta creerlo y el único cambio que hicimos fue el horario. Esto me hace pensar muy seriamente el mantener este horario matutino de forma permanente.