Wednesday, May 15, 2024

Amplificar el Aprendizaje

En este nuevo artículo de la serie sobre Lean Software Development, nos vamos a centrar en la naturaleza del desarrollo de software y la importancia de optimizar nuestro proceso para el aprendizaje continuo.

Naturaleza del Desarrollo del Software

Independientemente del error clásico que solemos cometer en la industria de comparar el desarrollo de software con la construcción de edificios o los procesos de manufactura (ver  Construction engineering is NOT a good metaphor for software), lo cierto es que el desarrollo de un producto software es un proceso de adaptación de la solución a las necesidades cambiantes del usuario (o a nuestras hipotesis sobre las necesidades del usuario). Es decir, es el proceso de evolucionar de forma continua el software para adaptarse a esas necesidades.

Esta evolución es continua no solo porque las necesidades de nuestro cliente van evolucionando (estrategia, reglas de negocio, procesos) sino porque el entorno en el que nos movemos cambia de forma continua y constante (SaaS, competidores, IA, evolución de dispositivos). Esta evolución es parte de la naturaleza intrínseca del software, puesto que su gran ventaja es precisamente esa, la velocidad con la que puede evolucionar y adaptarse. Un software que no está evolucionando es un software muerto (o que nadie usa o que se ha quedado obsoleto).

designed by www.freepik.com

A diferencia de los procesos de producción y manufactura, donde la calidad es la conformidad a requerimientos establecidos, la calidad en software es adecuarnos a las necesidades de nuestros clientes. Estas necesidades cambian de forma continua, por lo que el software debe cambiar a su vez.

Podemos ver, por tanto, que en el centro de la naturaleza del desarrollo del software está el aprendizaje continuo y profundo sobre el problema o necesidad (cambiante) de nuestros clientes y sobre la adecuación de nuestra solución para resolver ese problema y necesidad.

Lean Software Development reconoce esta naturaleza del desarrollo del software y considera necesario amplificar el aprendizaje para optimizar el proceso de desarrollo de producto.

"A mature organization focuses on learning effectively and empowers the people who do the work to make decisions." Mary Poppendieck


Amplificar el Aprendizaje

El aprendizaje es la piedra angular del desarrollo de software efectivo. En el contexto de Lean Software Development, este principio se eleva como una guía fundamental para la mejora continua. Reconocer que el conocimiento es dinámico y que el aprendizaje es un proceso constante es crucial para el progreso en un entorno de desarrollo ágil.

Sin embargo, este aprendizaje no puede limitarse a personas o perfiles concretos; debe extenderse a todo el equipo, puesto que queremos que todo el equipo pueda aportar y ya hemos visto que el aprendizaje es parte de la naturaleza del desarrollo de software.

Amplificar el aprendizaje implica no solo entender lo que el cliente desea, sino también discernir lo que no necesita. Este discernimiento es crítico, ya que construir características o funcionalidades innecesarias es el mayor desperdicio en el desarrollo de software. Por lo tanto, el proceso de aprendizaje debe estar enfocado en la clarificación constante de las necesidades reales del cliente, evitando así el desperdicio y optimizando la entrega de valor.

"The biggest cause of failure in software-intensive systems is not technical failure; it’s building the wrong thing." Mary Poppendieck

Resumiendo, Lean Software Development nos recomienda:

  1. Reconocer el aprendizaje continuo y constante como el cuello de botella fundamental en el desarrollo de productos software.
  2. Aprender de las necesidades y problemas del cliente, identificando también lo que NO necesita.
  3. Optimizar el aprendizaje continuo por parte de TODO el equipo.


Y como herramientas para ampliar ese aprendizaje nos habla de:

  • Ciclos de retroalimentación (feedback loops)
  • Iteraciones
  • Sincronización e integración
  • Diseño Basado en Conjuntos de Soluciones" (Set-Based Development)

Aterrizando la amplificación del Aprendizaje

En los últimos 15 años trabajando con diferentes equipos, siempre he considerado que el aprendizaje es parte fundamental de la naturaleza de desarrollo de software. Mi enfoque ha consistido en fomentar ese aprendizaje continuo y amplificado que promueve el Lean Software Development.

A continuación indico las herramientas que he usado para amplificar el aprendizaje.

Equipos de producto empoderados

Estos equipos, basados en las necesidades y estrategias de negocio, tienen la capacidad de decidir qué problema soluciónar y cómo hacerlo. Son equipos con una verdadera mentalidad de producto, compuestos por Product Engineers que no solo se interesan por el problema o necesidad del cliente, sino que también buscan entenderlo profundamente y proponer las mejores soluciones.

Como bien describe John Cutler, estos son los llamados Product Teams.

https://amplitude.com/blog/journey-to-product-teams-infographic

Estos Product Teams tienen como parte de su responsabilidad entender y aprender sobre los problemas del cliente, usando ese aprendizaje para plantear las mejores soluciones. En estos equipos el aprendizaje es clave, y por ello usan practicas de descubrimiento de producto. En nuestro caso concreto, los miembros del equipo se suelen rotar para hacer entrevistas de usuario, facilitar sesiones de co-creación o para dar soporte. Todas estas sesiones nos proporcionan aprendizajes que se ponen en común con el resto del equipo y que nos permiten ir tomando decisiones sobre los siguientes pasos a dar.

Aunque conozco algunas técnicas más avanzadas que las que he indicado para hacer descubrimiento de producto, nunca las he puesto en práctica y nos ha bastado con que todos los miembros del equipo tengan una mentalidad de producto, se cuestionen siempre por qué hacemos las cosas y si las debemos hacer o no. Supongo que hemos podido tener un gran impacto y conseguir buenos aprendizajes sin usar prácticas sofisticadas de descubrimiento de producto gracias al tipo de productos en los que hemos estado involucrados (productos poco visuales, en algunos casos internos, o dirigidos a perfiles técnicos).

