Agile 2017 Conference, day 4 & 5 notes

I started the day with the session “The pursuit of DevOps: 3 unique Microsoft journeys leading to a customer-focused path“, it was very interesting to hear real world experiences in first person.

Then I attended to the session “API Testing FUNdamentals” by JoEllen Carter and Dan Gilkerson. It was a hands-on session. Without any doubt it was the best session I attended in the whole conference.

In the afternoon I delivered my session “Infrastructure Patterns for Continuous Delivery“.

The day ended with the Conference Party at Pointe Orlando: drinks, food and live music!

The Friday was a short day, just the morning, in the first slot there were open space sessions and in the second: the closing keynote by Denise Jacobs. I can not say nothing about it because I didn’t attend because I was already on my way back home.

Anuncios

Estabilizando la velocidad

Durante las dos primeras iteraciones decidimos no puntuar las stories con un valor explícito de estimación. Simplemente a la hora de determinar el compromiso de la iteración utilizamos la tantas veces usada técnica de “estimación a ojo de buen cubero”. Pero ya en la tercera iteración el cliente nos pidió que puntuáramos las todas las stories del backlog para poder hacer una proyección. Así que eso hicimos, repasamos todo el backlog haciendo una estimación de mano (una variante del famoso planning pocker).

Adicionalmente al comienzo de cada iteración, repasamos los valores asignados a cada story  y de considerarlo necesario los volvimos a estimar.

La semana pasada completamos la sexta iteración y por primera vez entregamos exactamente lo que habíamos comprometido. Hasta entonces siempre habíamos tenido un pequeño delta positivo o negativo.

Comprometido vs. Entregado

Como se puede apreciar en el gráfico precedente la cantidad de puntos entregados por el equipo ha ido en aumento desde la iteración 4. Parte de ese incremento se debe a que las iteraciones 4 y 5 tuvieron días feriados en los que no trabajamos y que hicieron que dichas iteraciones fueran más cortas en términos de días trabajados.

En este momento estamos trabajando en la iteración 7 y el tamaño del compromiso tomado es bastante mayor a las iteraciones anteriores (75 puntos). Esto se debe a que se sumo una nueva persona al equipo.

Al finalizar la iteración 8 saldremos a producción. Yo hubiera preferido salir antes, pero resulta que estamos reemplazando un producto existente y ha sido muy difícil hacer un recorte de funcionalidad que nos permita salir antes sin impactar negativamente en el negocio.

Continuará…

Convocatoria de autores para el libro del AOC 2016

La semana pasada me informaron que mi postulación para el AOC había sido aceptada, con lo cual está confirmada mi participación en la conferencia.

La propuesta que envié como parte de mi postulación era para escribir un libro similar al del año pasado pero dando una vuelta de rosca sobre el contenido. El libro que escribimos (y publicamos) el año pasado era un compendio de experiencias.

Este año me gustaría que el libro sea un compendio de técnicas. Creo que existen en la actualidad diversas técnicas comúnmente utilizadas en el desarrollo de software que no están (hasta donde yo sé) formalmente documentadas en castellano. Me vienen a la mente técnicas como Impact Mapping y Mob-Programming. Al mismo tiempo creo que todo equipo luego de alcanzar cierto grado de “madurez” empieza a generar sus propias técnicas/prácticas/costumbres que bien pueden resultar de utilidad para la comunidad de practicantes. Me vienen a la mente el Delivery Map usábamos en Southworks y el ApplicationStatus que suelo utilizar en mis aplicaciones.

Por otro lado también quisiera hacer un cambio en la dinámica, me gustaría que este año lleguemos a la conferencia con todos los capítulos ya escritos, de manera que el tiempo dedicado en la conferencia sea para tareas de edición y revisión.

Con este artículo abro la convocatoria de autores para este segundo libro. Los interesados en sumarse a esta iniciativa por favor contactarse conmigo.

El desafio del Open Space

