Curso online de TDD

Hace ya un par de años que decidí no dictar más cursos de TDD, sin embargo desde ese momento me encontré con varias situaciones en las que necesité de un material introductorio a TDD, a modo de nivelación, para poder explicar luego el uso de TDD en escenarios más avanzados/reales. Busqué pero no encontré ninguno que me resultara convincente, entonces decidí generar mi propio material.

Es por esto que estas últimas semana estuve trabajando en un curso en video de «Introducción a TDD» que ya está disponible en la plataforma Udemy.

Si bien el curso está armando con C# y Nunit, la tecnología termina siendo anecdótica pues todo lo explicado es completamente aplicable en otros stacks de tecnología y todo el código es fácilmente traducible.

La idea de este curso es explicar los fundamentos de esta técnica de desarrollo ¿Vas a podes con este curso utilizar TDD inmediatamente en tu trabajo de desarrollo cotidiano? Depende, sin duda te va servir para entender la técnica y aplicarla en ciertas partes de tu código, pero de ahí a poder utilizarla al 100% en escenarios «reales», hay un largo trecho, hace falta mucha práctica y también utilizar algunas técnicas que intencionalmente no están cubiertas en este curso. Justamente la idea es: 1) comenzar tomando este curso, 2) practicar e incluso intentar aplicar la técnica en algunas partes/momentos de tu trabajo, 3) tomar una curso/taller más avanzado que tengo planeado publicar para mediados de 2025 y que incluirá muchas de las cosas que habitualmente doy en mis cursos de ingeniería de software.

Si sos estudiante de FIUBA y tenés pensado tomar mi curso de Ingeniería de Software 2, te recomiendo hacer este curso a modo de nivelación/repaso, escribime desde tu cuenta @fi.uba.ar y te tramito un pase gratuito.

Los seguidores habituales de este blog, también pueden escribirme y les tramito un pase.

Revisión y ajustes de «Construcción de Software: una mirada ágil»

Como mencioné hace unas semanas, estuve releyendo el libro. Bueno, lo terminé y encontré varias cuestiones. Aquí voy.

Contexto

Antes que nada me parece importante mencionar que el objetivo del libro era dar una idea general de agile incluso cuando algunos capítulos ofrecen bastante detalles de técnicas.

Sin duda que en estos últimos 10 años surgieron muchas cuestiones que podrían/deberían mencionarse en un libro de introducción a agile, algunos temas en este sentido podrían ser: escalamiento, #noEstimates y dual-track agile. Pero también es cierto que varias de las cuestiones que aparecieron no están necesariamente relacionadas a agile, por ejemplo «observabilidad» y «testear en producción» son prácticas que uno podría utilizar sin trabajar en un contexto agile del mismo modo que uno podría trabajar en un contexto agile sin usar estas prácticas.

Al margen de las prácticas yo creo que el mayor cambio que hemos presenciado es que hace 10 años agile era mainstream mientras que hoy en día ya ha supero eso y ahora es el enfoque por default (incluso cuando haya personas/organizaciones que no lo dominan).

Generalidades

