Alrededor de las 8 de la mañana, enciendo la máquina, inicio sesión y lo primero que hago es ver las novedades, pues dado que tenemos un equipo en India que trabaja a contrahorario es muy común iniciar el día con noticias de progreso. Entonces abro el cliente de correo y un navegador para loguearme en Campfire, la herramienta de chat colectivo. La ventana de Campfire queda abierta todo el dia. Voy leyendo los correos del proyecto, si es que hay alguno y voy contestando.

Una vez al tanto de las novedades, abro una terminal y actualizo mi repositorio local: git pull. Abro otra ventana del navegador para ver que todo esté en orden en el build server (Jenkins). En otra ventana del explorador abro la herramienta de gestión (Chili).

Con esto ya estoy listo para empezar a codear, inicio Rubymine y manos a la obra.

A las 10 de la mañana, inicio sesión en Vydeo para conectarme a la stand up global del proyecto, la cual dura entre 10 y 15 minutos. Luego  inicio GoToMeeting para hablar  con mi sub-equipo, esta reunión suele durar un poco más pues hablamos algunas cuestiones de diseño o hacemos troubleshooting de algún impedimento. Al finalizar esta reunión, ya tengo en claro el trabajo de mi dia, asi que envio un mail a la lista de proyecto contando brevemente mis compromisos.

El resto del día transcurre como una seguidilla de Pomodoros interrumpida solamente por 40 minutos para el almuerzo. Dependiendo de las funcionalidades en desarrollo, puede que hagamos una sesión de pair programming usando Google Hangout. Las funcionalidades en general las desarrollo haciendo TDD. Cada vez que termino una funcionalidad, corro todas las pruebas unitarias (que son alrededor de 1500) y si todo está bien, subo el código al repositorio común lo cual dispara el proceso de integración. Si la integración es exitosa, entonces disparo un despligue a al ambiente de preview para que quien guste pueda ver la nueva funcionalidad agregada. Finalmente actualizo el estado de la funcionalidad en la herramienta de gestión.

Si la funcionalidad desarrollada requirió algún cambio de impacto relevante en el resto de la aplicación (un cambio en la base de datos por ejemplo) envio un mail a la lista de proyecto avisando de esto y si corresponde también documento el tema en la wiki del proyecto.

Al final del día, envio un mail a la lista de proyecto resumiendo el estado de los compromisos asumidos para el día y comentando también mis siguientes pasos.

Era el gran día: la salida en producción, pero no fué. El producto está listo, ha pasado las pruebas, pero el cliente ha decido posponer la salida en producción por cuestiones de negocio.

De forma simplificada podemos decir que el sistema construido reemplaza a un sistema existente y que en este momento el negocio está cerrando un ciclo. El cliente ha considerado conveniente que el ciclo de negocio actual se complete con el sistema «viejo» y recien poner en funcionamiento el sistema nuevo al finalizar el ciclo. Dado que el ciclo de negocio termina la semana próxima, el aplazo de la salida en producción no debiera ser mayor a una semana.

Más allá de esto, mañana haremos el cierre formal del release.

Dado que estamos cerrando una etapa, es un momento apropiado para hacer un retrospectiva, pero resulta un contexto un tanto complejo dada la distribución del equipo. Asi que siguiendo la recomendación de @jgabardini, he propuesto que cada sub-equipo haga su propia retrospectiva y luego compartamos los resultados y coordinemos los action items.

De ahora en más ya no escribiré los avances diarios, sino sólo los hechos relevantes como la salida en producción, los resultados de la retrospectiva, etc.

Espero hayan disfrutado de este relato de un proyecto real. Fin.