Despedida de UNQ

El mes pasado cerré una etapa en mi carrera docente, presente mi renuncia en UNQ. No fue una decisión fácil, en UNQ estuve por primera vez a cargo de una materia lo cual fue un gran paso en mi carrera. Por otro lado tuve la oportunidad de aprender y compartir muchas experiencias tanto con colegas docentes como con alumnos. También tuve la oportunidad de participar de algunos de los debates de armado de la Licenciatura en Desarrollo de Software (que luego debió renombrarse por cuestiones administrativas). Por cinco años forme parte de un equipo docente de excelencia.

En estos cinco años, participé inicialmente del dictado de Objetos 1 y luego estuve a cargo de Ingeniería de Software. En los 9 cuatrimestres que dicté esta última materia tuve un total de 105 alumnos con un porcentaje de aprobación del 89%.

Pero como mencioné tiempo atrás, este año decidí dar un nuevo paso en mi carrera y tomé un cargo de mayor dedicación en UNTREF con el objetivo de trabajar en un proyecto de investigación.

A pesar de dejar mi cargo espero poder seguir en contacto con la comunidad UNQ y poder participar de futuras actividades.

Agradezco a toda la comunidad de UNQ  por las experiencias compartidas y muy especialmente a Fidel, quien me abrió las puertas de TPI y confió en mi para el dictado de Ingeniería de Software.

¡Gracias totales!

Reflexiones sobre la Enseñanza de la Ingeniería de software

En mi actividad profesional cotidiana me desempeño como ingeniero de software ocupando distintos roles y realizando distintas tareas dependiendo de las particularidades del proyecto de turno. Por ello cuando en 2011 tomé a mi cargo la materia Elementos de Ingeniería de Software en la Universidad Nacional de Quilmes busqué una dinámica de dictado de la materia que efectivamente pudiera preparar a los alumnos para desempeñarse profesionalmente en esta disciplina.

Personalmente considero que la ingeniería de software es una actividad naturalmente industrial, y en este sentido me parece fundamental que su enseñanza tenga un enfoque práctico puesto que la ingeniería de software teórica resulta insuficiente para el ejercicio profesional de la disciplina.

Curiosamente mi formación  en Fiuba no tuvo este enfoque. Como alumno tuve un conjunto de materias de índole más bien teórica y  tiempo después otras materias de tipo taller donde se suponía ponía en práctica la teoría aprendida tiempo atrás. Esto me parece perjudicial para el alumno, pues a la hora de estudiar la teoría, la misma se aprende «en el aire» sin ponerla en práctica. Luego, tiempo más tarde se cursa un taller, pero al llegar al taller uno ya se olvidó de la teoría «supuestamente aprendida». Exactamente esto me pasó con el tema de estimación: en una materia me enseñaron los diversos métodos de estimación pero nunca me pidieron estimar, simplemente me pidieron describirlos en un examen escrito. Tiempo después cuando cursé el taller y tuve que estimar, tuve que volver a estudiar los métodos y fue ahí, a la hora de aplicarlos, que me surgieron mil dudas. Algo similar me ocurrió con las cuestiones de testing y calidad.

Otra curiosidad de mi carrera (y que también se repite en otras casas de estudio) es que cursé en primera instancia una materia de análisis y luego una de diseño, como si fueran dos actividades disjuntas (un punto sin duda debatible). Hasta ese momento carecía de una visión general del proceso de desarrollo de software, cosa que aprendí tiempo más tarde en la materia de gestión. Creo que resulta muy dificil (y poco conveniente) enseñar técnicas de análisis y diseño sin contar con el marco general de un proceso de desarrollo. En este sentido me parece interesante el enfoque de la Universidad Nacional de Quilmes, donde primero se ofrece una materia introductoria a la Ingeniería de Software que brinda al alumno una visión general de la disciplina, con un enfoque muy práctico y luego en siguientes cuatrimestres se ofrecen materias específicas para cada actividad: Ingeniería de requerimientos, Gestión de proyectos, Arquitectura de software, etc, etc.

