Previsibilidad mata velocidad

Completamos la séptima iteración entregando menos de lo que habíamos planificado y eso generó cierto debate en la planning de la octava iteración, llevando incluso a que algunos miembros del equipo quieran replantear la forma de estimación.

Hasta el momento hacíamos lo siguiente:

  • Repasar el backlog candidato determinado por el Product Owner, asegurando que entendíamos cada uno de los ítems
  • Estimar “a ojo” los item que consideramos podríamos llegar a completar en la iteración por comenzar
  • Asignar puntos (1, 2 o 3) a cada uno de los items, principalmente para estar seguros que todos los miembros del equipo teníamos una idea similar de las implicancias/alcance de cada ítem. Importante: estos puntos no los utilizamos para determinar la cantidad de trabajo de la iteración, sino simplemente como un mecanismo de doble validación interna.

Con este mecanismo en la iteración 7 planificamos unos 23 items pero completamos unos 18.

Antes de continuar debo decir que:

  • En la gran mayoría de equipos que he estado involucrado “con problemas de estimación”, resultó que en realidad era mucho más grave el problema de ejecución que el de estimación
  • Para equipos comprometidos, auto-organizados y trabajando en iteraciones cortas y con un esquema de continuous delivery no creo que valga la pena estimar “formalmente” con puntos/horas ni nada por el estilo más allá de la sensación del equipo

Dicho todo esto, mientras parte del equipo debatía sobre los ajustes al método de estimación/planificación, me puse a repasar el histórico de iteraciones en el Jira y confirmé mi sospecha viendo unos de los reportes provistos por la herramienta:

El nombre que la herramienta da a este gráfico es “Reporte de Velocidad” el mismo muestra en gris el plan del equipo al inicio de cada iteración y en verde lo efectivamente completado al final de la iteración. Se supone que a partir de este gráfico uno podría deducir una velocidad/capacidad del equipo que puede resultar útil a la hora de planificar.

Analizando este caso particular uno podría decir que este equipo puede entregar alrededor de 18 puntos por iteración. Sin embargo, ese no es el dato más importante de este gráfico para mí.

Lo que me resulta más relevante de este gráfico es la predecibilidad. Puede verse que independiente del número X planificado, este equipo entrega consistentemente con un desvió promedio de ~18 %, siendo este desvío en ocasiones positivo (se entrega más de lo planificado) y en ocasiones negativo (se entrega menos de lo planificado). Más aún, si eliminamos del cálculo la iteración 4 que fue particularmente corta en términos de días laborales (por feriados) y que tuvo una variación de equipo (se sumo una persona), el desvío promedio cae por debajo del 15%. Personalmente creo que es un grado de predecibilidad muy bueno, sobre todo si consideramos que el equipo tiene la capacidad (tanto a nivel proceso como de infraestructura) de entrega software potencialmente todos los días.

En general prefiero no hablar de la velocidad de un equipo pues creo que puede generar falsas expectativas por la sola terminología. Alguien fácilmente podría tentarse de pedirle al equipo que aumente su velocidad generando así presiones para el equipo. Y ni hablar de quienes pretenden comparar la velocidad de distintos equipos. Es por esto que prefiero no hablar de velocidad como una característica del equipo. Prefiero caracterizar al equipo por cuan predecible es.

¡LLegamos a producción!

Hace unos días comenté que teníamos el desafió de llegar a producción en 8 días con una aplicación construida desde cero.

Ayer cumplimos el objetivo.

En el camino nos encontramos con varios imprevistos relacionados principalmente con las aplicaciones existentes con las que teníamos que interactuar. Cuestiones principalmente de networking, seguridad y accesos. Todas cuestiones que intentaremos ir puliendo en las próximas iteraciones.

El siguiente gráfico resume la arquitectura productiva de nuestra aplicación:

Nuestra aplicación consiste en un frontend construido con Angular (servido por Nginx) y un backend construido con Net Core (aspnet/kestrel) que consume servicios WFC/SOAP que proveen acceso al core de la organización. Tanto front como back son empaquedados en imágenes docker que luego corren en Kubernetes. Dentro de Kubernetes tenemos pods de front y pods de back que en ambos casos corren en un esquema de sidecars con filebeat. Esto es: cada pod corre dos contenedores, uno con nuestra aplicación (front o back) y uno con filebeat que se encarga de leer los logs escritos por nuestra aplicación y mandarlos a Elastic/Kibana para tener así un acceso centralizado al log. Por otro lado, por fuera del cluster Kubernetes hay un conjunto de dispositivos de red (routes, balancers, firewalls, etc) y servidores de distintos tipo donde corren los servicios con los que interactua nuestra aplicación.

