Mes: junio 2015

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.

Dos tipos de Review

Continuando con la cuestión de la reunión de revisión, ayer hablaba con Charly Paez sobre dos tipos bastante distintos de reuniones de revisión las cuales a mi entender son consecuencia del nivel de participación del responsable de producto a lo largo de la iteración.

Caso de poca participación

En estos casos el contacto entre el equipo de desarrollo y el responsable de producto ocurre en (unos pocos) momentos muy puntuales a lo largo de la iteración: la reunión de planificación, algún mail de validación, alguna reunión de refinamiento y la reunión de revisión. El equipo de desarrollo trabaja en las funcionalidades y consulta  al responsable de producto pero recién presenta la funcionalidades terminadas en la reunión de revisión. Esto hace que la reunión de revisión sea una presentación del equipo de desarrollo hacia el responsable de producto. A veces esta reunión de revisión trae sorpresas y se extiende más de una hora.

Caso de mucha participación

En estos casos la interacción entre el responsable de producto y el equipo de desarrollo es mucho más frecuente y fluida. Al mismo tiempo el equipo desarrollo no espera al final de la iteración para mostrar/validar las funcionalidades desarrolladas. Sino que a medida que las funcionalidades van siendo desarrolladas/completadas el equipo las va validando con el responsable de producto. Más aún, el responsable de producto tiene una participación muy activa en las pruebas de aceptación. Esto que hace que el responsable de producto llegue a la reunión de revisión sabiendo de antemano con qué se va a encontrar y habiendo ya usado las funcionalidad que se va a presentar. En estos casos la reunión de revisión tiene un sentido distinto. Ya no tenemos al equipo presentando el producto al responsable de producto (pues este ya lo vio) sino que tenemos al responsable de producto presentando el producto al resto de los stakeholders.

Personalmente cuando puedo elegir, elijo sin dudas este segundo tipo de revisiones ya que cuando pude utilizarlo el resultado de nuestro trabajo tuvo muchísimo más impacto en la organización. En realidad no creo que el impacto sea consecuencia del tipo de revisión sino al contrario: el proyecto era de alto impacto, eso hizo que el responsable de producto tuviera un gran involucramiento en el proyecto y eso derivó una excelente interacción con el equipo de desarrollo y en reviews del segundo tipo.

Continuará…

(no me gustan los nombres que le puse a cada tipo de review, si alguien mejores propuestas, son bienvenidas)

La reunión olvidada: Iteration Review

En el desarrollo (ágil) de software actual hay 3 reuniones bien establecidas: iteration planning, iteration review y retrospectiva. (nota: si bien esta es la terminología propuesta por Scrum no estoy hablando particularmente de Scrum sino de desarrollo ágil en general)

Hay libros enteros dedicados a planning y también los hay dedicados a retrospectivas, pero no ocurre lo mismo con reviews. Al mismo tiempo he visto consultores/facilitadores colaborando en reuniones de planning y retrospectiva (retrospectivas sobre todo) pero no ocurre lo mismo con las reviews.

Curioso ¿no?. ¿Simple casualidad? Mmm, no creo.¿Será que la review es menos importante? No ¿será que la review es más fácil? Mmmmm, no creo. @egutter me dice que es porque la review es anterior al desarrollo ágil y al mismo tiempo la agilidad no ha introducido grandes cambios en esta reunión, como si lo ha hecho en la planning. Esta justificación me resulta bastante convincente.

Mientras escribo estas líneas caigo en la cuenta que en mi propio libro hay capítulos dedicados a planning y retrospectivas pero no dedicado a reviews, ¡Ja!

Personalmente la mayoría de las veces que he asistido a reviews ajenas (o sea de proyectos/equipos en los que no estaba involucrado) me fui decepcionado. Reuniones empezando tarde, demostraciones inentendibles (o directamente fallidas), usuarios/stakeholders ausentes, incluso miembros del equipo ausentes, pérdida del foco de la reunión, horario de finalización incierto, entre otras cuestiones.

Para mi la review es una reunión clave. O tal vez LA REUNION CLAVE. En la planning el equipo asume un compromiso pero es en la review donde se ve el resultado de ese compromiso. Es en la review donde tenemos la posibilidad de deleitar a nuestros stakeholders. Es en la review donde se juega la continuidad del proyecto.

