XPConf 2016: Day 2, our workshop

We were a bit worried because we didn’t know how many people would attend our workshop. The conference agenda for that day was full of interesting sessions and attending to our full-day workshop would imply missing all those sessions.

To our surprise we started the session with ~15 participants! After the ice-breaker activity we shared the full set of activities we had plan for the session and asked the participants to vote them, so we can concentrate in those more interesting for the audience. After voting, the final plan was not very different to what had prepared.

During the morning we presented our vision of XP «new practices» and drilled into one of them: Infrastructure as Code. These two topics generated some interesting discussion.

Before taking a break we checked with the audience how to continue. At that point some people left the session, but about the half decided to complete the workshop. So after a 30 minutes break we we jumped into Continuous Delivery, we reviewed the main concepts and we did a demo.

The next topic was User Story Mapping which only one of the participants knew about. We presented the technique and then we put it in practice.

The latest topic was Specification by Example, we explained the technique and put it in practice using Cucumber-JVM and working a «enterprise-like» application we built for the occasion. We work on a set of stories identified in the Story Mapping. For each of them we provided a ser of rules and asked the participants to work in pairs to write examples, validate them with US and them implement them.

As usual, at the end we asked for participant to rank the workshop and we get 4.3 out of 5 which for us was great! Here are some quotes form participants:

I really appreciated seeing Story Mapping and BDD in action –  especially the continuity between the two because they used the same example project.

 

Certainly a lot of valuable things covered and I learned a lot.

 

Definitely worth attending!

Here are some pictures and here is the slide deck we used (it does not have much information and because of that we are writing an booklet some participants can drill down in the different topics)

DSC05746

DSC05747

DSC05748

 

 

XPConf 2016: Day 1 summary

The journey started with a very interesting keynote by Elizabeth Hendrickson who shared how they at doing XP at scale in Pivotal Labs.

After that I went to the session Symbiotic Design Practices by Michael Feathers.

In the afternoon I attended the session Example Mapping by the Cucumber guys. The session was very interactive and I really liked the approach proposed by Matt and Steve (the guys in charge of the session). I will share my info about this session in a future post.

My next session was a Panel where some «agile rock starts» discussed about the Agile Hype. The session was fine but at a certain point I felt it was not adding value to me, so I left the room and went into the hall to do some networking.

At 6 PM I joined the Open Space Marketplace where I proposed a Smalltalk Introductory session for that same day.

At the 7 PM there was a nice Whisky Tasting activity and right after that I went back to the open space to join a session about Mutation testing. Next to it, was my Smalltalk session. Seven guys joined the session and we did a walkthrough over Pharo Smalltalk that took about one hour. By the end of the session it was almost 10 and I went to my room to review some stuff for the workshop I had to run the next day.

DSC05744
Elisabeth Hendrickson’s Keynote
DSC05745
Example Mapping Session

About our Modern XP tutorial @ XPConf 2016

Today we (@dfontde and me) will held this workshop that is focused on a set of practices we consider have take the main stage in software development over the last couple of years.

During morning we will review the foundations of XP and we will share a backlog creation technique called User Story Mapping.

In the afternoon we will continue with Infrastructure as Code, BDD, DevOps and Continuous Delivery. For this second part we will work with Java, Cucumber, Jenkins and Ansible.

Even when the workshop is full-day we invite xpconf participant to join either in the morning or in the afternoon. We think the workshop is great resource for those just starting with agile and also for those that are already practicing it but that would like to get familiar with the mentioned practices.

The workshop is based on our Software Engineer course at UNTreF University and we have already run it a couple of times with very good results.

XPConf 2016: Pre-conference (day 0)

Day 0 is DONE. There was a set of pre-conference workshops. I attended to «Software Faster» full-day workshop facilitated by Dan North.  Another workshops I considered before making my mind were: Mob Programming (Woody Zuill) and Exploratory Testing (Elisabeth Hendrickson).

The workshop was useful, the main takeaways points for me were:

  • some techniques to deal with legacy code
  • a set of activities to experiment in my classes at the university
  • a list of reading

