3 elementos para una Arquitectura más Ágil

Esta semana me pidieron en un cliente si podía compartir algunas definiciones o lineamientos sobre agilidad en Arquitectura de Software, para trabajar en una reunión interna.

Como otras veces, después de pensar la respuesta y escribir un poco, les pedí permiso para compartir las ideas en este blog, y aquí van los tres elementos a los que llegué, a través de algunas preguntas de ellos:

Arquitectura incremental

Igual que con el diseño funcional, desconfiamos del "gran diseño preliminar", y tratamos de empezar con la arquitectura mínima necesaria para la funcionalidad que estamos encarando. Podemos hacer este ejercicio, idealmente, Sprint a Sprint, decidiendo sobre la arquitectura en cada planning.

IMPORTANTE: esto no implica que no iniciemos con algunos elementos mínimos de referencia, que nos son comunes (un lenguaje, un framework, una base de datos, etc). Es común que dentro de una organización tengamos algunos lineamientos (idealmente definidos de manera colaborativa). Lo que nos dejamos abierto es la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene.

Validación continua

Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayuda a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación.

Esa validación permanente en el entorno de desarrollo/QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico.

Demasiado importante para dejárselo a los Arquitectos

Como no diseñamos la arquitectura por completo en el inicio, tampoco se define desde un rol centralizado o mediante especialista en un silo. Aunque haya personas en el equipo con el título de Arquitecto, el tema se discute con todo el equipo y con los involucrados del negocio, y las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista.

Las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se validado o no en la implementación.

Nuevamente, este no quita que exista un equipo de Arquitectura Corporativa o algo similar. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación.

Finalmente, como para otras actividades, interese o tecnologías (testing, diseño, JS, bases de datos, temas de negocios) el intercambio y alineamiento de temas de arquitectura entre diferentes equipos se puede realizar mediante espacios de Comunidades de Práctica.

 

Continuando la discusión

Obviamente estas ideas están resumidas y tienen mucho más detrás. Si te interesa continuar este tema, algunas de las cosas en las que he trabajado a lo largo de los años son:

• El paper “Software Architecture in the Agile Life Cycle” que publicamos en 2010 con mi amigo y colega de la vida Diego Fontdevila.
  (Original en inglés, en el Architecture Journal; ó versión en español, actualizada en 2013)
• Mi libro en progreso, Agile Software Architecture.
• Mi Agile Architecture Workshop, que doy varias veces al año en distintas ciudades de América Latina
  (cuando hay fechas programadas aparecen a la derecha)
• Otros libros relacionados de colegas varios: 
• Building Evolutionary Architectures, de Rebecca Parsons, Neil Ford y Patrick Kua
• Lean Architecture, de James Coplien y Gertrud Bjørnvig

 

Colaboración real: lo que más cuesta lograr en los equipos

Trabajando con equipos que están adoptando Scrum (o algún otro framework ágil) suelo encontrarme escenarios como el siguiente:

• Trabajan en iteraciones (o sprints)
• Planifican al inicio
• Revisan al final
• Hacen retrospectivas (a veces) y tratan de mejorar

En muchos casos también tienen su reunión diaria (la daily standup o Scrum diario) y esos momentos suelen ser reveladores sobre qué están logrando como colaboración.

Antipatrón 1: cascada iterativa

Se nota al sincronizar que los miembros del equipo tienden a esperarse entre sí. Por ejemplo, alguien menciona que está terminando de diseñar X, que otro persona necesita para poder empezar a programar, para que finalmente otro pruebe...

Es frecuente en ese caso que algunos de los que no pueden continuar un item, inicien cualquier otra tarea (usualmente de menor prioridad) en la que no tengan trabas.

Obviamente, cuando se libera el ítem de más prioridad, es común que quede en espera hasta que se termine alguna de esas tareas menos prioritarias.

Antipatrón 2: sobre-especialización

También podemos notar que en diferentes momentos ciertos ítems se acumulan y quedan pendientes para un especialista en particular, dependiendo del momento en que estamos del proyecto. En algún momento puede ser que haya mucho por hacer en la interfaz de usuario, y la persona a cargo queda desbordada, mientras los demás, nuevamente, comienzan a trabajar en lo que puedan.

En el extremo, se nota en ciertas iteraciones que algunos de los miembros del equipo están llenos de trabajo, mientras que otros no tienen mucho que hacer.

La magia de trabajar de a pares

Es problema de estos escenarios es que ese grupo no está colaborando realmente. De hecho, no es un equipo ágil, sino un grupo con apenas un objetivo común, por más sincronización diaria que hagan.

Un equipo ágil se enfoca en la prioridad; en el valor de negocio. Por lo tanto, antes que iniciar ítems de menos prioridad, cada persona busca oportunidades de colaborar con quien ya inició un ítem más prioritario, con varios objetivos:

• Tratar de terminar cuanto antes lo que tiene más valor
• Ayudar a mantener el foco y evitar bloqueos mentales frecuentes cuando trabajamos solos
• Aprender lo básico de las especialidades del resto del equipo, para que poco a poco muchas tareas triviales (que estadísticamente son la mayor parte de un proyecto) puedan ser resueltas por cualquiera.
• Lograr mayor integridad conceptual en el producto, al compartir con todo el equipo una visión holística, donde el equipo entero es responsable por el total, y no por diferentes componentes o aspectos.

