Sobre la definición del Trabajo final de carrera

En las últimas semanas he recibido varias consultas sobre trabajos finales de carrera en FIUBA. Más allá de siempre recomendar dejar en claro el objetivo personal del trabajo, en estas ocasiones me encontré recurrentemente explicando una cuestión sobre la definición del trabajo y la presentación del proyecto. Lo escribo aquí para futuras referencias.

El primer paso formal del trabajo final de carrera es la presentación del plan de proyecto a la comisión curricular para su aprobación. Este un paso clave, y que a mi entender, en ocasiones subestimado. Si nos quedamos cortos en el nivel de detalle del plan de proyecto, corremos el riesgos que la comisión curricular no apruebe el proyecto. Al mismo tiempo si ponemos mucho nivel detalle sin tener suficiente conocimiento del dominio, la tecnología y el contexto, corremos el riesgos de estar embarcándonos en un trabajo mucho más extenso de lo esperado.

Entonces he aquí la clave: la formulación del plan de proyecto debe proveer el suficiente nivel detalle para que la comisión lo apruebe, pero para proveer ese nivel de detalle es necesario que tengamos suficiente conocimiento del dominio del proyecto, la tecnología que utilizaremos para la solución y el contexto del proyecto. Esta situación tiene distinto grado de “gravedad” en cada carrera/institución. En algunos casos no se pide tanto nivel de detalle en el plan de proyecto porque se espera que el proyecto incluya el esfuerzo de descubrimiento/análisis/requerimientos. Del mismo modo, en los casos en los que se pide mayor nivel de detalle se está, en cierto modo, forzando que al menos una parte importante del descubrimiento/análisis se realice previo/durante a la formulación del proyecto.

Si quisiéramos poner esto en términos formales (o de industria) podríamos pensar estas dos situaciones: en un extremo en una planificación adaptativa y en el otro en una planificación “up-front”. Al mismo tiempo si analizamos los trabajos finales desde una perspectiva de gestión de proyectos tenemos que generalmente los reglamentos establecen de forma fija los recursos/esfuerzo/presupuesto del proyecto (cada alumno debe trabajar X cantidad de horas como mínimo). También se establece un tiempo calendario máximo para completar el proyecto una vez aprobada la propuesta (por ejemplo 1 año calendario). De esta forma la dimensión variable del proyecto termina siendo el alcance y ahí la paradoja: en un planificación “up-front” muchas veces los alumnos (y también las empresas) intentan fijar un alcance, teniendo así las tres dimensiones del proyecto fijas de entrada: alcance, tiempo y recursos. Típico proyecto “llave en mano” con las ¿pocas? chances de que el proyecto llegue a buen puerto. Es así que nos encontramos con alumnos haciendo interminables trabajos finales y algunos otros que nunca siquiera lo empiezan.

La clave entonces podría estar en plantear un alcance variable, lo cual a mi parecer va mucho mejor con una planificación adaptativa que con una planificación “up-front”.

En términos formales, y dependiendo de las particularidades de la comisión curricular (o el organismo que sea que deba aprobar el plan de proyecto), puede que la mayor parte descubrimiento/análisis debamos hacerla antes o después de la aprobación del plan de proyecto. En base a lo que he hablado informalmente con miembros de las comisiones curriculares de FIUBA me queda la sensación de que en el caso de la Ingeniería el descubrimiento/análisis hay que hacerlo en su mayor parte antes de la presentación del plan de proyecto. En el caso de la Licenciatura el descubrimiento/análisis es en su mayor parte realizado una vez aprobado el plan de proyecto.

En este sentido, mi recomendación para los alumnos de Ingeniería en Informática es:

  • Conseguir un director y comenzar a trabajar
  • Presentar la propuesta formal una vez avanzando un porcentaje de ~30% del proyecto
  • Obviamente esta estrategia tiene el riesgo de avanzar en el trabajo y que luego la comisión no apruebe el plan de proyecto. Justamente es aquí donde resulta clave el rol del director para minimizar la chances de que el proyecto sea rechazado.

Ingeniería de Software para videojuegos (rpg)

El mundo de los videojuegos es muy amplio, tanto desde el punto de vista del usuario como también de los desafíos técnicos de su construcción. Personalmente no estoy metido en ninguno de estos dos aspectos. Apenas si desarrollé algunos juegos muy simples del tipo juego de mesa por turnos (tateti, teg, solitario) y como usuario me quedé en la época del Age of Empires 2.

