Historia de una primera salida a producción

Finalmente luego de 9 iteraciones(~4 meses) llegamos a producción. Mmmm, no, en realidad fue casi un año de trabajo. El proyecto comenzó con un sistema legacy desarrollado en Asia durante 6 años [1]. Sobre dicha plataforma hicimos una reingeniería para reemplazar algunos módulos y agregar uno totalmente nuevo. En ese contexto se comenzó a trabajar con un equipo de 4 personas que fue creciendo a lo largo del año hasta llegar a ser más de 25 personas (yo me sumé cuando rondábamos las 10).

A medida que la cantidad de personas se fue incrementando fuimos partiendo el proyecto/equipo en sub-proyectos/sub-equipos hasta llegar a ser 5 sub-equipos/sub-proyectos [2].

En Enero tuvimos el release del primer módulo que reconstruimos de cero [3]. En Mayo fue el release del segundo módulo y finalmente el viernes pasado tuvimos el release de 3 módulos más. Los primeros dos módulos había sido producto del trabajo de 2 sub-equipos, mientras que los módulos liberados el pasado viernes fueron resultado del trabajo del “big-team”, o sea, el release incluyó productos de todos los sub-equipos.

En este año de trabajo he compartido experiencias muy enriquecedoras con un excelente grupo de trabajo. Siendo alrededor de 30 personas, hubo algunos con los que compartí muchas situaciones y otros con los que apenas hablé. Entre todas las cuestiones acontecidas durante este año me parece importante destacar:

  • El foco en la mejora
  • El espíritu colaborativo
  • La especial atención a las personas
  • La disciplina en la forma de trabajo
  • El manejo de los esfuerzo extraordinarios (horas extra)
  • El manejo de las situaciones “no tan felices”

[1] En el artículo Aplicaciones legacy, monolitos y microservicios escribí más detalladamente sobre esta situación.

[2] En el artículo team.split() & project.new(), conté sobre la creación de uno de los sub-equipos/sub-proyectos

[3] En el artículo projifm, estadísticas del primer release compartí algunas estadísticas de ese primer release.

Estabilizando la velocidad

Durante las dos primeras iteraciones decidimos no puntuar las stories con un valor explícito de estimación. Simplemente a la hora de determinar el compromiso de la iteración utilizamos la tantas veces usada técnica de “estimación a ojo de buen cubero”. Pero ya en la tercera iteración el cliente nos pidió que puntuáramos las todas las stories del backlog para poder hacer una proyección. Así que eso hicimos, repasamos todo el backlog haciendo una estimación de mano (una variante del famoso planning pocker).

Adicionalmente al comienzo de cada iteración, repasamos los valores asignados a cada story  y de considerarlo necesario los volvimos a estimar.

La semana pasada completamos la sexta iteración y por primera vez entregamos exactamente lo que habíamos comprometido. Hasta entonces siempre habíamos tenido un pequeño delta positivo o negativo.

Comprometido vs. Entregado

Como se puede apreciar en el gráfico precedente la cantidad de puntos entregados por el equipo ha ido en aumento desde la iteración 4. Parte de ese incremento se debe a que las iteraciones 4 y 5 tuvieron días feriados en los que no trabajamos y que hicieron que dichas iteraciones fueran más cortas en términos de días trabajados.

En este momento estamos trabajando en la iteración 7 y el tamaño del compromiso tomado es bastante mayor a las iteraciones anteriores (75 puntos). Esto se debe a que se sumo una nueva persona al equipo.

Al finalizar la iteración 8 saldremos a producción. Yo hubiera preferido salir antes, pero resulta que estamos reemplazando un producto existente y ha sido muy difícil hacer un recorte de funcionalidad que nos permita salir antes sin impactar negativamente en el negocio.

Continuará…

Mejorando el flujo de trabajo a partir del burndown chart

Ayer completamos la tercera iteración del proyecto y la cosa empieza a fluir de lo lindo. Si bien veníamos cumpliendo con los compromisos asumidos el flujo de trabajo en las dos iteraciones anteriores había sido medio accidentado/abrupto como evidencia el burndown chart de la iteración 2.

Burndown chart iteración 2

En la retrospectiva de la iteración 2 tomamos conciencia de este flujo accidentado y decimos tomar medidas para mejorarlo. Principalmente intentamos tener ítems de backlog más pequeños, limitar el WIP y deployar de forma más frecuente. El resultado se puede apreciar en el siguiente gráfico.

Burndown chart iteración 3

 

A pesar de la mejora yo sigo teniendo un pequeña molestia pues no me gusta el cierre abrupto de la iteración. Este cierre es consecuencia de que terminamos a último momento el testing de la última porción de trabajo.

Ya que he compartido los gráficos quiero aprovechar también para compartir un breve análisis comparativo de los mismos:

  • Si bien ambas iteraciones tuvieron la misma duración calendario, la cantidad de días laborales en cada una, fue diferente (los días no laborales está representados por las franjas verticales de color gris más oscuro).
  • Debido al ítem anterior, el tamaño del compromiso asumido por el equipo también fue distinto: en la iteración 2 el compromiso fue de más de 50 puntos, mientras que en la iteración 3 fue de unos 40 puntos.

Nuevo desarrollo: ProyectoH

