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.

Comencé el dia hablando con el equipo de Chennai sobre como manejar una situación excepcional en el flujo de la aplicación. ¡Durísimo! ¡Como me cuesta entender el acento de la gente de India hablando en inglés! Definitivamente es el acento más dificil que me ha tocado interactuar. Siguiendo la buenas prácticas, al final de la reunión mandaron un mail con la conclusión de lo hablado y lo cual me permitió confirmar que a pesar de la dificultad de comunicación, había entendido bien.

Con el output de la reunión logramos completamos la funcionalidad faltante, arreglamos los test rotos y mergeamos nuestro branch con el master.

Ahora, test, test, test y producción y más allá.

Continuará…

 

Un día normal, sin certeza de la fecha de salida en producción, pero al parecer la funcionalidad que estoy desarrollando determinará la fecha en cuestión. Hice un progreso interesante en el desarrollo de esta funcionalidad, solo faltaría agregar un buen manejo de excepciones y arreglar algunas pruebas que se rompieron y no entiendo porque pues no parecen tener relación con el código agregado/modificado.

Tuve algunos aprendizajes interesantes en lo que respecta a diseño, ya les dedicaré algún post futuro.

El lunes es feriado en USA, con lo cual, si todo va bien, el usuario realizaré las pruebas el martes y si todo está bien saldremos en producción el miércoles.

Continuará…

La gran novedad del dia fue que el cliente decidió que la funcionalidad que estaba desarrollando yo, que estaba planificada para el siguiente release, debe ser incluida en este release, aunque eso implique retrasar la fecha de release, ¡ja!. Otro punto relevante es que tuve contacto directo con uno de los usuarios, si!!!!!!!!!

La demo de hoy estuvo dedicada a revisar la lista de issues. La buena noticia es que se estableció la fecha de release para el Lunes, pues los fix vienen bien y al mismo tiempo se destrabaron las cuestiones administrativas respecto del servicio de pagos.

Por mi parte comencé a trabajar en una funcionadad del siguiente release y para eso cree un feature branch en lugar de usar la estrategia de feature toogle. La razón de esto es que la nueva funcionalidad «colisiona» con una funcionalidad actual del sistema y varias modificaciones son necesarias, con lo cual usar feature toogle sería un caos por la cantidad de código adicional necesario agregar para el toogle.

Continuará…

No vamos a salir en producción mañana. En primer lugar porque el servicio de pago utilizado para las donaciones no ha sido activado por ciertas cuestiones «contractuales».

Más allá de eso, logré tener acceso a los resultados de las pruebas realizadas ayer por los usuarios. Hay más de 20 issues reportados pero ninguno relacionado a nuestras funcionalidades ¿curioso no?. En realidad no tanto, resulta que como el ambiente de pruebas estaba andando muy lento, alguien decidió que los usuario hicieran las pruebas directamente sobre el ambiente productivo, pero nadie se tomó el trabajo de aplicar ciertas configuraciones necesarias para nuestras funcionalidades, con lo cual las mismas no pudieron ser probadas ya que fallaban en el primer click, ja!

¡La bronca que me agarré!, porque yo mismo habia mandado un mail a la lista de proyecto hace un par de dias con los detalles de configuración que era necesario aplicar en el ambiente de producción antes de pretender usar las nuevas funcionalidades. Y no es algo que mencioné a la pasada, sino que era un mail dedicado exclusivamente a esta cuestión.

Respecto de mi trabajo de hoy, tuve unas cuantes reuniones, hicé algunos ajustes menores a funcionalidades existentes, ajusté la configuración del ambiente de producción y empecé a trabajar en el diseño de una funcionalidad del siguiente release.

Continuará…