Largamos el TP Final de Algo3

Este cuatrimestre el TP fue ideado por GabiD con aportes de DiegoM y PabloM. Consiste en un juego por turnos en el que el usuario debe mover su vehículo por una ciudad llena de obstáculos de distinto tipo, intentando minimizar la cantidad de turnos utilizados y maximizando el puntaje acumulado.

Yo tengo a mi cargo 3 grupos los cuales vienen trabajando muy bien. Para facilitar las cuestiones tecnológicas y permitir que los alumnos se concentren en OO, les dimos un proyecto base de ant y un par de videos que explican cómo dar los primeros pasos con Java, Ant y Subversión. Adicionalmente me encargué de configurar un servidor de integración continua. Para esto último estamos usando el servicio gratuito que muy gentilmente nos brinda la CloudBees. Como de costumbre hemos hecho mucho énfasis en que desarrollen sus trabajos haciendo TDD y según muestran los reportes de cobertura parece que lo estan haciendo.

algo3-g1-2013-2

Impresiones del Agile Open Buenos Aires Educación 2013

Hace dos semanas participé de este evento comunitario y me llevé un montón de cuestiones para profundizar y experimentar.

Una de las particularidades del evento fue la presencia de una importante cantidad de gente no relacionada al desarrollo de software, lo cual resultó muy enriquecedor.

Yo propuse dos sesiones: una para compartir experiencias de Aula Extendida y otra para debatir sobre los trabajos finales de las carreras de sistemas. Sólo la primera tuvo apoyo y se realizó, pero de todas formas hablé sobre el segundo tema en los pasillos, con algunos asistentes que estaban interesados. En la sesión de Aula Extendida, comenté mi experiencia en las materias que dicto en UBA y UNQ. Uno de los participantes planteó si es mejor utilizar las herramientas provistas por redes sociales que los sistemas típicos de los ambientes académicos (listas, foros, Moodle. etc).

Una de las sesiones que más me gustó fue la propuesta por la gente de EDEA, una organización que trabaja en cuestiones de diseño sustentable. Nos contaron sobre su organización, la forma en que trabajan e hicimos un par de dinámicas corporales muy interesantes.

También participé de una sesión facilitada por Alan Cyment, en la que compartió algunas técnicas «from the back» que suele utilizar en sus cursos.

Ya por la tarde participé de una sesión cuyo nombre no recuerdo, pero que trató sobre el impacto que tiene la tecnología en la educación. Bastante polémica e interesante. En cierto modo en la sesión de aula extendida hablamos principalmente sobre el efecto positivo, pero en este caso también tratamos algunos aspectos negativos y cómo lidiar con ellos.

En resumen, me resultó muy enriquecedor.

Cierre de Algo3, primer cuatrimestre 2013

Si bien no hicimos cambios explícitos en la dinámica de la materia, incorporamos algunas cuestiones internas que generaron impacto muy positivo.

Una de estas cuestiones fue la incorporación del sistema de corrección de TPs. Esto nos ayudo a reducir muchísimo la carga de trabajo manual al mismo tiempo que le permitió a los alumnos tener un feedback inmediato de las entregas de sus trabajos.

Por otro lado, trabajamos con más foco en la coordinación interna de las clases de los distintos cursos de práctica, reutilizando materiales y ejemplos.

Finalmente, en lo que respecta al trabajo final, tuve dos grupos a mi cargo y ya desde la primer semanal tuvimos el soporte de un servidor de integración continua. Para esto, utilice el servicio que gentilmente nos brinda en forma gratuita CloudBees. Al mismo tiempo, fue muy positivo que ambos grupos tomaron en serio el build server, rompiendo el build muy pocas veces. Todo el proceso de build lo hicimos usando Ant y consistia en compilación, ejecución de pruebas (junit), medición de cobertura (cobertura) y verificación de código (checkstyle). Otro detalle que me pareció muy positivo es que gran parte del modelo de la aplicación lo hicieron usando TDD, lo cual derivó en un porcentaje de cobertura muy bueno (superior al 80%). Algunos otro docente, también usaron esta herramienta con muy buenos resultados y por ello en la retrospectiva decidimos extenderlo a toda la cátedra para el próximo cuatrimestre.

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

