Hay gente que miente, gente que roba y gente que no respeta las convenciones

Esta frase me surgió espontáneamente esta tarde mientras daba clase en Algo3. Sonó un poco extrema, a punto tal que motivó algunas risas, pero a esta altura del cuatrimestre los alumnos ya me conocen lo suficiente y saben que para mi no es chiste.

Con el correr de los años me doy cuenta que gradualmente me he vuelto cada vez más radical en algunos temas. Sin duda las diversas lecturas y prácticas de Extreme Programming han tenido algo que ver en esta cuestión.

Personalmente me he ido convenciendo que si una práctica es beneficiosa entonces llevarla al extremo maximiza los beneficios. Y estoy convencido que esto va mucho más allá del desarrollo de software.

SEAL: Se buscan colaboradores

Si bien Aníbal y Martín han hecho un gran trabajo y tienen la intención de continuar colaborando con el desarrollo del producto, hay algunas cuestiones que requieren habilidades especiales o bien un esfuerzo importante.

Varias de estas cuestiones serán parte del alcance de algún futuro trabajo profesional de alumnos de Fiuba (ya hay algunos que han manifestado su interés), pero hay una cuestión en particular que dudo que alumnos «promedio» de Fiuba puedan manejar: la estética. Voy a ser sincero, la UI del sistema apesta, no sólo no es cómoda sino que tampoco es visualmente atractiva. Pero es algo que era de esperar, la formación que nos da Fiuba no trata estas cuestiones. Históricamente las casas de estudio de ingeniería se han ocupado que no falten en el plan de estudios materias de ciencia básica y ciencia aplicada, pero cosas de diseño y usabilidad, bien gracias. En fin, no perdamos el foco. El punto es que nos vendría bien contar con una mano de alguien que se dé maña con cuestiones de UI.

Por otro lado, la aplicación está hecha en Python, pero ni Aníbal, ni Martín, ni yo somos expertos en Python. Por esto nos vendría bien la colaboración de un experto Python para hacer una revisión de la aplicación y ver que hayamos aplicado apropiadamente las prácticas y convenciones del lenguaje.

 

Presentación formal del sistema de corrección: SEAL

El viernes pasado Aníbal y Martín realizaron la presentación formal del sistema de corrección de trabajos de programación y con ello completaron sus estudios para el graduarse de ingenieros en informática.

El nombre formal del sistema es SEAL: Sistema de Entregas Automatizadas Libre, un nombre apropiado en el sentido que representa lo que hace el sistema, pero desde el punto de vista comercial no tiene mucha onda (ya estamos trabajando en buscar un mejor nombre).

Como suele suceder en la presentación de los trabajos finales de carrera, la mayor parte de la audiencia son familiares de los alumnos que presentan y por lo tanto es poco lo que entienden de lo que se presenta. Siendo conscientes de esto, Aníbal y Martín prepararon una presentación muy didáctica para explicar su trabajo. Básicamente utilizaron la metáfora de un viaje a la luna para explicar el desafio que para ellos representaba hacer este trabajo de fin de carrera. Personalmente me gusto mucho la presentación, respeto los tiempo, resultó entretenida y expuso de forma adecuada el trabajo realizado.

Ha sido un gusto para mi trabajar con Aníbal y Martín, espero haberles aportado al menos un granito para su formación profesional. Al mismo tiempo les agradezco por haber confiado en mi para guiarlos en el trabajo.

¡Mi felicitaciones a los flamantes ingenieros!

presentacion_seal

El material utilizado en la presentación está disponible aquí.

Presentación formal del sistema de corrección

Llegó el gran momento, la presentación formal del sistema que significa no solo un hito en la vida del sistema como producto, sino que también es fin de una etapa para quienes lo construyeron: Martín y Aníbal. Con la presentación del sistema estos dos alumnos FIUBA terminan su estudios de Ingeniería en Informática. Por el momento, me limitó a copiar la invitación formal que se distribuyo entre la comunidad FIUBA y la semana próxima daré más detalles sobre la publicación del sistema.

El viernes 26/04 a las 18 horas, los estudiantes Aníbal Alejandro Lovaglio y Matín Mauro Zucchiatti presentarán en el Lab. E del Departamento de Computación su Trabajo Profesional «SEAL (Sistema de Entregas Automatizadas Libre)», que realizaron con la tutoría del Ing. Carlos Fontela y el Ing. Nicolas Paez como co-tutor.

