Estadísticas del nuevo cuatrimestre en MeMo2

Ya hemos completamos la segunda semana de clases. Tenemos 18 alumnos y un equipo docente con 2 profesores y 6 colaboradores, con lo cual deberíamos poder tener un flujo de seguimiento mejor que el cuatrimestre pasado.

Comparto aquí algunas estadísticas del perfil de alumnos que resultan llamativas:

  • Más del 70% de los alumnos ya están trabajando en alguna actividad afín a la carrera
  • Hay una variación muy grande en la cantidad de materias aprobadas: el alumno con más materias aprobadas tiene 33, mientras que el que tiene menos tiene 17

Condición laboral

Cantidad de materias aprobadas

Cantidad de materias aprobadas

Optimizando el pipeline de deployment – primeros resultados

A partir de la situación inicial previamente descripta, tuvimos que hacer algunos ajustes adicionales a lo esperado pero finalmente logramos paralelizar la pruebas de aceptación.

Logramos una mejora de ~30 % en el tiempo de ejecución del pipeline completo. La mejora es buena pero creemos que podemos mejorarlo aún más ya que en este momento los dos sets de pruebas automatizadas que hemos paralelizado se ejecutan dentro del mismo nodo de Jenkins compitiendo por recursos físicos.

Una mejora posible a esto es agregar un nuevo nodo Jenkins que permita que cada set de pruebas se ejecute con recursos físicos independientes.

Finalmente hay otra serie de posibles mejoras a experimentar pero que requieren trabajo ya a nivel código y por ello son más intrusivas en el día a día del equipo de desarrollo.

Presentación de libros en Agiles 2019

¿Escribiste un libro sobre Agile o un tema afín?

¿Vas a Agiles 2019?

Entonces lleva un par de ejemplares de tu libro para que los asistentes puedan darle una mirada mientras en 10 minutos les contas de tu libro.

Durante el Agiles 2019 vamos a hacer una sesión de presentación de libros de autores latinoamericanos. La idea es que cada autor presente su libro en 10 minutos y mientras lo hace ponga a disposición de la audiencia un par de ejemplares (¿2, 5, 10?) para que los asistentes puedan darle una mirada.

Esta sesión será una sesión más del Open Space pero la estoy anunciando con antelación para que los autores interesados en presentar su libro puedan preparar esa breve presentación y también para que puedan organizarse para llevar algunos ejemplares. La idea que haya al menos 2 ejemplares de cada libro que luego de la presentación puedan regalarse a los asistentes mediante algún mecanismo que definiremos durante la sesión. Más allá de esto, cada autor es libre de llevar ejemplares adicionales para vender o regalar.

Ya estuve hablando con algunos autores y hasta el momento la lista de libros a presentar incluye:

  • Proyecto Ágiles con Scrum (Martín Salías)
  • Construcción de Software (Nico Paez)
  • Por un Scrum Popular (Alan Cyment)
  • Desarrollo de Software Ágil en 10Pines (Fede Zuppa)
  • Poder Creativo (Ingrid Astiz)
  • Experiencias Ágiles (AOC libro 1) (autores varios)
  • Técnicas Ágiles (AOC libro 2) (autores varios)
  • Ensayos Ágiles (AOC libro 3) (autores varios)

Esas particularidades de la primera clase

Cada clase tiene sus particularidades pero la primera clase de una materia siempre me pareció especial. Tanto en mi rol de alumno como en mi rol docente. La primera clase encierra todo un conjunto de expectativas y cuestiones operacionales que la distinguen de todas las demás clases de una materia.

Como alumno, uno se inscribe en la materia teniendo muchas veces cierta información previa. Ya sea por algún compañero que curso la materia previamente o tal vez por simples rumores de pasillo, pero es en esa primera clase que esos mitos (o verdades) comienzan a develarse.

Como docente la previa del cuatrimestre es atareada. Hay que procesar el feedback del cuatrimestre anterior, actualizar ejercicios, reiniciar las herramientas de soporte (lista de correo, campus virtual, etc), preparar nuevos ejercicios e incluso a veces preparar nuevas clases. Más allá de esas cuestiones operativas también hay algunas cuestiones de índole emocional: ¿cuántos alumnos serán?¿cuáles serán sus expectativas?¿se habrán anotado en este curso por recomendación o por conveniencia de horarios?¿cuántos de ellos aprobarán? Algunas de esas cuestiones tendrán respuesta recién al finalizar el cuatrimestre pero otras encontrarán respuesta en esa primera clase.

Automatizando pruebas de IBM BPM

Una vez más un amigo que me tiene mucha confianza me invitó a proyecto desafiante: automatizar pruebas de una aplicación generada con una tecnología propietaria “IBM Business Automation Workflow” (IBM BPM).

Muy a grandes rasgos esta herramienta permite automatizar procesos de negocio utilizando una herramienta case que permite integrar (entre otras cosas) servicios (soap & rest) y componentes Java. Una vez que se ha generado el flujo, se genera un paquete (.ear) que se despliega en un servidor de aplicaciones Webphere y listo, está disponible para los usuarios. Hay que mencionar que la propia herramienta de desarrollo de IBM provee ciertas funcionalidades para realizar pruebas, pero en el contexto de esta iniciativa hemos decido ir por un enfoque basado en herramientas de uso general, aunque no descartamos hacer algunos experimentos con estas funcionalidades de prueba.

Luego de un par de sesiones de trabajo hemos identificado 3 tipos de pruebas:

  1. Pruebas end-to-end usando Selenium Web-Driver, esto eso: las prueba es un script que utilizando un nagevador emula el comportamiento del usuario
  2. Pruebas de servicio, realizadas con SoapUI y que consumen los servios SOAP que están por detrás de las pantallas
  3. Pruebas unitarias de los componentes Java codeadas con JUnit.

Decidimos empezar por (2) porque parecía ser un win rápido y efectivamente lo fue. No encontramos mayores complicaciones en hacer estas pruebas.

A continuación empezamos a trabajar en (3) y como sospechamos la cuestión se tornó más difícil porque el código de los componentes Java que se invoca desde la herramienta case (un eclipse customizado) tiene dependencias a bibliotecas de IBM que no están disponibles en repositorios públicos. Para hacer estas pruebas también debimos “mavenizar” los proyectos de cara a poder correr las pruebas en el servidor de itegración continua.

Finalmente, nos queda pendiente probar la estrategia (1) personalmente no me inquieta mucho pues al fin y al cabo las pruebas de UI son algo en lo que no suelo confiar mucho por su costo de mantenimiento y su fragilidad. En dos semanas les cuento que tal nos fue con esto último.

Preparando MeMo2, 2019-2c

Luego un muy buen primer cuatrimestre tenemos la vara más alta para este segundo. A partir del feedback obtenido en las encuestas y las retros con alumnos y con el equipo docente tenemos en mente lo siguiente:

  1. Creemos que la dinámica general de la materia funciona muy bien, con lo cual la mantendremos y solo haremos pequeños ajustes en cuestiones puntuales.
  2. A pesar de que algunos ya confirmaron que no podrán, continuaremos con ex-alumnos en el equipo docente (se están sumando 4 nuevos colaboradores). Esto, además de ayudarnos con la carga de trabajo, también nos permite tener una mirada distinta dentro del equipo docente. Al mismo tiempo es un manera de formar futuros docentes.
  3. Mantendremos el stack de herramientas de soporte (eso es: Google Groups, Canvas Campus y GitLab) e intentaremos incorporar el uso de Kahoot.
  4. También mantendremos el stack de desarrollo con Ruby/Sinatra/Padrino, aunque actualizaremos a Ruby 2.5.1
  5. Renovaremos los ejercicios y el TP final, aunque muy posiblemente mantendremos el JobVacancy como TP1
  6. Vamos a realizar algunos ajustes en la dinámica de los ejercicios de programación individuales y en su corrección. Queremos que las correcciones y el feedback sean más uniformes. Para esto último tenemos que trabajar internamente para generar más guías y rubricas para las correcciones y también vamos a intentar implementar un mecanismo de revisión de correcciones entre los docentes.

Como para cerrar quiero destacar algunos puntos relevantes para quienes planeen cursar este segundo cuatrimestre de 2019:

  • La asistencia a clase es obligatoria y por ende la controlamos
  • La materia es intensa, require de una dedicación constante a lo largo de todo el cuatrimestre lo cual implica unas 8 horas semanales de trabajo extra-clase.
  • Si bien no tenemos el tradicional mecanismo de evaluaciones parciales en papel, el sistema de evaluación que utilizamos genera menos tensiones de parte de los alumnos, pero al mismo tiempo requiere mayor disciplina y dedicación.
  • Las clases comienzan 19.00 (puntual)
  • La primera clase será el Jueves 22/8, ¡no falten! la primera clase siempre es muy importante para setear expectativas)

Ingeniería de Software 2019 @ UNTreF

Este cuatrimestre será la primera vez que dictemos la materia en el contexto del nuevo plan de estudios. Esto implica ciertos cambios a nivel contenido respecto de lo que veníamos dando en años anteriores. Estos cambios tienen más que ver con cambios generales a nivel del plan de estudios que con cambios en el contenido particular de nuestra materia.

Más allá de los cambios de contenido, planeamos mantener la modalidad de cursada, eso es:

  1. Modalidad de aula invertida
  2. Como consecuencia del punto anterior hay una constante carga de trabajo fuera del aula (~6 horas semanales)
  3. Trabajo y evaluación constante a lo largo de toda la cursada

Según nos indica el sistema de inscripción, tendremos unos 10 alumnos, un excelente número para poder establecer un ambiente de confianza entre los alumnos y los docentes.

Las clases serán los días miércoles, de 18 a 22 horas (inicio puntual) en el aula 307 de la sede Caseros 1.