Etiqueta: unq

Agile en la academia, mi experiencia

En este tema tenemos dos cuestiones:

  1. La aplicación de técnicas agile en la enseñanza (más allá de cual sea la materia de estudio)
  2. La enseñanza de agile como un enfoque de la ingeniería de software.

En mi caso tengo experiencia en ambas cuestiones.

En Algoritmos y Programación 3 (Universidad de Buenos Aires) nuestro foco de estudio es la programación orientada a objetos pero incluimos en el programa de la materia algunas prácticas comunes en el movimiento agile como ser TDD e integración contínua. Esto se debe a que en la actualidad no concebimos la construcción de software orientado a objetos sin el uso de estas prácticas.

Por otro lado, en Elementos de Ingeniería de Software (Universidad Nacional de Quilmes) el enfoque de ingeniería que enseñamos es el enfoque Agile. Es necesario mencionar que el objetivo de esta materia es proveer, a un técnico en programación, herramientas suficientes para llevar adelante el desarrollo de un sistema de software. La discusión de porqué el enfoque Agile y no otros, es tema de otro post. Al mismo tiempo la forma en que se dicta la materia tiene varias técnicas de agiles como ser:

  • La materia se encuentra dividida en iteraciones, al final de cada una los alumnos presentan un entregable y se realiza un retrospectiva sobre la forma en que se ha dictado la materia
  • El entregable puede ser un informe, software, un documento de diseño o una evaluación
  • Los alumnos se auto organizan para llevar adelante las distintas asignaciones
  • Cada alumno lleva un backlog de sus tareas, que es priorizado por el docente y estimado por cada alumno
  • Si al final de la iteración el entregable de un alumno no cumple con el criterio de done previamente acordado, entonces el docente puede decidir:
    • «cancelar el proyecto», lo que básicamente significa que el alumno ha pedido la materia)
    • agregar al backlog items distintos o adicionales para compensar/suplir el entregable incompleto

Asimismo hay dos cuestiones que nos parecen centrales más allá del enfoque agile:

  • Los proyectos de software se desarrollan dia a dia y eso mismo hacemos en la materia. Hay que trabajar todas las semanas. Esto resulta en ocasiones «chocante» para los alumnos que muchas veces están acostumbrados a simplemente asistir a clase y sólo trabajar/estudiar la semana previa a un exámen. 
  • Un factor importante para el éxito de cualquier proyecto es la comunicación y el manejo de expectativas. Durante toda la materia hacemos mucho incapié en esto. Por eso, si un alumno piensa no asistir a una clase, tiene la obligación de avisar previamente al resto de la clase. No hace falta que dé explicaciones, simplemente decir «No asistiré a clase». Esto permite que el docente puede planificar mejor las actividades de la clase sabiendo con cuantos alumnos contará.

Aqui dejo algunos links a posts anteriores que agregan más información sobre lo mencionado aquí:

Nota: este post surgió a partir de una consulta de mi colega Juan Gabardini quien me mencionó una iniciativa de gobierno de Medellín para la enseñanza de método ágiles en las universidades. Gracias Juan.

Cierre de cuatrimestre en UNQ, tercera promoción

El lunes pasado tuvimos la última clase de Elementos de Ingeniería de Software la cual como de costumbre estuvo dedicada a la retrospectiva. Pero antes de entrar en las conclusiones de la retrospectiva, les comparto algunos números:

  • Alumnos anotados: 8
  • Alumnos aprobados: 7
  • Alumnos pendientes de aprobación: 1
  • Nota final promedio: 8,14
  • Fueron un total de 27 clases
  • Tuvimos la visita de un profesional de la industria (¡gracias Emilio!)
  • Trabajamos exhaustivamente con Ruby, Sinatra y Cucumber
  • Desarrollamos varias aplicaciones, las cuales publicamos en heroku y algunas incluso con dominio propio

Personalmente estoy muy conforme con como resultó el curso. A diferencia de cuatrimestres anteriores, puse mucho menos foco en cuestiones de arquitectura/diseño y más énfasis en cuestiones de análisis y especificación (Visual Story Mapping, BDD, etc).

 Respecto de la retrospectiva, los puntos destacados fueron:
  • Mantener:
    • Dinámica de las clases
    • Lecturas
    • Resumenes
    • Herramientas
    • Invitados
    • Clase remota
  • Probar/incrementar:
    • Actividades de relación previas al comienzo de la clase
    • Clases al aire libre
  • Mejorar:
    • La forma de feedback >> Action Item: ser más explicíto al setear expectativas de los entregables y ser  más cuidados con el tono

Para cerrar el post, quiero agradecer a Natalia, una ex-alumna de la materia que colaboró conmigo durante todo el cuatrimestre.

unq-promocion3

Nota: el ícono representa una alumna que estuvo ausente el día de la retrospectiva.

 