Respecto del enfoque práctico, en concreto creo que es necesario hacer el ejercicio de construir/extender un pieza de software de cara a poner en práctica toda la teoría y técnicas enseñadas, tengo la sensación que enseñar ingeniería de software a partir de lecturas, cuestionarios y ejercicios conceptuales es insuficiente para formar profesionales de la informática y como dije antes el hacer estas actividades en materias separadas no me parece apropiado.

Creo que algunas de estas cuestiones han sido consideradas en el nuevo plan de la Licenciatura en Sistemas de la FIUBA (aunque no estoy seguro de hasta que punto). Espero también que estas cuestiones sean consideradas en el próximo plan de estudios de la carrera de Ingeniería Informática de FIUBA.

 

 

 

Cierre de cuatrimestre en UNQ (2015-2)

Un nueva cursada a ha terminado. Más allá de algún accionable menor surgido del feedback del cuatrimestre anterior no hicimos cambios relevantes este cuatrimestre.

Tuvimos 15 inscriptos (entre ellos 1 recursante) de los cuales 2 abandonaron la materia mientras que los otros 13 restante completaron la materia y aprobaron.

La nota promedio de aprobación fue 8.4/10 y el grado de conformidad de los alumnos con la nota obtenido fue 4.2/5.

La evaluación general de los alumnos según la encuesta anónima de cierre de la materia fue de 8.9.

A diferencia de cuatrimestres anteriores, en la retrospectiva de cierre de la materia no surgieron puntos relevantes (tal vez sea porque utilizamos una dinámica de retrospectiva nueva). Más aún algunos de los pocos puntos que surgieron, tuvieron opiniones distintas, o sea: algunos alumnos los consideraron como cosas a cambiar mientras que otros los consideraron como puntos importantes a mantener. Entre los pocos puntos que tomamos para mejorar/probar están:

  • Mejorar el feedback de las katas
  • Programar alguna kata en clase
  • Hacer alguna review online durante el desarrollo del TP final

Personalmente confirmo una vez más mi sensación de que realmente hemos logrado una muy buena materia en el sentido de que me hemos logrado una dinámica que nos ha permitido ayudar a los alumnos a incorporar nuevos conceptos y herramientas para su desarrollo profesional y académico.

Comparto aquí la foto de cierre y algunos de los videos de los TP finales:

eis_unq_20152

 

Se viene WISIT 2015

Este sábado 19 de septiembre se llevará a cabo la jornada principal del Workshop de Ingeniería en Sistemas y Tecnologías de la Información, WISIT 2015 organizado por la gente de Proyecto Uqbar. Esta tercera edición tendrá su jornada principal en las instalaciones de la Universidad Nacional de Quilmes. Hablo de jornada principal, pues ya hubo algunas actividades que realizaron la semana pasada en instalaciones de Universidad de Buenos Aires.

El programa completo de la jornada incluye varias propuesta muy atractivas con cuestiones de Big Data, Devops, lenguajes de programación y Agile. Respecto de esto último tengo el honor de haber sido invitado a participar de un panel de discusión sobre metodologías ágiles bajo la consigna «Presente y futuro de las metodologías ágiles«.

Como de costumbre la entrada es gratuita pero hay que registrarse aquí.

En mi opinión es una jornada para no perderse.

wisit15

Cierre de cuatrimestre en UNQ (2015-1)

Terminó el cuatrimestre y hemos marcado un record en la materia: 16 inscriptos y 16 aprobados. Si bien ya habíamos alcanzado esa cantidad de inscriptos, algunos habían abandonado la materia en el camino.

Este cuatrimestre tuvimos un cambio en el equipo, por motivos personales Ingrid no pudo estar este cuatrimestre pero tuvimos la incorporación Damián Cravacuore.