Resumen:
El presente trabajo se enmarca en la problemática de corrección de trabajos prácticos en las materias de programación. La mayor parte de la producción a evaluar se trata de programas de computadora, y resulta claro que la funcionalidad de los desarrollos constituye el núcleo de la atención dedicada por los docentes a la hora de corregir las entregas. Sin embargo, esta porción del trabajo muchas veces hace perder tiempo valioso que debiera utilizarse para revisar aspectos conceptuales, como el diseño de las soluciones o la separación de incumbencias dentro de los distintos núcleos de abstracción de dicho
diseño. Es decir que muchas veces se invierte tiempo en ver que las entregas funcionen, o cumplan con casos de pruebas, pero lo que realmente importa no es que funcione, sino cómo está construido, y cómo funciona.
Existiendo ahora tantas herramientas que nos permitirían hacer esto de manera automática, es imperativo que se abandone el trabajo artesanal de testing y que se pueda dedicar el tiempo de los docentes en cosas que requieran del criterio de una persona.

Breve descripción de la metodología, indicadores, etc. que llevaron para su gestión
La gestión del proyecto se hizo usando una metodología basada en Scrum, pero adaptada a las condiciones del equipo de trabajo, ya que los tiempos dedicados al proyecto no eran regulares y la interacción entre los miembros del equipo está limitada por las circunstancias laborales de cada uno. De cualquier manera se usó el desarrollo guiado por user stories, y se midió el avance por burndown chart de proyecto.
El desarrollo del proyecto fue pensado en una única fase, con el objetivo del proyecto cumplido a su fin.
Se trabajó con un servidor de integración continua, que después de cada commit, compila, comprueba la sanidad del nuevo código y redespliega la aplicación, poniendo disponible la nueva versión.

Están todos invitados.

El desafio de liberar un producto

En estos dias estoy trabajando en la liberación como producto del sistema de corrección de tareas de programación que desarrollaron unos alumnos de FIUBA bajo mi dirección. El producto, desde el punto de vista técnico ya está listo, de hecho ya lo estamos usando en Algo3, pero liberarlo como producto requiere de ciertas cuestiones, que hoy en día me doy cuenta que no suelen ser parte de la formación académica (o al menos no lo fueron de la mia).

El primer lugar tenemos una cuestión legal: la licencia. Si bien tenemos en claro que queremos que sea open source, no tenemos en claro las diferencias entre las distintas licencias. Al mismo tiempo, ocurre que nuestro producto está basado en otros componentes de software que tienen ciertas licencias y que deberíamos respetar. Por último, si bien queremos que sea open source, queremos que quienes decidan extender el producto respeten ciertos condiciones, por ejemplo que lo desarrollado siga siendo open source.

Por otro lado si uno pretende que el producto tenga cierto grado de adopción, es necesario que los interesados en utilizarlo cuenten con información básica sobre las funcionalidades del producto, sus requerimientos para ejecución, el procedimiento de instalación, cómo proceder en caso de problemas, roadmap de producto, etc. ¡Ah! y un tema no menor, el manual de usuario, ya sea en formato tradicional de texto o en formato de video.

Al ser un producto open source, es posible que los potenciales usuarios quieran extenderlo y/o personalizarlo, en ese caso es necesario proveer información técnica comenzando por cómo armar un ambiente desarrollo para el producto.

Por último una cuestión no menor: el nombre del producto. Generalmente cuando uno arranca un proyecto le pone un nombre, pero el nombre del producto es algo conceptualmente distinto del nombre del proyecto. El nombre del producto impacta directamente en varias cuestiones como ser la URL del sitio del producto y los diversos elementos de márketing.

 

¡Que lindo es ser Product owner en estas condiciones!

Como ya he comentado, he estado trabajando con un par de alumnos de FIUBA en la construcción de un sistema de corrección de trabajos prácticos. A lo largo del proyecto he ocupado diversos roles: director, consultor, tester, etc, pero sin duda el que más tiempo he ocupado y que más he disfrutado es el rol de Product Owner.

Es la primera vez que ocupo este rol y ¡que linda experiencia me ha resultado! Creo que en gran medida esta satisfacción se debe a que el equipo (los alumnos en este caso) han sabido contentarme, no solo construyendo un producto que satisface mis necesidades, sino que también han logrado que el trabajo sea fácil de llevar. ¿De qué estoy hablando? De cosas en un punto simples u obvias pero que no siempre se dan. Puntualmente, han entregado un producto de valor, han sabido adaptarse a los cambios pedidos, me han dado visibilidad completa y contínua del estado y el avance del proyecto y en líneas general han facilitado mucho mi trabajo como product owner.

¿Cómo enseñamos a programar?

Cada vez estoy más convencido que la programación es un oficio y como todos los oficios se aprende haciendo. Pero no haciendo en soledad sino con un maestro. Pensemos en un carpintero ¿cómo se forma? ¿leyendo libros? Tal vez, si, es posible que lea algún libro, pero no es su principal formación. Su principal formación es trabajando la madera junto a un carpintero ya experimentado, quien le va enseñando los gajes del oficio. Pero si miramos la forma en que suele enseñarse a programar lejos está de esto.

