En este 2026, al ya clásico Agile Brazil, se le sumarán el Agiles@Latam y la XPconf, dos eventos internacionales de la comunidad Agile que también se realizarán en Brasil.
Agiles@Latam es el evento Agile de la comunidad latinoamericana que inauguramos en 2008 en Buenos Aires y que desde entonces va rotando por distintos países de la región. De hecho, la segunda edición de este evento, allá por 2009, se realizó en Brasil, aquella vez fue en Florianópolis (aquí pueden encontrar mis notas de aquel evento). Es un evento que en la últimas ediciones ha tomado un formato de Open Space al 100% y que en sus temáticas, se encuentra (a mi parecer) cada vez más lejano al desarrollo de software. En 2026 Agiles@Latam se realizará en Foz de Iguazú.
La XPconf es la International Conference on Agile Software Development, el evento de Agile con más historia. Usualmente rota por países de Europa pero esta vez se realizará por primera vez en latam. Es un evento del cual también he participado en más de una ocasión (xp2015, xp2016, xp2018) . Tiene la particularidad de reunir Industria y Academia: se presentan charlas de practicantes y también papers académicos. Al mismo tiempo mezcla sesioes de distinto tipo (presentaciones, talleres, paneles, etc). En 2026, la XPConf se realizará en San Pablo.
Como todos los cuatrimestre cerramos el curso con una actividad tipo retrospectiva y fue en ese actividad en la que un alumno destacó el hecho de que tratamos a los alumnos por su nombre. Claro, resulta que esta camada de alumnos es parte de la ola ingresó a la facultad a hace un par de años y que incrementó la matrícula de forma importante, como consecuencia de ello muchos de estos alumnos estuvieron en cursos multitudinarios (más de 60 alumnos) donde resulta prácticamente imposible para un docente retener el nombre de los alumnos. A esto hay que sumarle que una parte de las clases se realiza en forma virtual y la gran mayoría de los alumnos no enciende la cámara e incluso ni siquiera tiene foto de perfil. De esta forma los alumnos llegan a nuestro curso que no es tan masivo (este cuatrimestre terminamos con ~20 alumnos), donde una importante cantidad de clases son presenciales, donde les exigimos que pongan foto de perfil en todas las herramientas que utilizamos y donde los alumnos trabajan en vivo en equipos de 4, con un docente dedicado durante varias semanas. Esto habilita a que uno como docente pueda aprender el nombre de los alumnos y eso es lo que el alumno destacaba en contraposición a la gran mayoría de los cursos anteriores.
Al margen de esta curiosidad Tuvimos un cuatrimestre muy desafiante ya desde la previa con record de inscriptos. Como suele ocurrir en los últimos años en varias materias de fiuba, hay muchos alumnos se inscriben y luego ni siquiera asisten a la primera clase. Es así que a pesar del record, podemos decir que comenzamos el cuatrimestre con unos 46 alumnos que asistieron a la primera clase, de los cuales solo 25 completaron la primera parte de la materia. Finalmente 19 alumnos aprobaron el curso y están en condiciones de rendir el final oral.
Este cuatrimestre también empezamos a ver una consolidación del perfil de alumno de nuestro curso:
amplia mayoría sin experiencia laboral (~82%)
edad promedio de los alumnos: ~23 años
cantidad de materias aprobadas incluyendo CBC: ~23 (según el plan deberían llegar con 24)
cantidad de materias cursando este cuatrimestre: 3,7 (según el plan deberían cursar 4)
Algunos números concretos surgidos de nuestra encuesta:
Cantidad de respuestas: 17
Evaluación general del curso: 8,9 / 10 (desvío 0.8)
Claridad de los docentes: 4,6/ 5
Conocimiento de los docentes: 5 / 5
Dinámica de las clases: 4,9 / 5
Conformidad con la nota: 4,4 / 5
NPS: 71
Dedicación semanal extra-clase: ~11 horas
Entre los puntos a mejorar claramente destaca la necesidad de ajustar el esfuerzo requerido para completar el TP que en este cuatrimestre requirió en promedio por equipo de unas ~260 horas (con un desvío ~85) distribuido en 3 semanas. Una curiosidad que vemos en este punto es que la mayor dedicación no implica mejor calificación, de hecho pareciera ser al revés, un tema que da para el análisis.
Algunos comentarios anónimos que los alumnos dejaron en la encuesta:
«Me gusto mucho la modalidad de ver videos sobre un tema y luego en la clase de los lunes retomarlos pero con «intensidad». La organizacion es otro de los puntos fuertes.»
«Buena onda de las clases. Clases participativas. Se notan las intenciones de querer enseñar y de querer que los alumnos aprendamos.»
«Excelente dinámica y temas, salí de la materia con 10 veces más de experiencia que con la que entre, definitivamente una cursada muy enriquecedora.»
«Se siente como el cuerpo docente se involucra bastante con los alumnos para que se sienta una enseñanza más personal lo cual ayuda mucho a asimilar varios conceptos y práctica.»
Por casi 15 años he estado trabajando de forma independiente, en la gran mayoría de los casos haciendo trabajo que podría calificar como consultoría/coaching. En todo este tiempo nunca me habían pedido hacer una prueba técnica de programación. Me ha tocado hacer algo tipo «entrevista técnica» pero fue pura charla, nada de codear.
Resulta que ahora, un potencial cliente me pidió hacer una prueba técnica, en el lenguaje de mi elección, una hora de pair-programming con un tech lead de la organización. Cuando lo comenté con un colega, le resultó doblemente curioso: por un lado le llamó la atención que me hubieran pedido la prueba y por otro que yo haya aceptado. Dadas las características del trabajo a realizar me pareció muy razonable el pedido, así que acepté con gusto.
Desde hace un par de semanas estoy ayudando a una organización a mejorar su proceso de delivery. Se trata de una organización que ofrece una plataforma de software que fue construida hace más de 20 años y que hoy en día sigue en operación, dando soporte a un negocio y resultando rentable para sus creadores.
Las tecnologías populares en aquella época (año ~2000), eran bastante distintas a las actuales. Una tecnología bastante popular por aquellos años era Oracle Forms que fue la tecnología elegida por esta empresa para desarrollar su software. Dudo mucho que en la actualidad se sigan haciendo nuevos desarrollos con Oracle Forms, pero sin duda hay varias soluciones construidas con esta tecnología que aún siguen operativas.
En el caso particular de mi cliente, el core de su plataforma está construido con tecnología Oracle pero con el correr de los años han ido generan «nuevas capas» con tecnologías más actuales como ser Java y JavaScript/TypeScript. Esta es una estrategia muchas veces utilizadas en los bancos con sus core bancarios construidos en tecnologías como COBOL.
Entre otras cuestiones lo que estamos haciendo es estandarizar el esquema de versionado y automatizar el proceso de despliegue. Venimos bien, aún me quedan unas 6 semanas de trabajo lo cual creo que es suficiente para completar la tarea.
Ultimamente hay eventos de IA por todos lados, luego de asistir a un par que me resultaron muy pobres (o dicho en vocabulario técnico: «puro humo»), decidí dejar de participar. Pero cuando vi el anuncio de Promptleala y vi que era organizado por la gente ArqConf no dudé en anotarme. Es que conozco a la gente de ArqConf (Gus Brey y secuaces) y me consta que hablan desde la experiencia. Y la verdad que una vez más, no decepcionaron. Sinceramente estuvo muy bien.
El evento se realizó el pasado 8 de Octubre en las instalaciones de la Universidad de CEMA. El carismático Ulises Martins ofició de host y lo hizo muy bien.
Todas las charlas que vi me parecieron muy buenas, pero sin duda las dos que más que gustaron fueron las Tomás Bacigalupo (Product Talk : activando IA en mobile) y la de Ricardo Di Pasquale (La IA sin ingeniería no alcanza ni escala).
Sin duda Agile, y más específicamente XP, hicieron esto, pero no fueron los únicos.
En la época «pre-agile«, el testing estaba en manos de un grupo de personas «externas» al equipo de desarrollo. Agile cambio esto en varios sentidos, por un lado puso de relieve el testing como un trabajo de todos y junto con eso puso gran parte del testing en manos de los developers. Al mismo tiempo puso a los testers a trabajar codo a codo con los developers dentro del equipo de desarrollo y a la pasada cambió las tareas cotidiadas de los testers incluyéndolos en otras cuestiones como ser las plannings y los refinamientos, etc. Hasta aquí creo que no hay novedad, cualquier practicante en la actualidad sabe esto (consciente o inconscientemente).
Pero hay otro hecho que me parece ha pasado desapercibido. Resulta que estoy ayudando a un equipo de un cliente a mejorar su proceso de delivery y en ese contexto estamos agregando tests automatizados, cosa que el equipo nunca hizo. Su solución consiste en una aplicación móvil construida con Ionic y un conjunto de servicios construidos con node/loopback. Personalmente había hecho algunas cosillas con Ionic pero nunca había trabajado con Loopback. Para mi sorpresa, ambos framework traen soporte (guias, ejemplos, etc) para hacer pruebas automatizadas de distinto tipo. Más aún, el scaffolding de Ionic ya genera el esqueleto de pruebas cuando uno genera un componente. Esta sorpresa me hizo caer en la cuenta que hoy en día la gran mayoría de los frameworks de desarrollo ya traen soporte, documentación y ejemplos para hacer pruebas automatizadas. Esto que puede parecer «normal» en la actualidad pero creanme que no era así hace ~20 años cuando yo empezaba a dar mis primeros pasos con automatización de pruebas. Recuerdo varios proyectos lidiando para agregar pruebas a aplicaciones AspNet/C#.
Creo que unas de las herramientas pioneras en este sentido fue Smalltalk (¿squeak?) y luego Rails. Me parece que hoy en día todo frameworks/sdk viene con soporte para hacer pruebas automatizadas: Rails, Django, Java/Spring, NetCore, Nest.js, Next.Js, Android Sdk, por nombrar algunos populares. Es cierto que tal vez no todos los developers escriben pruebas, pero el hecho que las herramientas los habiliten representa una posición de la industria: los developers deben escribir pruebas y es de esta forma el testing se ha convertido en un ciudadano de primera categoría.
El próximo mes de septiembre estaré participando en la conferencia Testearla organizada por la gente de Crowdar (JaviRe y sus colegas).
La conferencia será 9 y 10 de septiembre, el 9 online y el 10 presencial en Plaza Galicia (Ciudad de Buenos Aires). La entrada es gratuita pero requiere registración. Al margen de la agenda de sesiones, que se ve muy interesante, en el evento también habrá espacios de networking.
Adicionalmente, el 11 habrá una jornada intensiva de entrenamiento de la cual estaré participando. Habrá 4 sesiones y yo daré una de ellas. Mi sesión será «Principios y Patrones para el diseño de Pipelines», veremos la teoría y la pondremos en práctica con algunas herramientas. Será la primera vez que dicte este sesión, pues si bien parte del contenido suelo darlo en mi materia de Ingeniería de Software, para este caso agregaré algunas cuestiones nuevas surgidas de mis últimas experiencias. Esta jornada de entrenamiento tiene cupos limitados y es paga.
La semana pasada comencé a trabajar en un proyecto nuevo. El objetivo es hacer un «refactor» de un sistema que tiene varios años de vida y al mismo tiempo agregarle algunas capacidades nuevas basadas en IA. El sistema consta de 1 componente central construido en javascript, dos «satelites» en php y varias APIs externas algunas bajo el control de otros equipos de la misma organización y otras bajo el control de otras organizaciones.
En el equipo somos unas 10 personas: un Product Owner, cuatro devs todo terreno con dedicación full time, un dev referente técnico con dedicación parcial, un tester full-time, una persona de UX, un persona de infra con dedicación on-demand y yo con dedicación parcial en el rol de coach dev. Los miembros del equipo vienen de trabajar en distintos equipos de la organización y nunca trabajaron todos juntos como equipo.
El proyecto debería durar aproximadamente unos 3 meses.
Estamos haciendo iteraciones semanales con todas las ceremonias (review-retro-planning) de corrido los días miércoles. Estamos haciendo dailies que logramos mantener ~10 minutos.
En la primera iteración no hicimos una estimación formal, simplemente agarramos un conjunto de 17 ítems que consideramos podrían llegar a completarse en 1 semana (spoiler: a los dos días ya no dimos cuenta que llegamos a completar todo, ja!).
Hasta el momento evité escribir sobre cuestiones de Inteligencia Artificial en parte porque me pareció que había demasiada gente hablando del tema, algunos incluso hablando con muchas imprecisiones (por no decir «tirando fruta») pero también porque yo mismo no quería tirar fruta. A pesar de estar trabajando profesionalmente en iniciativas de IA desde 2023 sentí que mi conocimiento era muy superficial.
Pero ya desde un tiempo la IA comenzó a meterse en mis cursos y eso nos obligó a tomar el tema. Es por eso que a comienzos de este año junto a Diego Marcet y Gonza Cozzi (miembros de mi equipo docente en UNTreF) nos pusimos a estudiar formalmente el tema. En concreto comenzamos estudiando el uso de la IA en la enseñanza de la programación. Hicimos una revisión de papers y encuestamos a docentes de programación. Esta iniciativa quedó plasmada en un artículo que enviamos al Simposio Argentino de Educación en Informática y que estaremos presentando en Agosto en el contexto de las Jornadas Argentinas de Informática.
Algunos de los hallazgos que hicimos fueron:
La mayoría de los docentes (~70 %) ya utiliza herramientas basadas en IA en sus tareas docentes.
Al mismo tiempo (más del 70 %), la gran mayoría cree que la incorporación de IA en sus cursos requiere de un cambio significativo en la forma en que dictan sus cursos.
Más del 90% de los encuestados reportaron que sus alumnos ya utilizan herramientas basadas en IA
Más allá de todo lo anterior, y que en un punto era esperable, lo que más nos llamó la atención fue la diferencia de opinión cuando preguntamos si consideraban positiva o negativa la irrupción de IA en la educación, el siguiente histograma muestra la consolidación de las respuestas.
Este artículo representa el primer paso de nuestra iniciativa de estudio del uso de la IA en la enseñanza. Nuestro siguiente paso es trabajar con practicantes, con lo cual si hay algún desarrollador leyendo esto y utilizando IA (co-pilot, cursor, etc) y le interesa participar de un estudio, no deje de contactarme.
La UBA es una institución muy grande, tiene 13 facultades y más de 300 mil estudiantes. Los temas de Ingeniería de Software se estudian en más de una facultad.
Al mismo tiempo se da que la Ingeniería de Software es un cuerpo de conocimiento bastante amplio y diverso, incluye cuestiones de proceso y metodología como también cuestiones de arquitectura, programación y verificación. Y en los últimos años, algunos autores, también han incluido cuestiones de despliegue y operación.
Me animo a decir que la Facultad de Ingeniería (fiuba) es la facultad de la UBA que más cuestiones de Ingeniería de Software cubre. En fiuba hay temas de Ingeniería de Software que se ven en forma transversal a lo largo de distintas materias, cuestiones de programación, verificación, versionado, etc. Al mismo tiempo hay un núcleo de 3 materias específicas de Ingeniería de Software: Ingeniería de Software 1(IS1), Ingeniería de Software 2(IS2) y Gestión del Desarrollo de Sistemas Informáticos(GDS). Finalmente hay materias electivas enfocadas en áreas específicas de la Ingeniería de Software como ser Arquitectura de Software y Estándares de Calidad y Modelos de Referencia, entre otras. En lo personal creo que esta oferta da a los estudiantes una muy buena formación de cara a su ejercicio profesional como Ingenieros de Software. Quienes gusten curiosear pueden ver los contenidos mínimos de estas tres materias en el plan de estudios.
El reciente cambio en el plan de estudio de la carrera de Ingeniería Informática generó un reordenamiento de cursos que llevó varios cuatrimestre. Finalmente, este primer cuatrimestre de 2025, las materias del área de Ingeniería de Software quedaron organizadas en 8 cursos: 3 de IS1, 3 de GDS y 2 de IS2. A continuación resumo algunos datos de cada curso que pueden resultar útiles para futuros estudiantes.
Comparto también las páginas públicas de los cursos (no todos tienen):
Una particularidad interesante es que las 3 materias del núcleo de Ingeniería de Software apuntan a cubrir (en mayor o menor medida dependiendo del curso) todo el ciclo de desarrollo de software. En cierto modo, esto queda evidenciado en que en 7 de los 8 cursos hay que programar. Destaco este hecho porque en algunas carreras/instituciones e incluso en las versiones anteriores de los planes de fiuba, cada materia cubría solo una etapa del ciclo de desarrollo, lo cual denotaba un enfoque «secuencial» bastante distintos del ejercicio de la profesión. En el enfoque actual, más punta a punta e iterativo, se abordan las distintas etapas reiteradamente en las distintas materias pero con distinto foco y nivel de profundidad.
Blog de NicoPaez 