En lo referente al trabajo práctico final, este cuatrimestre todos los equipos trabajaron sobre aplicaciones existentes lo cual permitió que se pudieran enfocar en cuestiones de gestión y prácticas técnicas como especificación con ejemplos, TDD e integración continua.

Mantuvimos la dinámica de katas pero como hicimos algunos ajustes de último momento surgieron algunos issues técnicos. Una innovación que agregamos en relación a este punto fue el uso de integración continua desde el comienzo.

La encuesta anónima de fin de curso nos arrojó una evaluación general de la materia de 8.6/10 y un nivel de conformidad con la nota final de 4.66/5. La nota promedio de aprobación fue 8.

Entre los puntos destacados de la retrospectiva de fin de curso surgieron:

  • Mejorar la publicación de las consignas de los trabajos prácticos
  • Ser más explícitos respecto de los plazos de entrega
  • Cuidar más la forma de dar feedback  sobre los trabajos
  • Mantener la dinámica de katas
  • Mantener las clases interactivas
  • Mantener las tecnologías y herramientas utilizadas
  • Intentar sacar mayor provecho del campus

Comparto aquí algunas fotos de la retrospectiva y un par de videos de los trabajos finales realizados:

 

unq_retro_2015-1a unq_retro_2015-1b

Ejercicio de estimación

Un cuestión que siempre me hizo ruido de mi formación en FIUBA es el hecho de que en la materia que estudie métodos de estimación nunca me hicieron aplicarlos, o sea nunca me hicieron estimar, ¡cuac! Terminé la materia y sabía «los algoritmos de estimación» de memoria, pero en el contexto de la materia no los había aplicado nunca. Por suerte para esa altura de mi vida, ya tenía unos cuantos años de trabajo en la industria, con lo cual ya conocía algunos de los métodos vistos e incluso ya los utilizaba en mi trabajo diario.

Siendo consciente de esa falencia en mi formación, cuando comencé a dictar Ingeniería de Software en UNQ, me ocupe de incluir en la materia una clase práctica de estimación. El ejercicio que suelo utilizar para esa práctica se llama La fábrica de aviones y lo aprendí en un taller de Agiles 2009 en Florianópolis, Brasil.

El foco del ejercicio está en estimar la velocidad de un equipo y requiere simplemente varias hojas de papel tamaño a4 (~10 hojas por alumno). Describo a continuación la dinámica:

  1. Se divide a los alumnos en grupo5 (~5 por grupo)
  2. Cada grupo representa un fábrica de aviones y se les pide que indiquen que cantidad de aviones puede construir en un lapso de 10 minutos
  3. La forma de los aviones queda a criterio de cada grupo, pero deben asegurarse que el diseño elegido pueda volar X cantidad de metros (suelo pedir 5 metros)
  4. Se pide que cada avión cumpla con ciertos criterios estéticos: numéro de serie en las alas, nombre del equipo constructor a ambos lados, 2 puertas (una cada lado) y 6 ventanas (3 de cada lado). Todo esto se dibuja con lapicera en cada avión.
  5. Explicada la consigna se les pide a los alumnos que indiquen que cantidad de aviones pueden generar en 10 minutos. Difícilmente pueden hacer una estimación «razonable» sin haber generado al menos un avión. Si los alumnos toman conciencia de eso y aplican lo visto en la materia, deberian pedir una iteración para hacer un spike: generar un par de prototipos de avión y ver cuales son las implicancias de construirlos.
  6. Se les da entonces 1 iteración para generar algunos prototipos. Al final de la misma deben entregar el prototipo que copiarán las siguiente iteraciones y deben decir también que cantidad de aviones se comprometen a entregar al final de la siguiente iteración (básicamente tienen que estimar su velocidad).
  7. A partir de aquí se realizan iteraciones verificando al final de cada una que los aviones entregados cumplan con las condiciones previamente indicadas (3 y 4). Sólo se contabilizan aquellos aviones que cumplan con todas las condiciones, incluyendo el volar al menos X distancia.
  8. Luego de 3 iteraciones se ve que la velocidad del equipo se estabiliza.

