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

 

 

Más reflexiones sobre docencia universitaria

En 2011 cuando tomé a mi cargo la materia Elementos de Ingeniería de software en UNQ tuve que decidir cómo estructurar las clases de la materia. Por reglamento la materia tenía (y tiene) una carga horaria de 6 horas semanales de clase. Hasta ese momento la materia se dictaba en dos clases semanales, si mal no recuerdo una clase de 2 horas y otra de 4. Luego de una charla con las autoridades mis opciones eran:

  • Mantener un esquema de 2 clases semanales, ya sea de una de 2 y otra de 4 o un esquema más tradicional de 2 clases de 3 horas cada una.
  •  Cambiar a un esquema “maratónico” de una sola clase semanal de 6 horas

Una vez más el dilema: ¿comodidad del docente o “mejor aprendizaje” de los alumnos?  Quien me conoce sabe claramente que elegí la primer opción: dos clases semanales de 3 horas cada una. En parte porque dictar una clase de 6 horas me parece insalubre tanto para los alumnos como para el docente. Por otro lado estoy convencido que el aprendizaje tiene naturalmente una estructura iterativa y en ese sentido el tener más clases permite realizar más iteraciones lo cual representa más ciclos de feedback y por ende más oportunidades de mejora/aprendizaje.

¿y si la materia fuera de 4 horas semanales? Una clase de 4 horas parece bastante razonable. Si, definitivamente es más razonable, pero aún así hubiera elegido dos clases semanales pues el argumento iterativo sigue aplicando en este caso también.

 

Cómo enseñamos TDD

TDD es una práctica cuyo punto clave es la secuencia de pasos que se siguen para obtener la solución. En Algo3 explicamos la teoría y luego la ponemos en práctica haciendo dojos en las clases. También les damos ejercicios a los alumnos y les pedimos que los resuelven haciendo TDD, pero la realidad es no tenemos forma de asegurarnos que hayan arribado a la solución usando TDD. Hay algunas situaciones observables que pueden sugerir que la solución no fue generada utilizando TDD (por ejemplo si la solución tiene baja cobertura es muy posible que no se haya utilizado TDD o al menos no se lo haya utilizado correctamente o todo el tiempo). Al mismo tiempo todos los ejercicios de programación que resolvemos en clase procuramos hacerlo usando TDD. Finalmente evaluamos su conocimiento sobre TDD con alguna pregunta en el examen. Creo que es un enfoque bastante integral y razonable para el contexto de la materia, donde es común que tengamos más de 40 alumnos por curso. Pero es posible que haya mejores enfoque para otros contextos.

Sin ir más a lejos, yo mismo en UNQ estrené este cuatrimestre un enfoque distinto. Cabe aclarar que el contexto de UNQ es distinto, en primer lugar es una materia de ingeniería de software donde se supone que los alumnos ya vieron algo de TDD. Al mismo tiempo, la cantidad de alumnos es mucho menor, suelen ser alrededor de 10. Finalmente la dinámica de la materia es distinta: no tenemos separación explícita entre teoría y práctica y tampoco tenemos exámenes formales. Lo que hacemos (o mejor dicho lo que hemos hecho este cuatrimestre) es explicar TDD haciendo TDD, de una, explicando la teoría sobre la misma práctica. Luego les damos a los alumnos algunas katas para resolver y les pedimos que graben un screencast mientras van resolviendo la kata. Esto nos permite observar cómo los alumnos aplican la técnica paso a paso y detectar si algo no fue correctamente entendido.

Proyecto T: tecnología definida

Luego de investigar y hacer algunas pruebas de concepto, los alumnos eligieron construir la aplicación con Grails y AngularJS, una combinación con la personalmente no tengo experiencia pero que me gusta.

Respecto a la infraestructura, el repositorio será Git (github).

Respecto del build server y el ambiente de tests, yo tenía la ilusión de usar el servicio de CloudBees, pero los alumnos prefirieron ir con Travis y Heroku.

Cierre de cuatrimestre en UNQ, quinta promoción

La semana pasada terminó el cuatrimestre en UNQ y con ello mi quinto cuatrimestre dictando Elementos de Ingeniería de software.

Este cuatrimestre tuvo algunas particularidades entre las que destaco 2:

Respecto del cuatrimestre anterior la materia no tuvo cambios significativos, pues si bien se sumó Pablo, ya nos conocíamos desde hacía años y compartimos la misma filosofía en lo que respecta a los temas de la materia.

Un cambio que sí me pareció muy importante fue el contar con un espacio en el campus virtual de la universidad. Esto nos sirvió para compartir el contenido y también para realizar algunas actividades complementarias a las clases presenciales.

Otro cambio positivo fue el uso de videos para explicar algunas cuestiones técnicas que no son el foco de la materia. Así logramos utilizar mejor el tiempo de clase.

Entre los puntos que surgieron en la retrospectiva de la materia se destacaron:

  • Es muy distinto cuando damos feedback por mail a cuando lo damos en persona => reemplazar el feedback via mail por feedback en video
  • Algunas de las clases con formato “clase magistral” resultaron poco entretenidas => intentar cambiarlas por clases con dinámicas o al estilo “from the back”
  • En algunas clases comenzamos haciendo un ejercicio de relajación lo cual gustó mucho => hacerlo más seguido
  • Enviar tareas lo más temprano posible
  • Mantener los videos sobre temas técnicos
  • Mantener las clases con dinámicas
  • Mantener el uso de la máquina virtual para simplificar la configuración de ambiente y herramientas
  • Mantener las visitas de gente de la industria.

Para cerrar comparto algunos números frios:

  • Alumnos anotados: 9
  • Alumnos aprobados: 8 (el alumno que abandonó lo hizo la tercer semana de clase debido a que sufrió un accidente que impidió asistir a clase por un período prolongado)
  • Nota final promedio: 8,5
  • Total de clases: 31
  • Visita de profesionales de  la industria: 2, DiegoF y Fer Di Bartolo (¡gracias muchachos!)

eis-5-cohorte