La estructura de Scrum

Siguiendo con la premisa de que Scrum es "fácil de entender, pero difícil de dominar", avancemos con la parte fácil. 😁

Scrum está compuesto, además de sus pilares y valores, por una serie de artefactos, eventos y roles.

AVISO
Este artículo es una guía inicial, que se irá completando con links a detalles más completos (en artículos separados) a lo largo de las próximas semanas.

---

 Artefactos -> Transparencia

Los llamados "artefactos" de Scrum son elementos mínimos para lograr alto grado de transparencia respecto al planes, trabajo pendiente y resultados obtenidos.

Product Backlog

El Backlog (o Pila) de Producto es una lista ordenada de todo lo que el producto pueda necesitar. Es una lista en constante evolución, dinámica, y es la única fuente de trabajo para el equipo.

El orden en que están los ítems del Product Backlog transparentan la visión y estrategia de producto que clientes, gente de negocio y equipo comparten, poniendo énfasis en que lo que está en los primeros lugares es lo que queremos que el producto tenga en el más corto plazo.

Sprint Backlog

El Backlog (o Pila) del Sprint es un subconjunto del Product Backlog, seleccionado por el equipo para trabajar en un Sprint (o iteración), al que se agrega un plan de cómo convertir esos ítems en un incremento de producto cumpliendo el objetivo del Sprint.

El Sprint Backlog transparenta el trabajo del equipo durante el sprint, incluyendo el objetivo general y otros indicadores que sirvan al equipo y al resto de la organización.

Product Increment

El Incremento de Producto es la suma de todos los ítems del Product Backlog terminados durante el Sprint, agregado al valor obtenido en todos los Sprints anteriores.

Este Incremento transparenta de manera radical el estado del producto. Es una versión del producto utilizable y completa, independientemente de que se decida entregarlo o no a la audiencia final.

Para  asegurar esa usabilidad, el Incremento debe cumplir con la Definition of Done (definición de terminado) que el equipo tiene acordada.

---

Eventos -> Inspección y Adaptación

Los eventos de Scrum brindan la estructura temporal mínima, evitan reuniones adicionales, y tratan de minimizar el desperdicio de tiempo y esfuerzo.

Sprint

El Sprint (iteración) es el corazón de Scrum. Es un contenedor de todos los demás eventos más el trabajo regular de desarrollo. Marca el pulso de trabajo, siendo su duración inalterable y estable a lo largo del ciclo de vida del producto.

Cada Sprint comienza con una planificación de su Objetivo y su Sprint Backlog, trabajo de desarrollo de producto, que se sincroniza diariamente, un Incremento de Producto que es revisado sobre el final, y un espacio de reflexión para la mejora continua.

Sprint Planning

Al inicio de cada Sprint, el equipo se reúne para definir el Objetivo del Sprint, y seleccionar los ítems del Product Backlog en los que trabajarán para cumplirlo. Esos ítems, junto con información  adicional de cómo desarrollarlos, se convierten en el Product Backlog.

En la Planning el equipo inspecciona las expectativas de corto plazo sobre el producto y adapta su estrategia para lograr un resultado concreto.

Daily Scrum

Todos los días a la misma hora y el mismo lugar, el equipo se reúne durante un máximo de 15 minutos para inspeccionar cómo avanza hacia el objetivo del Sprint y adaptar sus planes para alcanzarlo.

El resto del día, a excepción de los eventos de inicio y fin del Sprint, el equipo se dedica al desarrollo del producto mismo.

Sprint Review

Sobre el final del Sprint, el equipo colabora con clientes, gente de negocios u otros interesados para inspeccionar el Product Increment, de manera de poder adaptar, a través de actualizaciones al Product Backlog y un entendimiento común, los planes hacia adelante.

Sprint Retrospective

La "Retro" es una oportunidad para que el equipo se auto-inspeccione, y adapte su manera de trabajar, mejorando de manera continua.