Algunas variantes que pueden utilizarse sobre esta dinámica básica son:

  • Trabajar sobre las condiciones de aceptación y poner el foco en el Definition of Done
  • Modificar los equipo o la duración de las iteraciones para evidencias como eso afecta a la velocidad

Si alguno de los lectores llega a utilizar está dinámica me gustaría que me comentara los resultados.

Nuevos Técnicos en Programación graduados de UNQ

El viernes pasado fue la presentación del trabajo de final de carrera de Marcia Tejeda y Néstor Muñoz. Con la presentación y aprobación de trabajo, Marcia y Néstor completaron la Tecnicatura Universitaria en Programación Informática y se convirtieron en los egresados 13 y 14 de esta jóven carrera.

Yo tuve el gusto de dirigir el trabajo junto a Fidel. El mismo consistió en el desarrollo y puesta en marcha de una aplicación para el proceso de Triage del servicio de guardia del Hospital Arturo Oñativa de Rafael Calzada.

Este fue el primer trabajo que dirigí en UNQ y estoy verdaderamente muy contento con el resultado por diversos motivos:

  • La pieza de software creada (producto)
  • La forma en que se trabajó (proceso)
  • El hecho de que el software quedó funcionando en manos del usuario (valor)
  • El hecho de que el software optimiza un proceso negocio con impacto en la sociedad (valor)

Los dos primeros ítems son bastante esperables por tratarse de un desarrollo realizado en un contexto académico, pero los últimos dos me parece que no son tan comunes y son de gran valor.

La aplicación fue construida con Grails + Angular, dos tecnologías que los alumnos tuvieron que aprender como parte del alcance del trabajo.

Mis felicitaciones para Marcia y Néstor por el trabajo realizado y también mi agradecimiento por haber confiado en mí para la dirección del trabajo.

fidel_marcia_nestor
Néstor, Marcia y Fidel

 

Cierre de cuatrimestre en UNQ (2014-2)

Un nuevo cuatrimestre ha pasado y seguimos batiendo records, este cuatrimestre tuvimos 15 alumnos. Lamentablemente no todos aprobaron, en concreto tuvimos:

  • 11 aprobados
  • 2 abandonos
  • 1 desaprobado
  • 1 pendiente de aprobación

Otra novedad de este cuatrimestre fue la incorporación como colaboradora de Ingrid Calderón, una ex-alumna de la materia.

Básicamente mantuvimos la misma estructura y dinámicas que el cuatrimestre anterior con la incorporación de algunas innovaciones y mejoras surgidas de la retrospectiva del primer cuatrimestre. Entre las innovaciones, incorporamos en forma temprana mini TPs que denominamos Katas y que tenían como objetivo:

  • que los alumnos se familiarizaran con ciertas herramientas (ruby, rspec, cucumber, etc) y técnicas (tdd y bdd)
  • que se habituaran a estimar y planificar tareas
  • que se acostumbren a dar visibilidad sobre todo en caso de no poder cumplir con fechas comprometidas

En cuanto a los TPs, mantuvimos la misma estrategia (equipos de 3 personas trabajando sobre aplicaciones Ruby/Padrino) pero con una pequeña innovación: la formación de los equipos estuvo condicionada por el desempeño de los alumnos al momento de inicio del TP. O sea, si un alumno no habia completado todas las tareas anteriores al momento de inicio del TP, entonces no podía conformar equipo con alguien que sí las había completado. La motivación detrás de esto es: dado que las tareas son relativamente simples, quien no las completa es en general por falta de compromiso/interés en la materia, entonces procuramos que todos los equipos cuenten con gente con el mismo nivel de compromiso/interés.

En cuanto a visitas de la industria, este cuatrimestre tuvimos a:

Al igual que el cuatrimestre pasado hicimos una encuesta complementaria a la retrospectiva y según la misma, la evaluación general de la materia por parte de los alumnos fue de 8,8.

De la retrospectiva y la encuesta destacamos algunos puntos en los que trabajaremos el cuatrimestre próximo:

  • Explicar desde el comienzo los criterios de evaluación de la materia y del TP final
  • Reorganizar las katas de forma de incluir alguna con Padrino y Travis
  • Hacer más prácticas de programación en clase (dojos)
  • Publicar todos los recursos técnicos de forma temprana para que cada uno pueda organizarse mejor (en general los punblicamos a medida que vamos avanzando en la materia).
  • Reevaluar la estrategia para la formación de equipo para el TP final

unq_2014_2

Finalmente, este cuatrimestre les pedimos a los alumnos que graben una breve demo de las aplicaciones desarrolladas:

Tenemos un video más pero al no estar publicado en YouTuve no he logrado embeberlo aquí.

El pajarraco Scrum con Qubics

El lunes pasado en EIS hicimos la ya clásica actividad de simulación de Scrum conocida como “”El pajarraco Scrum”.

A diferencia de otras veces en lugar de rastis utilizamos qubics lo cual permitió que realizar obras más “estilizadas”. De la simulación participaron 14 alumnos divididos en 3 equipos, cada uno con su correspondiente product owner. Los 3 product owners fuimos Ingrid (alumna colaboradora de la cátedra), Jona (un alumno que ya había cursado la materia) y yo.

Curiosamente a pesar que los cubics son más maleables que los rastis, hubo equipos que llegaron al final de iteración sin cumplir con la visión de producto.

pajarraco_qubic_2

pajarraco_qubic_3

 

 

pajarraco_qubic_1

Cierre de cuatrimestre en UNQ (2014-1)

Este cuatrimestre batimos algunos records. En primer lugar tuvimos record de alumnos: 14, al mismo tiempo tuvimos record de deserciones: 5, ¡ups! demasiado para mi gusto.

Hablo en plural pues ya desde el cuatrimestre pasado la materia la estoy dictando junto con @pablitosuarez

Como teníamos planeado, continuamos trabajando con el campus y más aún, potenciamos su utilización. Creamos varios cuestionarios como evaluaciones complementarias para algunos temas.

En lo que respecta a los TPs finales, hicimos algunas variantes. En primer lugar nos dividimos los grupos de manera que cada docente fuera product owner de dos grupos. Al mismo tiempo los grupos trabajaron sobre dos aplicacione distintas. Una de ellas era una aplicación creada de cero, mientras que la otra era una aplicación existente a la que debía agregarse funcionalidades. Quedamos muy conformes con la dinámica y los resultados, por lo cual estimo que repetiremos el cuatrimestre próximo.

Mantuvimos la dinámica de visitas de gente de la industria, en este caso tuvimos 3 visitas de excelente nivel de empresas radicalmente distintas:

Adicionalmente a la ya clásica retrospectiva de fin de curso, este cuatrimestre hicimos una encuesta anónima que nos permitió obtener una evaluación más cuantitativa. De esta encuesta sacamos que la evaluación general de la materia por parte de los alumnos fue: 8.4.

De la retrospectiva y la encuesta destacamos algunos puntos en los que trabajaremos el cuatrimestre próximo:

  • Comenzar con la kata de ruby en forma temprana para que los alumnos tenga más tiempo de familiarizarse con Ruby antes de comenzar con el trabajo final
  • Planificar con mayor anticipación las últimas semanas de clase de manera de poder hacerlas más interactivas
  • Alinear mejor entre los docentes los criterios de evaluación de los grupos

Aprovechando la moda, cierro el post con una selfie junto a los alumnos que estuvieron presentes la clase de cierre (solo falta uno que estuvo ausente por razones de salud).

unq-promocion-sexta
Sexta promoción de la materia desde que está a mi cargo