Repensando los trabajos prácticos

Si analizamos los trabajos prácticos que suelen hacerse en las carreras de informática como si fueran proyectos, veríamos que en general están planteados en términos de:

  • Alcance fijo: el docente define todo lo que hay que hacer y no negociable
  • Tiempo fijo: el docente indica la fecha de entrega, la cual generalmente tampoco es negociable
  • Esfuerzo variable: el docente no fija el esfuerzo que debe invertirse para completar el trabajo. Esto suena razonable, ya que habiendo fijado las otras dos variables es de esperar que esta sea ajustable.

Todos los trabajos prácticos que hice durante mi carrera de grado y postgrado fueron así y por lo que suelo hablar con mis alumnos, esto sigue siendo así. Duramente mucho años en las materias que estuve como docente también usábamos esta estrategia pero desde hace unos años hemos cambiado.

Actualmente en las dos materias de ingeniería de software que dicto utilizamos una estrategia distinta:

  • Esfuerzo fijo: les pedimos a los alumnos una dedicación semanal de 6 horas efectivas, extra clase por persona
  • Tiempo fijo: trabajamos durante 3 iteraciones, cada una de 1 semana de duración
  • Alcance variable: hay una lista de ítem/funcionalidades priorizadas y cada equipo estima y asume un compromiso en base a lo que consideran que podrán completar. Incluso si llegan a completar el compromiso, no tienen “penalización” de nota

Y particularmente en este cuatrimestre hicimos un primer trabajo práctico con las modalidad previamente descripta y tenemos un segundo trabajo práctico planteado de forma distinta:

  • Alcance fijo: está definido el conjunto de funcionalidades a completar
  • Tiempo variable: cada equipo decide cuando tiempo tomará para completar las funcionalidades. Trabajamos en iteraciones de duración fija, pero equipo decide la cantidad de iteraciones que utilizará. Idealmente creemos que el trabajo puede completarse 2 iteraciones, pero les damos a los alumnos la posibilidad de utilizar 4 o incluso 5 iteraciones
  • Esfuerzo variable: cada equipo elige cuanto esfuerzo pondrá en cada iteración. De esa forma en una iteración dada que coincida con fecha de examen de otra materia podrían poner poco esfuerzo y luego compensarlo en una iteración posterior.

Personalmente estoy muy convencido y contento con la estrategia TEfAv (tiempo y esfuerzo fijos, alcance variable). Y tengo mucha expectativa con este nuevo experimento de AFTEV (alcance fijo, tiempo y esfuerzo variable).

El desafió de Enseñar a Diseñar

El desafió de Enseñar a Diseñar

Desde mi comienzo en la carrera docente siempre he estado en materias que en mayor o menor medida han incluido la temática de diseño de software. Cuando estaba en Algo3 y AyDOO era diseño a nivel de clases, ahora en MeMo2 cubrimos un poco de diseño a nivel de clases y también diseño de más alto nivel (arquitectura e infraestructura). Enseñar a diseñar es una tarea que me parece muy difícil. De entrada debemos decir que no hay diseños “malos” o “buenos”, sino que un diseño podrá ser más o menos conveniente dependiente del contexto. Un diseño es consecuencia de un conjunto de decisiones, diseñar es decidir, elegir. Pensando en el proceso de diseño veo al menos 3 pasos:
  1. Entender el contexto, el problema a resolver, las restricciones y necesidades. Esto es lo que Kazman denomina Architectural Drivers.
  2. Entendido el contexto hay que identificar las decisiones relevantes que deben tomarse.
  3. Finalmente para cada decisión relevante hay que analizar las posibles alternativas y elegir una. Esto puede implicar hacer algunas pruebas de concepto para poder tomar decisiones con evidencia que las respalde.
El punto 1 cae dentro del área denominada ingeniería de requerimientos y cuenta con un amplio cuerpo de conocimiento. El punto 2, ya es más complejo y más allá del cuerpo de conocimiento requiere de experiencia, lo cual es bastante difícil de transmitir. El punto 3 también reviste de complejidad pero creo que en general es más fácil que el punto 2. A mi parecer identificar opciones y evaluarlas para decidir es una trabajo en esencia muy ingenieril. A comienzo de año estábamos hablando con mi colega docente Diego Marcet sobre los criterios de corrección de un ejercicio de AyDOO y lo vimos:
Pretender que en un cuatrimestre académico alguien aprenda a diseñar es demasiado ambicioso, o sea, se puede enseñar algún método/heurística pero pretender dominarlo y generar buenos resultados puede ser difícil. Por ello ajustamos nuestro objetivo para centrarnos en dar a los alumnos herramientas para ser capaces de detectar las decisiones importantes y al mismo tiempo que sean capaces de detectar decisiones inapropiadas para un contexto dado.
De cara a este objetivo trabajamos bastante sobre código ajeno, o sea, analizando y extendiendo código existente. Continuará….

Preparando la tercera edición de MeMo2 (95.21 / 75.10)

Se acerca un nuevo cuatrimestre y como de costumbre estamos haciendo ajustes en la planificación de la materia. Comparto aquí algunos datos importantes para aquellos alumnos que estén evaluando anotarse en nuestro curso este segundo cuatrimestre de 2018.

  • La materia se dictará lunes y jueves de 19 a 22.
  • El equipo docente estará conformado por Emilio Gutter y por quien escribe.
  • Estimamos que los alumnos deberán dedicar aproximadamente unas 7 horas de trabajo semanal extra-clase.
  • Mantendremos la misma propuesta pedagógica, la cual implica: clase invertida y trabajo continuo todas las semanas.
  • Continuaremos trabajando con el mismo stack de herramientas/tecnologías (Ruby, Padrino, GitLab, Heroku) e intentaremos agregar algo de Infraestructura como Código y Monitoreo.
  • Tendremos dos trabajos prácticos grupales.