After the workshop there was an ice-breaker activity sponsored by Head Resourcing with some drinks & snacks and finally we had the «Dinner with an agile stranger» sponsored by Headforwards.

DSC05743
Software Faster Workshop by Dan North

 

El camino freelance, parte 4: contratos

Muchas veces cuando trabajamos como ingenieros/programadores en un esquema de relación de dependencia no le prestamos mayor atención a las cuestiones contractuales. «Alguien» consigue los proyectos ya sea canalizando pedidos/necesidades de otras áreas (si desarrollamos software in-house) o bien vendiendo a algún cliente (si somos una software factory). Pero si vas a trabajar por tu cuenta deberías al menos tener algunos puntos presentes para encarar tus proyectos.

En términos generales y de forma muy simplificada existen dos tipos de contratos: los llave en mano y los Time&Materials.

En un contrato llave en mano, se define el proyecto completo antes de comenzar fijando el alcance del software a entregar y uno cobra un monto fijo también establecido al comienzo del proyecto por entregar la pieza de software en cuestión. Esta forma de contratación es muy común en construcciones civiles pero llevada al software muchas veces suele traer algunos inconvenientes por el simple hecho que suele resultar complejo determinar el alcance en forma temprana e incluso cuando se logra hacerlo siempre aparecen cambios y de la mano de ellos la necesidad de revisar el contrato.

En un contrato Time&Materials no hay un alcance fijo, sino que el alcance se ajustar sobre la marcha pero lo que se fija es un precio/hora. De esta forma el manejo de cambios es mucho más simple. El tema con esta forma de contratación es que uno como proveedor debe trabajar mucho más enfocado pues el cliente está pagando por cada momento que invertimos en el proyecto y por ello en cierto modo tenemos una responsabilidad mayor en asegurar que nuestras actividades agregan valor. No es que trabajando llave en mano uno no tenga responsabilidad, pero justamente al ser llave en mano, todo riesgo de retrasos lo estamos asumiendo nosotros (típicamente) sin impactar en los costos del cliente.

Estas dos modalidades representan dos extremos en los distintos esquemas de contratación dando lugar en el medio a infinitos posibles esquemas más cerca de uno u otro extremo.

Personalmente (freelance o no) me inclino a trabajar en un esquema Time&Materials. Más aún, desde que trabajo en forma independiente todos mis trabajos hasta el momento han sido con un esquema Time&Materials. Ahora bien, para que un proyecto en esta modalidad llegue a buen puerto creo que hay un par de puntos fundamentales que trataré en el próximo post.

Continuará…

Tablero Integrado de Equipo

Me uní a mi equipo cuando este ya llevaba varios meses trabajando en el proyecto. Una práctica que me sorprendió es que todo el código de la aplicación pasa por una revisión de pares utilizando merge-requests. Personalmente prefiero el pair-programming a las revisiones de código pero ese es tema de otro post. El punto aquí es que esta forma de trabajo nos lleva a que frecuentemente se nos acumulen merge-request esperando a ser revisados y retrasando el flujo de entrega. Al mismo tiempo ocurre que el autor del merge-request no puede dar por cerrada la story y para no estar ocioso comienza a trabajar en una nueva story aumentando así el work in progress (wip). Punto aparte.

El fin de semana estaba leyendo el capítulo de Visual Management de @SolePinter y de repente se me ocurrió que si tuviéramos esta información bien presente al alcance de la mano eso podría ser un buen primer paso para la solución del problema. Como el equipo está distribuido, el tablero físico no iba a funcionar así que aprovechando que hacía rato que no programaba Ruby me senté y me dí el gusto de programar un tablero digital que muestra en una misma pantalla la cantidad de merge-request activos en todos nuestros repositorios, la cantidad de tareas en curso en nuestro backlog (consultando Trello) y algunas otras cosillas. Además de consultar la información tiene cierta lógica para actuar de semáforo, pintando de rojo o verde cada indicar dependiendo de cierto límites pre-configurados.

tid_v1

Si vemos que esto funciona es posible que siga agregando funcionalidades al tablero y en una de esas tal vez lo comparta para que lo usen otros equipos.