Es el momento principal en que el equipo decide cómo le conviene hacer todo lo que Scrum no dice, como temas de relacionamiento, técnicos, de comunicación, organizacionales, y otros.

---

Roles

Un equipo Scrum tiene solamente tres roles internos: el Development Team (o equipo de desarrollo), formado por múltiples profesionales, y otros dos que son individuales, el Product Owner y el Scrum Master.

La suma de las personas cubriendo estos tres roles en un equipo es lo que se llama Scrum Team (o equipo Scrum).

Todas las personas interesadas en el producto que pueden interactuar con el Scrum Team pero no forman parte de él son llamados Stakeholders, o involucrados. Entre ellos puede haber clientes, personas de negocios, personas de otras áreas de la organización que tienen influencia sobre el producto, como marketing, legales, tecnología, atención a clientes, y también personas externas a la organización como consultores, auditores, analistas de mercado, y muchos otros.

Development Team

Es un grupo multi-disciplinario de profesionales que se encargan de entregar un incremento de producto utilizable al final de cada Sprint.

Product Owner

Es la responsable de maximizar el valor del producto que entrega el Development Team. La manera en que lo hace es muy diferente en cada equipo, pero se centra alrededor de la administración del Product Backlog.

Scrum Master

Es la responsable de promover y dar soporte a Scrum, ayudando a que todos comprendan y usen apropiadamente sus valores, prácticas y reglas.

Pilares y Valores de Scrum

Una contradicción frecuente en personas y organizaciones interesadas en adoptar Scrum es que no se resignan a dejar de preguntar cosas como: "¿Cuándo va a estar lista exactamente ésta característica del producto tal cuál yo pedí?"

La pregunta no está mal en sí misma, pero corresponde a lo que se conoce como "Control de procesos definidos", donde tenemos un plan establecido, y el alcance del proyecto/producto está completamente cerrado. Este tipo de procesos sigue siendo útil en temas como la ingeniería civil, o la industria de la construcción, por milenios, aunque como sabemos, las predicciones en este modelo muchas vez no son correctas.

Procesos de Control Empírico

Scrum no sirve como modelo predictivo, porque se encuadra dentro del modelo empírico. Este modelo se aplica cuando aceptamos que el nivel de incertidumbre de nuestro desafío es alto.

No por casualidad, Scrum tiene mucho éxito en lo que llamamos contextos VICA:

• Volatilidad
• Incertidumbre
• Complejidad
• Ambigüedad

De este estilo de control de procesos Scrum hereda sus tres pilares fundamentales.

Pilares de Scrum

Transparencia, Inspección y Adaptación

Podemos recorrer estos tres principios pensando en la pregunta original. Si el problema es complejo y la solución es incierta, ¿cómo podemos entonces saber cómo vamos?

La transparencia en Scrum es de doble vía: los clientes o el "negocio" deben brindar información concreta al equipo sobre sus hipótesis, objetivos y dependencias, y el equipo debe dar transparencia de sus planes, decisiones y sobre todo, resultados.

En base a esos datos, y en iteraciones cortas, el equipo mostrará resultados concretos (no planes, diseños ni porcentajes, sino un producto funcional) que inspeccionarán junto a los clientes o "negocio", entendiendo:

• Decisiones acertadas o no
• Hipótesis de negocio comprobadas o no
• Calidad del producto
• Estado actual frente a un contexto volátil
• Comprensión correcta entre todos, en un entorno ambiguo

Basados en este aprendizaje, el equipo y sus clientes adaptan su plan hacia adelante, poniendo en juego una nueva serie de premisas, objetivos de corto plazo y estrategias.

Todo esto se repite en ciclos permanentes, ya que los procesos empíricos se basan casualmente en la iteración continua.

Pero Scrum agrega a estos pilares una serie de principios que se encuentran detrás de cada uno de los roles, eventos y artefactos, junto con los pilares.

Valores de Scrum

Compromiso, Coraje, Foco, Apertura, Respeto

