Etiqueta: projectStory

Proyecto CMS, día #3

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á…

Proyecto CMS, día #2

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.

Año nuevo, proyecto nuevo (cms): contexto y día #1

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á…

The Rules goes live!

Hoy finalmente salimos en producción con The Rules luego de 3 intensas semanas de trabajo. Una aplicación no demasiado compleja pero un proyecto por demás interesante:

  • Equipo de proyecto distribuido en diversas ciudades alrededor del mundo: New York (US), Austin (US), Chennai (India) y Buenos Aires (Argentina)
  • Contenido en 5 idiomas, modificable en cualquier momento por un editor
  • Integración con varios sistemas externos (CMS, PayPal, SendGrid, etc)
  • Y lo más dificil (a mi parecer), crear la interface gráfica de la aplicación en base a las ideas de diseñadores expresadas en PhotoShop, menos mal que en el equipo estaba Gabriel C, un capo con cuestiones de HTML/CSS.

Como infraestura de desarrollo utilizamos GitHub y Jenkins. En Jenkins contamos  con 4 jobs: integración contínua, integración, deploy a staging y deploy a producción. Para las comunicaciones utilizamos GoToMeeting y Campfire. Esta última herramienta la podria describir como una sala de chat que donde va quedando guardada la historia de conversaciones y que permite insertar imágenes Nos resultó especialmente útil para hacer troubleshooting de algunas cuestiones. Resultaba interesante ver como a la gente en distintos usos horarios iba entrando y saliendo acorde avanzaba el día. En cuanto a la infraestructura de staging y producción corremos sobre Heroku.

El primer hito está completo, ahora tenemos un par de semanas más hasta el próximo release.

New series: game development

In a while I will start working on a new project related to game development and I thought that it was a good opportunity to write some stuff about it.

I have never been involved in commercial games development, but I have background on the topic. I been teaching object-oriented programming at Fiuba and most of the programming practices are related to games, because they provide very good scenarios to apply may OO concepts.  At the same time I have also been involved in the development of a simple framework to create loop-based games called titiritero and that is used by our students to perform their programming practices. And of course I have also implemented my own games, but that was a long time ago (I remember I used Delphi 4 and C++).

So, let’s start by setting the expectation so you can decide to continue reading or not: along this series of post I will write about development of simple loop-based games which covers most of the games that you can currently find in mobile devices. I will share some basic concepts that you can apply no matter which technology you use for the implementation. Regarding the implementation, I will focus on Microsoft technologies and particularly in XNA Game Studio.

From now on, you will find all articles in this series under the tag gameDevelopment.

Project A: day#end

We shipped it! The product is now complete. It is not yet in production environment because the Go live!is scheduled for the end of January. Working on this project has been a very pleasant experience and weperformed a smooth delivery as well.

A few numbers of this project:

  • 44 stories completed
  • Representing a total weight of 97 points
  • In a timeframe of 5 iterations
  • With an iteration lenght of 1 week.

There is one post pending about this project that I will write after going live.

Project A: day#11, same team new project

Today we started working on project A2. Project A is still in progress but the work remaining is enough for one dev, so  together with the customer we decided to split the team in two. Diego will continue working in project A for 2 weeks while Gabriel and myself will start working on project A2. Both projects are related, not at the code level but at business level and that is why we splitted the team in two instead of having a new team doing A2. This afternoon we had a review & planning meeting with the customer where we showed the progress on project A and we set the vision and overall context for project A2.

This is one of the things that I find interesting an different compared to previous work experiences: projects run fast, maybe in two weeks. So you need to be sharp, execute, deliver and get ready for the next challenge. Weekly iterations help and communicating status daily is crucial to steer the direction if needed.

To be continue…

Project A: day#10

We have just finished the second iteration and we are on track, we completed all the committed items and also some others that we found during the iteration. At the same time are working in a ISO complain way (that is what our complain checker says).

One interesting characteristics of this project is that we are working on a solution based on a open source product. During this two weeks we have found some issues on this product that we had to fix, but this didn’t affect our scheduled. At this moment we are almost ready to integrate the UI styles that are being developed by another company, I think that will be an interesting challenge.

To be continue…

Project A: day#6

Today we did the iteration review (it should have been last Friday, but our customer decided to move it because of Thanksgiving day). We completed all the committed items and some more. The review meeting was short (less that 30 min),  we had prepared a slide deck with 4 slides to highlight some facts of the past iteration and some important stuff about the next one. During the meeting we browsed the application, we reviewed the backlog and we agreed the scope for the next iteration. After the review we did a retrospective, and here we are now starting our second iteration.

To be continue…

Project A: day#4

We are in good shape, the customer confirmed that we are going to take care of developing the application and go live process.

Today we deployed to staging the first drop of the application. To set clear expectation with our customer we added a disclaimer message on top on each page.

image

The link “See drop details” takes the user to a page were the deatils of features/modifications are listed. This first drop includes 4 out of the 6 story commited for the current iteration.

To be continue…