Sobre los trabajos finales de carrera

Reciente algunos alumnos vinieron a consultarme para que los dirija en la realización de sus trabajos finales de carrera. Luego de repetir los mismo por tercera vez decidí ponerlo por escrito.

Mi condición para dirigir un trabajo es que el desarrollo del mismo se haga bajo las siguientes condiciones:

  • El trabajo se plantea como un proyecto de alcance variable, esfuerzo fijo y calendario ajustable (pero no mucho). El esfuerzo está dado por lo que determina el reglamento de la institución. Respecto del calendario, la institución suele poner un tiempo límite pero en general es mucho mayor del necesario. Adicionalmente mi idea de calendario es que el trabajo esté listo en un plazo máximo de medio año.
  • No dirijo trabajos de alumnos que no hayan sido alumnos en alguna de mis materias. El trabajo final es un proyecto “one-shot”, y la dupla alumno-director es en cierto modo como un equipo.  Resultaría muy arriesgado para un proyecto one-shot formar equipo con gente que no se conoce previamente.
  • Desde el punto de vista metodológico trabajamos a lo XP con iteraciones semanales.
  • A partir del momento que se inicia el desarrollo, se trabaja a un ritmo constante durante un período de ~16 semanas (un cuatrimestre).
  • Previo al comienzo de desarrollo hay un fase de setup/envisioning de aproximadamente 1 mes (a esfuerzo variable)
  • Una vez completado el desarrollo, hay un período de ~1 mes para terminar de redondear las cuestiones formales para la presentación del trabajo.

Para empezar recomiendo a los alumnos crear un GoogleDoc y empezar a escribir la propuesta de trabajo, no toda la propuesta pero si la parte de lo que sería la visión de proyecto.

Anuncios

Promediando el cuatrimestre en AyDOO @ UNTREF

Hemos completado la séptima semana de clase de Análisis y Diseño Orientado a Objetos en UNTreF. Este cuatrimestre viene con varias novedades.

En primer lugar tuvimos un cambio de equipo el cual esta conformado por: Diego Marcet (egresado de FIUBA con quien tuve el gusto de trabajar profesionalmente en diversas ocasiones y que está definitivamente en mi Dream Team) y Lucas Campaner (estudiante de UNTreF y uno de los mejores ex-alumno de la materia).

Otra novedad fue el cambio de la herramienta de soporte, comenzamos a utilizar Canvas LMS, una herramienta que yo ya venía utilizando en otras materias.

Finalmente la novedad a mi parecer más importante es el cambio en la dinámica de la clases. Este cuatrimestre estamos dividiendo la clase en 2 partes. En la primera vemos algo de teoría, atendemos consultas o resolvemos algún ejercicio en forma conjunta utilizando el proyector. En la segunda nos dedicamos a programar. Planteamos alguna consigna y programamos en grupos de tres, haciendo lo que podríamos denominar como “trio-programming” (o pair-programming con trios en lugar de pares). Al mismo tiempo los docentes vamos rotando por los equipos atendiendo dudas, debatiendo diseños y programando.

Esta semana, hicimos un retrospectiva con la intención de tener un feedback formal de los alumnos y detectar oportunidades de mejora. El feedback fue muy positivo y los alumnos destacaron el hecho de programar en clase. Entre los puntos accionables que salieron de la retrospectiva están:

  • Tener una semana sin tareas. En la dinámica que llevamos los alumnos tienen tareas todas las semanas lo cual hace que la materia tenga un ritmo intenso. Suele ocurrir (como en cualquier contexto de aprendizaje) que los alumnos deben reentregar alguna tarea y eso complica aún más la dinámica ya de por si intensa. En ese contexto los alumnos sugirieron tener una semana sin tareas para que quienes estén adeudando algo puedan ponerse al día.
  • Mejorar el material de estudio sobre diagramas de secuencia que actualmente resulta insuficiente.
  • Ajustar el tiempo de requerido por la materia y la dinámica de reentregas. Si bien en nuestro diseño de la materia esperábamos una dedicación extra-clase de 6 horas semanales, los alumnos reportaron estar invirtiendo unas 10 horas. Parte de las cuales resulta consecuencia de las múltiples reentregas que tienen algunas tareas. En este sentido acordamos que cada tarea tendrá solo una reentrega.

Sobre las prácticas técnicas y “las otras”

Hace un par de días circuló por la red un frase de Ivar Jacobson: Kill All Methods — Free the Practices“. Esto nos resonó mucho dentro de nuestro equipo de investigación en UNTreF porque nuestra temática de trabajo está enfocada en  prácticas de desarrollo de software.

En términos generales entendemos que en el desarrollo de software hay dos grandes grupos de prácticas cuyos nombres aún no terminamos de cerrar pero que por el momento venimos denominando practicas técnicas y prácticas organizacionales. Esta clasificación/agrupamiento de prácticas no es algo necesariamente novedoso, de hecho Bertrand Meyer en su libro Agile! habla de prácticas técnicas y organizacionales. Por otro lado, en el reporte anual de Agile de Version One se habla “técnicas ágiles” y “prácticas de ingeniería”.