¿Todo hay que hacerlo de a dos?

No necesariamente. De hecho, aunque suena raro, si un equipo empieza a trabajar de a pares más frecuentemente, va aumentando la capacidad de cada miembro de encarar solo cualquier tarea. Pero a la vez aumenta la facilidad con que cualquiera puede pedir ayuda (cosa que para mucha gente es una enorme barrera) a otros.

Lo que suele ocurrir es que las personas tienden a trabajar solas en las tareas más sencillas y triviales (con un poco de aprendizaje, incluso las que están fuera de su especialidad) y les resulta casi natural reunirse y dividirse de manera fluida según sus necesidades.

Colaboración real en equipos

Dentro de los equipos ágiles, en definitiva, se busca que a través del aprendizaje colectivo podamos extender las capacidades de cada persona más allá de su especialidad. Esto no significa que ignoramos el estudio y experiencia acumulada de cada uno, ni que queremos que todos sean absolutamente expertos en todo.

Lo que busca un equipo ágil es aplicar el principio de Pareto a las capacidades individuales, es decir que cada persona aprenda aproximadamente el 20% de las especialidades del resto del equipo, que suelen resolver el 80% de su trabajo.

En definitiva, buscamos poder distribuir más uniformemente el trabajo, aprovechando al máximo los conocimientos muy específicos solamente en esos pocos casos en que se plantean problemas tan complejos que requerimos todo el poder del "experto".

Finalmente, esta forma de trabajo es la que apoya el principio ágil de enfocarnos en la entrega de valor, ya que nadie necesita estar haciendo nada que no sea de la mayor prioridad.

Literatura Potencial al Aire Libre

Durante la reciente edición 2018 del Agile Open Camp, en Bariloche, Argentina, presenté una charla relámpago (21 slides de 20 segundos cada uno; 7 minutos en total) que titulé “Restricciones para la Creatividad” y en la que contaba sobre el Oulipo, el “Ouvroir de littérature potentielle” que en los años '60 fundaron en Francia escritores de diferentes orígenes, dedicado a explorar las posibilidades de restricciones auto-impuestas, surgidas sobre todo de las matemáticas y sus derivados (como la música o el ajedrez) para desencadenar procesos creativos.

Debajo queda la presentación, aunque son sólo imágenes. Pero más importante que eso, para mi, es el libro que tiene el mismo título que este post, resultado del taller que realizamos más tarde, durante una sesión del Open Space.

Los asistentes escribieron varios Haiku, y luego comenzaron cuatro cuentos, algunos de los cuales fueron finalizados días más tarde. El librito es una compilación de esos trabajos, más una breve introducción que recupera (con notas adicionales) parte de la charla relámpago.

Gracias a Marta Bendomir, Tommy Christie, Marcela Pelz y María Thompson por participar del taller y del libro, y gracias a Manuel Mandrafina Thompson que colaboró en el cierre de uno de los cuentos.

El libro puede descargarse en forma libre y gratuita desde aquí (o desde la imagen de tapa más arriba).

Espacios de Trabajo para Equipos Ágiles

Este es un tema recurrente con muchas organizaciones a las que ayudo. Como el foco principal del paradigma ágil es la colaboración, muchas veces llega un momento en que ellos notan que sus espacio de trabajo no son ideales para lo que intentan lograr.

 

Espacios frágiles

Los espacios de trabajo más nocivos que me encuentro suelen incluir desde cubículos hasta oficinas individuales a puerta cerrada. Y aclaro que he trabajado en lugares así, aunque nunca fue mi preferencia. Durante un tiempo -hace muchos años- me tocó una oficina privada, alejada por un pasillo largo del equipo que me tocaba liderar. Al principio me sentí inocentemente importante, pero pronto me di cuenta de que esa distancia no nos beneficiaba en nada.

Algunas variantes de los cubículos son los espacios semi-abiertos con escritorios con divisiones más bajas, que permiten verle los ojos a la persona de enfrente, aunque no alientan una colaboración más allá e una pregunta o conversación esporádica.

Y no sólo los espacios físicos generan fricción. Muchos espacios virtuales también lo son. Muchas de las llamadas "herramientas de colaboración" me resultan consistentemente un impedimento a la conversación cara a cara. A riesgo de controversia, no he visto nunca un equipo que mejore su comunicación (pero si montones que definitivamente empeoraron) por usar Jira, Sharepoint u otras monstruosidades que están más diseñadas para calmar al management que para que la gente se auto-organice.

 

Espacios con "Onda Ágil"

Muchas organizaciones, al sentir que la gente se entusiasma con la agilidad, quieren crear lugares atractivos para atraer talento que espera determinadas características laborales que no son tan fáciles de transmitir a simple vista. Así que recurren al folklore y no muy extrañamente, atraen a los estereotipos a los que se dirigen, lo que no siempre da resultado.