Es por esto que en mi materia de ingeniería de software dedico una clase para que mis alumnos entiendan la importancia de esta reunión y sepan como prepararla y guiarla apropiadamente. Al mismo tiempo como parte de la materia los alumnos tienen que realizar al menos 4 reviews y su desempeño en esas reviews tiene impacto directo en la aprobación de la materia.

Continuará…

Sobre el TP final de algo3 (2015-1)

A fines de mayo lanzamos el TP final de Algo3. En el curso de los miércoles tenemos poco más de 30 alumnos repartidos en equipos de 3 integrantes, cada equipo con un docente tutor. En mi caso soy tutor de 4 equipos.

Este cuatrimestre el trabajo prácticos se llama AlgoCraft y como su nombre lo sugiere es una variante del clásico juego StarCraft.

Como de costumbre desde el comienzo del trabajo práctico configuré un Jenkins para que los alumnos pudieran hacer integración continua. Esto también me permite tener métricas de su trabajo. Este cuatrimestre incorporé PMD al conjunto de tareas ejecutadas en el proceso de integración continua. PMD es un herramienta que entra en la categoría de «Linter» y como tal, lo que hace es analizar el código fuente realizando un conjunto de verificaciones relacionadas al cumplimiento de estándares y buenas prácticas de programación del lenguaje en cuestión.

algo3_20151

Reflexiones sobre XP 2015

Como ya mencioné (y también resumí) estuve participando de la conferencia internacional de Extreme Programming: XP 2015. Esta conferencia tiene algunas particularidades que la distinguen bastante del resto de las conferencias sobre métodos ágiles.

En primer lugar es la conferencia de Agile con mayor historia, este año fue la edición 16. Vaya curiosidad: la primer edición de la conferencia fue incluso antes de la publicación del manifiesto ágil.

En segundo lugar es una conferencia con un fuerte involucramiento académico. En la organización de cada edición hay siempre una universidad anfitriona. Al mismo tiempo la conferencia ofrece tanto sesiones «industriales» (presentaciones informales) y sesiones académicas (presentaciones formales de papers de investigación).

Durante mi participación en esta última edición tuve la oportunidad de hablar con algunos de los organizadores y conocer algunas cuestiones interesantes sobre la organización. Existe un steering committee que se encarga de asegurar la realización de la conferencia año tras año. Dicho steering committee está conformado principalmente por los chairs de las ediciones anteriores de la conferencia.

Hablando de esta edición particular (que es la primera en que participo) hay algunos puntos que quiero destacar:

  • La organización fue impecable. El centro de conferencias ofrecia unas instalaciones muy apropiadas para la dinámica del evento.
  • Días antes de la conferencia recibí un mail con información muy útil para los extranjeros: medios de transporte para llegar al centro de conferencias, pronóstico del tiempo para los días del evento, información de contacto, y recomendaciones de vestimenta, entre otros.
  • Adicionalmente como orador recibí otro mail con recomendaciones para preparar mi sesión.
  • Cada sesión tenía un chair asignado a quien los oradores debíamos contactar previamente a nuestra sesión. El chair obviamente estaba presente durante todas sus sesiones para presentar a los distintos oradores, moderar las preguntas de los asistentes y asistir al orador en lo que este pudiera necesitar.
  • La conferencia contaba con una app (android) oficial del evento que permitía acceder al programa de la conferencia, agendar sesiones, compartir mensajes entre los asistentes de la conferencia y también el envió de notificaciones de parte de la organización del evento.
  • Una vez finalizada la conferencia se envió una encuesta sobre el evento para completar online. La misma pedía feedback sobre la conferencia y recomendaciones para futuras ediciones. (más allá de esto en el cierre de la conferencia se hizo una retrospectiva con todos los presentes)

Si bien puede que algunas de estas cuestiones ya las haya visto en otras conferencias, la realidad es que esta vez (posiblemente por estar en un país totalmente desconocido y tan distante) me llamaron mucho más la atención.

xp2015_badge

XP2015: Day 5 Summary