Academia e Ingeniería de software

Desde que empecé a dictar la materia de Ingeniería de Software en UNQ, comencé a prestar mayor atención a los diferentes enfoques para enseañar esta disciplina. En Agiles 2012 y luego en mi reciente viaje a Venezuela pude hablar con gente de diversas instituciones y confirmar la teoría que aquí expongo.

El enfoque utilizado para enseñar Ingenieria de Software depende de carrera que uno analice, ya que cada carrera le da distinta relevancia al tema. Hay carreras en las que simplemente hay una o dos materias de Ingeniería de Software, mientras que otras tienen una materia por cada disciplina de la Ingeniería de Software. En este sentido la Tecnicatura en Programación de UNQ pertenece al primer grupo, ya que solo tiene una materia del tema (la que dicto yo ;-)). Por su parte, la Ingeniería informática de UBA está en el otro extremo, tiene una materia por cada disciplina: Análisis, Diseño, Administración de Proyectos, Arquitectura, Calidad, etc, etc.

El enfoque utilizado influye, como es de esperar, en los contenidos impartidos. Si uno cuenta con varias materias, es posible tratar distintos enfoques y técnicas con un nivel de profundidad interesante, pero si uno cuenta con sólo 1 o 2 materias, entonces se ve en un dilema: estudiar un único enfoque con cierta profundidad o bien ser más generalista y estudiar varios enfoques de forma más superficial. En la tecnicatura de UNQ solo tenemos una materia de Ingenieria de Software y la estrategia elegida fue centrarnos en un sólo enfoque (el de los métodos ágiles) aunque hacia el final de la materia hacemos una breve mención de waterfall y UP. Esta decisión estuvo motivada por el hecho de que pretendemos que al finalizar la carrera, el alumno pueda llevar adelante un proyecto de punta a punta y para ello creemos más valioso conocer un enfoque en detalle que conocer varios enfoques de forma superficial.

En base a lo que he hablado, leido y compartido con colegas de distintas instituciones, me da la impresión que en la actualidad la mayoría de las instituciones (en América del Sur) enseñan Ingeniería de Software utilizando un enfoque «tradicional» basado en los clásicos de Somerville y Pressman o bien se inclinan a un enfoque un poco más concreto y se basan en el Proceso Unificado. Adicionalmente en algunos casos se dictan materias complementarias (optativas generalmente) donde se ven enfoques alternativos (agile, waterfall, etc, etc).

Si algún lector no comparte esta visión, me gustaria que expusiera su opinión.

Jenkins: Plugins infaltables

De cara a automatizar parte de la corrección de los trabajos de los alumnos de la materia que dicto en UNQ, ayer estuve configurando un Jenkins. La idea es que los alumnos entreguen sus trabajos via Github, o sea, cada alumno tendrá un repositorio en GitHub. Llegada la fecha de entrega de cada trabajo, el build server (Jenkins en este caso) descaga los repositorios y verifica que existan archivos correspondientes a la entrega.

Como parte de la configuración de este Jenkins, instalé los siguientes plugins que me parecen fundamentales:

  • Git: la función de este plugin es obvia, permite a Jenkins conectarse con repositorios Git
  • Green Balls: por defecto, Jenkins representa el estado «build exitoso» con el ícono de una pelotita azul. Este plugin cambia dicha pelotita azul por una pelotita verde.
  • Copy Artifact: permite copiar artefactos de un proyecto a otro
  • Email Ext: extiende la funcionalidad de notificaciones de email provista por nativamente por Jenkins

Anteriormente había comentado sobre un plugin para enviar notificaciones via Jabber (particularmente gtalk), en esta ocasión no lo instalé, pues creo que dicho plugin resulta útil para cuando uno trabajar en desarrollo y este no es el caso.

Primer Balance TPI 2012

Al final de cada cuatrimestre en TPI, Fidel, el director de la carrera, organiza la denominada «reunión de balance». En dicha reunión Fidel comparte con los alumnos y profesores de la carrera los hechos y novedades relevantes acontecidas durante el cuatrimestre.

Tradicionalmente estas reuniones han tenido una forma de «pseudo-monólogos», lo cual es casi inevitable ya que es Fidel quien concentra casi toda la información de lo acontecido. A pesar de esto, este cuatrimestre Fidel decidió intentar un cambió y convocó a dos «maestros de ceremonias» para facilitar la reunión. Yo tuve el honor de ser uno de esos maestros de ceremonias, el otro fue Victoria Fabrice, una alumna de la carrera.

La reunión estuvo dividida en 3 partes:

  1. Dado que Fidel concretaba mucha de la información a compartir, la primera parte de la reunión, unos 40 minutos, Fidel hizo un resumen de los hechos más relevantes: estadísticas generales de la carrera, anuncios sobre las inscripciones, novedades en el equipo docente y en la infrastructura de la universidad, etc, etc.
  2. Una vez finalizada la exposición de Fidel, junto con Victoria falicitamos una dinámica para romper el hielo y que la gente se relaje. Al finalizar la dinámica cada participante escribió en post-its sus inquietudes/problemas/sugerencias/consultas y los pegó en el pizarrón.
  3. Una vez terminada la lluvia de post-its, pasamos a la parte de debate para lo cual utilizamos la técnica de Fishbolw. Victoria y yo fuimos agrupando los post-its por temática y los fuimos compartiendo en voz alta para ir tratándolos. La idea era que entre todos contestaramos las consultas y debatieramos posibles soluciones a los problemas.

Los principales temas de discusión estuvieron alrededor de la oferta horaria, la infraestructura de la universidad, la nueva Licenciatura en Desarrollo de Software, la publicación de notas, la organización/representación de los alumnos y comunidad TPI. Personalmente me resultó muy enriquecedor.

Al finalizar, utilizamos la técnica de las caritas para ver si los asistentes preferian está forma de reunión o la tradicional, los resultados fueron:

  • 🙂 , 25 personas prefieron está forma de reunión por sobre la anterior
  • 😐 , 3 personas opinionaron que esta forma de reunión o la anterior le dan lo mismo
  • 😦 , no hubo gente prefieriera la forma anterior

Hay un voto que me llamó la atención, ya que el dibujo no correspondia con la consigna, me queda la duda si es una carita asombrada o enojada.

Retrospectiva de Ing. de Software, primer cuatrimestre 2012

Antes de entrar en detalle sobre los resultados de la retrospectiva, quiero destacar por qué hacemos restrospectivas. La respuesta es simple: para mejorar. La idea es revisar como se desarrolló la materia intentando identificar puntos positivos y negativos, y partir de su análisis definir: qué cosas mantener, qué cosas cambiar y que cosas probar. Ahora sí, vamos a la restrospectiva.

Para la retrospectiva, utilizamos la técnica del timeline, mi favorita para estos casos (cierre de cuatrimestre). Lamentablemente, solo participaron 5 de los 7 alumnos. De todos los items identificados, una cuarta parte estaba relacionada a cuestiones «de ambiente» ajenas a la materia y sobre las cuales prácticamente no tengo posibilidad de influencia (por ejemplo: fallas en la infrastructura informática de la universidad). Respecto del resto de los items, esto es lo relevante:

Items a mantener

  • Estructurada iterativa de la materia
  • Actividades de aplicación
  • Dictado de una clase en forma remota
  • Presentación de invitados de la industria
  • Dinámica de evaluación final
  • Restrospectiva al final de cada iteración y restrospectiva final

Cuestiones a mejorar

  • Dificultades varias con Sinatra
    • Recomendar un tutorial y darlo con anticipación suficiente
  • Evaluación online
    • Hacer revisar las preguntas por un tercero para asegurar que sean claras y evitar posibles ambigüedades
    • Hacer una al final de cada iteración
    • Resolver las dificultades técnicas de la herramienta para permitir ver el resultado y las respuestas correctas al finalizar la evaluación
  • Retos del profesor (si, yo, los sermoneo mucho cuando no cumplen con las tareas)
    • No calentarme tanto
    • Mejorar las formas
    • Automatizar la corrección y parte del feedback con alguna herramienta
  • Material utilizado en clase no disponible (en algunas clases utilicé ppts que luego no compartí)
    • Publicar el material utilizado o bien ser explícito de antemano que no será publicado
  • Poca visibilidad de las notas
    • Publicar las notas al final de cada iteración

Para probar

  • Lecturas voluntarias: compartir algunas lecturas/videos opcionales que les permitan sumar «puntos adicionales» al presentarlos al resto de la clase
  • Proveer una guia de lectura para todas las lecturas, asi leen más enfocados
  • Dedicar los primeros 10 minutos de la primer clase de la semana para repasar los puntos destados de la lectura realizada

Bueno, esto es todo, voy a intentar incorporar todas estas cuestiones el próximo cuatrimestre.

Cierre de cuatrimestre en UNQ, segunda promoción

El jueves pasado realizamos la restrospectiva de cierre del cuatrimestre. Comparto aqui algunos números:

  • Este cuatrimestre se anotaron 7 alumnos
  • Los 7 completaron la materia
  • La nota final promedio fue 7,42
  • Tuvimos 30 clases organizadas en 4 iteraciones
  • Tuvimos 2 visitas de profesionales de la industria
  • Leimos más de 12 artículos
  • Hicimos varios ejercicios de BDD y TDD con Ruby
  • Desarrollamos 3 aplicaciones trabajando en grupo, utilizando Scrum, user stories, cucumber, sinatra y github.
  • Hicimos varias actividades para ejercitar diferentes prácticas: pajarraco scrum, fábrica de aviones, estimación de subastas, etc.

