Cierre y estadísticas del desarrollo de Fira

El lunes pasado fue la presentación formal Fira, el trabajo final de carrera de Facundo Gertsner y Matias Feld y del cual fuí director. La presentación la hicimos presencialmente en la facultad acorde a la normativa vigente pero adicionalmente fue transmitida por Twitch, donde quedó disponible para posterior visualización.

Comparto algunas métricas que pueden resultar de interés para otros alumnos:

  • 23 iteraciones de desarrollo
  • Más de 860 horas de desarrollo
  • Más de 600 pruebas automatizadas
  • ~1300 commits
  • Más de 20 GB de assets

A estos números hay que contextualizarlos considerando:

  • Desde que comenzamos a hablar sobre el trabajo con los alumnos (fines de 2020) hasta que se presentó el trabajo (mazo 2022) pasaron más de 14 meses.
  • Adicionalmente a las horas de desarrollo, los alumnos invirtieron una cantidad no menor de horas en capacitación e investigación, principalmente dedicadas a aprender Unreal (el motor sobre el que está construido el juego)

Algunas otras cuestiones que me parecen interesantes para destacar por no ser tan habituales en los trabajos finales de carrera:

  • Matias y Facundo decidieron aprovechar el trabajo final de carrera para comenzar un emprendimiento comercial. Esto resulta muy interesante pero trae también algunos desafíos como ser el hecho de regular las potenciales tensiones entre el aspecto comercial y el aspecto académico. Ejemplo: comercialmente el producto podría requerir más tiempo de desarrollo que el inicialmente estipulado; al mismo tiempo desde el punto de vista académico pretendemos que los alumnos terminen su formación en un tiempo acotado. Es justamente en este tipo de cuestiones donde el director debe guiar a los alumnos.
  • Al momento de finalización del trabajo académico, el producto no se encontraba comercialmente finalizado pero sí había tenido una validación de mercado (como director no habría podrido dar el trabajo por finalizado sin esta validación). El juego tuvo ~400 descargas de la versión beta y más de 25 mil visitas a la página de promoción.
  • El desarrollo de un juego de este tipo requiere del desarrollo de piezas artísticas (imágenes, texturas, animaciones, sonidos, música, etc). Esto implicó que parte del trabajo de los alumnos incluyera la gestión con los artistas/profesionales proveedores/creadores de estas piezas. Este trabajo de gestión es una tarea habitual para un ingeniero pero resulta algo casi inédita en un trabajo final de carrera.

Bueno, esto es todo sobre Fira. Felicito a Matias y Facundo por el trabajo realizado y les agradezco por haberme permitido ser parte de esta aventura.

Presentación de Fira, un videojuego con raíces académicas

Comenzamos las primeras conversaciones a fines de 2020. El primer mail en la lista de correo del equipo data de febrero de 2021. Presentamos la propuesta formal a la comisión curricular a comienzos de junio 2021. La primera iteración de desarrollo comenzó el 23 de agosto de 2021. Fueron un total de 24 iteraciones. Fueron más de 800 horas de desarrollo a las que hay que sumar el tiempo invertido en estudio/capacitación (los chicos tuvieron que aprender Unreal) que se invirtió antes del inicio formal del desarrollo.

Finalmente, este lunes 28 será la presentación formal del trabajo y con ello Facundo y Matias completarán su carrera de Ingeniería en Informática. La presentación será a las 17:00 hs. en la sede Paseo Colón de la Facultad de Ingeniería y también será transmitida por Twitch por el canal del departamento de computación.

¡Nos vemos!

Desafíos en la formación de un equipo docente

Hace unos 20 años que estoy en la docencia. En todo ese tiempo he sido parte de varios equipos docentes en distintas materias e instituciones. Hace unos 10 años tuve por primera vez un curso a mi cargo. Pero recién en 2019 estuve en la situación de conformar un equipo estable de más de 2 personas. Hasta ese momento siempre había dictado las materias a mi cargo yo solo o en compañía de otro docente. Estando solo no había opciones, todo el trabajo debía hacerlo yo mismo. Siendo 2 y ambos con muy similar experiencia y perfil, en general dividimos el trabajo en parte iguales apuntando a que ambos podamos dictar todos los temas de la materia. No hacemos distinción entre teoría y práctica porque en la dinámica de nuestra materia no existe tal distinción.

