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!

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 el rol del director en el trabajo final de carrera

Como ya he mencionado en varias ocasiones es habitual que en la carreras de informática/sistemas los estudiantes tengan que hacer un trabajo final aplicando los conocimientos obtenidos durante la carrera.

Dependiendo de la carrera, el trabajo final suele tomar distinta forma. En algunas carreras ese trabajo final suele ser un trabajo de investigación (tipo «tesis») mientras que en otras carreras ese trabajo suele plantearse como un proyecto de desarrollo de software. Pero en todos los casos, ese trabajo final requiere de profesor que auspicie de director o tutor (el nombre del rol también suele variar de una carrera a otra).

Muchas veces se cree que el director/tutor debe ser un especialista en la temática del trabajo final. Yo personalmente no comparto esa idea, al menos no en forma general. El objetivo del trabajo final es que el alumno demuestre que ha adquirido los conocimientos para ejercer su profesión y en ese sentido es el alumno quien debe ser (o mejor dicho convertirse) en especialista en el tema en cuestión. Entonces ¿Cuál es el rol del director? Podemos debatirlo, pero sin duda el director debe «allanar» toda la cuestión administrativa que conlleva la realización del trabajo. Obviamente esto implica que el director esté familiarizado con el reglamento del trabajo final y el reglamento de la carrera en forma más general.

En lo personal creo que el director debe jugar un rol entre coach y project manager ayudando a los alumnos a mantener el foco y buscando que el trabajo sea completado en tiempo y forma.

Una situación particular puede darse cuando la idea del trabajo final surge del director, en ese cosas el director juega un rol adicional de Product Owner, definiendo funcionalidad y priorizándola.

Si el trabajo es de investigación, entonces uno esperaría que el director tenga cierta experiencia en investigación. De mismo, modo si el trabajo es desarrollo uno esperaría que el director tenga experiencia en desarrollo. La duda en ambos casos es cuánto debe conocer el director del dominio del trabajo, o sea, si estamos desarrollando un aplicación financiera ¿debería el director ser experto en el dominio financiero? Yo creo que creo. Tampoco creo que el director deba ser experto en blockchain si el trabajo se tratara sobre un tema de investigación relacionado a ello.

Para cerrar hay que mencionar que en algunas carreras el director es el encargado de evaluar el trabajo realizado por sus dirigidos, mientras que en otras carreras la evaluación está a cargo de un jurado que no incluye al director. En este segundo caso, uno esperaría que el director hiciera todo lo posible para asegurar el trabajo de los alumnos y que el jurado pueda calificarlo con la mayor nota.

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.

Ideas para trabajos finales de carrera

Una de las (¿pocas?) cuestiones positivas de la pandemia es que ha habilitado/forzado la «virtualización» de diversas actividades. De la mano de esto vienen un conjunto de potenciales ideas de trabajos finales de carrera.

En particular creo que hay todo un conjunto de problemáticas que se ponen de relieve al intentar llevar a una modalidad virtual eventos empresariales y académicos como conferencias, reuniones científicas, seminarios, etc. Asimismo en lo que tiene que ver con conferencias, es común en los eventos relacionados a agile que las sesiones tengan formatos «no tradicionales». Para que se entienda: el formato tradicional sería un orador hablando a una audiencia mientras comparte unas diapositivas, la comunicación es principalmente unidireccional. El orador es el protagonista de la sesión, expone información hacia una audiencia que escucha generalmente de forma pasiva.

En los eventos relacionados a agile es común encontrarse con formatos donde el orador toma una actitud más pasiva, fomenta y facilita la participación de la audiencia que toma un mayor protagonismo durante la sesión. En este sentido el orador toma un rol más de facilitador que de expositor. Existen una serie de formatos, dinámicas y actividades bien conocidos como ser Open Space, Fishbowl y World Café entre otros. Todas ellas diseñadas para ser realizadas de forma presencial. He aquí la oportunidad: generar herramientas/aplicaciones que permitan realizar estas actividades de forma virtual.

Un ejemplo de esto es la herramienta Stooa que permite hacer de forma virtual dinámicas tipo fishbowl.

Para quienes esten interesados en explorar estas ideas les recomiendo dos libros donde encontrarán dinámicas que podrían ameritar el desarrollo de una herramienta especializada para su soporte virtual:

Egreso online de Ingeniería en Computación @ UNTreF

El miércoles pasado asistí a una defensa de trabajo final de carrera en modalidad online. El ponente fue Gonzalo Cozzi, quien presentó su trabajo final para obtener el título de Ingeniero en Computación de la Universidad Nacional de Tres de Febrero. Los jurados evaluadores fueron Carlos Fontela, Diego Fontdevila y Diego Marcet. También estuvo en la defensa el director de la carrera Alejandro Oliveros. Yo participé en la presentación en calidad de director del trabajo presentado.

La presentación de Gonzalo fue muy sólida, ordenada y en tiempo. Los jurados felicitaron a Gonzalo por el trabajo realizado. Yo como director del trabajo también quedé muy satisfecho, tanto con el resultado como con todo el proceso de trabajo.