Estos valores, que muchas veces se ignoran en adopciones de Scrum, tomando solamente la parte mecánica (los roles, eventos y artefactos) son los que revelan la intención detrás del marco de trabajo, y permiten entender mejor el porqué de cada pieza.

Veamos un poco el origen de estas palabras (en su versión inglesa original) y porqué tienen tanta importancia en Scrum:

Compromiso (commitment)

Viene de "confiar a alguien, delegar autoridad", y refiere a unirse por un objetivo común.

En Scrum, los miembros del equipo se comprometen de manera personal, para cumplir con un objetivo colectivo. Dentro del equipo cada uno es responsable y rinde cuentas a los demás, pero hacia fuera comparten una responsabilidad y rinden cuentas como grupo.

La importancia de este principio es que no se puede afectar la autonomía del equipo como tal, tratando de "gestionar" a miembros individuales, ni se puede reducir ese compromiso haciendo que los miembros tengan responsabilidades fuera de su equipo.

Coraje (courage)

Originalmente, "desde el corazón", se entiende como el tomar acción en base a nuestras creencias o principios.

En Scrum, se espera que el equipo mantenga los principios de Scrum y sus acuerdos, sobre todo cuando no sea fácil hacerlo. Tiene que ver con "hacer lo correcto, de la manera correcta", y refiere a mantener el objetivo común y la calidad técnica, pero implica un alto nivel de autonomía.

Un equipo Scrum no puede sentirse limitado por decisiones externas, y constantemente cuestionará normas o políticas que no considere positivas para alcanzar sus resultados de manera sostenible.

Foco (focus)

Proviene de "fuego", y tiene que ver con reunirse alrededor de la fuente de calor. Por eso lo usamos para algo que nos mantiene "mirando hacia ese lado".

Scrum es una manera de mantener al equipo permanentemente enfocado en el trabajo de la iteración actual (sin preocuparse por detalles de lo que vendrá, más allá de la visión de conjunto) y de sus objetivos como equipo, que surgen siempre de lo que es importante "ahora" para el producto.

Apertura (openess)

Algo abierto es algo expuesto y evidente.

En Scrum (dado el pilar de transparencia) se expone abiertamente tanto el plan, el trabajo en marcha, los resultados, y sobre todo, los desafíos (del equipo, de la organización, del producto, del mercado, de los clientes, y otros).

La apertura en cuanto a todo, incluyendo feedback abierto sobre todos los temas, permiten efectuar todo el tiempo el proceso de inspección y adaptación.

Respecto (respect)

Refiere originalmente a "ver" o "volver a mirar", y significa apreciar sinceramente las características únicas de otras personas.

En Scrum se propicia el respeto cruzado, de los clientes hacia la capacidad y autonomía del equipo, del equipo al entendimiento del negocio y sus desafíos de los clientes, pero también entre cada miembro del equipo, y por sus roles y responsabilidades.

Pero ese respeto implica que todo está abierto a cuestionamientos, de manera amable, con el objetivo de que las partes se entiendan lo mejor posible, elevando siempre la transparencia.

¿Y cuál es la respuesta?

Antes de comprender la estructura de Scrum, entonces, es importante entender que podemos preguntar o no.

Esto no quiere decir que no podamos tener fechas límites, o limitaciones de presupuesto. Lo que no trata de hacer Scrum es predecir nada.

Scrum no es un modelo predictivo, es un modelo adaptativo.

Las preguntas constantes en Scrum serán entonces, inspeccionando el producto frecuentemente:

• ¿El producto agrega valor?
• ¿Estamos más cerca de resolver el problema?
• ¿Vale la pena seguir adelante, o hay otro problema más valioso por resolver?

Y así, mediante continua inspección y adaptación, en muchos casos podremos tener resultados mejores a los que tenemos tratando de cumplir con predicciones que ya no son relevantes.

¿Qué es Scrum y para qué se usa?