Pero hoy en día, en el equipo de la materia a mi cargo en FIUBA, somos 10 personas con distintos perfiles y experiencia. Graduados, estudiantes, rentados y no-rentados. Esto, a mi entender, hace que la distribución de tareas no sea tan simple. Me pregunto si alguna capacitación para docentes incluirá este tipo de cuestiones: armado de una equipo docente. Me late que no. Como docente responsable formalmente a cargo del curso, soy responsable de todo lo que ocurre en la materia. Claro que puedo delegar tareas, pero si algo no van bien, «me vendrán a buscar a mi».

Hay dos cuestiones que me resultan muy desafiantes en este contexto:

  1. De cara a los alumnos el mayor desafió que veo es la uniformidad. Siendo varias personas en el rol docente dentro de un mismo curso uno esperaría cierta uniformidad de criterios. Obviamente que puede haber diferencia de matices pero hay un conjunto de cuestiones centrales en las que todos deberíamos estar alineados. En este contexto entran los criterios de evaluación. Debería ser irrelevante para los alumnos que docente realiza la corrección de una entrega pues todos deberíamos aplicar el mismo criterio y por ende el resultado debería ser el mismo.
  2. De cara hacia el propio equipo docente encuentro un desafió importante en la distribución de tareas. Dentro del curso hay distintos tipos de tareas que varían en dedicación, responsabilidad y experiencia/conocimiento. Una cuestión que condimenta este tema es el hecho de que parte del equipo docente no está rentado. Esta situación de docentes no rentados es una práctica habitual en las universidades públicas argentinas, pero excede este artículo, ya lo trataré en otro.

Respecto de la primera cuestión creo que he encontrado una estrategia efectiva con la que estoy conforme. Respecto de la segunda, venimos operando de una forma que funciona pero que no termina de convencerme.

Al margen de estas cuestiones operativas formar un equipo implica muchas más cosas, más complejas y más profundas. Cuestiones de principios, solidaridad, vínculos, valores, sentido de pertenencia, etc, etc. Estas cuestiones de índole «más humano» requieren tiempo y oportunidades de interacción, dos elementos escasos cuando todos los miembros del equipo tiene una dedicación muy acotada en el contexto de la materia. Yo personalmente como responsable del curso dedico entre 5 y 10 horas semanales, pero un colaborador no rentado difícilmente dedique más de 5 horas por semana. Y como condimento adicional le sumamos la situación de pandemia que nos quitó el vernos en persona, un condimento importante para establecer vínculos personales.

Continuará…

Dirección de trabajos finales de carrera

Luego de recibir varias consultas de alumnos para que dirija sus trabajos finales de carrera, he decidido resumir aquí algunas cuestiones/condiciones referentes mi forma de trabajo como director.

  • La dinámica de trabajo es al estilo Agile/XP tal como enseñamos en MeMo2, esto es: iteraciones semanales de tiempo fijo, 1 reunión de seguimiento (review+planning) semanal, entrega continua, gestión adaptativa, etc.
  • En línea con el punto anterior, solo dirijo alumnos que hayan cursado MeMo2 en mi curso, esto se debe a que no quiero tener que lidiar explicando la forma de trabajo, si cursaron MeMo2 entonces ya lo conocen.
  • Ya desde el planteo del proyecto apunto a que el trabajo no exceda de ninguna manera los 365 días.
  • Como consecuencia de los puntos espero una dedicación semanal (por alumno) de al menos unas 10 horas semanales.
  • La documentación (propuesta e informe técnico) la prefiero escrita en Latex, en particular me inclino por trabajar con Overleaf que ofrece una muy buena experiencia de trabajo colaborativo online al estilo Google Docs.
  • Para los trabajos que impliquen un desarrollo de software, apunto a que sean publicados bajo licencia open source.
  • Para los trabajos que sean más del tipo «research» apunto a que el trabajo sea publicado en alguna conferencia y/o revista.