Creo que este segundo cuatrimestre ha sentado las bases para lo que pretendo que sea la materia, con lo cual el próximo cuatrimestre será muy parecido.

En el siguiente post, compartiré los resultados de la retrospectiva.

Nota: los iconitos representan a los alumnos ausentes el día de cierre que fue cuando tomamos la foto.

Cómo enseñar/aprender a estimar

Tengo la impresión de que este es un tema muy pobremente tratado en los contextos académicos. Digo esto basado en mi experiencia personal y en lo que he hablado con varios colegas.

En mi caso vi la temática estimación en una clase en una materia, donde el docente realizó una explicación de diversos métodos. Nada más, sólo una explicación teórica. Nada de práctica para pudieramos entener mejor los métodos. Lamentablemente creo que esto no fué una situación aislada, pues he hablado con varios colegas de diversas casas de estudios y la situación no es muy distinta.

Personalmente creo que la estimación, al igual que varias de las actividades de la ingenieria de software, es una actividad que se aprende a partir de la práctica.

Cuando tuve que preparar el tema estimaciones para la materia que dicto en UNQ, determiné utilizar el siguiente enfoque:

  1. Explicar algunas generalidades sobre estimación (quien, cuando, para que, etc)
  2. Comentar brevemente los métodos más difundidos
  3. Explicar en detalle dos métodos
  4. Hacer un ejercicio grupal de estimación en clase
  5. Darles un apunte para lean y refuercen lo explicado en clase
  6. Pedirle a los alumnos que estimen cada tarea de la materia antes de realizarla
  7. Hacer un segundo ejercicio grupal de estimación en clase

El punto (6) lo hemos hecho a lo largo de todo casi toda materia, estimando y planificando cada tarea (esto es: cada alumno lleva un excel donde registra cuando va realizar la tarea de la materia y cuando tiempo estima decicarle). Luego de realizada la tarea, deben registrar también el tiempo real insumido. Con esto apunto a que los alumnos no solo hagan el ejecicio de estimar, sino que también se acostumbren a planificar.

Obviamente este enfoque me lleva más de una clase, pero creo que bien vale la pena.

Mi dream team

Estaba preparando mi clase de Ingeniería de software de mañana, cuando me vino a la mente la idea que quiero compartir con este post.

Resulta que esta clase va a tener dos partes: revisión de las  evaluaciones y visita de un invitado. Estaba pensando en como presentar al invitado cuando decidí que con una simple oración debería ser suficiente:

«Si tuviera que armar un dream team para llevar adelante un proyecto de desarrollo de software, este individuo seria la primer persona que incluiria»

Tal vez alguien lea esto y piense que la persona merecedora de esta frase debe ser un excelente programador, muy habilidoso, muy productivo, etc, etc. Un groso en una palabra. Y en parte sí, lo considero un groso, pero… ¿es un excelente programador? Mmm, si pero no es el mejor que conozco ¿es muy productivo? mmm…si nada nada del otro mundo.

Entonces…¿por qué he de incluirlo en mi dream team? Porque es un profesional capaz de adaptarse al contexto, tiene una sólida formación, es criterioso pero sobre todas las cosas: es una persona en la que tengo absoluta confianza y con la que sé que puedo trabajar armónicamente.

¿Y tú? ¿que cuestiones tendrías en cuenta para armar tu dream team?

Taller sobre motivación: saliendo de la zona de confort

Ayer fui facilitador de una taller de actualización pedagógica sobre motivación realizado en el contexto de la iniciativa «El aula y el trabajo«, un proyecto de extensión de la Universidad Nacional de Quilmes. Llegué por invitación de Mara Dalponte y Daniel Palazzo.

El taller se llevó acabo en la EEST N° 4 de Berazategui y contó con 25 asistentes entre los que habia docentes de docentes nivel medio, docentes de TPI y algunos otros referentes sociales de la zona.

La actividad comenzó con una bienvenida a cargo de Mara, quien repasó brevemente el objetivo del proyecto y del  taller en particular. Luego llegó mi turno. Me presenté brevemente y propuse una actividad para romper el hielo (al mejor estilo agiles@baires). Una vez entrados en confianza utilicé la ideas de Dan Pink sobre motivación como disparadores del debate y les sumé algunas ideas/técnicas surgidas de mi propia experiencia.

Facilitar esta actividad fue un gran desafio para mi, pues el cambio de audiencia me obligó a salir de mi zona de confort. Sinceramente disfruté la actividad y quedé muy conforme con como se desarrolló. Es más, creo que en un punto es más lo que me llevé yo que lo que les dejé a los asistentes, ja!

Bueno, esto es todo por ahora, me despido no sin antes darle las gracias a Daniel y Mara por haberme dado la oportunidad de participar.