En próximos post compartiré algunos detalles de nuestra forma de trabajo y nuestro pipeline de delivery.

De desarrollo a Producción en 8 días

El jueves pasado completamos la primera iteración. Construimos una funcionalidad mínima pero que nos sirvió para sentar las bases del proyecto y mitigar muchos riesgos técnicos. Al mismo tiempo montamos la infraestructura de CI/CD y el ambiente de desarrollo.

En esta segunda iteración tenemos el objetivo de agregar un poco más de funcionalidad, ajustar la estética/pantallas de la aplicación e ir a producción. Para esto tenemos 8 días hábiles. Puede parecer más que suficiente pero yo tengo mis dudas. Ninguno de los presentes en la reunión de planificación conocía a ciencia cierta el procedimiento formal para ir a producción con una nueva aplicación. La complejidad radica en que la organización es una entidad financiera que está sujeta a ciertas normas y regulaciones generales definidas por una entidad controladora externa. Al mismo tiempo ocurre que la implementación de algunas de esas normas es en ciertos casos obsoleta, extremadamente burocrática y sin sentido.

En 2 semanales cuento que tal nos fue.

El curioso incidente del Scrum Master y el merge a master

El curioso incidente del Scrum Master y el merge a master

Estábamos arrancando con el setup del proyecto y nos enteramos que el área arquitectura definió que el único que puede aprobar los merge-requests a master es el Maintainer. Curiosamente arquitectura asignó el rol de Maintainer en nuestro proyecto al Scrum Master, el único miembro del equipo (junto con el PO) que no codea, ¡ooops!

Ayer comenté esto en twitter y generó varias reacciones.

Lo que me incomoda de esta situación no es el hecho de quién puede aprobar los merge-request sino el hecho de que alguien externo al equipo defina cómo debe trabajar el equipo. Entiendo que haya ciertos lineamientos generales en cuestiones que puedan tener impacto fuera del equipo, pero cuestiones como el esquema de branching creo que no es una de esas cuestiones.

Al mismo tiempo quiero destacar que si bien recién estamos comenzando con el proyecto, la persona en el rol de Scrum Master me cae muy bien, creo que está haciendo un buen trabajo y si bien actualmente no codea lo hizo en el pasado.

Otra curiosidad es que en los lineamientos de arquitectura se asume en cierto modo que el equipo utilizará branches y merge-request, cuando en realidad la intención de nuestro equipo es hacer trunk-based development trabajando de pares para todo código productivo.

En fin, como conozco a uno de los referentes de arquitectura y me parece una persona bastante criteriosa y accesible lo llamé por teléfono para comentarle esta situación. Me explicó algo razonable: solo una persona por equipo tiene el permiso Maintainer y cuando se creo el proyecto el único miembro del equipo de desarrollo que estaba confirmado era el Scrum Master. Adicionalmente me explicó que lo que hizo arquitectura no fue establecer “reglas de piedra” sino lineamientos generales que surgieron del diálogo con diversos referentes de la organización y que pueden revisarse en cada caso particular. Esto también me resultó muy razonable. Más aún me parece muy sano cuando uno comienza un proyecto no se encuentre con la nada misma, está bueno tener algunos lineamientos que luego uno pueda debatir y eventualmente ajustar.

Cerrando la historia pinta que el equipo trabajará sobre un branch develop y luego en la salida a producción haremos el trámite de merge-master.

Nuevo proyecto, nuevos desafíos

Nuevo proyecto, nuevos desafíos

Esta semana estoy arrancando formalmente un nuevo proyecto. La semana pasada hicimos el descubrimiento de producto y como parte del mismo identificamos objetivos de negocio y métricas para medir el éxito. También definimos algunas cuestiones de estrategia tanto técnica como de negocio.

Entre los desafíos del proyecto hay algunas cuestiones que me parece relevante mencionar:

  1. Un equipo de desarrollo distribuido en 2 ciudades y conformado por personas de 4 organizaciones distintas.
  2. El uso de un conjunto de tecnologías de desarrollo (.net core y angular) en las que la mayoría del equipo no tiene experiencia.
  3. El uso de una infraestructura de ejecución (docker y kubernetes) en la que la mayoría del equipo no tiene experiencia.
  4. La necesidad de generar un entregable de valor en un tiempo máximo de 6 semanas.
  5. La integración con una aplicación legacy.
  6. Requerimientos concretos de accesibilidad.
  7. El uso de ciertas prácticas de desarrollo de cara a intentar asegurar la calidad del entregable (continuous delivery, test-automation, infra as code, etc)