He tenido la oportunidad de participar de más de 20 Open Spaces de Agile, en diversas ciudades de Argentina, Latinoamética y Europa. Y si bien Open Space se ha convertido en mi formato favorito de conferencia, he observado un patrón que creo que le juega en contra. En todos los Open Spaces que he participado, he la gran mayoría de las sesiones han carecido de preparación previa, incluso en aquellos casos donde existía la posibilidad de proponer sesiones en forma previa a la conferencia. Esta “improvisación” (falta de preparación) a la hora de proponer sesiones, termina en muchos casos generando sesiones desordenadas o de “baja calidad”. Insisto en que no creo que esto sea una limitante del formato, sino una característica (negativa a mi parecer) de cómo la comunidad Agile utiliza este formato.

@acyment viene insistiendo desde hace un tiempo en que la conferencia Latinoamericana de Métodos Ágiles sea 100% Open Space. Personalmente apoyo esta idea pero considero necesario darle una vuelta de rosca a la cuestión para intentar asegurar sesiones “de calidad”. Como mencioné hace un tiempo, creo que el punto de partida es hacer el marketplace en forma anticipada con alguna herramienta web. Eso debería permitir que la gente proponga sus sesiones y también que reciba feedback de las mismas. Al mismo tiempo permite tener una idea general de los temas y oradores de la conferencia, lo cual suele ser muy importante para gente sin experiencia en Open Spaces.

La semana próxima tendremos la conferencia Ágiles Argentina 2015 en formato 100% Open Space y ya está disponible la plataforma para proponer sesiones asi que ahí vamos, a experimentar.

 

Cursos en la previa de Agiles 2015

Como de costumbre en la previa de Agiles 2015 habrá un conjunto de cursos organizados de forma independiente. En ese contexto estaré dictando en Montevideo mi Taller de Continuous Delivery y Prueba automatizada.

El términos generales el taller está divido en 2 partes. La primera enfocada en los conceptos centrales de la práctica de Continuous Delivery y un conjunto de técnicas y herramientas para su implementación que incluyen Jenkins, Puppet y Docker. La segunda se enfoca en la automatización de pruebas, lo cual constituye un punto fundamental en toda estrategia de Continuous Delivery. En esta segunda parte veremos herramientas tales como JUnit, Cucumber-JVM y FitNesse. Si bien el taller tiene una base conceptual independiente de toda tecnología, la parte práctica de automatización de pruebas se realiza con Java.

Los detalles de logística e inscripción están disponibles en la página de Evolución Ágil.

Prácticas DevOps: 3 repos por proyecto

Desde que empecé a trabajar fuerte con prácticas de DevOps, hace unos 2 o 3 años que todos mis proyectos tienen al menos 3 repositorios.

El primer repositorio es el que almacena el código fuente de la aplicación. En realidad dependiendo de la complejidad del proyecto, puede que haya más de un repositorio para el código fuente.

El segundo repositorio es el almacena la configuración de la aplicación. Este repositorio tiene típicamente un 1 branch por ambiente. Hay que destacar que estoy branches nunca se mezclan, sino que evolución a la par. Cuando la aplicación requiere de un nuevo parámetro de configuración, el mismo debe ser agregado simultáneamente a cada uno de los branches con el valor correspondiente para el ambiente asociado.

Finalmente el tercer repositorio es el que contiene los scripts de deploy. Dependiendo de la infraestructura del proyecto puede que sean simplemente scripts de bash, ansible, puppet o similar.

Premisas para reuniones de revisión

Quiero compartir algunos premisas básicas que utilizo intento utilizar en mis reuniones de revisión (iteration review).

Todo el equipo

En la review está presente todo el equipo, ya sea para llevarse halagos o críticas.

Ambiente limpio

La revisión no se realiza en un ambiente desarrollo sino en un ambiente de review/demo, el cual es un ambiente “limpio” y donde el producto queda disponible incluso después de finalizada la reunión para que el responsable de producto y los stakeholders puedan acceder a su gusto en cualquier momento ya sea para realizar demostraciones a terceros, pruebas exploratorias o simplemente para consulta.

La review no se mueve

La reunión de revisión se agenda al comienzo de la iteración y no se posterga por retrasos de parte del equipo de desarrollo. La reunión se realiza y se muestra lo que se tiene, si parte del compromiso no llegó a completarse, no importa, hay que dar la cara y decir que no se llegó. La reunión puede moverse si el responsable de producto o los stakeholders tienen un imprevisto, pero NO puede moverse por funcionalidades incompletas.