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

Project Bootstrap, cómo inicio mis proyectos

Al comienzo de todo proyecto de desarrollo hay ciertas cosas que debemos tener en claro y algunas decisiones que debemos tomar respecto de las herramientas de soporte que utilizaremos. Estas cuestiones constituyen lo que suelo denominar como bootstrap del proyecto. Hace un tiempo grabé este screencast para mis alumnos de UNQ sobre este tema. Para quienes prefieran leer a escuchar, resumo brevemente lo que mencionado en el screencast.

Todo proyecto surge a partir de una visión. La visión es definida por el cliente y es básicamente el justificativo del proyecto. El cliente decide llevar adelante el proyecto para resolver un problema o para aprovechar una oportunidad. Es fundamental que todos los involucrados del proyecto conozcan la visión, por ello siempre suelo ponerla por escrito y compartirla con todos los involucrados.

Al desarrollar proyectos es común hablar de «el cliente», un término que me resulta inapropiado, pues lo considero ambiguo. Personalmente prefiero utilizar términos más específicos. Desde mi perspectiva todo proyecto tiene un sponsor, que es aquel que brinda el apoyo político para que el proyecto se lleve adelante. En forma simplificada podemos decir que el sponsor es quien está pagando por el proyecto. Por otro lado tenemos al experto de negocio, que es quien conoce en detalle la problemática a resolver. En ocasiones puede que el sponsor sea también el experto de negocio, pero no siempre es así.

Ya en el terreno de las herramientas, hay algunas cosas básicas como:

  • un repositorio de código: git, mercurial, subversion o el que más te guste
  • una herramientas de gestión: Jira, Redmine, Trello, una hoja de cálculo o simplemente un tablero de post-its
  • un servidor de integración continua: Jenkins, TeamCity, Travis o el que gustes

Adicionalmente me parece importante contar con:

  • Un ambiente de prueba/demo: este es un ambiente «neutro», fuera de la máquina del programador, donde se instala la aplicación en cuestión de forma frecuente. Este ambiente es usado para las revisiones de iteración. De cara a mitigar riesgos, debería ser lo más similar posible al ambiente productivo
  • Projectpedia: es básicamente una wiki que concentra información del proyecto. Con información del proyecto me refiero a cosas bastante variadas que van desde información de contacto de los involucrados, hasta la visión del proyecto y la información de acceso a los distintos ambientes, etc, etc

¿y tu? ¿usas algo más?

Proyecto T: definición de tecnología

Hace un tiempo empecé a trabajar con un conjunto de alumnos de UNQ en su trabajo final de carrera. El mismo consiste en la construcción de una aplicación para gestión de una sala de guardia de un hospital público.

Una de las decisiones que tenemos que tomar  al comienzo del proyecto es la tecnología a utilizar.

Intentando dejar de lado las preferencia personales, hay algunas consideraciones importantes para esta decisión:

  1. Dado que el contexto del proyecto es un institución pública donde el presupuesto es realmente acotado es necesario que la tecnología a utilizar no requiera el pago de licencias.
  2. Dado que se espera que el sistema tenga una vida «más larga» que el tiempo de desarrollo es muy posible que una vez completado el sistema, alguien más debe encargarse del mantenimiento. Sumado a que trabajeremos con alcance variable es posible que en un futuro el product owner deba conseguir más gente para agregar nuevas funcionalidades. Por esto es necesario que sea fácil conseguir programadores con conocimiento de dicha tecnología.
  3. La tecnología elegida debería estar lo suficientemente estable y contar con herramientas que faciliten la resolución de situaciones técnicamente comunes en un proyecto como el planteado y no de larga sesiones de investigación y resoluciones de problemas técnicos.
  4. Dado que seguimos estando en un contexto académico, la tecnología a utilizar debería permitirnos aplicar ciertas buenas prácticas que los alumnos aprenden a lo largo de la carrera.

Con estos puntos de partida ya podemos empezar a eliminar algunas candidatos.

  • En primer lugar podemos descartar tecnología Microsoft  por (1).
  • Al mismo tiempo y pesar de que me causa cierta pena, creo que (2) deja afuera Smalltalk.
  • Creo que (2) y (3) dejan afuera a cosas tales como Erlang

La lista de candidatos es aún bastante larga y al mismo tiempo con sólamente un lenguaje no llegamos a ningún lado. Es necesario considerar lenguaje + frameworks, lo cual nos podría llevar a la siguiente lista de candidatos:

  • Php, tal vez sea por sus orígenes «informales», creo que las convenciones y herramientas aún no están claramente unificadas, hay varios alternativas (Symphony, Cake, etc) y a mi parecer ninguna se ha establecido. Sumado a que el lenguaje no me gusta.
  • Python + Django, lo usé y no me gustó, creo que Django tiene demasiada magia negra.
  • Java, ¡ja!  ¿cual de sus n variantes? No lo sé, creo que en un punto casi todas cumplen con las premisas iniciales. simplemente descartaría el uso de contenedores pesados (EJB).
  • Hermanitos de Java ya sea Scala o Groovy, que más allá de las particularidades que ofrecen como lenguajes, ambos proveen un conjunto de herramientas muy interesante y que simplifican varias cuestiones cuestiones cotidianas que tal vez en java requieren un esfuerzo de configuración/xml realmente pesado.
  • Ruby, Rails tiene demasiada magia negra, pero creo Padrino definitivamente es un opción válida.
  • JavaScript sin duda está en ascenso y si bien apenas he ido más allá de jquery es algo que me tienta mucho