Aquí comienza una serie de artículos en que intentaré describir el marco de trabajo Scrum, cubriendo temas que en su momento no quedaron incluidos en el libro "Proyectos Ágiles con Scrum" que escribimos con mi amigo Martín Alaimo. Tal vez al terminar la serie tenga el material para una nueva edición, o para un libro nuevo, pero eso ya lo veremos.

Sitio de la Guía de Scrum

¿Qué es Scrum?

Según la Scrum Guide (la guía oficial que mantienen Ken Schwaber y Jeff Sutherland, los desarrolladores originales) Scrum es (mi traducción):

Un marco de trabajo en el que las personas abordan problemas adaptativos complejos, mientras entregan productos del mayor valor posible de manera productiva y creativa.

Me gusta esa  definición que fue evolucionando a lo largo del tiempo, pero voy a tratar de analizarla por partes, para evitar algunas confusiones comunes.

Un marco de trabajo...

Como dicen los autores, Scrum no es un proceso, ni una técnica, ni un método definido. Es un marco intencionalmente incompleto.

Scrum brinda apenas un conjunto mínimo de Roles, Eventos, Artefactos y las reglas que los enlazan, sin entrar en detalles profundos sobre los mismos. Scrum no viene "listo para usar", y no es algo que un equipo (mucho menos varios equipos) pueden aprender y dominar en un par de semanas.

Scrum requiere paciencia para adaptarlo constantemente, y no hay una situación en la que alcanzamos el "máximo nivel posible". Como con casi todo sistema de mejora continua, si creemos que ya alcanzamos el máximo rendimiento, seguramente estamos en graves problemas.

...en el que las personas...

Esto es fundamental, y es fuente de muchísimas confusiones. Scrum no es una herramienta de management, al menos en el sentido tradicional. No es un marco para dirigir y controlar "recursos". Es un marco en el que las personas, individualmente y como equipo, se auto-organizan para lograr un objetivo común.

...abordan problemas adaptativos complejos, mientras entregan productos...

Scrum no es útil para problemas bien definidos o de baja complejidad. Por ejemplo, es probable que no aporte valor en un proceso de manufactura o prestación de servicios en serie, una vez que estos ya fueron definidos. Incluso si en ambos casos se puede aplicar mejorar continua, hay marcos mas útiles.

Mas allá de que Scrum es utilizado cada vez en más industrias y áreas, en líneas generales aplica al desarrollo de productos (o servicios) a lo largo de todo su ciclo de vida.

Pero tampoco es una definición exacta. Por la dificultad de determinar qué es un productoy que no. Y también porque nuestro contexto es cada vez más complejo.

...del mayor valor posible de manera productiva y creativa

El gran aporte de Scrum (al igual que otros marcos ágiles) es la entrega continua y frecuente de un producto para resolver ese problema adaptativo complejo.

La productividad de Scrum está basada en que el equipo de trabajo usa su creatividad y auto-organización para entregar un producto que se puede observar en períodos muy cortos, sobre el que se puede reflexionar y ajustar para seguir desarrollándolo.

Es común ver adopciones de Scrum que no ponen énfasis en entregar producto de forma frecuente, o sólo lo hacen a nivel interno, sin ponerlo en producción, ó lanzarlo al mercado, ni siquiera para una audiencia reducida que luego vaya en aumento.

Otras características

Una a frase adicional que destaca otras características de Scrum es que "es un marco de trabajo liviano, simple de comprender, pero difícil de dominar".

Es liviano porque no requiere demasiada supervisión. Por lo contrario, lo que suele costar en organizaciones con alto nivel de formalidad, es que requiere menos supervisión y más delegación de responsabilidades.

Es tan simple de comprender que los cursos iniciales son de dos días como máximo, y la Guía mencionada tiene menos de 20 páginas, que al quitar portada, índice, agradecimientos y demás agregados llegan apenas a una docena.

Pero es difícil de dominar porque requiere práctica y adaptación al problema, el producto, el equipo, la organización y muchas otras variables que hacen al contexto en que será utilizado. Al no haber una receta, depende del equipo mismo. La buena noticia es que Scrum sirve casualmente para eso, para ayudar a que un equipo madure de manera continua mientras entrega incrementalmente un producto.