El trabajo en cuestión consistió en el desarrollo un radiador de información incluyendo una solución integral de software y hardware y soportando distintas arquitecturas de despliegue:

  • SmartTV + Cloud
  • SmartTV + Raspberry Pi
  • TV/Monitor + Raspberry Pi

El software está desarrollo con una arquitectura hexagonal, la cual a partir de un modelo de ports and adapters permite integrar distintas herramientas de una habitual con los proyectos de desarrollo. Out-of-the-box hay soporte de conectores para GitHub, GitLab, Redmine y Travis-CI.

Todo el código del proyecto está disponible en GitHub bajo licencia GPL-V3.

Algunos punto interesantes para destacar de este trabajo:

  • Se buscó proveer una solución integral contemplando software y hardware.
  • El trabajo está publicado con licencia de código abierto.
  • El trabajo está desarrollado de forma tal que permite muy fácilmente incorporar extensiones lo cual puede significar un oportunidad interesante para trabajos finales de otros alumnos (interesados no duden en contactarme).
  • Adicionalmente a la presentación formal de trabajo en la universidad, el mismo también fue presentado en un congreso de ingeniería.

¡Felicitaciones Gonza!

Abajo (los jurados): Carlos, Diego y Diego
Arriba: Nico, Alejandro y Gonzalo

Consideraciones para elegir un trabajo final de carrera

En las carreras de informática en Fiuba no hay, a mi entender, una definición lo suficientemente clara sobre los trabajos finales de carrera. Hay documentación, pero no hay una materia (como ocurre en otras universidades) donde los alumnos sean asesorados o tengan algún tipo de seguimiento. El alumno debe encontrar un director para su trabajo y acordar con él un tema.

En este contexto suelo recibir varias consultas de los alumnos y uno de los primeros consejos que les doy es que dejen en claro el objetivo personal que persiguen con el trabajo. Con esto no me refiero a la temática del trabajo sino a su expectativa personal, doy tres posibles ejemplos:

  • Recibirse y listo: la realización del trabajo final es requisito para recibirse y puede que el alumno quiera puntualmente eso. No tiene ninguna expectativa adicional. En este sentido el trabajo final es, en términos de transcendencia, como cualquier otro trabajo práctico de la carrera: una vez evaluado, ha cumplido su objetivo: la aprobación; entonces se archiva y nunca nadie lo vuelve a tocar.
  • Iniciar un emprendimiento: dado que el trabajo final requiere típicamente al menos un cuatrimestre de trabajo, puede ser una oportunidad interesante para aprovechar y hacer que ese trabajo final sea el puntapié inicial de un potencial emprendimiento.
  • Hacer un aporte a la comunidad: otra opción interesante para aquellos con intención de que su trabajo final tenga transcendencia más allá de la aprobación de la carrera es hacer algún tipo de aporte ya sea desarrollando una aplicación para una alguna institución, colaborando con un proyecto open source existente o incluso generando un nuevo desarrollo open source.

Esta es una clasificación muy genérica que no cubre todos los casos. De hecho mi propio trabajo final no entra en ninguna de estas categorías. De todas formas creo que plantearse la pregunta de las expectativas personales puede ser muy útil para definir el tema y sobre todo para armar el plan de trabajo.

Notas sobre los trabajos finales de carrera en informática/computación

Notas sobre los trabajos finales de carrera en informática/computación

Durante este cuatrimestre he recibido varias consultas sobre trabajo finales de carrera tanto en FIUBA como en UNTREF.

En UNTreF los alumnos deben hacer un Trabajo final Integrador mientras en FIUBA los alumnos pueden optar por Trabajo Profesional o una Tesis. En este artículo quiero centrarme en el Trabajo Profesional de FIUBA que es equivalente al Trabajo Final Integrador de UNTreF. En otro post trataré el tema de la tesis.

Antes que nada aclaro: lo que escribo aquí no es información oficial de ninguna carrera. Esto es un resumen Es información que yo he recopilado a partir de charlas informales con otro

Algunas cuestiones generales sobre este TFI/TP son:

  • Puede hacerse en forma individual o grupal.
  • Se espera que insuma un esfuerzo aproximado de unas 200 horas por estudiante.
  • Es necesario un profesor que dirija el trabajo.
  • El estudiante debe presentar una propuesta formal con el aval de su director.
  • No existe una lista de temas para el trabajo, en ocasiones los profesores/directores tienen algunas propuestas.
  • Se espera que el trabajo integre los contenidos y habilidades adquiridas durante la carrera.
  • El trabajo no es un trabajo práctico de una materia, es un trabajo final de carrera con lo cual las complejidad y alcance deberían ser mayores a los de un trabajo práctico de una materia.
  • Típicamente el trabajo consiste en algún tipo de desarrollo. No es mandatorio que el desarrollo sea alto totalmente nuevo, la novedad o desafío puede estar en la forma de resolución, en las tecnologías utilizadas o algunas otra cuestión de índole ingenieril.
  • Una fuente interesante de ideas que suelo recomendar es el Technology Radar que publica periódicamente la gente de Thoughtworks

Espero estas líneas resulten de utilidad.