Mi participación en el proyecto tiene que ver principalmente con ayudar en los puntos 2, 3 y 7.

Como parte del trabajo de discovery (que duró 3 días) generamos también algunos acuerdos de trabajo:

  • Trabajaremos en iteraciones de 2 semanas
  • El jueves será el día de las ceremonias de planning/review/retro
  • La daily standup será 9.30
  • El trabajo lo organizaremos en Jira
  • Para la comunicación diaria utilizaremos Microsoft Teams
  • Para el código utilizaremos GitLab
  • Jenkins será nuestro Build Server

Me gusta mucho que la daily sea tempranito pero no me gustan tanto las iteraciones de 2 semanas, sinceramente prefiero iteraciones de 1 semana, pero en bueno, es algo con lo que puedo vivir.

A medida que el proyecto vaya avanzando iré compartiendo novedades en este espacio.

Estructura de equipo para desarrollo de producto

Desde hace un tiempo estoy trabajando un equipo de producto de más de 20 personas y estamos organizados en una estructura que es nueva para mi pero que al mismo tiempo me parece viene resultando efectiva. La siguiente figura resume esta estructura.

Si bien todo el equipo de producto son más de 20 personas, en el día a día estamos divididos en 4 equipos: 3 feature teams y 1 equipo de toolsmiths (este nombre lo tomé del enfoque FDD, pero no es el nombre real del equipo)

Los 3 feature teams trabajan en funcionalidades del producto y están en el día a día con gente de negocio.

El equipo de toolsmiths es donde yo trabajo. Actuamos como proveedores/facilitadores de los features teams y nos encargamos de mantener/optimizar la infraestructura de desarrollo: repositorios, build server, ambientes, etc. Incluso en ocasiones agregamos código al producto, pero obviamente relacionado a cuestiones de soporte/infra como feature flags, health endpoints, etc. Como parte de nuestro trabajo tenemos que interactuar con otros grupos de soporte organizacional que se encargan de infraestructura de base y regulaciones (seguridad, red, etc). En el equipo somos 3 personas con skills mixtos: podemos codear, agregar tests, configurar servers, scriptear infraestructura pero sobre todo podemos hablar con otros grupos y generar concenso. Alguien podría tentarse de decir que somos DevOps, pero no lo vemos así, porque de entrada no creemos que DevOps sea ni un rol ni un área, sino un mindset con un conjunto de prácticas.

No se si este es el mejor enfoque para la estructura de un equipo de producto, pero consideramos que nos viene resultando bien: el negocio está contento, los distintos equipos están contentos, el producto está estable y tenemos la capacidad de ir a producción bajo demanda y de forma altamente automatizada.

Historia de un proyecto (no tan) ¿ágil?

En este momento estoy participando en dos proyectos, en uno tengo un rol técnico y en otro un rol más de gestión. A este segundo caso quiero referirme.

El objetivo de este proyecto es reemplazar una aplicación de escritorio con una aplicación web de manera que esta aplicación web ofrezca algunas funcionalidades adicionales. El equipo tiene varios developers y un tester. Yo me sumé al proyecto meses después del primer release (que llevó un 1 año) con el objetivo de intentar mejorar el flujo de trabajo ya que el equipo venia con algunos problemas de estimación, planificación y ejecución. Si bien el propio equipo decía estar trabajando “de forma ágil” en mi opinión no era así, pero a mi parecer esto no era un problema, ya que trabajar de forma ágil no lo veo como un fin en si mismo, sino como un medio para un fin. Desde la perspectiva del cliente el producto entregado estaba muy bien en términos de usabilidad, calidad, etc, pero el proyecto no estaba tan bien ya que el avance era lento y la fecha de fin de proyecto estaba retrasándose recurrentemente. El proyecto tenia una infrastructura de CI con muy pocos tests automatizados, pero con una importante cantidad de casos de pruebas de ejecución manual. El proceso de deployment estaba automatizado.