Ciclos de retroalimentación (feedback loops) 

Utilizamos Extreme Programming (XP) como base, que se enfoca en generar ciclos de retroalimentación lo más frecuentes y pequeños posibles para optimizar el proceso de desarrollo:

  • Comunicación constante: En nivel de mob o pareja (segundos).
  • Proceso de TDD (Test-Driven Development): Ciclos cortos de pruebas y desarrollo (minutos).
  • Tests de aceptación: Evaluación rápida de las funcionalidades (minutos).
  • Despliegues frecuentes: Implementación regular de mejoras (horas).
  • Planificación diaria: Revisión y ajuste de objetivos diarios (1 día).


http://www.extremeprogramming.org/introduction.html

Adicionalmente, complementamos estos ciclos de retroalimentación de XP con técnicas de Entrega y Despliegue Continuo (Continuous Deployment, CD), ampliando nuestra capacidad para integrar y validar cambios de manera casi instantánea.

“Extreme Programming is a team style of software development. Collaborative style of software development that emphasizes deferring as many decisions as possible and enabling that by increasing feedback loops at every possible level....
so if you get great feedback then you don't have to make good decisions because you can afford to just make a decision and you'll find out.”   Kent Beck

Por supuesto estos ciclos de retroalimentación no se producen solo en el proceso técnico de desarrollo de software, también se producen a a partir de la retroalimentación proporcionada por los clientes, donde podemos ver si nuestras hipotesis sobre lo que necesita el cliente y la solución propuesta están teniendo el impacto buscado.

Iteraciones

Aunque hemos dejado atrás el enfoque tradicional de hacer iteraciones, seguimos optimizando el flujo de entrega continua. Frecuentemente iteramos por distintas partes del producto, centrándonos siempre en las áreas más prioritarias en cada momento. Para nosotros, ninguna característica o funcionalidad está definitivamente completa; están en constante evolución, y es común volver a iterar sobre elementos ya desarrollados según la necesidad. (Ver https://productdeveloper.net/iterative-incremental-development/)

Sincronizacion e integración

Usamos la práctica de Integración Continua y Entrega Continua mediante el enfoque de Trunk Based Development. Esto permite que todo el equipo mantenga una visión completa e integrada del producto a diario, evitando el mantenimiento de ramas con código aislado por días o semanas. Solo existe una versión activa en la rama principal, lo que minimiza el desperdicio, evita conflictos y garantiza una visión común. 

Esta forma de trabajar permite que todo el equipo comparta la misma visión en todo momento del código (la solución) e impide que una persona o parte del equipo se aislen con una visión (y conocimiento distinto) durante dias trabajando en una rama de funcionalidad.

Diseño Basado en Conjuntos de Soluciones (set-Based Development)

En Lean Software Development, el término Diseño Basado en Conjuntos de soluciones (set-based development) describe una metodología que prioriza mantener abiertas múltiples opciones de diseño durante el proceso de desarrollo. Este enfoque permite acumular la mayor cantidad de información posible, no solo sobre un elemento específico del diseño, sino sobre cómo todos los elementos se integran. Contrario a la tradición de tomar decisiones de diseño tempranas basadas en la información disponible en ese momento, el set-based development favorece el aplazamiento de decisiones de diseño hasta contar con información más completa, lo cual es crucial para el desarrollo de software de alta calidad y flexible.

Este método se fundamenta en la realidad de que, en el desarrollo de software, las interacciones entre diferentes componentes no se pueden predecir con total certeza hasta que no se implementan y prueban. Por tanto, mantener abiertas opciones de diseño y evitar decisiones definitivas hasta obtener más datos resulta en un enfoque más eficaz para manejar proyectos de software complejos y de alta calidad.

En mis equipos, la práctica de mantener abiertas las opciones de diseño y posponer decisiones hasta obtener el máximo de información posible es una obsesión. He llegado a crear un taller específico para practicar esta metodología (Ver Taller Lean Posponer Decisiones). La clave para trabajar con opciones abiertas reside en enfatizar la simplicidad (XP), fomentar un diseño evolutivo y proceder en pasos muy pequeños que nos permitan tomar decisiones en el último momento responsable. Profundizaré más en este tema en un artículo completo dedicado a ello en la serie.

“La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.” Principio del Manifiesto por el Desarrollo Ágil de Software

Otras Técnicas Útiles para Amplificar el Aprendizaje

En nuestro día a día, aplicamos estrategias como mob programming o pair programming, con rotaciones frecuentes de parejas. Esto facilita la rápida diseminación del conocimiento dentro del equipo y evita la formación de silos de información.

Además, empleamos con regularidad los Spikes de Extreme Programming, que son tareas con timeboxing dedicadas exclusivamente a explorar y aprender sobre aspectos específicos que necesitamos dominar, como una nueva técnica, biblioteca o tecnología.

Otra técnica que siempre me ha funcionado para mejorar y amplificar el aprendizaje es introducir Blameless postmortems tanto aplicados a incidencias en producción, como aplicados como retrospectiva de iniciativas. Ver CAS18 sobreviviendo en producción - gestión de incidencias y aprendizaje

Conclusiones

En resumen, nuestro enfoque consiste en priorizar el aprendizaje como un elemento fundamental, trabajar con ciclos de retroalimentación frecuentes y tomar decisiones basadas en lo que aprendemos continuamente. Este enfoque nos ayuda a adaptarnos rápidamente y a mejorar constantemente nuestra efectividad y eficiencia en el desarrollo de productos.

Referencias y enlaces relacionados

No comments: