XP2018, day 2 summary: I ‘m Kent, I ‘m back

First of all, let me explain how the conference was organized: the conference was divided into 3 parts, Monday tutorials + Main conference (Tuesday+Wednesday+Thursday) + Friday tutorials. Participants could choose to attend to each of these parts independently. What usually happens is that most of the people attend to the main conference.

On Tuesday the journey started with the keynote speaker Laurie Williams, a well-prepared talk about Security and DevOps. After the keynote we have the coffee break and next the Open Space.

The Open Space Marketplace was facilitated by Charlie Poole (NUnit core team), it was in the park of the faculty, we were all standing in a circle with Charlie in the center using the microphone. I was in the queue to propose a session, when a big guy with a black cap took the microphone and said: «Hi, I ‘m Kent, I ‘m back…«, it took me a while to realize that the guy was Kent Beck.

During the afternoon I attended to the panel:»Agile Development in a Mission Critical World» and the sessions «Ship it or It Never happed: the power of Docker, Heroku and CircleCI» and «DevOps as an Enabler for More Efficient Testing in Large-Scale Agile Projects«.

In the last slot of the journey it was our turn, me and Diego presented our research work: «Technical and Organizational Agile Practices: A Latin-American Survey«. Here are the slides of our presentation.

Once all the sessions were over, we attended to the social activity of the day: the visit to a cellar. We had a brief explanation about Oporto Wine and after that we had an awesome reception with a beautiful view of the city.


XP2018, day 1 summary

This first day was completely dedicated to workshops. I started the day delivering my tutorial on DevOps Practices. During the afternoon I split my time between the session «To Swarm or Not to Swarm (Programming and Review Simultaneous in Pairs)» and the session «Automatic Refactoring Implementation With TDD and Meta-Programming» delivered by my colleague Hernán Wilkinson. The day ended sharing some drinks with all the participants in the café area.

For me it was a great journey because beyond the sessions I was able to meet several colleagues with whom I have collaborated lately like Martin Kropp and Philipp Diebol and some other that I meet in previous editions of the conference like Juan Garbajosa and Wouter Lagerweij.

Regarding my tutorial, there was 9 participants and the general evaluation was 4 out of 5. Here are the slides I used. I am very satisfied with the tutorial.

I close this post with a photo of «la banda Argentina«: Diego Fontdevila, Hernán Wilkinson, Nico Paez, Ignacio «Code» Raguet and Marcelo Talamona

Sobre los trabajos finales de carrera

Reciente algunos alumnos vinieron a consultarme para que los dirija en la realización de sus trabajos finales de carrera. Luego de repetir los mismo por tercera vez decidí ponerlo por escrito.

Mi condición para dirigir un trabajo es que el desarrollo del mismo se haga bajo las siguientes condiciones:

  • El trabajo se plantea como un proyecto de alcance variable, esfuerzo fijo y calendario ajustable (pero no mucho). El esfuerzo está dado por lo que determina el reglamento de la institución. Respecto del calendario, la institución suele poner un tiempo límite pero en general es mucho mayor del necesario. Adicionalmente mi idea de calendario es que el trabajo esté listo en un plazo máximo de medio año.
  • No dirijo trabajos de alumnos que no hayan sido alumnos en alguna de mis materias. El trabajo final es un proyecto «one-shot», y la dupla alumno-director es en cierto modo como un equipo.  Resultaría muy arriesgado para un proyecto one-shot formar equipo con gente que no se conoce previamente.
  • Desde el punto de vista metodológico trabajamos a lo XP con iteraciones semanales.
  • A partir del momento que se inicia el desarrollo, se trabaja a un ritmo constante durante un período de ~16 semanas (un cuatrimestre).
  • Previo al comienzo de desarrollo hay un fase de setup/envisioning de aproximadamente 1 mes (a esfuerzo variable)
  • Una vez completado el desarrollo, hay un período de ~1 mes para terminar de redondear las cuestiones formales para la presentación del trabajo.

Para empezar recomiendo a los alumnos crear un GoogleDoc y empezar a escribir la propuesta de trabajo, no toda la propuesta pero si la parte de lo que sería la visión de proyecto.

Materiales de la charla en Madriagil

El miércoles pasado estuve dando una charla en el meetup de Madriagil en las oficnias de RyanAir Madrid.

Agradezco a Israel Alcázar por la coordinación y a David Cuesta por ser anfitrión de este encuentro

Hubo alrededor de unos ~20 participantes. La evaluación general de la charla fue de 4.1/5.

Los slides de la utilizados durante la presentación está disponibles aquí.

Comparto aquí algunas fotos del encuentro.

DevOps Practices Tutorial: Preparation Instructions

My DevOps Practices Tutorial covers a set of tools that my not be easy to setup, so I created a Vagrant configuration to simplify this setup. It does not matter if have no idea about vagrant (you will learn about it during the tutorial) but ensure to perform the following tasks before attending the tutorial session:

  1. Install Git
  2. Install Virtual Box (version 5 o newer)
  3. Install Vagrant (version 2 o newer)
  4. Download this vagrantfile and place it in a directory
  5. Open a terminal and move to the directory where you placed the vagrantfile
  6. Run the command vagrant up, it will download some stuff from the cloud, so it may take some time (depending on your connection it could take around ~10 minutes)
  7. When the vagrant up completes, you should the message «Welcome to NicoPaez DevOps tutorial»

Estudio sobre la comunidad ágil de latam: paper aceptado y publicado

Tiempo atrás comenté que habíamos enviado el paper resultante de nuestro trabajo investigación a la International Conference on Agile Software Development (informalmente llamada XP Conf). Dicho trabajo fue aceptado y estaremos presentándolo la semana próxima en Porto, lugar donde se lleva a cabo la conferencia.

Comparto aquí de modo muy resumido los hallazgos más relevantes del trabajo:

  • Las prácticas organizacionales son mucho más usadas que las prácticas técnicas.
  • La cantidad de prácticas utilizadas aumenta con la mayor experiencia de la organización en el uso de métodos ágiles.
  • La diferencia entre la cantidad de prácticas técnicas y la cantidad de prácticas organizacionales disminuye a medida que aumenta la experiencia de la organización en el uso de métodos ágiles.
  • Las variables tamaño de equipo y duración del proyecto no tienen impacto en la cantidad de prácticas utilizadas.

Si bien puede que estas conclusiones parezcan evidentes, la realidad es que no había prueba científica de esto y eso es precisamente lo que generamos con este trabajo.

El trabajo está disponible en forma abierta en el sitio de Springer.

Quiero agradecer a todos aquellos que colaboraron con este estudio completando la encuesta y en particular a Juan Gabardini, Soledad Pinter, Emilio Gutter, Federico Zuppa, Thomas Wallet, Natalia Baeza y tantos otros que nos ayudaron en la difusión de la encuesta y en la validación de algunas ideas.

HOY: Patrones de Infraestructura para Continuous Delivery

Esta tarde a partir de las 18.50 estaré en la oficinas de RyanAir Madrid, exponiendo sobre esta temática.

De paso, voy a aprovechar el contacto con la comunidad ágil de Madrid para hacer difusión de algunos libros «Made in Argentina». Voy a estar sorteando entre los participantes algunos ejemplares de «Construcción de Software, una mirada ágil» y «Experiencias ágiles, relatos de experiencias del uso de métodos ágiles en Argentina».

Si están por Madrid y quieren sumarse, la entrada es gratis pero es necesario registrarse aquí.

Promediando el cuatrimestre en AyDOO @ UNTREF

Hemos completado la séptima semana de clase de Análisis y Diseño Orientado a Objetos en UNTreF. Este cuatrimestre viene con varias novedades.

En primer lugar tuvimos un cambio de equipo el cual esta conformado por: Diego Marcet (egresado de FIUBA con quien tuve el gusto de trabajar profesionalmente en diversas ocasiones y que está definitivamente en mi Dream Team) y Lucas Campaner (estudiante de UNTreF y uno de los mejores ex-alumno de la materia).

Otra novedad fue el cambio de la herramienta de soporte, comenzamos a utilizar Canvas LMS, una herramienta que yo ya venía utilizando en otras materias.

Finalmente la novedad a mi parecer más importante es el cambio en la dinámica de la clases. Este cuatrimestre estamos dividiendo la clase en 2 partes. En la primera vemos algo de teoría, atendemos consultas o resolvemos algún ejercicio en forma conjunta utilizando el proyector. En la segunda nos dedicamos a programar. Planteamos alguna consigna y programamos en grupos de tres, haciendo lo que podríamos denominar como «trio-programming» (o pair-programming con trios en lugar de pares). Al mismo tiempo los docentes vamos rotando por los equipos atendiendo dudas, debatiendo diseños y programando.

Esta semana, hicimos un retrospectiva con la intención de tener un feedback formal de los alumnos y detectar oportunidades de mejora. El feedback fue muy positivo y los alumnos destacaron el hecho de programar en clase. Entre los puntos accionables que salieron de la retrospectiva están:

  • Tener una semana sin tareas. En la dinámica que llevamos los alumnos tienen tareas todas las semanas lo cual hace que la materia tenga un ritmo intenso. Suele ocurrir (como en cualquier contexto de aprendizaje) que los alumnos deben reentregar alguna tarea y eso complica aún más la dinámica ya de por si intensa. En ese contexto los alumnos sugirieron tener una semana sin tareas para que quienes estén adeudando algo puedan ponerse al día.
  • Mejorar el material de estudio sobre diagramas de secuencia que actualmente resulta insuficiente.
  • Ajustar el tiempo de requerido por la materia y la dinámica de reentregas. Si bien en nuestro diseño de la materia esperábamos una dedicación extra-clase de 6 horas semanales, los alumnos reportaron estar invirtiendo unas 10 horas. Parte de las cuales resulta consecuencia de las múltiples reentregas que tienen algunas tareas. En este sentido acordamos que cada tarea tendrá solo una reentrega.