Lo primero que hice al sumarme al proyecto fue lo mismo de siempre: observar, preguntar y medir. Luego propuse algunos experimentos en la forma de estimar y planificar. A continuación propuse establecer una cadencia en el proceso de desarrollo, hasta ese momento el equipo hacía iteraciones de 10 días hábiles de desarrollo (coding y testing), lo cual hacía que los dias de review y planning cayeran en días variables. Ajustamos esto y establecimos los lunes (cada 2 semanas) como día de review+retro+planning. Todo esto ayudó a establecer un ritmo estable, predecible y facilitó la interacción con los usuarios. Estos cambios también fueron muy bienvenidos por el Product Owner. Antes cada cambio propuesto volvimos a medir para confirmar si se había producido una mejora concreta o no. La semana pasada acordamos establer una cadencia de release haciendo 1 release por mes.

Continuará…

Adivinanza: el proyecto con calidad

Advertencia: aunque el siguiente relato parezca ficción, doy mi palabra que es está basado en hechos reales.

Érase una vez una eṕoca en la que me toco trabjar en 2 proyectos en simultáneo. Pertenecian a organizaciones distintas. Ambos estaban construidos con la misma tecnología y ambos llevaban aproximadamente el mismo tiempo de desarrollo al momento que yo me sumé. Pero tenían algunas diferencias radicales.

A)
Un proyecto llevaba ya varios releases productivos y de hecho realizaba releases en forma frecuente. El otro proyecto tenía apenas un release que había ocurrido luego de casi 1 año de desarrollo.

B)
Un proyecto tenía pruebas automatizadas de distinto tipo que sumaban varios cientos: pruebas unitarias, de integración, de aceptación hasta incluso de performace. El otro proyecto no tenía más de 20 pruebas unitarias automatizadas, tenía muchos casos de prueba de ejecución manual pero que obviamente no se ejecutaban todo el tiempo.

C)
En un proyecto usaban trunk-based development y escribían todo el código haciendo pair-programming. En el otro proyecto usaban feature branches y merge-request/code-reviews.

D)
En un proyecto trabajaban a lo Extreme Programming. En el otro proyecto dicían hacer Scrum.

E)
En un proyecto el cliente estaba contento con los resultados y con la marcha del proyecto. En el otro proyecto el cliente no estaba contento con los resultado ni tampoco con como marchaba el proyecto.

En un proyecto me pidieron que los ayude a estabilizar el build y optimizar el tiempo que este tardaba en correr que solía rondar los 50 minutos. En el otro proyecto me pidieron dar una mano para mejorar la dinámica de trabjo en un sentido amplio.

Uno era el proyecto A y el otro era el proyecto B. Adivinen cual es cual.

Continuará…

DevOps: un camino bottom-up

Actualmente estoy trabajando en una institución bancaria colaborando entre otras cosas en una iniciativa DevOps. En forma resumida la iniciativa surgió a partir de varios equipos de desarrollo trabajando en paralelo de forma independiente. Cada equipo fue trazando “su propio camino a producción” con la colaboración de algunos miembros del equipo de infraestructura. Luego, por iniciativa de un gerente de desarrollo, representantes de cada equipo y algunos miembros del equipo infraestructura comenzaron a reunirse para compartir lo hecho por cada uno.

De esta forma, con un esquema de reuniones periódicas, vamos generando acuerdos a partir de las experiencias concretas de cada equipo. Las primeras reuniones fueron un poco caóticas, pero gradualmente van mejorando y agregando más valor. 

A mi parece el uso de un enfoque bottom-up en una institución bancaria es algo novedoso porque tradicionalmente este tipo de organización tienen más a los enfoques top-down. En dicho enfoques top-down hay generalmente un equipo/grupo/gerencia que define/diseña/toma decisiones y luego baja linea al resto de la organización imponiendo dinámicas y políticas que suelen no convencer a la gente que concretamente hace el trabajo de desarrollo/operación.

En los enfoques bottom-up como el que menciono aquí, el trabajo suele ser más lento pero a mi parecer más efectivo ya que se le da voz a los equipos y se construye a partir de su experiencias.

Nuevo proyecto: Arquitectura de Prueba

Una vez más me meto es cuestiones de automatización de pruebas y una vez más en un contexto bancario. Esta vez junto a mis estimados colegas de Grupo Esfera. Ayer hicimos el kickoff del proyecto y a continuación tuve una de las mejores sesiones de trabajo del año junto a mi amigo Diego Fontdevila. Estuvimos unas 2 horas revisando código, hablando de diseño, trade-offs y herramientas 😉

En términos genéricos el objetivo del proyecto es armar una arquitectura de prueba para facilitar/guiar a los equipos de desarrollo de la organización que trabajan en aplicaciones de canales y que deben integrarse con los sistemas core.

El stack de tecnologías con el que voy a estar trabajando incluye: Cucumber, Selenium, Pact, Java y AS400 entre otros.