En el contexto de nuestra investigación las prácticas organizacionales son aquellas practicas aplicables en diversas disciplinas porque no requieren conocimiento específico de la disciplina porque tratan sobre la forma en que el equipo de organiza para realizar su trabajo.  Un ejemplo de este grupo de prácticas son las de gestión de proyectos, las cuales pueden aplicarse tanto en un proyecto de desarrollo de software como un proyecto de construcción civil.

Las prácticas técnicas son prácticas particulares de la disciplina y que generalmente no aplican (o pierden sentido) en el contexto de otra disciplina. Un ejemplo de esto podrían ser las prácticas de versionado de código en desarrollo de software.

Continuará…

Cierre de cuatrimestre en Ingeniería @ UNTreF

La semana pasada cerramos el cuatrimestre en la materia Ingeniería de Software en UNTreF. Fue mi tercer cuatrimestre en la materia y personalmente estoy muy conforme con el resultado. Algunas particularidades de este cuatrimestre fueron:

  • Tuvimos un cambio en el equipo docente, Diego Marcet (@diemarcet) reemplazó a Pablito Tortorella (@pablitux)
  • Cambiamos el campus virtual que usamos como herramienta de soporte, pasamos de Eliademy a Canvas.
  • Hicimos algunos ajustes en el programa, incluyendo algunos temas nuevos relacionados principalmente a cuestiones de control de calidad y gestión de la operación
  • Tuvimos dos clases especiales: una sobre modelos de calidad dictada por Sergio Villagra y otra dictada por Fernando Pelliccioni quien compartió la forma de trabajo de su equipo de desarrollo en Bitprim

En términos estadísticos:

  • 8 inscriptos, 1 abandono, 7 aprobados
  • La nota promedio de cierre de cursada fue 8,9
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue 8,3

Entre los puntos a mejorar que identificamos en el cierre de la materia destacamos:

  • Mejorar la consigna de la tarea de performance testing
  • Agregar un video introductorio a JMeter
  • Revisar el envió de notificaciones del campus (varios reportaron que la notificaciones les llegaban con mucho retraso)
  • Repetir el ejercicio del elefante carpaccio que fue de las mejores actividades de la materia
  • Comenzar antes con el desarrollo del trabajo final
  • Intentar que las tareas individuales se hagan sobre la misma base de código que el trabajo final
  • Hacer una introducción técnica a Padrino
  • Probar haciendo que las iteraciones del trabajo final sean de 2 semanas

Primeros egresados UNTreF

El pasado miércoles por la tarde tuve la oportunidad de asistir a la defensa del trabajo final de carrera de los dos primeros egresados de la carrera de Ingeniería en Computación de la Universidad Nacional de Tres de Febrero: Fernando Scorpiniti y Fernando Degirmenntjis. Adicionalmente fui jurado evaluador de uno de estos trabajos. Más allá de lo que esto representa para los egresados y sus familias, este es un gran hito para la carrera e incluso para la universidad. Mis felicitaciones a ambos Fernandos.

PD: Curiosamente también fui jurado evaluador del trabajo de primer egresado de la Tecnicatura en Programación de UNQ, ¡que loco!

Cierre de AyDOO 2017 en UNTreF

Se fue otro cuatrimestre y como de costumbre es momento del informe de cierre.

El primer punto a destacar es que, incorporando el feedback de la edición anterior, ajustamos la carga de trabajo y ampliamos el equipo docente. En la edición anterior yo fui el único docente, mientras que en este caso, también participaron de la materia Facundo Arcieri y Diego Fontdevila. Personalmente creo que esta extensión del equipo fue muy positiva. Más allá de esta cuestión contextual, las métricas del curso fueron:

  • 14 inscriptos, 2 abandonos, 8 aprobados y 4 desaprobados.
  • La nota promedio de cierre de cursada fue 8/10.
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue de 7,9/10.

Como siempre cerramos la materia con una retrospectiva. Entre los puntos a probar/mejorar surgieron:

  • El tiempo de corrección, en varios casos nos demoramos más de una semana en entregar las correcciones de las tareas semanales
  • Cambiar el campus, pues el que usamos tuvo varias caídas y algunas de las funcionalidades ofrecidas no están muy logradas
  • Hacer más ejercicios con Ruby y/o empezar a trabajarlo antes
  • Armar el calendario de entregas de forma tal de tener 2 semanas de trabajo entre la fecha de publicación de cada tarea y la fecha de vencimiento

Por otro, entre los puntos positivos de la materia los alumnos identificaron:

  • El uso del campus virtual
  • El stack de herramientas utilizado
  • La dinámica de cursada con evaluación constante