Algo que me parece inevitable para este contexto de aplicación es el uso de Javascript del lado del cliente manejando toda la lógica de presentación y dejando en el server sólo servicios de negocio, entonces el punto sería con qué construir estos servicios.

Ahora bien, más allá de mis gustos, la realidad es que la aplicación la tienen que construir los alumnos y llegado a este punto son ellos quienes deben tomar la decisión considerando todo lo aquí expresado.

Mi recomendación para los alumnos fue: tomense un rato para googlear las cosas que aquí menciono si es que no las conocen. Si alguna de las alternativas les tienta más que otra y no la conocen, entonces bajense lo que sea necesario e intenten escribir una pruebas unitaria y hacer una página que sume 2 números. Eso debería darles cierta idea de dónde se están metiendo.

Comienzo de nuevo proyecto, llamémosle T

En estos días estoy por comenzar un nuevo proyecto, llamémosle T. Se trata de un trabajo de inserción profesional que voy a co-dirigir con Fidel. El trabajo será desarrollado por dos alumnos de la carrera y el objetivo es construir un sistema de gestión para la sala de guardia de un hospital. El proyecto surgió a partir de una necesidad detectada por Luis, un médico, jefe de guardia de un hospital del conurbano.

Como suelo recomendar para todos los trabajo finales de carrera, la idea es gestionar el proyecto como de alcance variable, lo cual requiere una trabajo muy cercano con el product owner para asegurar una correcta priorización de funcionalidades y un rápido feedback a medida que estas se van completando.

Continuará…

 

 

Cierre de cuatrimestre en UNQ, cuarta promoción

Terminó el cuatrimestre y se fue la cuarta promoción de Elementos de Ingeniería de software desde que la materia está a mi cargo. Este cuatrimestre la materia tuvo un enfoque mucho más práctico. El primer mes de clase fue más o menos igual que siempre, pero luego nos fuimos enfocando mucho más en cuestiones cercanas al código. Para ello trabajamos con Ruby+Padrino, GitHub, Travis y Heroku. Lás últimas 5 semanas los alumnos trabajaron en grupo en el desarrollo de distintas aplicaciones. La aplicaciones en sí no fueron más que una excusa para poner en práctica los temas de ingeniería abordados durante la materia: estimación, planificación, comunicación, gestión de alcance y cambios, etc, etc.

Otro cambio que tuvimos este cuatrimestre fue que usamos un sitio basado en Jekill para llevar la bitácora de clase.

Para cerrar la materia cada grupo de alumnos grabó un screencast contando el trabajo realizado, les dejo los links a los videos:

Al igual que el cuatrimestre pasado, conté con la colaboración de Natalia, una ex-alumna de la materia (¡gracias Nati!)

Algunos números frios:

  • Alumnos anotados: 10
  • Alumnos aprobados: 8 (2 alumnos abandonaron la materia en el primer mes de clase)
  • Nota final promedio: 8,25
  • Fueron un total de 28 clases
  • Tuvimos otra vez la visita de un profesional de la industria (¡gracias Emilio!)

Estoy muy contento con como salió la materia y según lo hablado en la restrospectiva, los alumnos también quedaron contentos. Una cosa en particular que me puso muy contento, es que logré mejorar la forma en que doy feedback, algo que había salido de la restrospectiva anterior.

eis2013-1

Nota: el ícono representa un alumno que estuvo ausente el día de la retrospectiva.

eis-2013-1b

Cambiando la forma en que enseñamos: primero la tarea y luego clase

Generalmente el docente dicta una clase y luego le da a los alumnos algún texto para profundizar/repasar el tema visto en clase. Casi sin quererlo la semana pasada invertí esta dinámica y obtuve interesantes resultados. Paso a explicar:

Resulta que la semana pasada en EIS comenzamos a estudiar las técnicas y herramientas de análisis. Vimos modelado de dominio, diagramas de estado, visual story mapping y teníamos que ver también user stories. Como no nos alcanzó el tiempo para ver este último tema, les dije a los alumnos que lo investigaran por su cuenta.

La clase siguiente abordamos el tema de user stories, pero dado que los alumnos ya habían investigado al respecto, los invité a que ellos mismo preparan una clase al respecto. Salí del aula para buscar un café y los dejé para que prepararan la clase. Al regresar, expusieron el tema de una forma que me sorprendió, la exposición fue correcta y bastante completa. Faltó mencionar algunas cosillas, pero sinceramente estuvo mucho más completa que lo que yo había esperado.

Una vez finalizada la exposición de los alumnos, volvimos a repasar los conceptos vistos, profundizando en algunos puntos, destacando otros y mencionando algunas cosillas que habían faltado.

La experiencia me resultó por demás interesante y estoy convencido que a los alumnos les resulto más entretenido y al mismo tiempo el tema les quedó mucho más claro.