Luego de casi 2 meses trabajando con el equipo de DevOps en cuestiones de infraestructura y soporte a los equipos de desarrollo, pasé a integrar un nuevo equipo de desarrollo. En este nuevo equipo somos 4 personas de perfil técnico (siendo yo una de ellas) y una persona de negocio.
Dos de los técnicos se especializan en cuestiones de UI lo cual implica que se encargan de relevar/diseñar junto con la persona de negocio la UI/UX de la aplicación.
El otro técnico está enfocado en cuestiones de backend y básicamente se encarga de la programación server-side y de realizar algunas de las pruebas de concepto de arquitectura.
Por mi parte tengo un rol medio “híbrido” que incluye tareas varias como ser:

  • Facilitar el cumplimiento del proceso y la prácticas técnicas
  • Asistir a la persona de negocio en el armado/refinamiento del backlog de producto
  • Y obviamente codear

Continuará…

Cuando el mínimo producto viable es demasiado grande

El proyecto en el que estamos trabajando es una plataforma que nuestro cliente ofrece como servicio a sus propios clientes bajo un modelo tipo “suscripción”.

Más específicamente estamos construyendo una nueva versión de esta plataforma, pues el cliente ya tiene versión que ha construido durante varios años. Más aún el cliente ya está recuperando su inversión. Las razones que lo llevan al contratar a un nuevo proveedor para hacer una nueva versión de su plataforma no vienen al caso en este artículo, pero es interesante destacar que la nueva versión no incluye nuevas funcionalidades (al menos en un principio) aunque se espera que resulte mucho más estable y escalable. Pero esta cuestiones técnicas no son precisamente lo que más me inquieta.

El tema que más me inquieta tiene que ver con la planificación. Construir un nuevo producto con toda la funcionalidad existente en el producto actual podría llevarnos más de un año. Demasiado tiempo, demasiado riesgo.

En estos días precisamente estamos trabajando con la gente de negocio para intentar identificar un estrategia que nos permita liberar al menos una parte del producto y de esa forma comenzar a tener un retorno de la inversión y mitigar los riesgos.

Continuara…

 

El equipo de DevOps

El equipo de DevOps

Como mencioné anteriormente ya estamos en producción y dado que el cliente no tiene un area de sistemas está acordado que nosotros mismos nos encarguemos de la operación. Para esto armamos el equipo “DevOps”, y para ser sincero debo admitir que inicialmente el nombre no me cerró, yo lo habría llamado directamente “operaciones”. Pero creo que la intención al llamarle “DevOps” fue ya desde el nombre intentar transmitir el mindset con el que se quiere trabajar. En fin, en punto del nombre no es tan relevante. Creo que lo interesante es la forma en que estamos intentando trabajar. En este momento somos 3 personas:

  • Una persona con skills de operaciones/sysadmin y automatización (en particular usando Chef)
  • Una persona proveniente del equipo de UI (js/html/css)
  • Una persona proveniente del equipo de desarrollo server-side (C#). Este soy yo, que adicionalmente estoy oficiando de “facilitador” del equipo

Para la coordinación/organización del equipo estamos usando las siguientes herramientas:

  • Una lista de correo
  • Un canal de Slack
  • Un tablero Kanban (en Jira)

Respecto de la dinámica de trabajo, trabajamos en un flujo continuo, limitando el work-in-progress e intentando planificar semanalmente. En este sentido cada lunes reportamos los items completados la semana anterior e identificamos los items más prioritarios para trabajar en la semana actual. Luego con el correr los días se van sumando a nuestro backlog nuevos items que debemos atender en forma inmediata. En todos los casos estos items “urgentes y no planeados” los registramos en el Jira para que quede constancia de nuestro trabajo.

Respeto del tipo de tareas que realizamos, en este momento tenemos 3 hilos de trabajo principales:

  • Automatizar el provisionamiento de toda nuestra infraestructura
  • Armar la arquitectura de build y el pipeline de deployment
  • Atender pedidos puntuales de los equipos de desarrollo (por ejemplo asistir a un equipo en la configuración de alguna herramienta cuya configuración aún no está automatizada)

Un punto que puede resultar curioso es que este equipo de operaciones no se encarga completamente de la operación, al menos no por ahora. En este momento tenemos una solo aplicación en producción pero es el equipo que la desarrolló quien la monitorea y atiende eventuales alertas.

Por el momento me gusta la forma en que esto está fluyendo, pero recién empezamos, ya veremos como evoluciona.

 

projifm: Estadísticas del primer release

Finalmente la semana pasada salimos a producción. El evento en cierto modo fue muy tranquilo ya que nuestra aplicación estaba instalada y funcionando en el ambiente productivo desde hacía varias semanas.
Comparto aquí algunas estadísticas:
Estadísticas de proceso
  • 7 iteraciones (2 semanas cada una) con un equipo de 5 ingenieros
  • 6 semanas de trabajo “on-demand” de un ingeniero monitoreando y realizando ajustes menores
  • 313 items de Jira resueltos
Estadísticas de código
(esto números son específicos del nuestra aplicación, pero el equipo también trabajó sobre componentes compartidos con otras aplicaciones que no está considerados aquí)
  • 138 test automatizados
  • 83.5% de cobertura
  • 67 clases (sin contar las clases de tests)
  • 7329 líneas totales de código
  • 4211 líneas de  código productivo (57%)
  • 3118 líneas de código de tests (43%)

Deuda técnica
Al momento de este primer release registramos los siguientes items de deuda técnica:

  • Código duplicado en los tests
  • Dependencias externas desactualizadas
  • Falta de monitoreo más granular de ciertos componentes