Clásicos de ese estilo son las metegoles (o futbolines, según la región), las paredes ploteadas con íconos y slogans sobre creatividad, innovación y talento, aunque frecuentemente esos y otros valores están en las paredes pero no se sienten en el día a día. En algunos extremos (que creo bien intencionados) se ven exaltaciones a los super-héroes, los rock-stars o ninjas. Como si colaborar fuese tratar de ir solo contra todo, inmolándose por alguna causa esquiva.

 

¿Espacios realmente ágiles?

Mis consejos para quienes quieren realmente generar un ambiente de colaboración y dinamismo van siempre en el mismo sentido: empezar por no definir todo, sino dejar lo máximo posible a criterio de los equipos que usarán el lugar.

Para eso, realmente suele ser preferible contar con espacios abiertos, pero como pueden ser ruidosos, se puede recurrir a elementos que la gente pueda usar para crear sub-espacios flexibles y reconfigurables.

Algunos de los elementos que prefiero (por experiencia, como materia mínima para que los equipos decidan después):

• Mesas pequeñas, con patas no intrusivas, donde al menos se pueda trabajar de a dos. O livianas o con rueditas.
  
  
• Tomas de corriente a granel, sobre las paredes. Y que los equipos puedan poner sus (inevitables) extensiones por donde quieran. Si los cables se tornan molestos o peligrosos, ellos deberían encontrar la mejor solución, no un "arquitecto".
  
  
• Pizarras o bastidores fáciles de mover (con rueditas o livianos) pueden servir como separadores, aislantes acústicos y también como soporte para radiadores visuales.
  
  
• Paredes libres (también pueden ser ventanas o paneles de vidrio), sin inscripciones, emblemas ni slogans previos. El uso de las paredes para pegar tableros, indicadores, información necesaria para el equipo, es vital para la comunicación osmótica. Los pizarrones de diferente tipo, sobre todo si son móviles, son un buen recurso para discusiones y diagramas efímeros.
  
  
• Buenas sillas. Pensando que los trabajadores del conocimiento usamos sobre todos nuestro cerebro y nuestro trasero, tener buenas sillas (de nuevo, móviles) es una excelente inversión para cuidar la salud y comodidad de los equipos.

Sobre todo, si queremos promover un ambiente de autonomía y creatividad, demos los elementos básicos y dejemos que los equipos se apropien. Lo que no significa dejarlos a la deriva. Se puede explícitamente pedirles que determinen un plan, tal vez con un presupuesto básico y posibles extensiones iterativas.

Varias veces vi que se diseñan espacios incluyendo áreas de "esparcimiento" para los equipos, donde se incluyen equipos de videojuegos, mesas de ping-pong o instrumentos musicales. Pero este nuevamente es per-determinar qué es lo que ellos querrán, en lugar de preguntarles. Tal vez terminen poniendo la consola de juegos, pero ellos elegirán cuál prefieren y cómo instalarla. O tal vez prefieran otra cosa, como un espacio para cocinar o para hacer yoga.

En definitiva, al pensar espacios ágiles, tenemos que mantener sus principios: flexibilidad, transparencia, diversidad.

Si alguno tiene interés en compartir los espacios que generaron, pueden mandarme fotos, y veo cómo compartirlas.

 

Cómo escribir tu propio intérprete (o compilador)

Suelo escuchar varios podcast mientras me muevo por Buenos Aires u otras ciudades en mi trabajo. Uno de los que sigo desde hace años es el de Scott Hanselman, que es quizá una de las personas que más me impactó dentro de lo que se conoce como la "comunidad Microsoft".

Scott, más allá de seguir trabajando para Microsoft en el grupo de ASP.NET y herramientas de Azure, es un tipo inquieto que mantiene varios podcasts e iniciativas, y sobre todo valoro su constante esfuerzo por lograr una industria más inclusiva, recibiendo a a gente de toda edad, raza, identidad u orientación sexual, religión o ideario.

Pero basta de elogios al amigo Scott. El tema que me atrajo especialmente en éste último podcast fue que entrevistaba a Thorsten Ball, quien auto-publicó el libro "Writing An Interpreter In Go", que trata básicamente de eso: recorre todos los pasos de escritura de un intérprete. En su caso del lenguaje Monkey que él diseñó para el libro mismo, y que es bastante similar a JavaScript o un montón de otros lenguajes de la familia de las llaves {}.

Más allá de que es un tema interesante, me gustó que la manera en que lo hace es utilizando lo más básico de Go, sin más que la librería standard, construyendo desde cero el parser y el lexer, y sin usar ninguna librería particular. Y por supuesto, utilizando TDD.

Es un libro que recorre en mayor detalle el camino constante del Maestro Ángel Java López, que como puede verse en su cuenta de GitHub escribe este tipo de intérpretes o compiladores todo el tiempo.

¿Por qué escribir un intérprete a esta altura? Básicamente porque las capacidades y el entendimiento de sus partes nos ayudan a ser mejores programadores en general, como llegado cierto punto un buen automovilista tiene que aprender de mecánica, o un rocker necesita aprender sobre ingeniería de sonido.