No hay diferencia entre universidades, institutos terciarios o centros de capacitación privados, en general todos siguen el mismo esquema. El alumno asiste a un curso donde el docente ofrece algún tipo de explicación inicial y luego le dá a los alumnos ejercicios para que resuelvan. Luego se hace una resolución general en el pizarrón o usando un proyector. Puede que también se entregue algún material de lectura. Pero sentarse a programar con el alumno, no, nunca. En el mejor de los casos, mientras los alumnos trabajan en la resolución de los ejercicios, puede que un docente se acerque para responder alguna consulta o para destrabar a un alumno que no logra avanzar en la resolución.

¿Por qué es esto así? no lo sé a ciencia cierta. Creo que puede haber diversos motivos.

En sus comienzos la programación surgió vinculada a la matemática y por ello puede que haya heredado su didáctica. También puede ser que los docentes no vean la programación como un oficio. En algunos casos podría argumentarse que la masividad de algunos cursos hace imposible que el docente se siente a programar con los alumnos. En fin, cada cual tendrá sus argumentos. En lo que a mi respecta, estoy convencido que la programación es un oficio y si bien en Algo3 tenemos cursos masivos y recursos acotados, intentamos programar con los alumnos haciendo dojos en clase o incluso algo de «community-programming» al desarrollar el trabajo final, donde cada docente puede sentarse con grupos de 3 o 4 alumnos a programar conjuntamente.

Caso de éxito: sistema de gestión de trabajos prácticos

Hace un tiempo comenté sobre el sistema de gestión que estábamos por estrenar en Algo3. Bueno, lo estrenamos y fue un éxito rotundo. El sistema nos permitió corregir en forma automática más de 150 entregas.

Básicamente el trabajo práctico tenia como objetivo que los alumnos se familiazaran con el entorno de Pharo y la sintáxis de Smalltalk. Para ello les dimos un script con un conjunto de pruebas unitarias y los alumnos debían escribir todo el código necesario para que dichas pruebas se ejecuten exitosamente. Una vez escrito el código, los alumnos tenian que registrase en el sistema y subir el código escrito. Entonces el servidor se encargaba de correr el script de prueba e informar el resultado de la entrega via mail. Luego, una vez completada exitosamente la corrección automática, los docentes teniamos la posibilidad de navegar el código de los alumnos y realizar una corrección manual enfocada en cuestiones de diseño.

Con este hito, los alumnos que desarrollaron el sistema de corrección, obtuvieron la aprobación de su trabajo profesional de ingenieros en informática (aún restan ajustar algunas cosillas menores y algunos trámites administrativos, pero la parte «dura» ya está).

En las próxima semanas estaremos trabajando en ajustar algunos detalles del producto de cara a liberarlo formalmente como herramienta open source. Al mismo tiempo, ya estoy trabajando en armar un nuevo backlog para continuar trabajando con otros alumnos que quieran recibirse haciendo un aporte a esta herramienta.

Inclusión de métodos ágiles en las carreras de informática

En este post quiero tratar un tema que estuve trabajando la semana pasada en los talleres que participé en Medellín.
Según mi visión, a la hora de diseñar una carrera de informática existen distintas alternativas para incluir los métodos ágiles. En una simplificación extrema podriamos hablar de un enfoque conservador y otro innovador.

El enfoque conservador podria consistir simplemente en agregar una materia sobre métodos ágiles (posiblemente hacia el final de la carrera) y mantener el resto del plan sin mayores modificaciones.

Por otro lado, el enfoque innovador sería repensar la carrera completa incluyendo temas de agilismo en diversas materias. De esta forma se podría incluir Scrum en la materia de gestión de proyectos, TDD en las materias de diseño/programación, BDD y User Stories en las materias de análisis/requerimientos y así sucesivamente.

Si bien el enfoque innovador puede parecer más difícil de implementar, la realidad es que no siempre es así. Un claro ejemplo es lo que ocurre en FIUBA. Si bien los planes de estudio actuales no hacen referencia explícita a métodos ágiles, varios profesores han incluido temas de métodos ágiles en sus respectivas materias por iniciativa propia. Claro está, que esto es pura informalidad ya que la inclusión de los temas está sujeta por completo a la iniciativa de cada docente. Pero también es cierto que es una implementación «rápida», ya que no require de todo el trámite burocrático que puede implicar el modificar un plan de estudios. En FIUBA los temas de agilismo se empezaron a dictar hace ya más de 6 años por iniciativa de algunos docentes. Hoy por hoy, más docentes se han sumado a esta iniciativa y los nuevos planes de estudio (que están en proceso de aprobación) ya incluyen formalmente estos temas que en la realidad se vienen dictando hace varios años.