Hacia adelante

Esta definición es de muy alto nivel, y lo que queda para entender Scrum, a través del resto de esta serie, son sus elementos:

(nota: en la serie utilizaré para la mayoría de los elementos los nombres originales en inglés, ya que las traducciones pueden ser ambiguas, y son términos sencillos y muy utilizados)

• Pilares: Transparencia, Inspección y Adaptación
• Valores: Compromiso, Coraje, Foco, Apertura y Respeto
• Estructura general
• Artefactos: Product Backlog, Sprint Backlog, Product Increment
• Eventos: Sprint, Planning, Daily Scrum, Review, Retrospective
• Roles: Development Team, Product Owner, Scrum Master (y stakeholders)
• y las pocas reglas que los vinculan: 
• Definition of Done
• Refinement

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.

Codewars: jugar, practicar, codear

Hace unos días recordé este sitio que conocí hace unos años, al verlo mencionado en un tweet de mi amigo el Maestro.

A raíz de esa mención volví a visitarlo y me alegró ver cuánto progreso mientras yo no estaba mirando.

Codewars es básicamente un sitio de práctica. Está basado en la idea de Code Katas, pero extendido a formas adicionales como el Kumite (una especie de competencia entre desarrolladores), y todo en un entorno colaborativo donde los participantes mismos son quienes agregan y refinan los ejercicios, también votando y comentando tanto los planteos como las distintas soluciones.

Entre las características que más me gustaron es que hay:

• Diferentes niveles de dificultad
• Tags que agrupan los ejercicios por temas, niveles, foco
• Alto nivel de gamification: los participantes tenemos Kyu (niveles), Honor (puntos acumulados), seguidores, clanes y medallas entre muchas otras característica que generan una comunidad vibrante
• Foros y comentarios bien integrados
• Un gran contenido gratuito soportado por publicidad, pero que está bien integrada y es relevante (son siempre productos o servicios de desarrollo y los avisos no son molestos), más una oferta paga económica y que más allá de ofrecer unas pocas características avanzadas para quienes realmente le dedican mucho tiempo, es casi una membresía a un club de amigos.
• Y sobre todo, la chance de aprender y/o practicar en una variedad enorme de lenguajes:
  (en este momento) C, Clojure, CoffeeScript, C++, Crystal, C#, Dart, Elixir, F#, Go, Haskell, Java, JavaScript, Lua, Objective-C, OCaml, PHP, Python, Ruby, Rust, Shell, SQL, Swift, Typescript, y otros que todavía no tienen Katas, pero están en proceso, como: CSS3, D, Erlang, Groovy, Julia, Kotlin, Liso, Perl, R, Racket, Sass y Scala.

Para los que ya saben que soy un enfermo de los lenguajes de programación, se dan cuenta que esto es un picnic para mi.

Recién retomé, y usualmente esto es para mi un equivalente a mirar series o jugar videojuegos: un pasatiempo estimulante. Los que quieran pueden encontrarme en Codewars y eventualmente podemos hacer un Kumite.

Katas de Arquitectura

Un año atrás mi amiga Rox (¡que viva México!) me hizo una consulta por mail que acordamos compartir. Me demoré un poco, pero aquí va.

Primero copio su consulta:

Mañana tengo una sesión de kata de arquitectura con un equipo.  El objetivo principal no es la arquitectura en sí, sino un problema que tienen en partir en historias de usuario porque la mayoría de sus requerimientos son no-funcionales y dicen que no se puede.

Así que pensé en hacer un experimento: mezclar la kata de arquitectura con una kata de User Story Splitting.

Así que estoy en el sitio, pero veo que faltan los requerimientos no-funcionales que se agregan y recuerdo que tenías unas cartas.

¿Son los "normales" (escalabilidad, performance, mantenibilidad, etc)? o ¿cuáles son?

