El pajarraco Scrum con Qubics

El lunes pasado en EIS hicimos la ya clásica actividad de simulación de Scrum conocida como “”El pajarraco Scrum”.

A diferencia de otras veces en lugar de rastis utilizamos qubics lo cual permitió que realizar obras más “estilizadas”. De la simulación participaron 14 alumnos divididos en 3 equipos, cada uno con su correspondiente product owner. Los 3 product owners fuimos Ingrid (alumna colaboradora de la cátedra), Jona (un alumno que ya había cursado la materia) y yo.

Curiosamente a pesar que los cubics son más maleables que los rastis, hubo equipos que llegaron al final de iteración sin cumplir con la visión de producto.

pajarraco_qubic_2

pajarraco_qubic_3

 

 

pajarraco_qubic_1

Cierre de cuatrimestre en UNQ (2014-1)

Este cuatrimestre batimos algunos records. En primer lugar tuvimos record de alumnos: 14, al mismo tiempo tuvimos record de deserciones: 5, ¡ups! demasiado para mi gusto.

Hablo en plural pues ya desde el cuatrimestre pasado la materia la estoy dictando junto con @pablitosuarez

Como teníamos planeado, continuamos trabajando con el campus y más aún, potenciamos su utilización. Creamos varios cuestionarios como evaluaciones complementarias para algunos temas.

En lo que respecta a los TPs finales, hicimos algunas variantes. En primer lugar nos dividimos los grupos de manera que cada docente fuera product owner de dos grupos. Al mismo tiempo los grupos trabajaron sobre dos aplicacione distintas. Una de ellas era una aplicación creada de cero, mientras que la otra era una aplicación existente a la que debía agregarse funcionalidades. Quedamos muy conformes con la dinámica y los resultados, por lo cual estimo que repetiremos el cuatrimestre próximo.

Mantuvimos la dinámica de visitas de gente de la industria, en este caso tuvimos 3 visitas de excelente nivel de empresas radicalmente distintas:

Adicionalmente a la ya clásica retrospectiva de fin de curso, este cuatrimestre hicimos una encuesta anónima que nos permitió obtener una evaluación más cuantitativa. De esta encuesta sacamos que la evaluación general de la materia por parte de los alumnos fue: 8.4.

De la retrospectiva y la encuesta destacamos algunos puntos en los que trabajaremos el cuatrimestre próximo:

  • Comenzar con la kata de ruby en forma temprana para que los alumnos tenga más tiempo de familiarizarse con Ruby antes de comenzar con el trabajo final
  • Planificar con mayor anticipación las últimas semanas de clase de manera de poder hacerlas más interactivas
  • Alinear mejor entre los docentes los criterios de evaluación de los grupos

Aprovechando la moda, cierro el post con una selfie junto a los alumnos que estuvieron presentes la clase de cierre (solo falta uno que estuvo ausente por razones de salud).

unq-promocion-sexta

Sexta promoción de la materia desde que está a mi cargo

 

 

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á…