Hoy en día siento más curiosidad por el desarrollo de video juegos que por jugarlos. Es por ello cuando dos alumnos de Fiuba me contactaron para que fuera su director en el desarrollo de un videojuego RPG que sería su trabajo final de carrera, no tarde mucho en aceptar.

Es así que luego de armar la propuesta formal del trabajo para la comisión curricular y obtener la aprobación de la misma, esta semana comenzamos a trabajar en el desarrollo.

En cierto modo el alcance está dado por una historia, un “cuentito”, una narrativa que en este caso particular está organizada en capítulos. A la hora de pensar en versiones incrementales del juego uno podría pensar en tener en primera instancia un esqueleto base (walking skeleton) que permita recorrer todos los capítulos con una funcionalidad/extensión mínima. Pero otra alternativa podría ser ver cada capítulo como potencial versión incremental del juego.

Otro elemento del proyecto a destacar es que hay todo un trabajo artístico que incluye elementos multimedia como imágenes y música. De la mano de esto viene el manejo de todos estos artefactos desde el punto de vista de versionado ya que estos archivos suelen ser muy pesados y no es conveniente meterlos a la ligera en cualquier versionador.

Desde el punto de vista del desarrollo está la cuestión del motor, o sea, es muy común que estos juegos se desarrollen con un motor, en este caso particular el juego está basado en el motor de Unreal.

El último punto que quiero destacar es la mecánica de distribución. Es habitual que los juegos de este tipo se comercialicen y distribuyan utilizando una plataforma como Steamworks, lo cual en cierto modo tiene un impacto en el diseño y la implementación del pipeline de delivery.

Más allá de todas estas cuestiones tengo aún una serie de interrogantes respecto de hasta que punto y con que variaciones pueden aplicarse ciertas técnicas de desarrollo como ser: Test-Driven Development, End-2-End automation testing e integración continua entre otras. Todas estas cuestiones y muchas más son las que espero descubrir en el desarrollo de este trabajo final.

A medida que descubra les iré contando.

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.

Feliz 200 años UBA

Ingresé a la UBA en 1998, me llevó 3 cuatrimestres completar las 6 materias del Ciclo Básico Común. Es así que mi ingreso a la Facultad de Ingeniería fue recién a mediados de 1999.

En 2001 cursé la materia Algoritmos y Programación 3 que marcó un hito en mi formación y en mi carrera. Recuerdo mi exaltación cuando nos dijeron que el trabajo práctico de la materia era programar un juego tipo TEG. Estaba como loco, yo era fanático del TEG y tenía la intención de hacer una versión para jugar en computadora cuando me recibiera de ingeniero, y de repente tenía que programarlo en una materia de segundo año. Excelente. Tal era mi motivación que recuerdo que ese cuatrimestre estaba cursando Análisis Matemático 2 y decidí abandonarla para poder dedicar más tiempo a programar el TEG. Valió la pena, nos sacamos un 10. En parte, ese 10 posibilitó que el profesor Fontela me ofreciera sumarme al equipo docente de la materia. Ni lo dudé y así empezó mi relación con Carlos Fontela quien ha sido mi mentor en la docencia. Trabajé en el equipo de Carlos durante más de 15 años, aprendí muchísimo, de Carlos, de los otros docentes y de los alumnos que pasaron por el curso. Es por esto que le estoy eternamente agradecido a Carlos.

En 2002 cursé la materia Teoría de Algoritmos donde conocí a la profesora Rosita Wachenchauzer con quien también tuve la oportunidad de ejercer la docencia. Años más tarde Rosita fue mi directora de tesis. Mis agradecimientos también para Rosita.

En 2006 cursé mi última materia, Introducción de a los Sistemas Distribuidos. En 2007 completé mi tesis de ingeniería.

Si bien mi desempeño docente comenzó 2001, no fue hasta 2003 que fui nombrado formalmente como docente auxiliar (ayudante de segunda, el único cargo docente al que pueden acceder los estudiantes). Desde entonces vengo concursando y recorriendo toda la carrera docente: ayudante de segunda, ayudante de primera, jefe de trabajos prácticos y profesor.

Hoy en día, 23 años después de haber ingresado como estudiante, sigo en UBA pero ahora como profesor. Estoy a cargo de la materia Métodos y Modelos de la Ingeniería de Software 2 (95.21).