Nuevo libro: Herramientas Ágiles

Durante el AOC 2016 repetimos la experiencia del AOC 2015 y escribimos un libro y es justamente ese segundo libro el que ahora está disponible.

El primer libro trató sobre relatos de experiencias del uso del métodos ágiles. Este segundo libro trata sobre técnicas, lo cual me parece en cierto modo una camino natural: primero uno hace, experimenta, luego a partir de la experiencia repetida, generaliza dando origen a técnicas aplicables distintos contextos.

El libro está disponible en forma totalmente gratuita en diversos formatos digitales en la plataforma GitBook y también está disponible en forma físico en la plataforma Hesiodo (el formato físico no es gratuito).

¡Mis felicitaciones y agradecimientos a todos los autores por sumarse a esta iniciativa y lograr este nuevo entregable!

herramientas_agiles

El camino freelancer, parte 3: la mejor parte

Cuando empecé a recorrer este camino lo que más valoraba era la libertad horaria. Con el correr del tiempo comencé a valorar otros aspectos, todos ellos relacionados con la posibilidad de elegir: elegir mis proyectos, elegir mis clientes, elegir mis compañeros de trabajo, elegir la fecha y extensión de mis vacaciones.

Obviamente a la hora de elegir uno debe poner diversos factores en la balanza: expectativas económicas, motivación, finanzas, valor estratégico, diversión, seguridad, probabilidad de éxito, etc, etc. Lo bueno es que es uno mismo quien realiza la ponderación de cada uno de esos factores.

En este sentido si estas pensando en comenzar tu camino freelancer podrías ir pensando cuales sería tus criterios para elegir tus proyectos.

Continuará…

Time to learn Smalltalk: big opportunity

A while ago Stef and his troop started working on a MOOC (massive online open course) about Pharo Smalltalk.

The course is finally live and its formal name is Live Object Programming in Pharo.  The course content is very interesting because it goes far beyond Pharo Smalltalk. Of course it covers Pharo/Smalltalk syntax but it also covers OOP foundations and how OOP mechanisms are implemented in Pharo.

I think this course is a great opportunity for all those programmers who are not familiar with Smalltalk and specially those that are only familiar with static-type languages (like java and c#), believe me: Smalltalk will blow your mind!

The course started last week, but don’t worry it is seven weeks long so you are on time to join, just register here.

pharo_mooc

 

Jenkins 2 ha llegado

Así es, Jenkins 2 finalmente está aquí. Según se cuenta en el sitio oficial los puntos destacados de esta nueva versión mayor (major release) son:

  • Soporte nativo para delivery pipelines
  • Mejoras de usabilidad
  • Completa compatibilidad con versiones anteriores

Tuve la oportunidad de verificarlos cuando pasé uno de mis proyectos a la versión pre-release que Jenkins publicó hace un tiempo. Adicionalmente a esto noté:

  • «Independencia» de Maven, lo pongo entre comillas porque no estoy seguro que el término apropiado sea independencia. Lo que noté es que en la versión anterior, al crear un nuevo job existía la opción «proyecto Maven», cosa que ya no existe. Creo que inicialmente esto tenía sentido pues Jenkins había surgido en el mundo Java, pero en los últimos años creo que ha transcendido ampliamente el mundo Java y se ha convertido en la herramienta de-facto para integración continua.
  • Integración con Gradle para la definición de los pipelines, los cual tiene mucho sentido ya que Gradle es una herramienta que se posiciona como herramienta de build genérica capaz de buildear proyectos en distintos lenguajes.
  • Se removió el soporte nativo para repositorios CVS, quedándo nativamente soporte solo para Git y Subversion.

Más allá de estos puntos, un detalle que me llamó positivamente la atención fue que como parte del proceso de instalación, se ofrece instalar un conjunto de plugins que son los más comunmente utilizados por la comunidad.

A partir de esta nueva versión de Jenkins y de algunas charlas que he tenido con mi equipo actual de proyecto he decido empezar a trabajar en la preparación de un curso de Jenkins para dictar en Julio o Agosto.