Ya estamos promediando el cuatrimestre y tanto en la materia de fiuba como en la untref ya hicimos la retro de mitad de curso. Tengo la sensación que en ambos casos las materias vienen fluyendo muy bien. Digo esto en base a dos cuestiones: lo hablado en las retrospectivas y también el desempeño de los alumnos.
Un factor fundamental en esto creo que es el tamaño del curso. En ambos casos estamos hablando de cursos chicos lo cual nos permite hacer un seguimiento bastante personalizado de los alumnos: feedback constante y detallado.
Curiosamente, a diferencia de cuatrimestres anteriores, no hubo en las retrospectivas mención a la carga de trabajo ni a las tecnologías utilizadas. Hasta ahora era típico que los alumnos hicieran mención a utilizar otro stack de tecnologías y alguna «queja» a la carga de trabajo. Pero este cuatrimestre no ocurrió. Tal vez porque son dos cuestiones que explicamos bien explícitamente al comienzo de cada curso.
En el caso de fiuba hicimos 3 actividades en la retrospectiva. La primera un chequeo de «realidad vs. expectativas». Les pedimos a los alumnos que indicaran si lo que efectivamente encontraron en la materia era mejor, igual o peor de lo que esperaban inicialmente.
Luego, en la segunda actividad pedimos feedback sobre distintos aspectos de la materia.
Finalmente, en la tercera actividad, hicimos un clásico keep-fix-try donde obtuvimos feedback más específico.
Finalmente el martes pasado, 8 de agosto, el Consejo Directivo de la FIUBA aprobó el nuevo plan de estudios de la carrera de Ingeniería en Informática. Esto ocurre en el contexto de la iniciativa «Plan 2020» en la cual la facultad se propuso generar nuevos planes para todas sus carreras, pero que por motivos diversos, llega con años de retraso.
El lo personal no estuve involucrado en la creación de este nuevo plan, es una tarea de la Comisión Curricular de la carrera de la cual yo no formo parte. Pero como docente del departamento de computación suelo recibir consultas de los alumnos respecto de la carrera en general. Es por ello que comparto aquí algunas opiniones respecto de este nuevo plan.
Cabe destacar que tiempo atrás escribí sobre un borrador de plan que se había compartido, pero había sido elaborado por otra comisión, o sea: el plan se empezó a trabajar con una determinada formación de la comisión curricular y un director pero el plan publicado ahora fue creado por una comisión liderada por otro director de carrera y otros miembros. Y si bien algunos miembros se mantienen, no estoy seguro de hasta qué punto esta comisión mantuvo el trabajo realizado por la anterior o hasta que punto, hicieron borrón y cuenta nueva.
En primer lugar hay un cambio significativo respecto de las cuestiones de ciencia básica. No hay ninguna materia de química (ni siquiera en el CBC) y solo quedan dos materias de Física: la del CBC y una nueva materia llamada «Física para Informáticos». También hay algunos cambios menores en las materias de matemática.
Por otro lado, en cuestiones de informática, hay varias cuestiones a notar, detallo algunas materias:
Introducción al Desarrollo de Software: me parecen interesantes los contenidos que plantea de forma temprana en la carrera, me gusta que ya tempranamente habla de Desarrollo Orientado por Pruebas (asumo que se refiere a TDD). No me gusta tanto la mención explícita a front-end y back-end pues me parece que es una cuestión tecnológica «de moda».
Paradigmas de Programación: entiendo que se la considera equivalente a Algo3 pero no lo veo tan así pues por un lado incluye cuestiones de otros paradigmas más allá de OO y al mismo tiempo no veo ninguna mención a cuestiones de ing. de software (nada de TDD, ni unit testing y tampoco patrones)
Ingeniería de Software 1: parece que algunas de las cuestiones que «sacaron de algo3» las metieron aquí, puntualmente las cosas de diseño, oo, patrones. Creo que quedó más parecida a la materia de Ingeniería de Software 1 que se dicta en Exactas. Yo la veo distinta a MeMo 1 en parte por contenido y también porque es una materia 8 créditos (MeMo 1 es de 6).
Ingeniería de Software 2: pinta como lo que vengo dando en MeMo2 (de hecho los contenidos mínimos son los mismos) pero tiene 8 créditos cuando MeMo2 tiene 6. Intentaré averiguar que onda.
Taller de programación: sus contenidos mínimos me suenan muy distintos a los de la materia que se dicta actualmente y me resulta intrigante cómo se plasmaran en un curso.
Empresas de Base Tecnológica: la 1 me parece como un mix de varios temas «de materias de Las Heras» (en general en Las Heras se dicta materia de organización/gestión). La 2 pinta mejor, trae algunas cuestiones de innovación, startups, etc.
Gestión del Desarrollo de Sistemas Informáticos: entiendo que esto es lo que viene dictando Carlos Fontela en la materia de gestión de proyectos que dicta actualmente. Pinta bien aunque me llama la atención lo de «Análisis del Impacto Socioambiental» (según averigué es un lineamiento de la facultad que todas las carreras tengan algo de esto)
Taller de Seguridad Informática: me parece bien que se haya puesto esta materia, creo que seguridad es un tema muchas veces postergado. Los contenidos son debatibles pero por algo hay que empezar.
Electivas: veo muchas que me suenan a «data / machine learning» y solo arquitectura de software del área de Ingeniería de Software. No vi ninguna materia relacionada a operaciones, infraestructura, data centers, etc, cosa que si había en alguna versión preliminar del plan.
En lo personal creo que es un buen plan, mucho más adecuado a los tiempos actuales que el plan anterior. También creo que está mucho más enfocado en cuestiones de informática (y no tantas generalidades de ciencia básica). Por último pero no menos importante, el plan tiene una estructura distinta que entre otras cosas elimina las orientaciones y que constituye una carrera más corta (al menos en los papeles): son en total 10 cuatrimestres incluyendo el ciclo de ingreso.
Este nuevo plan se pondrá en funcionamiento este segundo cuatrimestre de 2023 con la oferta de 3 materias aún cuando falta la aprobación del Consejo Superior de la UBA, cosa que debería ocurrir en las próximas semanas.
Actualización 2023-09-08: el plan ya es oficial, fue aprobado por el consejo superior. Aún no lo actualizan en la página de la facultad pero se puede descargar desde la página de UBA, aquí.
Cerramos un cuatrimestre más con algunas particularidades. Una de las más destacadas fue el horario de cursada: dimos la materia en horario matutino de 8 a 11 hs. Otra de las particularidades fue la relación entre la cantidad de alumnos y la cantidad de docentes que nos permitió dar feedback bastante detallado en las entregas de los alumnos.
El feedback de los alumnos en la encuesta de cierre la cual nos arrojó los siguientes números:
La encuesta fue contestada por la totalidad de los alumnos que completaron el curso (10)
La evaluación general de la materia (en promedio) dio: 8,8 lo cual es menor que el cuatrimestre anterior (9,1) pero es mayor al promedio histórico (8,4). Adicionalmente el desvío fue mínimo: nadie calificó la materia con menos de 8.
Respecto del porcentaje de clases presenciales/virtuales, 9 alumnos lo consideraron apropiado mientras que solo 1 hubiera preferido más virtualidad.
Las otras dimensiones de evaluación de la materia también resultaron muy positivas (algunas incluso con valores record): claridad de los docentes: 4,6/5; Conocimientos de los docentes: 5 /5; Dinámica de las clase: 4,4/5; Materiales de estudio: 4/5.
El NPS nos dio 60 (esta es una métrica que puede tomar valores en el rango -100 +100, con lo cual un 60 es muy bueno)
De la restrospectiva de cierre nos quedamos con los siguientes accionables:
Agregar un ejercicio individual con el bot para familiarizarse antes del TP2
Dar un video o clase mostrando el flow de desarrollo guiado por pruebas desde el bot hasta la api
Dar la opción de usar infra gratuita o paga (por los propios alumnos) y considerar también que los propios alumnos gestionen su infra
Algunos otros números:
Respecto a la dedicación, tuvimos 28 clases de entre 2 y 3 horas cada una. Por otro lado la dedicación extra clase, en promedio por alumno, fue de un total de 116 horas (51 horas de tareas individuales, 12 horas de tp1 y 53 horas de tp2) repartidas en 16 semanas. Esto nos da unas 7,25 horas de dedicación semanal extra clase por alumno a lo largo de todo el cuatrimestre. Claro está que en este promedio hay semanas de 2 horas de dedicación extra clase y hay otras de 15 horas.
Tuvimos 42 tareas individuales, 1 en parejas y 2 TPs.
Tuvimos 14 inscriptos, solo 11 que asistieron alguna clase y finalmente 10 que aprobaron la cursada.
Más de una vez algún alumno me planteó la intención de hacer un video juego como trabajo final de carrera en FIUBA pero hasta el momento he tenido la oportunidad de dirigir solo un trabajo de este tipo. Sin embargo ese único caso, el video juego Fira de Facu Gertsner y Mati Feld, me permitió entender varias cuestiones del tema.
Hacer un juego implica al menos 3 cuestiones. En primer lugar tenemos la idea, el argumento, las reglas, en gran medida un trabajo creativo. En segundo lugar tenemos la parte artística: imágenes, sonido, animaciones, etc, lo tiene un parte creativa pero también una parte técnica. Finalmente está la programación. Podríamos ir un poco más allá y pensar en cuarta cuestión: la coordinación de tres cuestiones anteriores. La importancia y complejidad de cada una de estas cuestiones varia dependiendo del tipo de juego. Claramente la tarea de un ingeniero pasa por la programación pero también podríamos agregar la gestión.
Cuando un alumno se plantea hacer un juego como trabajo final debe considerar estas cuestiones. Asimismo, dependiendo también del tipo de juego, la programación puede no ser una tarea trivial. Otra vez dependiendo del tipo de juego puede ser necesario aprender algún lenguaje y/o framework particular y la mayor complejidad aquí no pasa por aprender el lenguaje/framework, sino por el hecho de tener que estimar y hacer un plan de trabajo sin tener un conocimiento del lenguaje/framework.
Teniendo en cuenta todo esto yo veo al menos 3 formas de plantear el trabajo final:
La primera opción es tomar el paquete entero y hacer «todo», lo digo entre comillas porque la parte de artística podría hacerlo el alumno o bien la podría subcontratar pues es una cuestión que excede a lo que se espera de un estudiante de ingeniería.
Una segunda opción es aprender el lenguaje/framework en la previa, o sea, dejar esa parte de investigación/aprendizaje fuera del alcance del trabajo final. En términos del esfuerzo total, la cuestión pareciera no cambiar pero hay una diferencia grande: si nos mandamos de una a hacer todo (opción 1) corremos el riesgo de armar un plan para X tiempo/esfuerzo y que luego termine llevando mucho más. En cambio, si hacemos la investigación en la previa, eso nos debería dar una mayor certeza para la planificación del proyecto disminuyendo así los riesgos de desvio.
Otra opción podría ser no hacer el juego en sí, sino hacer un prototipo que si bien puede sonar a poco, puede igualmente ser un trabajo considerable si hay que aprender un framework como Unreal.
En lo personal creo que en todos los casos el alcance del trabajo debe incluir la distribución del juego, no necesariamente en un marketplace de juegos pero al menos en una página web donde resulte accesible al público en general.
Aclaro: lo que menciono aquí es una opinión personal, o sea: no es una posición oficial de la institución.
En FIUBA la gran mayoría de los docentes en el área de computación son de dedicación parcial lo cual básicamente significa que van a la facultad a dictar una materia y listo. Esta dedicación parcial implica formalmente de ~10 horas semanales y un sueldo en sintonía con eso, con lo cual muchos de estos docentes ejercen la docencia más por gusto (¿vocación?) que por necesidad, ya que casi todos «viven» de su trabajo en la industria. Más aún, algunos ni siquiera tienen nombramiento formal, lo cual implica que no perciben un sueldo. Al mismo tiempo, en general no hacen investigación ni ninguna otra actividad en la universidad salvo tal vez colaborar en alguna cuestión como participar de una comisión asesora o dirigir los trabajos finales de los alumnos. Es posible que esta situación también ocurra en alguna otra institución pero no puedo asegurarlo. En lo personal, esta situación de FIUBA yo solía verla como «inconveniente» ya que a nivel institución esos docentes de dedicación parcial no generan conocimiento (publicaciones formales) pues no se hacen investigación. Esto hace que sean muy pocas las publicaciones formales en el área de computación con filiación FIUBA.
Por otro lado tampoco me parece conveniente que todos los docentes de una carrera sean de dedicación completa/exclusiva, porque en un área de ingeniería es necesario una dosis de «mundo real» que viene dada por el ejercicio en la industria.
Pero hace un par de meses tuve una charla con un docente investigador del área de computación de otra institución que me comentaba que gran parte de sus docentes son de dedicación completa/exclusiva y que como tales hacen hacen investigación. Y más aún, varios de ellos solo quisieran dedicarse a hacer investigación pero que por reglamentación están obligados también a dar clases. ¡Ooopss! docentes que no quieren hacer docencia.
Este me hace pensar que en la situación de FIUBA no es tan mala, al menos en términos de docencia pues como mencioné, gran parte de los docentes ejercen la docencia por «vocación»* . Sin embargo, creo que es necesario lograr una balance a nivel institucional para poder tener docentes que hagan investigación (lo cual requiere cargos de mayor dedicación) y docentes «de industria» (practitioners, como se les suele llamar a la gente de industria en los en ámbitos académicos).
* sin duda que hay más motivaciones que la pura vocación, algunos harán docencia para sumar antecedentes, otros para continuar aprendiendo, pero mi punto es que en general esos docentes no lo hacen «por necesidad» ni obligación.
Bien. Muy bien. Mucho mejor de lo esperado. En la previa teníamos record de inscriptos y el desafió de un cambio importante en el equipo: la salida de EmilioG (que teniendo un cargo de ayudante hacía la veces de JTP) y varios colaboradores. Motivados por estas dos cuestiones y el feedback de los alumnos de cuatrimestres anteriores decidimos realizar algunos cambios en la materia (algo ya había adelanto yo en este otro post)
En resumidas cuentas los cambios más relevantes que implementamos fueron:
La primera parte de la materia fue principalmente presencial mientras que la segunda parte fue principalmente virtual. Esto permitió que los alumnos se conozcan cara a cara para formar los equipos de trabajo y luego con los equipos ya armados pasamos a modalidad virtual.
Bajamos prioridad a algunos temas para dar más profundidad a otros. En este sentido despriorizamos cuestiones como escalamiento de equipo y principios Lean (cuestiones que verán posiblemente en AdminProd y/o EvaPro) y arquitectura de software (hay una materia entera dedicada a ello). Al mismo tiempo pusimos más foco en el proceso de BDD/TDD/CI/CD y «programación colectiva» (pair-mob programming).
También agregamos un ejercicio para trabajar de a pares antes de la conformación de los equipos de proyecto
Empezamos a tomar examen final, hasta el momento el mecanismo de evaluación estaba basado exclusivamente en el desempeño de los alumnos en las tareas realizadas durante la cursada (incluyendo tareas individuales y grupales). Pero en los últimos años tuvimos algunos casos en los que en verdad dudamos que algunos alumnos realmente hubieran entendido ciertos conceptos. Para mitigar/minimizar estas situaciones (gente que apruebe la materia sin tener en claro algunos conceptos importantes) es que agregamos el examen final
En lo personal quedé muy conforme con la forma de fluir de la materia. Desde la coordinación de la materia todo resultó muy fluido, no fue necesario «correr» con ningún tema. Preparamos las clases y las consignas con suficiente antelación y no tuvimos la soga al cuello con ninguna corrección. Al mismo tiempo creo que encontramos un mix justo de presencialidad/virtualidad.
El feedback de los alumnos también fue muy positivo, tanto en las retrospectiva como en la encuesta final del curso. No hubo tantos reclamos respecto de la carga de trabajo de la materia, si bien fue un tema mencionado, fue mucho más discreto que en ocasiones previas. Con la encuesta de la materia se dieron algunas situaciones particulares:
La encuesta fue contestada por 23 de los 24 alumnos que completaron la materia (record)
La evaluación general de la materia (en promedio) dio: 9,1 lo cual iguala el máximo histórico de la materia pero con una particularidad adicional: un desvío mínimo, todas las evaluaciones fueron 8, 9 y 10, o sea que nadie calificó la materia con menos de 8.
Las otras dimensiones de evaluación de la materia también resultaron muy positivas (algunas incluso con valores record): claridad de los docentes: 4,7/5; Conocimientos de los docentes: 4,9 /5; Dinámica de las clase: 4,7/5; Materiales de estudio: 4,4/5.
El NPS, que anteriormente nos había dado 38, ahora nos dio 61 (esta es una métrica que puede tomar valores en el rango -100 +100, con lo cual un 60 es muy bueno)
De la restrospectiva final identifiqué las siguientes acciones concretas para trabajar:
Revisar/editar los videos sobre infraestructura pues tienen contenidos que se sueperponen
Crear una base de conocimiento con los problemas recurrentes que se encuentran los alumnos al programar con Ruby/Padrino
Revisar el timelime de ejercicios/correcciones
Hacer una explicación más detallada de la configuración & funcionamiento del pipeline y la infra de los trabajos finales
Algunos otros números:
De los más de 30 inscriptos iniciales, solo 24 completaron la cursada
La nota promedio de aprobación de cursada fue 7,9
Tuvimos 38 tareas individuales, 1 tarea en parejas y 2 trabajos prácticos
En términos de dedicación extra clase, en promedio por alumno, fue de un total de 112 horas (53 de tareas individuales/en pareja, 12 horas de tp1 y 47 horas de tp2) repartidas en 15 semanas (que fue la duración de este cuatrimestre para nosotros). Esto nos da unas 7 horas de dedicación semanal extra clase por alumno a lo largo de todo el cuatrimestre.
Hasta el momento tuvimos 2 fechas de examen final en las cuales se presentaron 17 estudiantes de los cuales 15 fueron aprobados.
La facultad de Ingeniería de Universidad de Buenos ofrece dos carreras en el área de sistemas: Ingeniería en Informática y Licenciatura en Análisis de Sistemas. Son dos carreras distintas en el sentido que la licenciatura no es un paso intermedio de la ingeniería. Pero obviamente hay ciertas materias que son «compartidas» por ambas carreras, típicamente las materias de algoritmia, estructura de datos, sistemas operativos y algunas materias de ciencia básica.
En mí época de alumno (allá por comienzos del siglo) ambas carreras compartían dos materias de ingeniería de software que se llamaban: Análisis de Información y Técnicas de Diseño. Tal como los nombres lo sugieren, una estaba centrada en cuestiones de requisitos y la otra en cuestiones de diseño y ambas se cursaban secuencialmente. En el año 2015 la licenciatura modificó su plan de estudio y entre otras cuestiones cambio estas materias reemplazándolas por Métodos y Modelos de la Ingeniería de Software 1 y 2 (comúnmente conocidas como MeMo1 y MeMo2). Por su parte la ingeniería continua aún hoy en día con las mismas dos materias que cursé yo hace 20 años.
Las dos nuevas materias introducidas por la licenciatura están pensadas en línea con la forma en que se desarrolla el software actualmente: de manera iterativa e incremental. Esto implica que en ambas materias se estudia «lo mismo» con distinto pero con distinto foco/profundidad. Ambas materias cubren las distintas actividades del desarrollo de software (requisitos, análisis, diseño, gestión, programación, prueba, etc, etc).
La primera materia (MeMo1) tiene más foco en las primeras actividades del proceso de desarrollo pero cubriendo también cuestiones de diseño, programación y despliegue. La segunda materia (MeMo2) tiene más foco en las cuestiones «del tramo final» incluyendo programación testing, gestión de ambientes y despliegues. Obviamente que hay cierta superposición teórica de temas y es intencional: cuestiones que en una materia tal vez se ven en solo teoría en la otra se ven en la práctica.
A partir de la iniciativa de la Facultad de Ingeniería de rehacer los planes de estudio de todas las carreras, junto a Carlos Fontela y Sergio Villagra comenzamos a trabajar en un propuesta para la enseñanza de la Ingeniería de Software de cara a determinar una estrategia unificada para las 2 carreras. Dado que ambas carreras tienen un perfil distinto, el desafío estaba en determinar el núcleo mínimo común para ambas carreras permitiendo que luego cada carrera acorde a su perfil pueda profundizar contenidos/materias adicionales según considere necesario. En lo que resta de este artículo voy a compartir algunos de los puntos que me parecen más importantes de la propuesta en la que trabajamos.
Antes de hablar de potenciales materias y sus contenidos, hay 2 premisas que tomamos como puntos de partida:
Hay contenidos de ingeniería de software que deben ser abordados en forma temprana y transversalmente en todo el plan de estudio. Ejemplos de esto son prueba unitaria automatizada y versionado.
La ingeniería de software debe cubrir todo el proceso de desarrollo, desde la formulación de la idea hasta la puesta en producción. Lo primero es algo muy aceptado y muy presente en la bibliografía, podríamos incluso llamarlo Ingeniería de Requisitos. Lo segundo es algo un poco más polémico y menos habitual en la academia pues incluye cuestiones como despliegues, ambientes, infraestructura y hasta algunas cuestiones operación, lo que comúnmente se engloba bajo el término «DevOps».
Para este segundo cuatrimestre de 2022 estamos considerando realizar varios cambios en la dinámica de la materia.
En primer lugar tenemos un cambio importante en el equipo docente. Emilio Gutter quien venía desempeñando funciones de JTP ya no estará en la materia. Su lugar lo tomará, al menos parcialmente, Hernán de la Fuente, ex-alumno de la materia, miembro del equipo hace ya varios años y muy próximo a graduarse. También tenemos algunos otras bajas, no todas ellas cubiertas, con lo cual el tamaño del equipo se verá disminuído.
Por otro lado vamos a cambiar el orden de algunos temas y la forma en que los damos. Vamos a mantener una modalidad híbrida en la apuntamos a realizar cambios significativos en la dinámica de las clases presenciales.
También tenemos la intención de «reenfocar» algunas cuestiones, concretamente vamos a quitar un poco de relevancia al modelado de objetos/clases para poner más foco en el proceso de construcción (BDD/TDD) y el trabajo en equipo. Esto implica que algunos de los ejercicio individuales de programación pasarán a ser ejercicios en grupales.
Finalmente el último cambio es tal vez el de mayor impacto, vamos a cambiar el mecanismo de evaluación. Hasta el momento no tomábamos parciales ni final. La evaluación de los alumnos era constante a partir de las distintas tareas semanales y proyecto de TP. La idea es mantener eso pero adicionalmente agregar una instancia de evaluación al final de la materia donde cada alumno individualmente tenga que desarrollar «en vivo» una funcionalidad sobre su proyecto. Cuando digo en vivo me refiero a una sesión tipo pairing, donde el alumno acompañado por un docente desarrolla una funcionalidad de acuerdo al proceso y técnicas estudiadas en la materia. Esto no debería representar ningún desafío para los alumnos ya que es lo que hacemos durante la materia. ¿Entonces por qué lo vamos a hacer? Porque tenemos la sospecha de que al trabajar en equipo no todos los miembros asimilan los conceptos, como que algunos «delegan» en sus compañeros.
Luego de dos años de completa virtualidad, en marzo de 2022 volvimos a las aulas. Pero dado que descubrimos que algunas cuestiones funcionaban mejor en modo virtual, la vuelta fue mixta. La facultad habilitó un esquema híbrido con un cierto porcentaje obligatorio de clases presenciales y el resto a criterio de cada docente. En el caso de MeMo2, hicimos principalmente presencial la primera parte de la materia y principalmente virtual la segunda parte.
Para ser «el primer cuatrimestre del regreso» creo que estuvo bien y confío en que aún podemos mejorar algunos aspectos. De todas formas tengo la sensación de que gran parte de los alumnos (¿casi todos?) prefiere quedarse en la virtualidad total. Al margen de la vuelta parcial a la presencialidad, este cuatrimestre tuvimos 2 cambios relevantes respecto de cuatrimestres anteriores: 1) dedicamos una clase a hacer el setup de la infraestructura del TP2 (creación del clúster de kubernetes, configuración del pipeline, etc), cosa que previamente lo veníamos haciendo los docentes «tras bambalinas» y 2) Reciclamos un TP2 existente (hasta el momento, cada cuatrimestre «inventábamos» un nuevo TP). Creo que ambos cambios fueron positivos.
En lo referente al desempeño de los alumnos notamos una disparidad importante en la dedicación del TP2. Contexto: el TP2 tiene un alcance fijo (negociable) y dadas las capacidades de cada equipo puede que el tiempo requerido para completarlo sea distinto para cada uno. Lo que vimos es que en términos de calificación todos los equipos tuvieron notas muy similares (menor dispersión de notas que cuatrimestres anteriores), pero al ver la dedicación tenemos en un extremo equipos que completaron el TP2 en ~80 horas mientras que otros dedicaron ~170 horas. Mi explicación de esto tiene que ver con 2 cuestiones: 1) afinidad de los miembros de equipo y 2) experiencia / «habilidad» técnica (no necesariamente en este orden):
No es lo mismo un equipo cuyo miembros son amigos y vienen trabajando juntos en varias materias que un equipo cuyos miembros recién se conocen y que tal vez no se llevan muy bien.
No es lo mismo un equipo cuyos miembros ya tienen experiencia profesional programando y están familiarizados con el stack de herramientas que un equipo donde no todos sus miembros tienen experiencia profesional programando y que desconocen completamente el stack de herramientas. Aquí también entra en juego «la maña» que cada uno se puede dar para resolver dificultades técnicas.
Respecto de 1) no veo que como docentes podamos hacer mucho más allá de permitir que los alumnos armen los equipos a su parecer y de forma temprana en la materia como para que se vayan conociendo. Respeto de 2) lo que intentamos hacer es contestar muy rápidamente las consultas de indole técnicas y proveer a los alumnos con guías/videos para facilitar las cuestiones técnicas/tooling.
Las encuesta interna del curso nos arrojó los siguientes números:
Evaluación general de la materia: 8.1 / 10
Conformidad con la nota de aprobación: 4.8 / 5
Dedicación semanal extra-clase: 8.6 horas
Materiales de estudio: 4.0 / 5
Claridad de los docentes: 4.3 / 5
Conocimientos de los docentes: 4.9 / 5
Dinámica de las clases: 4.1 / 5
Net Promoter Score: 37.5 (métrica que puede oscilar entre -100 y +100)
Comenzamos el cuatrimestre con 22 alumnos, 2 abandonaron en las primeras semanas y los restantes 20 aprobaron la materia. Lo nota promedio de aprobación fue 8 lo cual es lo mismo que el cuatrimestre anterior pero en este caso la dispersión fue menor.
Como de costumbre cerramos el cuatrimestre con una retrospectiva pero esta vez entre barbijos (que solo algunos nos los sacamos para la foto final)
El año pasado comenzamos con la práctica de encuestar informalmente a los alumnos sobre las algunas de las prácticas de desarrollo que estudiamos (y aplicamos) en la materia. Concretamente les consultamos con 3 prácticas que estudiamos en la materia, que consideramos muy beneficiosas pero que curiosamente en la industria no tienen un uso masivo (aún): Mob-programming, Trunk-based development y Desarrollo guiado por Pruebas (BDD/TDD).
Explicamos a los alumnos cómo utilizar estas prácticas y las aplicamos en el contexto de un proyecto de desarrollo.
Si bien los alumnos pueden no utilizar estas prácticas (hecha la ley, hecha la trampa) insistimos en las utilicen principalmente con dos argumentos (ya que en general a los alumnos no les basta con que el docente les diga «es por aquí» ¡ja!):
Son prácticas que traen importantes beneficios y cuya efectividad está ampliamente probadas
A pesar de lo anterior, son prácticas que en la industria no son mainstream y que incluso se las mira con cierta desconfianza en algunos contextos. En la materia les ofrecemos un ambiente seguro para que puedan experimentar con la práctica, contando incluso con la guía del equipo docente. Si prueban estas prácticas en este contexto ¿donde las van a probar? ¿en sus trabajos con la presión de su jefe, los deadlines y el apuro de la industria?
La actividad de encuesta es bastante simple, les presentamos un cuadro de dos ejes y les pedimos que indiquen ahí cómo fue su experiencia utilizando estas prácticas.
Puede resultar curioso para algunos que la la práctica con mejor evaluación es el desarrollo guiado por pruebas. Cabe destacar aquí que al hablar de desarrollo guiado por pruebas me refiero al uso de BDD/TDD, o sea, guiar el desarrollo a partir de especificaciones en forma de ejemplos (pruebas) generados colaborativamente entre usuarios y el equipo de desarrollo.
Blog de NicoPaez 