Proyecto CMS, flujo diario de trabajo

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.