Estos puntos representan una guía que pretendo seguir, pero en determinados casos son cuestiones «charlables». Quienes estén interesados en que dirija su trabajo pueden contactar por aquí.

Fira: un juego con raíces académicas

Hace un tiempo comenté que estaba dirigiendo un trabajo final de carrera que consistía en el desarrollo de un videojuego. Ya estamos en el tramo final, por el momento viene todo según lo planificamos: 24 semanas a un ritmo de unas ~30 horas semanales. Si no surgen imprevistos, estimo que estaremos presentado el trabajo durante marzo. El juego ya está jugable hace varias iteraciones y de hecho ya hemos recibido feedback de varios beta users. Un detalle interesante es la intención de hacer de este juego un producto comercial y en ese sentido se ha trabajado con profesionales para externos a la facultad para el desarrollo de los artefactos multimedia (gráfica, sonido, etc). El nombre comercial del juego es Fira y ya está disponible (preview) en la plataforma Steam. Aprovecho para invitar a la audiencia a descargar el juego y darnos su feedback.

Desconozco como suelen trabajar los estudios que se dedican al desarrollo de este tipo de videosjuegos pero creo que la forma en que encaramos el desarrollo viene funcionando muy bien. Esta forma de trabajo es básicamente lo que enseñamos en MeMo2 y tiene que ver con el uso de varias prácticas básicas de ingeniería de software: feedback temprano, integración continua, planificación adaptativa, prueba automatizada, propiedad compartida, uso convencione, etc.

Si bien no he estado muy involucrado en cuestiones de programación, he aprendido muchas cuestiones técnicas de la mano de los alumnos. Creo que el desarrollo de este tipo de juegos es un mundo en sí mismo y por ello creo que bien podríamos tener en FIUBA una materia dedicada a esto.

Estas últimas semanas estuve participando de algunas sesiones de programación con los alumnos y me reencontré con C++. No es un lenguaje de mi preferencia pero me parece importante que todo ingeniero de software tenga alguna experiencia con C++.

Sobre la enseñanza de la Ingeniería de Software

La materia que dicto (tanto en UBA como en UNTReF) es Ingeniería de Software, pero dado que la «Ingeniería de Software» es un rótulo tan amplio, no basta con decir eso para transmitir qué es lo que realmente estudiamos.

Razonablemente alguien podría pensar que toda materia nombrada como «Ingeniería de Software» debería cubrir los temas descriptos en el Software Engineering Body of Knowledge (SWEBoK). Esto es lo que intentamos hacer en las materias Ingeniería de Software 1 y 2 (conocidas informalmente como memo1 y memo2) de la Licenciatura en Análisis de Sistemas de la UBA. Pero esto muchas veces no es así.

En algunas casas de estudio la materia «Ingeniería de Software» solo cubre una parte de esos temas del SWEBoK. Un caso de esto parece ser la materia Ingeniería de Software de la carrera de Licenciatura en Ciencias de la Computación de la UBA, la cual está muy enfocada en cuestiones de diseño y programación orientada a objetos y sin tratar varios temas de SWEBoK.

También está el caso de algunas carreras que no tienen ninguna materia llamada Ingeniería de Software, sino que cuentan con materias particulares para las distintas disciplinas que componen la Ingeniería de Software (análisis, diseño, programación, testing, etc). Este es el caso de la carrera Ingeniería en Informática de la UBA.

También tenemos el caso carreras que cuentan con materias específicas para algunas de las distintas disciplinas de la Ingeniería de Software y al mismo tiempo tienen una materia Ingeniería de Software que cubre los temas restantes de la Ingeniería de Software que no cubre ninguna materia particular como ser muchas veces las cuestiones de proceso, trabajo en equipo y metodologías de desarrollo. Este el caso de la carrera Ingeniería en Computación de UNTreF.