Y ahora mi respuesta (ampliada con algún material extra que no incluí en el mensaje original, que pongo entre [corchetes]):

---

¡Hola, Rox! 

Te paso el material:

• Las Katas de Arquitectura en español    [y aquí el sitio original en inglés]
  
  
• Y mi Tarot de Arquitectura
  
  
• [agrego también la guía ágil de patrones de slicing - que a su vez tiene el link a las tarjetas con los patrones]

 

Pero... me suena raro que quieran hacer historias de usuario sobre requisitos no funcionales, que es algo que no recomiendo, salvo que esté originado en un problema de negocio concreto (por ejemplo, la App se pone demasiado lenta cuando hay más de N usuarios).

Las cartas de Tarot están pensadas para discutir esos temas con la gente de negocio *en el contexto* de una historia funcional. 

Trataría de que para los atributos que quieren mejorar definan y anoten explícitamente:

Contexto

¿Por qué es importante este tema? Entender la operación detrás de este tema en un proceso concreto. No pensar que la aplicación tiene que escalar a tantos usuarios, sino lo como 'la transacción de pago de una orden' debe poder soportar tantas sesiones concurrentes.

Métrica 

¿Cómo vamos a medir que estamos en el nivel que queremos? Siguiendo el ejemplo anterior, puede ser cuánto tiempo demora para 1, 5, 10 o 30 transacciones concurrentes, y ponerle tiempos JUNTO con la gente de negocio.

Esto luego, idealmente se escribe en pruebas automatizadas que corren al menos en el build nocturno. 

Decisión 

¿Cómo hacemos para lograr esa métrica?

Acá es donde nos concentramos en 'lo técnico'. ¿Hacemos un componente que escale en threads? ¿Usamos una queue? ¿Cuál? Esto se va a convertir en una o más tareas, de una o más historias.

3 dudas sobre Extreme Programming

Esta semana una asistente a uno de mis talleres de Desarrollo Ágil de Software me envío estas consultas, que como acordamos, intento contestar aquí de manera abierta, para ella y para otros que puedan tener esas dudas.

Hola Martín!

Saludos desde Lima.

Disfruté mucho el taller de Desarrollo de software ágil, ya lo estoy recomendando.... al pasar los días me surgieron unas preguntas que cuando tengas oportunidad por fa me escribes...

Vale la pena aclarar que yo voy a dar mi opinión personal. Yo empecé a utilizar ideas de Extreme Programming (XP) a fines de los '90 y a principios de los 2000 me convertí (se ve que no había mucho más para elegir) en XP Coach de varios equipos. En todo ese tiempo he juntado muchas ideas y dudas nuevas, pero trataré de aportar alternativas y vías de exploración, ya que no creo en que haya UNA respuesta para estos temas.

 

1- Una vez que se decide adoptar XP. El pair programming se aplica todo el tiempo? O se da cabida a espacios para programar individualmente y mob programming?  

Aunque en los orígenes de XP esa era la idea, en la práctica y a medida que ha pasado el tiempo la práctica se ha vuelto más pragmática. Recordemos siempre que a pesar del nombre, XP está basado en principios y valores que son los que buscamos, y las prácticas son solo un reflejo adaptable de ellos.

Cuando la solución más sencilla (recordemos que la Simplicidad es primordial en XP) es escribir el código de a uno, no vale la pena buscar un par. Los casos típicos son los que son triviales: construir otra pantalla, adaptador o función que es una variante particular de otras que ya están hechas.

Cuando el desafío es bajo y las tareas son de muy bajo riesgo, podemos obviar el par. Ahora, cuando nos encontramos realizando tareas repetitivas pero que pueden ser críticas, podemos al menos mantener un criterio de revisión de a pares. Lejos de la programación, en Kleer siempre hacemos revisión de a pares para propuestas o presupuestos.