Más allá de todo esto, estamos realizando varios ajustes a las clases.

Ingeniería de Software: materiales de estudio

Hace un par de semanas un colega docente me hizo una consulta porque tenia que comenzar a dictar una materia de Ingeniería de Software. Hicimos una llamada vía skype y le conté sobre el enfoque que suelo usar en mis materias sobre dicha temática. Al final de la charla quedamos en que le compartiría los materias de estudio que utilizo y de ahí la idea de este post.

En primer lugar un poco de contexto. Yo dicto dos materias de Ingeniería de software una en UNTREF y otra en UBA (Facultad de Ingeniería). La materia de UNTREF se llama efectivamente Ingeniería de Software mientras que la de UBA se llama Métodos y Modelos en la Ingeniería de Software 2 (memo2). Más allá de las diferencias de nombres, el contenido de ambas materias es muy parecido y la dinámica de cursada y aprobación es la misma (está descripta en este paper).  Al mismo tiempo hay que destacar que en ambos casos los alumnos llegan luego de haber cursado previamente alguna otra materia de Ingeniería de Software más introductoria, con lo cual ya tienen cierta idea de un proceso de desarrollo y han leído/estudiado algunos de los clásicos como No Silver Bullet y el SWEBoK.

Explicado el contexto vamos al contenido. En ambos casos tomamos como base el libro Construcción de Software: una mirada ágil (aunque no lo leemos completo). Complementariamente tenemos los siguientes materiales (no todos son de “consumo obligatorio” y en algunos casos se referencia un libro, pero no pedimos leerlo completo sino algunos capítulos en particular):

Adicionalmente tenemos algunos material de nivelación sobre temáticas que se supone vieron en materias anteriores:

Debo mencionar que esta lista de materiales está en constante evolución.

Cierre de cuatrimestre en MeMo2 @ FIUBA

La semana pasada finalizamos el segundo cuatrimestre de la materia con dos diferencias muy importante respecto de cuatrimestre anterior:

  • Se sumó Emilio Gutter al equipo docente.
  • Hubo un total de 20 alumnos (el primer cuatrimestre hubo solo 3)

Comparto algunos números frios:

  • 20 inscriptos: 3 abandonos, 17 aprobados
  • Nota promedio de aprobación: 8,1
  • 3 visitas de la industria
  • 1 clase especial
  • 2 invitados de la industria
  • 8 cuestionarios
  • 8 katas/ejecicios

Algunos otros números surgidos de la encuesta interna de la materia:

  • Cantidad de respuestas: 16
  • Evaluación general de la materia: 8,25 / 10
  • Claridad de los docentes: 4,25 / 5
  • Dinámica de clases: 4,4 / 5
  • Materiales de estudio: 4,3 / 5
  • Dedicación semanal promedio fuera de clases (horas): 7.8

Finalmente están los números resultantes de la encuesta oficial del departamento de computación:

  • Cantidad de respuesta: 14
  • Opinion general de la materia: 4,14 / 5
  • Dificultad de la materia: 3,57 / 5
  • Nivel de las clases: 4,2 / 5

Personalmente estoy muy contento con este resultado aunque sabemos que tenemos algunas cuestiones a mejorar:

  • Rearmar algunas clases: generar más videos para poder incorporar actividades más interactivas en las clases presenciales
  • Ajustar las fechas de los TPs
  • Clarificar al comienzo del cuatrimestre los criterios de aprobación/evaluación

Para cerrar dejo algunas fotos tomadas en algunas clases:

Un tercio de cuatrimestre en MeMo2@Fiuba

Hemos completado la sexta semana de clase y estoy conforme con como viene saliendo la materia. Tenemos 18 alumnos firmes, uno en la cuerda floja y uno que abandonó en la segunda semana.

La semana pasada hicimos una retrospectiva y las conclusiones fueron muy buenas a mi juicio. Entre los puntos positivos mencionados por los alumnos estuvieron los videos, la actividad de programación en clase, el material de lectura y el feedback dado en las correcciones de las tareas. Entre los action ítems resultantes acordamos trabajar en los siguientes 3:

  • Habilitar un espacio en el campus para debatir las preguntas de los cuestionarios
  • Seguir agregando más videos al material de estudio de forma de poder utilizar más tiempo de clase para actividades interactivas
  • Procurar que las preguntas de los cuestionarios que sean de tipo verdadero/falso tengan un campo de justificación

El Perfil de los alumnos de MeMo2 @ Fiuba

La semana pasada comenzaron las clases y de cara a conocer fehacientemente el perfil de los alumnos hice una breve encuesta. Comparto aquí algunos de los resultados.

Respecto de la condición laboral, el 70% trabaja y mayoritariamente lo hace en una actividad afín a la carrera.

Respecto de la cantidad de materias que están cursando este cuatrimestre, la mayoría (55%) contestó 3. Es un número “conservador” pero inferior a la cantidad que prescribe el plan de estudios formal. Esto podría ser una explicación para el hecho de que en general son muy pocos los que completan la carrera en el plazo estipulado por el plan.

Un dato que me llamo mucho la atención es la gran dispersión en la cantidad de materias aprobadas: el alumno con menos materias aprobadas tiene 10, mientras que el alumno con más materias aprobadas tiene 27. Una explicación posible para esto es que quienes tienen más materias, han cursado varias de las electivas, mientras que quienes tienen menos, han cursado solo las obligatorias para llegar a esta materia.

Finalmente, la última pregunta apuntaba al rol en el que les gustaría desempeñarse profesionalmente a largo plazo. Me alegró ver que la gran mayoría eligió roles técnicos.