Anécdotas sobre cobertura de la prueba

«No quieres 100% de cobertura, porque es realmente muy caro lograrlo. En cambio deberías enfocarte en asegurarte la cobertura en los lugares donde más frecuentemente tienes bugs«.

Este es un extracto de una charla que tuve con Stef mientras transitábamos por la ruta que lleva de Lens a Lille, en Octubre de 2010. Si bien puse el texto entre comillas, la cita no es textual, pues Stef hablaba en inglés, pero la idea central es la que reflejo aquí.

Para cerrar este post, les comparto una situación que viví hace un tiempo: resulta que una de las personas que estuve capacitando hizo una demo de la aplicación que desarrolló como parte de la capacitación. La demo venia bien y en un momento le pedimos que mostrara una funcionalidad particular que no habia sido mostrada. Resulta que cuando la va a mostrar, la aplicación ¡pincha!, ja!  a lo que le pregunto ¿y los tests? adivinen….no había tests para esa funcionalidad. El porcentaje de cobertura de la aplicación no superaba el 40%. ¡Que mejor forma de ilustrar la importancia de estas cuestiones! Espero que este colega haya aprendido la lección.

Por último quiero agradecer a David Frassoni quien la semana pasada me dio la idea de escribir este post.

Curso de Startup Engineering: Semana 1

Hola, hoy completé todas las tareas correspondientes a la primer semana de este curso que estoy haciendo en Coursera. Me está resultando muy interesante, no por las cuestiones técnicas (que por el momento son muy básicas) sino por las cuestiones más «de negocio y estrategia».

Si a alguien le interesa sumarse a este curso, aún está a tiempo, dado que la debido a la gran cantidad de gente registrada en los últimos dias, se ha extendido el plazo de entrega de la primera tarea hasta el 3 de Julio.

Prometedor curso online de Ingeniería de Software

Esta semana estoy comenzando un nuevo curso online en Coursera. En este caso se trata de un curso ofrecido por Standford y si bien el título es «Startup Engineering» el contenido está enfocado en cuestiones de ingeniería de software para contextos de startups web. La dinámica parece ser muy similar a la del curso Berkeley que tomé el año pasado. Tengo muchas expectativas, ya veremos.

La clave es educarlos de chiquitos

Hoy compartí el almuerzo con mi colega JuanG y algunos otros profesionales de la informática. En un momento comenzamos a hablar sobre TDD y algunas otras prácticas ágiles. Durante la charla uno de los comensales comentó que le parecía muy difícil pretender que los programadores «junior» utilicen dichas técnicas cuando las mismas ni se mencionan en las universidades. Estuve de acuerdo con el comentario respecto de la complejidad, pero al mismo tiempo agregué que en algunas universidades, estos temas son materia corriente. Para mi : «La clave es educarlos de chiquitos».

Como ocurre en todos los ámbitos de la vida, una vez que algo se hace hábito, cuesta mucho cambiarlo. Es por esto que en las materias que dicto hago mucho énfasis en cuestiones tales TDD y prueba unitaria. Un caso testigo es lo que hacemos en Algo3. En las clases prácticas resolvemos ejercicios y en todos los casos lo hacemos usando TDD. Luego, en los dos trabajos prácticos individuales que los almnos deben resolver, les recomendamos una y otra vez que los resuelvan utilizando TDD. Finalmente cuando llegan al último trabajo práctico que implica trabajar el grupo, los alumnos tienen la técnica incorporada. Un detalle importante es que si bien la técnica de TDD la aprenden en nuestra material, ya en la materia anterior los alumnos comienzan a hacer pruebas unitarias automatizadas.

Cierro este post con algunos gráficos de métricas de tests de los grupos que estoy dirigiendo en Algo3 este cuatrimestre. ¡Hermoso!

covertura

Qué hacer cuando mi compañero no trabaja

Ayer recibí esta consulta de un alumno:

Te escribo para hacerte una consulta, de algo que me viene pasando en todas las materias en las que tuve que hacer trabajos grupales.
El problema es que no sé como manejar el tema cuando mi compañero de grupo no hace las cosas, o las deja para último momento. Siempre trato de alentarlo y ayudarlo en sus dificultades, pero cuando la otra persona no se dispone se complica. A veces pienso en que debería «retarlo», porque es algo que nos afecta a ambos, pero ese es un rol que no me corresponde, yo no manejo sus tiempos ni demás.
Me imagino que con tu experiencia académica y en la industria te habrá pasado muchas veces. Te pido algún consejo, que seguramente me será de ayuda a lo largo de toda mi carrera.
….
¡Ja! Efectivamente he enfrentado este tipo de situaciones en reiteradas ocasiones.
Antes de entrar a ver posibles soluciones dejemos en claro el problema. A mi entender podemos tener dos situaciones:
  1. Mi compañero no trabaja
  2. Mi compañero trabaja, pero se traba y no logra completar su trabajo
Es importante hacer la distinción, pues la forma de abordar la situación puede ser distinta para cada caso.
Más allá de estas dos situaciones, la consecuencia suele ser que se genera cierta tensión en el grupo y a la larga el resultado es:
  1. Termino haciendo el trabajo yo solo (posiblemente trabajando mucho más de lo que debiera)
  2. No llegamos a cumplir con la consigna, lo cual suele acarrear un calificación negativa.
Luego de este análisis preliminar, veamos entonces algunas recomendaciones que a mi entender aplican a todos los casos.

1. Mejor prevenir que curar
Mi primer recomendación es mirar con quien armamos el grupo de trabajo. En este sentido soy de una postura conservadora: más vale malo conocido que bueno por conocer. Yo en estos contexto académicos prefiero trabajar con alguien que ya conozco, aún cuando sepa que tiene «ciertos defectos», pues ya sé a que atenerme y puedo planificar en consecuencia.

2. Organización del trabajo
Una vez que el grupo está constituido y la consigna del trabajo a desarrollar está clara, el grupo debería hacer una lista de tareas, estimarlas y planificarlas. Cuando digo planificar me refiero a determinar: quién hará la tarea, y cuando la hará. Esto implica que cada integrante asuma un compromiso. Si luego ese compromiso no es cumplido habrá que analizar que ocurrió ¿surgió un imprevisto?¿llevó más tiempo de lo esperado?¿o ni siquiera se comenzó a trabajar en la tarea?
3. Visibilidad
Por un lado es importante que cada miembro del grupo de visibilidad sobre el estado de sus tareas al resto de los integrantes. Pidiendo ayuda en caso de problemas y avisando en caso de retrasos.
Por otro lado, dependiendo de la materia, puede resultar útil e importante, dar visibilidad a los docentes de cómo avanza el grupo, pues para algunas materias (generalmente las de gestión) la interacción de los miembros del grupo de trabajo es parte de los temas de estudio.
4. Comunicación constante
No basta con dar visibilidad, esa visibilidad debe ser frecuente, sin temer a generar «spam», más vale que sobre a que falte.
5. Adaptación
Si damos visibilidad de forma frecuente, podremos ser capaces de detectar problemas y adaptar nuestros planes en consecuencia. Si un integrante del grupo no pudo completar sus tareas, entonces podremos repriorizar, hacer una sesión de trabajo conjunto o asignarla a otro miembro del grupo.
6. Trabajo de pares
Si bien puede parecer una pérdida de tiempo que dos personas trabajen al mismo tiempo en la misma tarea, la realidad es que en muchísimas ocasiones, esto permite avanzar mucho más rápido, pues al trabajar en parejas la gente se enfoca mucho más en la tarea en cuestión y si uno se traba tiene un compañero a su lado para ayudarlo. Herramientas como Google Hangout, Team Viewer y Skype permiten trabajar en forma conjunta estando físicamente separados.
Bueno, espero que estas recomendaciones les resulten útiles al lector y que no dude en contactarme si se encuentra en una situación que no sabe como manejar.