Mob Programming es todavía una técnica relativamente experimental como práctica continua, pero en varias oportunidades en distintos equipos en los que trabajé pasamos de programar de a pares a tríos o cuartetos. Cuando uno pasa ese límite es difícil trabajar con un monitor usual y el salto a un proyector o una pantalla grande  implica un reacomodamiento mayor. Un paso intermedio usual es realizar workshops de diseño en conjunto para definir componentes de arquitectura, refactorizaciones importantes a nivel de framework o para ensayar alternativas de diseño con todo el equipo.

En todos los casos lo que funciona es probar y aprender. Una de las premisas es que si no experimentamos en la búsqueda de mejores maneras de trabajar como equipo, siempre estaremos ocupados pero probablemente desperdiciando esfuerzo.

 

2- Se puede aplicar TDD o BDD a proyectos que ya han empezado de la manera tradicional (sin metodologia de desarrollo agil o casos de prueba?) o tiene que ser proyectos que aún no hayan arrancado?  

Claro que si. Lo más sencillo es usar TDD para código nuevo aunque la solución sea vieja. Un poco más complejo es construir la infraestructura de pruebas en el código antiguo. Para eso utilizamos una serie de técnicas especiales para romper dependencias fuertes en el código. La referencia canónica para esto es el excelente libro de Michael Feathers, Working Effectively with Legacy Code.

Básicamente, mientras haces TDD para el código nuevo, vas necesitando desacoplar la parte del código viejo con el que hay que interactuar, y para eso hay que ir logrando desarmarlo e ir dejando algunas pruebas que nos ayuden en esa tarea.

Algo que si desaconsejo es generar proyectos de "refactorización pura". Cuando nos ponemos exquisitos en cuanto a la calidad del código sin tener en cuenta las necesidades reales de la organización o sus clientes, nos arriesgamos a entrar en un proyecto con objetivos poco claros. Mejor que eso es comprometernos a usar estas técnicas para mejorar el código relacionado con la funcionalidad que necesitamos modificar, y esa manera, con el pasar del tiempo, las partes del código que requieren más cambios (lo que de alguna manera demuestra que son más valiosas) irán mejorando y serán más fáciles de entender, probar y extender.

 

3- Algunas empresas no les agrada mucho el aplicar Pair Programming porque tienen la idea que es menos productivo y que así los programadores charlarán entre ellos y no programaron. ¿ Qué argumentos se pueden utilizar para cambiar esas ideas? Y Cómo hacer para que los programadores efectivamente no se pongan en ese plan (pudiera pasar)  

Lamentablemente todavía hay organizaciones que dejan pasar las oportunidades de mejorar porque se enfocan en que la gente (a a que suelen llamar recursos) cumple un horario haciendo lo que suponen que es su tarea.

Si pensamos que la tarea de un desarrollador de software es programar, y no hablar, casi seguro obtendremos como resultado código que hace lo que el programador interpreta de un documento, sin entender lo que hace, y sin preocuparse por que lo que hace agregue valor. Para un desarrollador en esas situaciones siempre recomiendo tratar de generar evidencias de que hay maneras mejores de trabajar, y en último lugar recuerdo siempre el dicho "si no puedes cambiar tu trabajo, cambia tu trabajo". No me parece bien tomarse livianamente la ida de que la organización "es así", porque en muchos casos vi gente desde las posiciones más humildes e inesperadas generar una ola de cambio. 

Un buen desarrollador tiene que charlar con el resto del equipo y buscar soluciones apropiadas a las necesidades planteadas, y debe lograr entender el contexto de negocio y aportar su visión. Si limitamos a los desarrolladores a programar lo que otros le indican sin nada más, llegaremos siempre a soluciones mediocres o pobres. De la misma manera, si el equipo no entiende y no está conectado con los problemas que tiene que resolver, su motivación será obviamente más baja, y eso no lo compensa trabajar de a pares o no. 

Al revés, si el equipo está conectado con el negocio, al trabajar de a pares encontrarán mejores soluciones que trabajando solos. El principal problema de trabajar solo para un desarrollador es la facilidad para perder el foco o bloquearse en detalles menores, cosas que casi no suceden al trabajar de a pares.

