Mes: agosto 2019

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.

Optimizando el pipeline de deployment

Esta semana empezamos a trabajar con @CodeRaguet y Maxi Cruz en la tarea de optimizar el pipeline de deployment. Actualmente tenemos un pipeline de deployment que hace lo siguiente:

  1. Ante cada cambio en el repositorio obtiene el código
  2. Compila y corre las pruebas unitarias
  3. Despliega a un ambiente que «de integración»
  4. Corre las pruebas de aceptación
  5. Publica los artefactos
  6. Publica los pactos (pact)
  7. Despliega a un ambiente «de demo» donde la aplicación queda disponible para pruebas manuales

La ejecución de este pipeline insume actualmente ~45 minutos y el ~85 % de ese tiempo de ejecución lo consume el paso 4: la ejecución de los tests de aceptación.

Este pipeline representa la primera parte del camino hacia producción y se ejecuta varias veces al día ya que el equipo hace trunk-based development (todos trabajan en master). A continuación de este pipeline hay otro que se dispara manualmente que cubre los ambientes de tests y producción.

Un detalle no menor de esta situación es que si no hacemos nada esta situación va a empeorar gradualmente porque el producto está en constante evolución y todo el tiempo se van a agregando nuevos tests.

El desafió que enfrentamos es reducir el tiempo que insume este pipeline y por ende el tiempo que insume la ejecución de las pruebas aceptación. La estrategia que vamos a intentar implementar es: segmentar los tests de aceptación por grupos de funcionalidades y luego ejecutar cada grupo en paralelo.

En una semana les cuento como nos fue.

Cierre MeMo2 2019-1

Se fue un cuatrimestre más y es momento de análisis. Comencemos por los fríos números:

  • 32 inscriptos (34 formalmente pero 2 nunca asistieron a clase)
  • 3 abandonos antes de la sexta semana
  • 23 alumnos completaron la materia con promoción
  • 5 alumnos pendientes de final
  • 19 tareas individuales (11 cuestionarios y 5 ejercicios de programación)
  • 2 TPs grupales
  • 1 visita de la industria
  • Evaluación general de la materia: 8.9 (según encuesta interna)
  • Opinión general de la materia: 4.6 (según encuesta del departamento)
  • Claridad de los docentes (según encuesta interna): 4.8 / 5
  • Conocimiento de los docentes (según encuesta interna): 4.9 / 5
  • Dinámica de clases (según encuesta interna): 4.5 / 5
  • Materiales de estudio (según encuesta interna): 4.3 / 5
  • Dedicación promedio extra clase (según encuesta interna): 8 hs. semanales

Por otro, más allá de los números la sensación es muy positiva. Basado en el feedback recibido tanto en las encuestas como en las retrospectivas creo este resultado es consecuencia de 3 puntos destacados:

  • Un cambio de orden en los temas de la materia poniendo más foco inicialmente en cuestiones de programación. Esto a mi parecer facilitó en entendimiento de los temas de proceso y el desarrollo de los TP grupales.
  • La incorporación de ex-alumnos al equipo docente. Si bien una ex-alumna había colaborado en algunas cuestiones el cuatrimestre anterior, esta vez con contamos con varios ex-alumnos que colaboraron a lo largo del todo el cuatrimestre.
  • La temática del TP final que incluyó el desarrollo de un Bot de Telegram. Creo que esto generó cierta motivación entre los alumnos.

No están en la foto los ex-alumnos que participaron como colaboradores: Jessica, Josefina, Anarella, Facundo, Pablo y Martín.

Experimento consultorio

Experimento consultorio

Hace un tiempo me contactó un directivo de una organización para que ayudara a mejorar cuestiones de calidad en sus equipos. Pero a mi parecer los equipos no estaban tan interesados en mejorar esos aspectos que me planteaba el directivo. Me pasó varias veces que luego de haber acordado reunirme con un equipo, me cancelaron a último momento. Es así que luego de un par de actividades (algunas de ellas fallidas) acordamos comenzar esta semana con un nuevo experimento: el consultorio.

La idea es simple: yo voy a estar recurrentemente una tarde por semana en las oficinas de este cliente para atender consultas de sus equipos. Esas horas recurrentes son take or pay, o sea: se cobran haya o no consultas. Esto pone «cierta carga» del lado del cliente en generar consultas/actividades para que esas horas efectivamente se utilicen. Por mi parte, este esquema me permite planificar mi tiempo sin correr el riesgo de «perder horas» por cancelaciones de último momento.

Si este esquema funciona ese espacio de consulta debería disparar acciones concretas dentro de cada equipo. Si la cuestión no puede resolverse en el tiempo de consulta entonces agendariamos sesiones adicionales.

Sinceramente no estoy muy convencido esto vaya a funcionar pero bueno, es un experimento, sino al cabo de un par de semanas no funciona, se ajusta o se cancela.