Creo que la UBA tiene muchas virtudes pero sin duda también mucho por mejorar. Hay falencias que viví en mi época de estudiante que fueron resueltas pero hay algunas otras que aún hoy siguen sin solución (ya escribiré de esto en otro momento).

Poco me importan “los laureles” de la UBA, sus posiciones en los rankings, quienes pasaron por sus aulas, los logros de sus graduados y demás datos. La UBA me formó en muchos sentidos y hasta en un punto creo que la formación académica no fue necesariamente el factor más relevante. Si, obtuve un título y contento estoy con ello, pero haber estudiando en la UBA formó mi carácter y todo un conjunto de habilidades que exceden los conocimientos particulares en ingeniería de software. En UBA conocí muchos profesionales que admiro y con algunos de los cuales aún hoy tengo el placer de trabajar. Hoy en día, en mi rol de profesor sigo aprendiendo. ¿Habría sido lo mismo en otra casa de estudios? Tal vez sí, tal vez no, no lo sé y tampoco importa. Estudié en UBA y sigo siendo parte de UBA. Gracias UBA, felices 200 años.

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.

Experimento: Fiuba meets Discord

Estamos promediando el cuatrimestre, completamos la novena semana de clases y con ello cerramos la primera parte de MeMo2. Hasta aquí los alumnos estuvieron trabajando de forma individual estudiando, aprendiendo y practicando diversas técnicas para poder trabajar en equipo durante la segunda parte de la materia.

Es aquí donde entra Discord, este cuatrimestre hemos decido habilitar un servidor Discord para que los equipos de alumnos puedan trabajar sincrónicamente haciendo mob programming. Discord es una plataforma de colaboración similar a Slack, Microsoft Teams y otras tantas. Ofrece salas de video y de audio que emulan de forma virtual a salas físicas. El usuario puede estar en una sala de audio a la vez. Al mismo tiempo las salas de audio no tiene espacio de texto sino que los usuario “entran” con cámara y video y tienen la posibilidad de compartir pantalla.

El trabajo en equipo es un proyecto de desarrollo con alcance variable y esfuerzo fijo. Pedimos a los alumnos trabajar 6 horas semanales (extra clase) pero haciendo (dentro de lo posible) mob-programming todo el tiempo. En las próximas semanas veremos si también probamos Discord para las clases en vivo pero sabemos que esto puede resultar más complejo ya que tenemos colegas que han reportado inestabilidades en la suscripción gratuita de la plataforma. De todas formas, como nosotros tenemos pocos alumnos creemos que podría andar bien.

Sobre las estadísticas de inscriptos en FIUBA

Esta semana la facultad difundió un reporte bastante detallado de las inscripciones de este cuatrimestre. Comparto aquí algunas datos que me resultaron interesantes.

La cantidad inscriptos fue de 8.209, esto nos da una idea de la cantidad de alumnos regulares de la facultad (y ubica a fiuba bastante abajo en ranking de alumnos de facultades de la uba 😦 ).

La cantidad de inscripciones fue 31.495 lo cual da un promedio de 3.84 materias por alumno.

Al analizar el desagregado de género vemos que el 26% del los inscriptos son mujeres lo cual me sorprendió positivamente ya que tenia la sensación que había muchas menos mujeres en fiuba. Este cuatrimestre en MeMo2 tenemos ~15% de mujeres.

El departamento de computación se ubica cuarto en cantidad de inscripciones detrás de los departamentos de física, matemática y gestión. Que física y matemática sean los departamentos con mayor cantidad de inscriptos no me sorprende ya que todas las carreras tienen en los primeros años materias de esos departamentos. Pero si me sorprende la cantidad de inscriptos del departamento de gestión.

En departamento con mayor paridad de género en las inscripción es química (~49 % de mujeres). Esto no me sorprende pues es saber popular que las carreras del departamento de química concentran el mayor % de mujeres.

Quienes gusten leer el informe completo lo pueden encontrar aquí.

Recomendaciones para alumnos de MeMo2

