El foco de hoy estuvo en las pruebas de usuario. No tuvimos reportes de errores sobre las funcionalidades desarrolladas por nuestro equipo, pero puede que se deba a que no llegaron a probarlas, lamentablemente no tenemos suficiente visibilidad al respecto.

Lo que sí supimos es que hubo algunos issues de infraestructura (errores de memoria) pero aún no leí el reporte en detalle.

Más allá de esto, hoy trabajé en implementar una funcionalidad que estaba planificada para el siguiente release, pero que por un cambio de prioridad tuvimos que adelantarla. También empecé a trabajar en el diseño de otra funcionalidad de alta prioridad de la siguiente iteración.

Mañana voy a meterme a analizar los errores de infratructura que fueron reportados hoy.

Continuará…

Hoy completé la story que había comenzado ayer y con ella toda la funcionadad requerida para el primer release. Sé que el cliente ya comenzó a ejecutar pruebas de aceptación y encontró algunos issues, pero aún no me han reportado nada formalmente con lo se me ocurre que puede que los issues detectatos esten relacionados a stories desarrolladas por otros equipos.

Esta tarde también tuve una call con los muchachos del equipo a cargo de la migración de datos y nos sincronizamos.

De aquí al release del próxmo miércoles: carga/migración de contenidos y estabilización.

Continuará…

Hoy fue un dia sin mayores sobresaltos. Efectivamente el enfoque que había elegido para implementar la story que comenté ayer, resultó ser el correcto. Hoy completé una story relacionada a la de ayer y comencé con una nueva story que quedó exactamente a la mitad de camino. Mañana completaré la story que tengo en progreso y luego hecharé un vistazo a algunos issues que han reportado relacionados a stories ya completas.

Hay solo una cosa que me está incomodando, el equipo trabajando en la migración de datos no está asistiendo a la stand up meeting y tampoco está dando visibilidad diaria en la lista de correo del proyecto. Espero que al menos estén en contacto con el cliente, pero aún así no me gusta la situación.

Mañana entramos en modo pre-release pues tenemos que empezar a cargar la información real para el lanzamiento, asi que…¡agarrate catalina!

Continuará…

Trabajé en extender una funcionalidad existente de la cual no tenia ni la más mínima idea de como estaba implementada. Comencé buscando donde y como se utilizaba la clase que tenia extender, pero no me sirvió de mucho. A continuación busqué en las pruebas de la clase en cuestión y ¡Bingo!: encontré un par de pruebas que me sirvieron para orientarme. Sin tener demasiado en claro como implementar la funcionalidad que necesitaba, escribí un test, lo corrí y falló como era de esperar y a partir de ahí con un poco de investigación de por medio fue agregando funcionalidad. Como no estaba seguro si el enfoque de implementación por mí elegido era el correcto, quise consultarlo con los muchachos que habian escrito el código original, pero resulta que eran del equipo de Indía, ¡ups!, en ese momento deberian estar durmiendo, asi que simplemente escribí un mail pidiendo validación de mi enfoque.

Por otro lado, la base de código y pruebas está creciendo rápidamente, lo está provocando que los jobs del build server tarden cada vez más el correr, tal vez debamos ver de agregar algún agente adicional.

Continuará…

Me atrasé, por eso aquí paso el reporte de los últimos dos días.

El día #4 (el lunes pasado), fue durísimo, muy poco avance pues me pasé casi todo el día haciendo troubleshooting de ciertas funcionalidades que detectamos no corrian correctamente en el ambiente de prueba. Primero habia una temita con ciertos chequeos de seguridad de Rails que se activan por default cuando la aplicación corre en environment=production. Una vez detectado y resulto este tema, surgió algo inesperado. La gema XMLObject (que mencioné en otro post) lanzaba una excepción en el ambiente de test, pero en mi máquina y en el build server andaba joya. Finalmente resulto que se debia a un cambio de implementación en una dependencia que en Ruby 1.9.3 andaba joya pero no así en Ruby 1.9.1 (versión de la instancia de test). La solución «rápida» una vez detectado el problema, fue remplazar esa gema por Nokogiri. Por suerte el cambio era interno a una clase la cual tenia los correspondientes test. No hubo mayor historia pero me consumió muchísimo tiempo.

El día #5 fue mucho más productivo, logramos completar las dos stories siguientes en orden de criticidad para el negocio y al mismo tiempo un miembro de otro equipo se hizo cargo de una story que nos iba a llevar mil años implementarla por no estar familiarizados con un determinado módulo de la aplicación.

Continuará…

 

Un día realmente complicado pero para que se entienda debo dar un poco más de contexto del proyecto. Anteriormente mencioné que tenemos varios equipos trabajando en distintos lugares alrededor del globo, pero lo que no mencioné es que cada equipo trabaja en cosas distintas, básicamente cada equipo tiene un subproyecto. La visión global del proyecto es tomar un sitio existente y ponerlo a correr sobre la plataforma CMS. Esto implica varias cuestiones:

• Agregar a la plaforma CMS algunas funcionalidades faltantes (aquí estoy yo)
• Estabilizar algunas funcionalidades de la plataforma que hasta el momento no estaban en uso (equipo en India)
• Migrar la información del sitio «viejo» a la plataforma (equipo en USA)
• Realizar diversos ajustes a nivel de infraestructura (otro equipo en USA)
• Realizar varias gestiones a nivel organizacional (por ejemplo el anuncio de prensa)

Todo esto nos lleva a que distintos equipos, trabajando en distintos lugares, en distintas bandas horarias, se encuentren tocando el código de una misma aplicación. Uno podría pensar que usar una estrategia de feature branch podría ser apropiado, pero quienes llevan la batuta del proyecto tienen una postura bastante extrema y se han tomado la cuestión del delivery contínuo muy a pecho. Por ello es que todo el mundo trabaja sobre el trunk utilizando una estrategia de Feature Toggle. Personalmente no me termina de convencer, pero por ahora funciona. Al mismo tiempo, para poder dar soporte a la estrategia de delivery contínuo contamos con una robusta infrastructura basada en Jenkins y Heroku. Tenemos dos ambientes casi identificos corriendo en Heroku: preview y producción. Cada vez que se completa una story, se realiza un depliegue a preview. Por su parte Jenkins tiene 4 trabajos:

• Integración contínua, se dispara automáticamente en cada commit, ejecuta las pruebas unitarias (Ruby y JavaScript) y verificaciones de código
• Integración, ejecuta pruebas de integración y se dispara automáticamente luego de cada despligue a preview
• Depliegue a Preview, se dispara manualmente y como su nombre lo indica, despligue la aplicación y tagguea
• Depliegue a Producción, se dispara manualmente

La complicación del día se debió a que el equipo estaba trabajando en la migración de datos, probó sus scripts con la base del ambiente de preview y ello generó ciertas inestabilidades en la instancia de preview. La situación se vió agravada porque este equipo no avisó de esto al resto de los equipos. ¿y porque no mencionaron eso en la reunión de standup? Simplemente porque no asistieron, ja!. Para sumar un poco más de tensión a la situación, resulta que en otra parte del globo estaba el cliente probando la aplicación, ja!.

En cuanto se detectaron las inestabilidades, todos los equipos suspendimos nuestras tareas y nos pusieron a ver cuales eran las causas de las misma. Luego de varias verificaciones detectamos que el problema se debía a los datos inconsistentes/faltantes y pudimos resolverlo. Todo este revuelo me costó dos horas. A pesar de eso pude completar mis compromisos del dia y desplegar mis stories al ambiente de preview.

Una vez más ví confirmada mi tesis, el principal factor de éxito de los proyectos, no es una cuestión de técnica, sino humana: comunicación.

Continuará…

Si bien el equipo de Argentina está distribuido, hoy me reuní para trabajar con un compañero pues teniamos que atacar una de las funcionalidades más críticas del proyecto. La jordana fue muy productiva,  mucho TDD, varios debates sobre como nombrar métodos, tres rondas de mate y una taza de café para despejar el sueño luego del almuerzo.

Aprendizajes varios:

• FactoryGirl, una gema facilitar las pruebas con dependencias de base de datos
• XML-Object, una gema para acceder a un documento xml utilizando sintáxis de objetos
• SublimeText es un interesante IDE que en algún deberia probar
• Si bien en la actualidad hay herramientas como Google Hangout que facilitan mucho el trabajo remot0, no hay nada como el trabajar sentado junto a un compañero y aún más si ese compañero sabe más que uno 😉

Mañana será un día intenso pues vamos a desplegar una nueva versión de la aplicación con las funcionalidades desarrolladas hasta el momento.

Hace ya un tiempo vengo trabajando con gente de ThoughtWorks, Purpose y Tipit, en una especie de CMS para montar sitios de ONGs. Un par de dias atrás me contactaron para un proyecto puntual: hacer una prueba de concepto agregando soporte de donaciones recurrentes utilizando el servicio de Recurly. La prueba de concepto fue exitosa y cliente nos pidió que hicieramos la implementación «posta» de esta funcoinalidad para así poder montar en la plataforma el sitio de una ONG.

Dadas ciertas restricciones de negocio, el proyecto fue definido tipo «comando»:  8 dias para implementar la funcionalidad de donaciones, montar el sitio de la ONG y ajustar varias cuestiones de UI. En términos más concretos el proyecto debe dar solución a 8 user stories. Algunos datos de contexto del proyecto:

• Equipo distribuido entre Argentina, USA e India
• Tecnologia base: Ruby
• Plataforma de ejecución: Heroku + PG + Amazon
• Herramientas de soporte: GitHub, Jenkins, ChiliProject, Campfire y GoToMeeting

Hoy fue el día #1 y por el momento el mayor riesgo que tenemos son algunas definiciones pendientes del lado del negocio. Si mañana no tenemos algunas de estas definiciones vamos quedar bloqueados y ello va producir retrasos.

Continuará…