This was the last day of the conference and it was dedicated to workshops (academic and industrial**). I started the day in the Refactoring (academic) workshop and after coffee break I switch to the Retrospectives (industrial) Workshop by Paulo Caroli which was one of the best sessions I attended in the whole conference. Paulo shared many techniques to plan/guide retrospectives, many of them are documented in his book Fun Retrospectives.

After the lunch it was the time to delivery my BDD Tutorial, a technical hands-on session where we reviewed the BDD technique and several implementation details with tools like Cucumber-JVM, Fitnesse and JBehave. Everything went as expected, no major issues with the technical stuff, all participant were able to run the Virtual machine I created for the tutorial. I am very happy with the results and I think I will plan to run it again in South America before the end of the year.

DSC04944

 

** academic workshop are basically presentation and discussions about formal research papers while industrial workshops are totally different, they are interactive sessions where the audience listen and do.

Agiles 2015: Diseño del proceso de selección de propuestas

Este año al igual que los años anteriores la conferencia contará con un conjunto de sesiones que surgirán de una convocatoria abierta (dicha convocatoria ya está en curso). Dado que tenemos una cantidad limitada de tiempo y espacio para sesiones, tenemos que seleccionar cierta cantidad de sesiones de entre todas las propuestas recibidas. Estimamos que tendremos espacio para entre 30 y 40 sesiones. Para elegir esas sesiones hemos definido un proceso de 3 etapas: revisión, evaluación y selección.

Etapa 1: revisión

En esta primera etapa un equipo de revisores surgidos de la comunidad, revisa las sesiones de forma objetiva, dando feedback sobre cuestiones concretas como ser:

  • La propuesta tiene faltas ortográficas
  • La propuesta está incompleta
  • La descripción es muy escueta y no queda claro el objetivo de la sesión
  • La propuesta no es consistente (se propone un workshop para 10 personas pero se plantea que los participante trabajen en 3 grupos de 5 personas )
  • La propuesta tiene errores conceptuales (técnicas para que el Scrum Master asigne a cada miembro del equipo las tareas en las que debe trabajar)

Con este feedback, cada autor debería poder mejorar su propuesta antes del cierre de la convocatoria.

Etapa 2: evaluación

Una vez cerrada la convocatoria, el equipo de revisores realiza una evaluación de las propuestas de cara a generar un ranking de propuestas. Cada propuesta es evaluada por varios pares de revisores pues en esta etapa todos los revisores trabajan de a pares.

Etapa 3: Selección

Una vez completada la evaluación hay que tomar las sesiones y ubicarlas en el programa de la conferencia. Esta no es un tarea trivial pues hay algunas restricciones adicionales como ser la diversidad: queremos tener sesiones sobre diversos temas y de oradores de diversos paises. Naturalmente estas restricciones adicionales implican que algunas sesiones queden fuera del programa a pesar de tener una muy buena evaluación (si las mejores 15 propuestas son sobre Scrum, es muy posible que varias de ellas queden fuera del programa para respetar la diversidad).Al final de esta etapa se cuenta con el programa completo de sesiones y cada autor sabe si su sesión ha sido o no aceptada.

XP2015: Day 4 Summary

As usual we started with the keynote, in this occasion by Brian Fitzgerald (Irish Software Engineering Research Centre). He talked about New directions for Software Development Process. He started with a summary of the evolution of software development process and after that he focused on the impact of Open Source movement and Crowd funding initiatives.

After the keynote I attended to the Lightning talks session where I found some interesting presentations performed by Brazilian folks (Paulo Caroli and Rafaela Fontana).

In the afternoon I attended to the testing track where I saw the most interesting sessions of the day: Llewellyn Falco talking about Getting Existing Code under Tests and Charlie Poole’ demo: From Test to Theories and back  again. Excellent speakers and very useful information.

The last session I attended was Pragmatic Architecture for Agile Teams by Janne Sinivirta, it was fine, nothing new for me but it was a useful summary of key points.

Finally at 5 PM it was the main conference closing (even when the next day there were some more workshops). As usual the closing included a retrospective activity, thanks to everyone and the announcement of the next year conference which will be held in Edinburgh.

xp_day_4