Como de costumbre en cada cuatrimestre intentamos incorporar mejoras en base al feedback recibido el cuatrimestre anterior. Entre esas mejoras vienen algunas recomendaciones para los alumnos:

  • Dado que gran parte del trabajo de la materia es en grupo te recomendamos que ya de entrada coordines con otros alumnos para conformar grupos 3 integrantes.
  • La materia se dicta en modalidad virtual con lo cual es mandatorio para cursarla contar con sistema de audio (parlante y micrófono). Asimismo es importante que cuentes con cámara.
  • Si aún no tienes una cuenta @fi.uba.ar es un buen momento para que la tramites.
  • La materia tiene un flujo importante de mails durante la época de trabajos grupales con lo cual podría resultar muy útil (y conveniente) aprender a armar filtros en tu herramienta de correo electrónico.
  • En la materia utilizamos Git y Ruby pero no dedicamos tiempo de clases a enseñar ninguna de estas dos herramientas, por ello si aún no estas familiarizado con estas herramientas te recomendamos que comiences a estudiarlas a la brevedad.
  • Si sos alumnos de Ingeniería Informática y como tal debes cursar Técnicas de Diseño (75.10) te recomendamos que leas este artículo donde explicamos que MeMo2 no es TDD.
  • Más allá de las 6 horas de clases semanales (de asistencia obligatoria), la materia suele demandar una dedicación semanal constante de otras ~6 horas semanales de trabajo/estudio fuera del horario de clase todas las semanas. Durante las primeras semanas puede que sea un poco menos y durante las últimas semanas puede que sea un poco más.
  • Es muy importante que asistas las primera clase, pues ahí explicamos varias cuestiones sobre la dinámica de la materia y la modalidad de evaluación. Si por alguna razón no puedes asistir por favor comunícate conmigo a la brevedad.

Antes cualquier duda puedes contactarme por aquí.

FIUBA: MeMo2 no es TDD

Escribo esta líneas para potenciales alumnos de mi materia y por ello agrego un poco de contexto para los lectores ajenos a FIUBA. En FIUBA se dictan actualmente dos carreras relacionadas a sistemas/informática/computación. Por una lado está la Licenciatura en Análisis de Sistemas y por otro la Ingeniería en Informática. Son dos carreras separadas, no es que la licenciatura es un paso intermedio de la ingeniería. Son dos carreras distintas, totalmente independientes pero que comparten varias materias.

La materia que yo dicto actualmente se llama Métodos y Modelos en la Ingeniería de Software 2 (código 95.21). Comúnmente es conocida como MeMo2. Es una materia que surgió a partir de la reforma 2015 del plan de estudios de la carrera de Licenciatura en Análisis de Sistemas. En el plan anterior había dos materias de ingeniería de software, una enfocada en cuestiones de análisis (Análisis de la Información – 75.09, comúnmente conocida como AnInfo) y otra enfocada en cuestiones de diseño (Técnicas de Diseño – 75.10, comúnmente conocida como TDD). Estas dos materias eran compartidas entre ambas carreras. Con el nuevo plan de estudios de la licenciatura se actualizó la visión de la ingeniería de software y esa dos materias (75.09 y 75.10) fueron reemplazadas por dos materias nuevas (95.20-MeMo1 y 95.21-MeMo2) que apuntan a cubrir con distinto nivel de profundidad todas las actividades de la ingeniería de software. Adicionalmente también se agregaron temas de ingeniería de software a otras materias del plan. De esta forma MeMo2 quedaba exclusivamente para la Licenciatura y TDD exclusivamente para la ingeniería.

En este contexto yo armé la materia MeMo2 en base al programa de la licenciatura. Cuando comencé a dictar la materia tuve muy pocos alumnos pues el plan era nuevo. Al poco tiempo, el Departamento de Computación decidió que mi materia, MeMo2, del plan de la licenciatura, era equivalente a TDD del plan de la ingeniería, una decisión polémica a mi parecer. Esto implicó que mi materia sea formal y simultáneamente MeMo2 y TDD. Yo siempre consideré esta decisión muy polémica ya que en términos formales los programas de TDD y MeMo2 tienen muy poco en común (a simple vista no más de un 30%).

Hoy en día mi materia sigue siendo formalmente MeMo2 y TDD pero en términos reales en su contenido es MeMo2. Esto hace que en habitualmente alumnos de la ingeniería vengan a cursar mi materia con una determinada expectativa (contenidos de TDD) pero se encuentran con algo distinto (contenidos de MeMo2).

Comparto una tabla comparativa de los programas de ambas materias, resaltando en verde los temas de TDD que cubrimos en MeMo2.

Cierre del segundo cuatrimestre 2020 en MeMo2@fiuba

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