En resumen, para mi un argumento fundamental es si queremos "cantidad de código" o "buenas soluciones".

El Kyū-Dan de la Integración Continua

En algún momento del 2014, tuve una consulta de mi amigo Sebis Henzenn, que generó (estaba lejos y tenía un rato)  un mail con una explicación bastante larga de lo que se me ocurrió en ese momento como una metáfora aproximada de los pasos de aprendizaje respecto a prácticas relacionadas con Integración Continua y sus derivaciones.

El mensaje quedó guardado unos años, pero lo recordé recién hablando con otro amigo, Edson Chávez, de Kleer Perú, donde estoy en este momento.

Así que aquí va mi elucubración de esa vez, que no sufrió mucho cambios en el ínterin. Sólo aclararía que no es una categorización exhaustiva, sino un recorrido posible, que espero que le sirva a alguien para formular sus planes al respecto.

Aquí el texto original:

Mi recomendación es empezar por el build server, e ir evolucionando. Por ejemplo:

Cinturón blanco:
- instalás Team City (o Jenkins, o el que te guste -salvo TFS que yo no recomendaría).
- empezás haciendo que cada equipo aprenda a configurar su proyecto (es importante que sepan hacerlo ellos)
- lo básico es que en cada commit el proyecto compile, por lo menos
- que se acostumbren a no tener el proyecto en rojo NUNCA. Si queda en rojo, arreglarlo antes de seguir con nada.

Cinturón amarillo:
- pueden empezar a hacer tests (si no los hacen) y correrlos en el build en cada commit.
- de nuevo: nunca dejarlo en rojo, y aprovechar los arreglos para entender más lo que los demás están haciendo y nivelar la calidad de las pruebas.

Cinturón naranja:
- empezar a hacer TDD y ATDD, y elevar el número de pruebas
- seleccionar alguna manera de medir code coverage y hacer que el build falle si ni se alcanza el 1% (pruebas mínimas)
- cada tanto medir el coverage promedio de la solución e ir subiendo el límite casi hasta ahí (incrementalmente)
- cada vez que se reporta un incidente o bug (en testing o producción), no puede arreglarse si no se escribe la prueba primero que demuestra el problema, y se da por resuelto una vez que se corrige la aplicación para que pase ese test

Cinturón verde:
- empezar a ejecutar analizadores estáticos, y que el build server muestre el informe.
- concentrarse en los problemas más importantes; cuando ya no existen en la solución, hacer que rompan el build
- seguir con el problema más importante, y así sucesivamente; alcanza con eliminar un tema o dos por sprint

Cinturón azul:
- empezar a versionar junto al código migraciones de bases de datos, configuraciones y scripts de instalación de componentes o librerías
- hacer que si el build server compiló con éxito y ejecutó todas las pruebas y validaciones, genere desde cero un entorno nuevo de testing

Cinturón marrón:
- trabajar en conjunto con el equipo responsable de despliegue para que valide y adopte los scripts y métodos de generación de ambientes
- lograr que el build server genere en cada commit un ambiente de prueba desde cero, y otro incremental
- lograr que si se detecta un problema en el ambiente incremental, se pueda volver a la versión anterior de la aplicación con el script de reversión

Cinturón negro:
- cada vez que un desarrollador hace un commit que pasa todo el pipeline de pruebas y validaciones en csda uno de los ambientes de prueba, potencialmente puede llegar a producción de manera automática, aunque se opte por decidir manualmente el momento de despliegue
- trabajar en el diseño de la solución para que soporte el desplliegue sin interrupciones de servicio (hot deploy)

Cinturón rojo:
- cada vez que un desarrollador hace un commit, llega a producción sin interrupción de servicio

 

Cada uno de esos saltos puede llevar de 1 a 9 meses, dependiendo del equipo, el proyecto, y de dónde arrancar en cada parte, pero creo que te das una idea. :)