La primer cuestión que detecté es que tendríamos que haber numerado explícitamente los capítulos, o sea, en la edición actual los capítulos solo tienen un nombre pero no tienen un número lo cual resulta incómodo cuando uno quiere referirse a un capítulo en particular :-(.

Como era de esperar (o no tanto) detecté algunos errores menores de tipeo (typos).

Creo que en ningún lado explicamos como es el flujo completo de un proyecto ágil, tenemos capítulos que tratan sobre cada una de las partes y tenemos también un capítulo que, a modo novela, cuenta un relato de un proyecto pero no tenemos un capítulo que explique la secuencia de eventos, ceremonias, etc. de un proyecto de punta a punta.

Me parece que falta más énfasis en la entrega continua, es una cuestión que está mencionada pero de forma muy tímida, discreta. Tal vez sea que la entrega continua es mi foco de trabajo actual (y desde hace unos años) pero si tuviera la posibilidad de hacer un ajuste en el libro, definitivamente sería poner más énfasis en la práctica de la entrega continua.

Muy relacionado con lo anterior, falta también más énfasis en stories pequeñas, de hecho creo que debería haber una sección (o incluso un capítulo) de slicing.

La práctica de Pair-Programming, que tiene más de 20 años y es core en XP, está apenas mencionada, creo que deberíamos haber escrito un capítulo al respecto (admito que cuando escribimos el libro, yo mismo no le daba la importancia que le doy en la actualidad a esta práctica).

En todo el libro hablamos constantemente de cliente pero en algunos casos creo que hubiera sido más conveniente hablar de usuario y obviamente hacer la diferenciación explícita entre usuario y cliente.

Finalmente, en lo personal, creo que cambiaría el orden de algunos capítulos.

Sobre cada capítulo

Nota previa: creo que la mayoría de los capítulos puede calificarse en uno de dos grupos: de mindset o de práctica. Los capítulos de mindset buscan explicar cuestiones de valores, principios, el espíritu de alguna cuestión casi sin entrar en cuestiones de prácticas o técnicas, aquí claramente están los dos primeros capítulos. Al mismo tiempo hay otros que se meten más concretamente en prácticas y técnicas, en cómo hacer concretamente alguna cuestión como es el caso del los capítulos de estimación (4) y retrospectivas (11). Dicho esto, los capítulos de mindset siguen siendo completamente válidos y casi que no requieren actualización. Por su parte los capítulos de prácticas, en su mayoría, requieren actualización ya sea por variaciones de las prácticas o por cambios en las herramientas.

Capítulo 1, «¿Por qué cambiar?»: es bastante filosófico/conceptual y si bien se podrían agregar algunas párrafos/secciones, creo que todo lo que dice sigue siendo válido.

Capítulo 2, «Iterativo por naturaleza»: también tiene un tinte bastante conceptual y apunta a explicar la necesidad de trabajar en forma iterativa. Me parece que hoy en día esta es una cuestión ampliamente aceptada aunque no en todos los casos correctamente implementada. Al igual que el capítulo 1, creo que se podría ampliar pero me parece que el contenido actual sigue siendo válido.

Capítulo 3, «Delineando el alcance»: explica las generalidades de las User Stories y la técnica de descubrimiento conocida como Visual Story Mapping(VSM). El contenido sigue siendo completamente válido y actual, aunque creo que amerita algunos ajustes relevantes. En primer lugar, cuando escribimos el libro no había una publicación formal de la técnica Visual Story Mapping, las fuentes disponibles eran algunos posts del blog del Jeff Patton (creador de la técnica) y de algunas otras personas que habían participado de alguna capacitación con el propio Patton. Al poco tiempo de la publicación de nuestro libro, finalmente Patton publicó un libro sobre esta técnica: User Story Mapping, Discover the Whole Story, build the right product. A partir de esto, nuestra descripción de la técnica difiere un poco de la descripción que hace Patton en su libro, lo cual no lo veo como un problema, nuestra descripción sigue siendo una herramienta válida y útil de comunicación/relevamiento. En este sentido creo que lo que sí le falta a nuestro libro (y en particular a este capítulo) es mostrar un ejemplo concreto del uso de la técnica. Finalmente algo que me suele ayudar mucho a entender el alcance de una funcionalidad es la técnica Example Mapping y por ello creo que agregaría una sección sobre la misma.

Capítulo 4, «Estimar no es predecir»: el contenido sigue siendo válido aunque mi práctica de estimación ha variado un poco. Creo que también que faltaría agregar algunos ejemplos concretos de las técnicas explicadas. Finalmente, si hubiera una nueva versión, sin duda agregaría alguna mención al movimiento #NoEstimates.

Capítulo 5, «Planificación constante»: aquí me parece que hay espacio para varios ajustes en línea con la idea de trabajar en un esquema de entrega continua. Planificamos el trabajo para toda la iteración pero esperando entregar los ítems apenas los vamos terminando sin esperar necesariamente al final de la iteración. Al mismo tiempo haría más énfasis en iteraciones cortas: una semana o a lo sumo dos. Creo que también es necesario ajustar la definición del slack pues me parece que no es precisa ni clara. Definitivamente agregaría algún apartado sobre técnicas slicing.

Capítulo 6, «Empezando por la aceptación»: este capítulo está muy bien y seguramente sea este el lugar para explicar con cierto detalle la técnica de Example Mapping. Este es uno de los capítulos que cambiaría de orden (lo pondría antes).

Capítulo 7, «Arquitectura y Diseño en emergencia»: gran parte de este capítulo habla de cuestiones que van más allá de agile, pero al margen de eso, su contenido sigue siendo actual.

Capítulo 8, «Probar, Probar, Probar»: trata de testing y dado que hace mención a varias herramientas requiere una actualización de las mismas. Al mismo tiempo creo que un punto para revisar es la taxonomía de pruebas, en lo personal, hoy en día no me convence del todo la taxonomía que escribimos.

Capítulo 9, «Esto está listo»: es más conceptual que práctico y ha envejecido bien. Nada que ajustar.

Capítulo 10, «Integrando el producto al instante»: al igual que el capítulo de arquitectura, tiene algunas cuestiones que van más allá de agile y al igual que el capítulo de pruebas hay cuestiones de herramientas a actualizar. Al mismo tiempo creo que falta mencionar más explícita y enfáticamente que hacer integración continua implica que todo el equipo trabaja simultáneamente sobre el mismo branch (o que si se crean branches, no deben vivir más de 1 día). Finalmente me resulta curioso que hablamos de feature flags sin utilizar el término feature flag.

Capítulo 11, «En retrospectiva»: es el más largo y si bien sigue siendo completamente válido, dista un poco de lo que es mi práctica actual de retrospectivas, principalmente la parte de preparación.

Capítulo 12, «Reuniendo al equipo»: creo que está muy bien, tal vez profundizaría sobre Pair-Programming (si no agregara un capítulo exclusivo para esta técnica).

Capítulo 13, «Irradiando Información»: muy bien, no creo que necesite cambios, tal vez un agregado para escenarios remotos.

Capítulo 14, «¿Quién manda a quién?»: es muy de mindset y sigue aplicando completamente.

Capítulo 15, «No hay como un buen ambiente»: me gusta mucho, sigue aplicando completamente tal como está aunque creo que faltaría agregar algo de operaciones y/o ambiente productivo.

Capítulo 16, «La fantasía de evitar los cambios»: completamente actual, nada que ajustar.

Capítulo 17, «Formalizando compromisos»: completamente actual, nada que ajustar.

Capítulo 18, «Construyendo con calidad día tras día»: completamente actual, nada que ajustar.

Capítulo 19, «Un día de desarrollo ágil»: creo que fue una muy buena idea para ejemplificar como fluye el día de un equipo trabajando con agile, sin embargo hoy en día creo que faltaría agregar alguna mención/situación relacionada a la operación/producción.

Capítulo 20, «Todo muy lindo pero…»: completamente actual, nada que ajustar.

Capítulo 21, «La riqueza de la diversidad»: completamente actual, nada que ajustar.

No sé si algún día escribiremos una segunda edición, pero en lo personal voy a escribir algunas línea relacionadas a los capítulos marcados en rojo y tal vez también para los naranjas.

Sobre la movida de la Agile Alliance y el PMI

El pasado 3 de enero se anunció «la unión» de la Agile Alliance (AA) al Project Management Institute (PMI) y por todos lados saltaron opiniones, muchas de ellas bastante críticas.

En lo personal el hecho en sí mismo no me resulta demasiado relevante. Al mismo tiempo lo que me llama la atención es la reacción «de la comunidad», muchos de los denominados agilistas.

En lo personal, he estudiado el PMBoK pero nunca me certifiqué como PMP ni fui parte del PMI. Por otro lado sí he tenido membresía de la Agile Alliance, ya que al ser speaker de su conferencia anual (Agile XX) solían otorgar una membresía como parte de los beneficios de speaker. Tampoco tengo ninguna certificación del universo Agile. En términos generales no soy partidario de las certificaciones, no les veo gran valor, pero eso es tema de otro post.

Respecto de la noticia en cuestión solo quiero compartir algunas preguntas para que el lector pueda reflexionar y sacar sus propias conclusiones:

¿Hasta qué punto estas organizaciones representan a los practicantes y a la práctica en sí misma? La misma pregunta podríamos hacerla para «la comunidad» ¿hasta qué punto la comunidad (la gente que organiza y participa activamente de eventos y del debate público) representa a los practicantes?

Aquellos que critican a la AA, ¿cuán involucrados están (o han estado) con la AA?

Cuando hacemos proyectos: gestionamos los proyectos o los proyectos nos gestionan a nosotros ¿qué preferimos?. Sin duda hay distintos enfoques para la gestión pero en lo personal me parece que algunos agilistas reniegan exageradamente de la gestión y en este sentido muchos han demonizado al PMI y su enfoque de gestión.

Sin duda que dentro de estos dos movimientos hay posiciones extremas. Podríamos pensar en los tradicionales gerentes de proyectos del mundo PMI y los fundamentalistas abrazadores de árboles dentro del mundo ágil. ¿Cuán representativos son estos estereotipos del grueso de los practicantes?

Una cuestión que sería importante tener presente es que el PMI como organización ha propuesto un enfoque de gestión que en cierto modo muchos ven como lejano, distante o incluso hasta contrario al enfoque de gestión de Agile. Debemos decir también que Agile surgió del mundo IT mientras que el PMI es mucho más amplio y por supuesto que no es lo mismo gestionar proyectos de IT que proyectos de Ingeniería Nuclear, Civil o Naval.

Finalmente, creo si leemos el comunicado dejando de lado cualquier prejuicio, el anuncio resulta interesante e incluso hasta prometedor. Veremos.

Una mirada ágil, 10 años después

Mi libro «Construcción de Software: una mirada ágil», que escribí con colegas de FIUBA, ya tiene más de 10 años. Lo publicamos en 2014 y desde ese momento algunas cuestiones han cambiado. Sin embargo creo que todo el contenido del libro es aún válido y por ello lo sigo usando en mis cursos. De hecho el libro está disponible gratuitamente en forma digital desde el año pasado, solo hay que completar este formulario y una copia registrada llega por correo en el transcurso de un par de horas.

Si bien el libro sige siendo actual, hay algunas cuestiones que en la actualidad suelo manejar de una forma distintas a la que quedó descripta en el libro. El auge de DevOps, las transformaciones digitales y la pandemia dispararon y/o aceleraron varios cambios haciendo algunas partes del libro cobren mayor relevancia y tal vez alguna otra ya no tengo tanto valor.

Cabe destacar que cuando escribimos el libro lo pensamos para un lector que posiblemente ya estaba familiarizado con el desarrollo de software tradicional y por ello en el libro apuntamos a destacar aquellos puntos en los que los métodos ágiles tenían una propuesta innovadora. Hoy en día los métodos ágiles son el estándar de facto (al menos desde la intención ya que en la práctica no todos los logran). Más aún, muchos de lo que empezaron en la profesión en los últimos años bien podrían ser denominados «nativos ágiles».

Esta semana empecé a releer todo el libro tomando algunas notas para una potencial segunda edición que incluya actualizaciones a algunos capítulos e incluso tal vez algún nuevo capítulo. En las próximas semanas, a medida que avance en la revisión, iré publicando mis notas «de actualización».

[off-topic] Políticos en la oposición

Hace un par de semanas me encontré con una compañera de la secundaria que fue diputada por el «Frente de Todos (contra todos)» y cuyo mandato terminó en el 2023. Hablando con ella sobre las medidas tomadas por el gobierno actual y sobre la inacción [1] de su espacio político, ella me dice «la gente votó a Milei, ahora que se lo banquen«. Esta respuesta me generó una mezcla muy variada de sensaciones: risa, bronca, impotencia y finalmente resignación.

No todo el mundo votó a Milei, más del 40% votó al Frente de Todos (contra todos) y con una expectativa que va más allá de ganar o no la elección. De una u otra forma, esa expectativa puede resumirse en que hagan algo para mejorar nuestra sociedad en línea con los valores y principios de su movimiento. De hecho, el puesto de presidente lo ganó Milei, pero hay varios legisladores que obtivieron una banca. Ojo, esto que digo no es solo para el Frente de Todos (contra todos) sino para todo movimiento: si te presentas a elecciones y alguien te vota entonces tenés una obligación con esos votantes. «No vale» que te quedes cruzado de brazos hasta la próxima elección y menos aún si ganaste una banca legislativa.

Y no me vengas con «estamos votando en contra», no alcanza, espero que traigas ideas, que te muevas, que hables con la gente, que acompañes, que traigas ideas porque con solo votar en contra no se construye nada.

Libro Recomendado: Tidy First?

Ayer terminé mi primer lectura de vacaciones, el libro más reciente de Kent Beck: «Tidy First?: A Personal Exercise in Empirical Software Design».

Primero los datos: el libro es bastante corto, apenas 99 páginas distribuidas en 33 capítulos lo cual sigue el estilo típico de los libros de Beck: capítulos cortos. En este caso está llevado al extremo porque hay capítulos de menos de 2 páginas. El libro es el primero de una serie, que según el propio Beck, tendrá 3 libros. El libro arranca con cuestiones muy concretas y gradualmente se va poniendo más teórico/filosófico.

Pero… ¿qué es un «tidy»? Como la traducción puede sugerir, un tidy es un emprolijamiento. Una mejora en la estructura del código de cara a facilitar su entendimiento/evolución. En un punto es cómo un refactor, pero más chico.

Ahora mi opinión: el libro me gustó mucho, mezcla cuestiones muy concretas/prácticas (los «tidyings») con cuestiones más teóricas/filosóficas (cuando tidy y cuando no, cuánto tidy, etc). Todo esto analizado una visión económica. Creo que son muy pocos los libros que tratan este tipo de cuestiones. A su vez, la organización en capítulos cortos hace que la lectura me resulte muy cómoda. Si bien es libro que cualquier programador debería poder entender sin dificultad, creo que los programadores más experimentados van a sacarle mayor provecho.

Proyectos de verano 2025

Desde mediados de diciembre hasta mediados de Marzo es el período que denomino «cuatrimestre de verano» y que en mi caso se caracteriza por tres cuestiones:

  1. Mis actividades en la universidad son mínimas en gran medida por el receso de verano
  2. Como consecuencia del punto anterior tengo más tiempo disponible que durante el resto del año. Obviamente parte de ese tiempo lo utilizo para descansar pero también para hacer «proyectos distintos», por ejemplo proyectos «experimentales», proyecto con nuevos clientes, etc.
  3. Investigación y generación de material, escribo, hago videos, etc, etc.

Para este «cuatrimestre de verano de 2025», tengo poco trabajo agendado con clientes con lo cual, si la situación no cambia, ya tengo dos temas en los que trabajar.

Por un lado quiero hacer algunos experimentos con tecnologías de inteligencia artificial. Creo que mi proceso de desarrollo podría mejorar (en términos de productividad/velocidad) a partir del uso de herramientas como Co-Pilot y JetBrains AI.

Por otro lado quiero escribir una actualización de algunos capítulos de mi libro «Construcción de Software: una mirada ágil» que ya tiene más de 10 años y ya tengo identificado algunos capítulos que requieren una actualización.

De vuelta Linux +10 años después

Mi última PC de escritorio la compré allá por 2005 y dejé de utilizarla allá por 2008. Desde entonces he utilizado notebooks. A comienzos de 2013 compré una MacBook Air y desde entonces he vivido con MacOS.

Pero este año decidí volver a comprarme una máquina de escritorio, me compré una mini PC (en otro post hablaré sobre el hardware). La cuestión era qué sistema operativo utilizar, las opciones eran: Windows 11 o algún Linux. Descartar el Windows fue mucho más fácil que elegir la distribución de Linux. Luego hablarlo con un par de colegas y leer algunos foros, los finalistas fueron Arch y Ubuntu. Me incliné por Ubuntu, principalmente porque pensé que tendría menos troubleshooting con los drivers (la última vez que instalé Linux tuve que recompilar el kernel para hacer andar un modem 3G).

Ya teniendo decidido instalar Ubuntu lo siguiente a ver era si ir por un «Ubuntu puro» o alguno de sus «primos» como Mint o Elementary. Finalmente me quedé con Ubuntu y con el sistema de ventanas default.

La instalación fue muy fluída, descargué una imagen, la quemé en un USB booteable y desde ahí instalé. Hice una configuración dual-boot con el Windows que venía de fábrica con la PC porque uno nunca sabe si en algún momento sale un proyecto de desarrollo Windows.

Para mi sorpresa, todo, absolutamente todo me anduvo de una: wifi, bluetooth, micrófono, webcam, impresora y los dos monitores. Impresionante. El dato curioso es que lo único que me requirió más trabajo de lo esperado fue la configuración de la VPN que yo pensaba que andaría de una y sin embargo tuve que hacer troubleshooting y unas operaciones adicionales via terminal.

Luego de esta fluida experiencia, estoy convencido que de ahora en más vamos a pedir uso obligatorio de Linux en las materias a mi cargo. Perdón, corrijo, no vamos a obligar a usar Linux, sino que solo daremos soporte a quienes trabajen con sistemas de la familia unix/linux.

Notas de un cuatrimestre atípico @fiuba

Atípico básicamente por dos cuestiones: un cambio en plan de estudios de la carrera y una situación de movilización y defensa de la educación pública. Vamos por parte.

La situación sin precedentes de emergencia presupuestaria y ataque constante a la educación pública nos llevo a realizar varias acciones de visualización y apoyo, que entre otras cuestiones, nos llevó a realizar clases públicas.

Por otro lado, y al igual que en UNTreF, este cuatrimestre «estrenamos» curso en FIUBA a partir de la implementación del nuevo plan de Ingeniería Informática.

En este sentido, el curso que dicto actualmente está «homologado» como Métodos y Modelos en la Ingeniería de Software 2 (9521 para la carrera de Licenciatura en Sistemas) y como Ingeniería de Software 2 (TA049 para la carrera de Ingeniería Informática).

En lo formal el cambio de plan de Ingeniería Informática tiene un impacto menor en términos de contenidos, pero en la práctica vivimos dos impactos:

  1. Si bien la materia sigue ubicada en cuarto año, hay un cambio en la correlativas que hace que los alumnos puedan llegar habiendo recorrido un camino distinto de materias.
  2. Al mismo tiempo, como la materia no es correlativa de ninguna otra, es posible que esta materia sea la última de la carrera. De hecho este cuatrimestre tuvimos 3 alumnos para quienes esta fue su última materia.

Adicionalmente, debido a el proceso de transición entre planes, tuvimos gente gente en situaciones particulares respecto de las materias cursadas previamente.

A pesar de estos cambios creemos que el curso salió muy bien. Inicialmente parecía que sería más complicado pero luego la cuestión mejoró. Comenzamos el cuatrimestre con un record de inscriptos, según nos informó el departamento: 51 alumnos. Sin embargo, varios nunca aparecieron y en la segunda clase ya teníamos 33. Como de costumbre, durante el cuatrimestre se fueron bajando algunos más y finalmente terminamos la materia con 22 alumnos. Algunos otros números de nuestra encuesta:

  • La encuesta fue contestada por 18 alumnos
  • La evaluación general de la materia: 8,9 / 10
  • La nota promedio de aprobación fue 7,3/10 lo cual representa un mínimo histórico pero al mismo tiempo la conformidad con la nota fue 4,4 / 5.
  • Dinámica de clases fue 4,7/5 lo cual iguala el máximo histórico. Curiosamente algunos alumnos destacaron que lo mejor de la materia fueron las clases presenciales.
  • Respecto del porcentaje de presencialidad/virtualidad, 15/18 indicaron que les pareció indicado mientras que 2 hubieran preferido más virtualidad y 1 más presencialidad.
  • La dedicación semanal extra-clase, según reportaron en la encuesta, fue de 9 horas, sin embargo en el tracking de tareas ese número da 7,9.
  • El NPS nos dió 44

Por otro lado, en la actividad de cierre destacaron dos items accionables hacía adelante:

  • Proveer más material sobre Arquitectura Hexagonal, un tema central de la materia y que este cuatrimestre costó mucho.
  • Revisar la configuración de las reglas de code quality ya que algunas resultaron incómodas, sin sentido y/o demasiado exigentes.

Cierro con algunos comentarios de feedback libre de la encuesta:

«Excelente la materia, por momentos la odie, pero ya al haber terminado, puedo observar que la dureza y el nivel de exigencia valieron la pena y me enriquecieron en todo sentido.»

«Fue la materia en la que más aprendí en lo que va de la carrera»

«Me pareciero muy util el contenido dado y la forma de dictarlos. Me da lástima recién a esta altura de la carrera toparme con esta materia que siento que me hubiera servido mucho en otro momento. Me gustó mucho que se recomienden autores para leer sobre ciertos conceptos, que utilicemos TDD (por más que personalmente no me gusta, ahora le encuentro un gran valor) y sobre todo que hayamos tenido clases presenciales.
Me voy de la materia sintiéndome motivada a mejorar, queriendo investigar y profundizar sobre los temas que aprendí. Muchas gracias por a todo el equipo docente de la materia, me pareció muy bueno todo!»

Nuevos cursos de Ingeniería de Software

A partir del cambio de plan de estudios de la carrera de Ingeniería en Computación de UNTreF, este cuatrimestre tuvimos que cambiar nuestro curso de Ingeniería de Software. Previamente la materia Ingeniería de Software se encontraba al final de la carrera (último año) y ahora, en el nuevo plan, se encuentra en tercer año.

Este cambio impactó en varias cuestiones:

  1. Los conocimientos previos con los que llegan los alumnos. Previamente los alumnos llevaban con unas 35 materias aprobadas, mientras que ahora llegan con alrededor de 20.
  2. El nivel de maduración/experiencia de los alumnos. En general los alumnos de último año ya se encuentran trabajando en el rubro y eso les da una determinada experiencia de programación, resolución de problemas, etc. Los alumnos de tercer año, en cambio, muchos aún no trabajan en el rubro y su experiencia en programación es mucho más acotada.
  3. La cantidad de alumnos, hay muchos más alumnos en tercer año que en quinto. Pasamos de tener unos 8-10 alumnos a tener alrededor de 25.

Al mismo tiempo, si bien el nombre de la materia se mantiene y los contenidos no son tan distintos, el nivel de profundidad cambió radicalmente. Vimos de forma mucho más superficial ciertas cuestiones de gestión, e incluso sacamos algunos temas de arquitectura, mientras que nos detuvimos mucho más en temas de programación y diseño a nivel objetos. Cuando comenzamos a planificar la materia pensamos en varios cambios, pero finalmente decidimos no hacer demasiado cambios «up-front» porque desconocíamos el perfil de los «nuevos alumnos», así que decidimos seguir un enfoque más «adaptativo» e ir viendo sobre la marcha.

Comenzamos el curso con 33 alumnos y lo terminamos con 24, una caída muy importante comparado con nuestros números históricos (en los últimos dos años todos los alumnos que comenzaron la materia, la completaron). Sin embargo creemos que no estuve tan mal, sobre todo porque en un primer momento pensamos que llegaríamos al final con menos de 10 alumnos.

Una consecuencia del cambio de plan de estudio es que muchos de los contenidos que sacamos de la materia, los estaremos dando en una nueva materia optativa, «Ingeniería de Software Avanzada» que comenzaremos a dictar el año próximo. En lo personal nunca dicté una materia optativa, pero es algo que me viene dando vueltas en la cabeza hace un buen rato. Me gusta la idea de que la gente no venga «obligada». Al mismo tiempo, creo que al ser una materia optativa, se presta un poco más a la experimentación.

Hoy, habiendo terminado la materia, estamos muy conformes con el resultado y lo cual es confirmado por el feedback de los alumnos. La evaluación general de la materia, resultado de una encuesta anónima, nos arrojó en promedio 9/10, con una dispersión mínima (fueron todos 8, 9 y 10).

Cierro con algunos comentarios de la encuesta:

«Gran materia, aprendí un montón. Vine de entrada con esa expectativa, ya que compañeros que ya la había cursado me dijeron que era de las mejores de la carrera.»

«Aprendí como es la dinámica de trabajar desarrollando, algo que no se aprende en ninguna materia. Me parece muy valiosa la enseñanza desde cero y terminar aplicando todo junto en un proyecto. Estoy muy agradecido»

«Buena dinámica de clases, menos aburridas que una clase normal.»

(esto último comentario que encantó «menos aburridas que una clase normal» 😉 )