Más allá de todas estas variantes, hay una cuestión que quiero destacar respecto de la forma en que dictamos las materias MeMo1 y MeMo2 en UBA. Ambas materias pretenden cubrir todas las disciplinas de la Ingeniería de Software, en ambas materias se estudia desde requerimientos hasta puesta en marcha pero con mayor profundidad en distintos temas. MeMo1 tiene un mayor foco en las cuestiones iniciales de los proyectos, como ser visión, requisitos, etc, pero aún así trata cuestiones de metodología, arquitectura, etc. Y un punto central: se hace implementación, o sea, los alumnos tienen que programar y poner lo que programan en un ambiente «símil producción». Esto me parece que es fundamental para cerrar el «feedback loop», recién al poner nuestra aplicación en producción sabemos cuán bueno ha sido nuestro trabajo en requisitos y demás tareas de la ciclo de desarrollo. Por otro lado en MeMo2 también cubrimos todo el ciclo pero con un mayor foco en ciertas cuestiones que MeMo1 toca de forma más superficial. En particular en MeMo2 ponemos mucho foco en proceso de desarrollo, el ciclo de BDD/TDD, CI/CD, Configuration Management y dinámica de equipo.

Sobre la presentación de la nueva gestión del Departamento de computación de FIUBA

El pasado viernes fue la presentación de la nueva gestión del Departamento de Computación de Facultad de Ingeniería de la Universidad de Buenos Aires. Este departamento se encarga de la gestión de las materias del área de computación, no de las cuestiones de «informática/tecnología» de la facultad, eso está en manos de la Subsecretaría de Tecnologías de la Información y Comunicaciones.

Esta nueva gestión está encabezada por la el Lic. Manuel Camejo en el rol de director del departamento. Según me comentaron es un nombramiento interino pero no puedo asegurarlo, la única información formal que recibí sobre este cambio fue el mail de despedida del director anterior hace menos de un 1 mes.

Este cambio viene en principio con cambio de imagen y estrategia de comunicación. Hay un logo y presencia en Twitter, Twich e Instagram. Al mismo tiempo me parece interesante el hecho de que hayan realizado una presentación de la gestión y que la hayan transmitido en vivo por redes.

Respecto de lo que se habló en la reunión de presentación hay algunos puntos que me parece interesante destacar:

  • La intención explícita de que el departamento sea un proveedor de servicios a la carreras.
  • El foco inmediato en reestructurar la asignación de recursos del departamento dado que hay materias del comienzo de la carrera con una relación de 1 docente cada 30 alumnos y materias del final de la carrera con una relación de 1 docente cada 4 alumnos. Creo que esto puede ser un desafió interesante y tengo mis dudas hasta que punto puede corregirse.
  • La información que comentó Rosita respecto de el rumbo de los planes 2020 que por la pandemia terminarán siendo los planes 2022.
  • Como parte de la presentación, también habló el Ing. Pablo Deymonnaz, el reciente director de la carrera de Ingeniería en Informática. Entre las cosas que mencionó Pablo lo que me resultó más interesante es el foco que tendrá la carrera de ingeniería con el nuevo plan. Claramente se apunta a una formación muy técnica con contenidos de matemática aplicada/ciencia de datos, system programming y sistemas distribuidos entre otros. Con esto queda muy clara para mi la diferencia entre la Ingeniería Informática y la Licenciatura en Sistemas. La licenciatura queda posicionada como una carrera de Ingeniería de Software, no es que la Ingeniería no vaya a tener contenido de Ingeniería de Software, sino que dicha temática será tratada con mucho mayor profundidad en la Licenciatura.
  • Se presentaron también dos colaboradores externos que justamente estarán colaborando con la dirección del departamento. Uno de ellos es Javier Brugues, egresado de la casa y con quien tuve la oportunidad de compartir algún proyecto hace unos años. El otro es Federico Carrone, un ex-alumno de la casa que abandonó la carrera.

Ojalá este cambio en la gestión sea para mejor. En un par de meses les cuento que tal.

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.