Categoría: projectStory

Proyecto nuevo, código viejo: update

Hace un par de semanas comenté de este proyecto que estaba iniciando.

Al momento que estoy escribiendo estas líneas hemos completado 6 iteraciones.

Luego de unas 3 primeras iteraciones un poco accidentadas, ya hemos logrado equilibrio con un flujo de trabajo bastante armónico y decente. Esto puede observarse, entre otras cuestiones, en las métricas recogidas en la siguiente tabla.

Podemos observar que en las 2 primeras iteraciones no se cumplió con el objetivo de la iteración y tampoco se pudo completar la cantidad de ítems planificados. Asimismo en la tercera iteración, logramos cumplir a medias con el objetivo, pues logramos codearlo pero no llegamos a tiempo a completar el testing.

Finalmente, ya a partir de la cuarta iteración logramos cumplir con el objetivo de la iteración y también mejoramos la cantidad de ítems completados respecto de los planificados.

Algunas cuestiones que me parece relevante compartir:

  1. Al ser un equipo nuevo, es normal que el equipo necesite 4 o 5 iteraciones hasta «fluir» y lograr equilibrio.
  2. Trabajamos en iteraciones semanales y nos llevó 1 mes alcanzar el equilibrio. Es importante notar que el equilibro no está dado necesariamente por el tiempo calendario sino que es más importante la cantidad de ciclos. Lo que nos permite «estabilizar/mejorar» es la cadencia de ajuste y reflexión al final de cada ciclo. Durante las primeras semanas hicimos retrospectivas todas las semanas pues éramos conscientes que teníamos aún mucho por mejorar. Si hubiéramos trabajado con iteraciones de 2 semanas (como hacen muchos equipos), seguramente nos habría llevado mucho más tiempo calendario.
  3. Si bien puntuamos todos los ítems, mantenemos la puntuación acotada a 3 valores (1, 2 y 3) porque queremos mantener ítems chicos y de tamaño «similar». De hecho la puntuación solo la utilizamos para validar que el ítem no sea muy grande. Luego el plan lo armamos mirando la cantidad de ítems. Es así que luego de 4 iteraciones creemos que en condicionales «habituales» podemos completar unos 7 u 8 ítems por iteración.

Continuará…

Nuevo proyecto a la XP: Argenzuela

Hace unas dos semanas comencé a trabajar en un nuevo proyecto. Yo en Argentina y el resto del equipo en Venezuela y de ahí el «Argenzuela», ¡ja!. En el equipo somos 3 Devs, 1 tester, «proxy» Product Owner (que está en el día a día) y un Product Owner con participación más esporádica.

Al margen del (mal) chiste el proyecto consiste en desarrollar la integración de una aplicación con un Sistema CRM (Customer Relationship Management).

En términos de tecnología estamos trabajando con Ruby y RabbitMQ. En términos de infraestructura la aplicación Ruby la corremos dockerizada en Heroku y para el Rabbit usamos el servicio de Amazon. Como herramientas de gestión/desarrollo estamos utilizando el stack de Atlassian: Jira, Confluence y Bitbucket.

Trabajamos «a la XP», iteraciones semanales, TDD, CI/CD, diseño simple, refactoring, mucho pairing y otras yerbas varias.

El proyecto tiene un par de desafíos técnicos y de negocio interesantes pero al margen de eso me gusta la dinámica que equipo que estamos construyendo. Continuará…

Build de 10 minutos y categorización de tests

Cuando el equipo actual tomó a su cargo el sistema este tenía una alto grado de inestabilidad y prácticamente no tenía tests automatizados. Gradualmente se fueron agregando tests que ayudaron a mejorar a la estabilidad del sistema. En un punto se llegó a tener unos ~2600 tests de componentes/unitarios cuya ejecución excedía los 30 minutos. Todos estos tests eran ejecutados como parte del build de integración continua. A esto se sumaba el hecho de que equipo hacía feature-branches, los cuales también eran buildeados automáticamete, aumentando la carga del build server. Llegado un punto, cada vez que un developer hacía un commit (+push) tenía que esperar, en el mejor de los casos, unos 40 minutos para obtener feedback. Podía llevar a pasar que el build server estuviera ocupado y entonces el build quedaba encolado estirando aún más el tiempo de espera.

Ante esta situación hicimos dos cosas. En primer lugar instalamos un segundo agente del Build Server, para bajar el tiempo tiempo de espera en cola. En segundo lugar categorizamos los tests y ajustamos la configuración del build server. En este segundo punto quiero profundizar.

Es un práctica muy difundida y aceptaba, el tener un build de integración/feedback continua que no exceda los 10 minutos (algunas referencias para profundizar aquí y aquí). En línea con esto decidimos categorizar los ~2600+ tests, identificando aquellos que cubrían las partes críticas de la iteración. Identificamos unos ~600 tests fundamentales cuyo tiempo de ejecución resultó en unos 7 minutos. Categorizamos esos tests como «core». Al mismo tiempo ajustamos el build server para que se ejecuten en forma continua (ante cada commit+push) los tests «core» y de los «current» (pertenecientes a la iteración actual), de manera de poder tener un feedback «rápido». Por otro lado, creamos otra tarea que se ejecuta al fin del día para correr el set completo de tests.

 

Banca DevOps, nuevo proyecto

Desde hace un tiempo hay en Argentina un auge de transformación digital en el sector bancario, el cual suele incluir iniciativas Agile + DevOps. En ese contexto, fui contactado hace un par de semanas por un banco para colaborar en la optimización de su flujo de valor (en realidad el pedido vino por otro lado y después de un par de charlas derivó en esto).

Luego de un par de conversaciones con las personas que me convocaron, nos pusimos de acuerdo y accionamos. La idea es comenzar trabajando sobre un equipo en concreto, y luego incorporar gradualmente otros equipos. La intención es poder ir resolviendo problemas reales de los equipos y definir reglas/patrones a partir de generalizaciones de lo realizado en cada equipo.

Una de mis premisas de trabajo cuando participo de este tipo de iniciativas es definir criterios claros y objetivos de éxito. Muchas veces he visto iniciativas fundamentando su éxito en frases tales como «La gente se siente más contenta», lo cual puede estar bien para «la gente», pero muchas veces resulta insuficiente para quien paga. Tal vez sea una limitación mía, pero no he tenido éxito convenciendo gerentes con «sensaciones». Tal vez sea por mi perfil ingenieril: las sensaciones me parecen importantes, pero a la hora de tomar desiciones quiero números concretos. En este sentido, en el contexto de esta nueva iniciativa, hemos definido dos métricas iniciales como referencia: lead time y risk exposure.

Continuará…