Terminamos nuestro segundo cuatrimestre en modalidad 100% online. Fue un cuatrimestre muy particular, porque más allá de la virtualidad, tuvimos un cuatrimestre partido: por la situación de pandemia el inicio de clases en 2020 se retrasó y eso impactó en todo el calendario quedando el segundo cuatrimestre partido en 2. La primera parte terminó a mediados de diciembre permitiendo completar 12 semanas de clase. La segunda se retomó en febrero y contempló 4 semanas de clases para así completar las correspondiente 16 semanas de clases del cuatrimestre. Este particionamiento generó ciertas incomidades tanto para alumnos como para docentes.

Por otro lado, al margen de la particulidad del calendario y la virtualidad, este cuatrimestre hicimos 2 cambios mayores en la dinámica del TP2.

En primera instancia, no escribimos una descripción detalla de consigna. Previamente solíamos darle a los alumnos una especificación funcional de la aplicación a desarrollar en forma de pruebas de aceptación, las mismas no eran completas pero daban un nivel de detalle suficiente para marcar el comportamiento y alcance esperado. Este cuatrimestre cambiamos esto pues nos parecía que en cierto modo era una situación demasiado ficticia en el sentido que esas pruebas de aceptación no son típicamente provistas por el cliente/usuario sino que se desarrollan conjuntamente (equipo de desarrollo + usuarios) a medida que «se va descubriendo» el software a construir. En línea con esto, este cuatrimestre no les dimos las pruebas de aceptación, hicimos un product discovery y luego dejamos que cada equipo haga el trabajo de descrubimiento con su Product Owner (miembro del equipo docente). Obviamente que puertas adentro, todos los product owners (o sea el equipo docente) acordamos y alineamos ciertos puntos centrales de cara a intentar asegurar que todos los grupos construyan la misma aplicación más allá de algunas diferencias en términos de reglas de negocio. Esto trajo de la mano ciertas situaciones de negociación y trabajo de más ida y vuelta entre product owner y equipos de desarrollo, lo cual fue intencional para llevar a la práctica el slicing de funcionalidades. Respecto de este cambio, nos gustó y seguiremos con esta estrategia pero somos concientes que es necesario realizar algunos ajustes en la dinámica.

El segundo cambio importante requiere explicar un poco el contexto. Típicamente el TP2 tiene 3 ejes: alcance/funcionalidad, proceso y diseño/implementación. Previamente cada equipo de alumnos tenia un docente asignado que trabaja sobre los 3 ejes, proveía definiciones funcionales (tomando un rol típicamente de Product Owner), verificaba el cumplimiento del proceso (más en onda PMO que facilitador) y finalmente hacía seguimiento/evaluación de las cuestiones de diseño/implementación. Este cuatrimestre dividimos estas responsabilidades/ejes. Por un lado cada equipo tuvo asignado un docente que se encargaba del seguimiento del proceso y jugaba el rol de product owner proveyendo definiciones funcionales y validando su aprobación. Por otro lado, otro docente (yo en este caso) se encagó de la guíar técnicamente a todos los equipos y hacer el seguimiento y correcciones de diseño e implementación. También nos gustó este cambio y por ello vamos a mantenerlo.

Algunos otros cambios de menores que hicimos fueron que recortamos algunos temas (como escalamiento de agile y performance tests) e incluimos algunos nuevos. En realidad no es que agregamos nuevos temas sino que agregamos práctica de algunos temas que solo dábamos teoricamente como infra as code y contenedores.

Por otro lado, en la retro y en la encuesta de fin de curso, detectamos algunos puntos a ajustar entre los que se destacan dos: la gran dedicación requerida para el TP2 y la forma de dar feedback del código en las correcciones del TP2. Tomamos ambas cuestiones considerando que:

1. En algunos casos hubo falta de foco durante el TP2 que llevó a invertir esfuerzo en funcionalidades no necesarias.
2. Incluso cuando haya cuestiones que no esten bien al revisar el código hay que buscarle la vuelta en la redacción del feedback para también destacar algunos puntos positivos, pues siempre hay algo positivo para destacar y es necesario destacarlo para mantener la motivación del equipo,

Un tema intersante para descatar es que el primer cuatrimestre que no tuvimos abandonos. Los 21 alumnos que asistieron la primera clase, completaron la materia.

Ya para cerrar comparto algunas estadísticas:

• Evaluación general del curso: 8.6 / 10
• Claridad de los docentes: 4.3 / 5
• Conocimiento de los docentes: 4.9 / 5
• Dinámica de clases: 4.1 / 5
• Materiales de estudio: 4.1 / 5
• Dedicación promedio extra clase: 9.7 hs. semanales
• Conformidad con la nota de aprobación: 4.3 / 5
• Cantidad de tareas individuales: 38 (incluyendo 10 cuestionarios y 7 ejercicios de programación además de lecturas y videos)
• Visita de la industria: Mariano Simone (gracias totales)
• Nota promedio de aprobación de la materia: 7.9