Sunday, April 21, 2024

Eliminar desperdicios en el desarrollo de software

En nuestro primer post, exploramos los orígenes y los principios fundamentales del Lean Software Development. En el segundo, introdujimos ciertos conceptos básicos que usaré durante toda la serie. Ahora, nos enfocaremos en el primero de estos principios: Eliminar el desperdicio. Es clave entender y reducir las actividades que no añaden valor para optimizar nuestros procesos de desarrollo y aumentar el valor que entregamos a nuestros clientes.

En el articulo describiré ejemplos y prácticas que he utilizado en diversos equipos ágiles desde hace años y es importante notar que las prácticas y ejemplos que mencionamos son específicos de nuestro contexto, como el desarrollo de producto y los equipos empoderados, y que suelen reforzarse mutuamente. Por ello, no es recomendable implementarlos de forma aislada. Por ejemplo, iniciar despliegues continuos sin un sistema de pruebas automáticas adecuado podría ser más perjudicial que beneficioso.

Adaptando los Principios del Lean Manufacturing al Desarrollo de Software

En el Lean Manufacturing original, se identificaban siete tipos principales de desperdicio: Inventario, Procesamiento extra, Sobreproducción, Transporte, Esperas, Movimientos y Defectos. Mary y Tom Poppendieck, basándose en su extenso conocimiento del Lean y del desarrollo de software, adaptaron estos conceptos para hacerlos más relevantes en este nuevo contexto. Por ejemplo, redefinieron el concepto de "Inventario" como "Trabajo parcialmente hecho", el “Procesamiento extra” como “Proceso extra”, la "Sobreproducción" como "Features extras", y el "Transporte" como "Cambio de tareas". Consideraron que los demás tipos de desperdicio mantienen su aplicabilidad directa en el desarrollo de software.



Identificando y Eliminando el Desperdicio

Para poder eliminar el desperdicio, el primer paso es capacitar al equipo sobre cómo identificar lo que constituye desperdicio. En este sentido, es importante:

  • Analizar desde la Perspectiva del Cliente: Siempre debemos preguntarnos si una actividad añade valor al cliente/usuario y si podemos eliminarla sin afectar a su percepción.
  • Fomentar una Cultura de Crítica Constructiva: Ser críticos con nuestras acciones y métodos permite al equipo analizar periódicamente su manera de trabajar para identificar y eliminar el desperdicio.
  • Considerar el Impacto a Largo Plazo: Es vital distinguir entre lo que puede parecer un desperdicio en el corto plazo pero no necesariamente lo es en el mediano o largo plazo, siempre con la satisfacción del cliente/usuario en mente.

Es fundamental clasificar los desperdicios identificados en dos categorías: aquellos que son necesarios por razones específicas, como regulaciones o leyes, y aquellos que podemos eliminar completamente o en parte sin comprometer la satisfacción del cliente/usuario. En el caso de los primeros, debemos enfocarnos en entender el motivo detrás de estas limitaciones para poder minimizar el desperdicio lo máximo posible. Para los segundos, es crucial adoptar una actitud más decisiva, buscando eliminarlos de manera sistemática.

Trabajo Parcialmente Hecho

En Lean Manufacturing, el inventario de piezas a medio hacer es físicamente visible y requiere organización y, en ocasiones, mantenimiento. A diferencia de esto, en nuestro contexto el "inventario" (código, conocimiento, información, análisis, etc.) no es tan visible, pero es igualmente costoso.

El valor real para el cliente o usuario surge únicamente cuando este accede a la nueva funcionalidad o cambio. A menudo, incluso en ese instante, el valor sigue siendo incierto hasta que recibimos retroalimentación. Por lo tanto, dado que el valor verdadero solo se potencializa en la etapa final, es crucial acortar el tiempo desde la concepción de la idea hasta su entrega. En otras palabras, debemos esforzarnos por reducir el trabajo en progreso y disminuir el lead time (tiempo de entrega). Como dice Dan North, el objetivo es minimizar el intervalo entre la idea inicial y el “gracias” del usuario.

Estas son las prácticas que usamos para eliminar el trabajo parcialmente hecho:

  • Analizamos/Preparamos trabajo en el backlog bajo demanda: Mantenemos el backlog para no más de un mes y, si crece, eliminamos iniciativas. Si es importante, volverá a surgir.
  • Vertical slicing radical: Tanto a nivel de producto como técnico, permitiéndonos desplegar incrementos en pocas horas o un día. Esto por supuesto requiere hacer CD / Entrega Continua.
  • Trunk Based Development: Evitamos trabajo parcial en feature branches y los problemas de merge.
  • Gestión extremo a extremo por nuestro equipo: Realizamos despliegues, validamos la calidad, monitorizamos el producto, etc. Evitando el tiempo de espera por otros equipos o especialistas.
  • Despliegue inmediato de mejoras: Tanto mejoras de usuario, que ofrecen feedback de negocio, como técnicas, que aportan feedback del sistema.

Como se muestra en el Diagrama de Flujo Cumulativo del equipo, mantenemos un backlog mínimo y gestionamos las tareas relacionadas solo cuando es necesario y en la menor cantidad posible.




Proceso Extra: Simplificación hacia el Valor

Alineándonos con el Manifiesto Ágil, Lean Software Development promueve que el avance principal se mida por el software de valor entregado al cliente. En este marco, cualquier elemento —como documentación excesiva, procesos redundantes, reuniones innecesarias o aprobaciones— que no contribuya directamente al valor para el cliente/usuario, debería ser evaluado para su eliminación.

Desde que adopté los principios ágiles, he colaborado con equipos para depurar nuestros procesos, descartando lo que no generaba valor. 

De esa experiencia destaco dos cambios significativos:

  • Transición de Scrum a Kanban: Scrum nos ayudó inicialmente, pero evolucionamos hacia Kanban para enfocarnos en un flujo de trabajo continuo. Esto redujo las reuniones y planificaciones extensas, favoreciendo sesiones más breves y enfocadas, adaptándonos al modelo Just In Time caracteristico de Lean.
  • Eliminación de Estimaciones: Priorizamos cambios pequeños y continuos, lo que nos permite prescindir de las estimaciones tradicionales. Aún hacemos estimaciones de alto nivel para grandes iniciativas, pero con un enfoque en minimizar el riesgo y la inversión de tiempo innecesaria.

Hemos descubierto que al trabajar en pasos pequeños y preparar solo lo inmediatamente necesario, minimizamos el re-trabajo (failure demand), puesto que no hacemos trabajo “especulativo”. Esto simplifica enormemente la priorización y gestión del backlog, permitiéndonos concentrarnos en lo esencial y ahorrar esfuerzos considerables.

En resumen: Adoptar un enfoque de hacer solo lo necesario y justo a tiempo (Just-In-Time) nos ha llevado a un proceso más eficiente, con menos retrabajo y una gestión de prioridades y backlog más ágil.


Aunque es imposible eliminar toda la documentación o burocracia asociadas a regulaciones y certificaciones de seguridad, es posible abordar estos requisitos de manera creativa para evitar trabajo adicional. En nuestro caso, adoptamos el desarrollo basado en Trunk (Trunk Based Development). Cada commit o push incluye a los coautores y desencadena una serie de pruebas exhaustivas. Esta metodología no solo satisface a los auditores sino que, de hecho, resulta ser más efectiva que los métodos tradicionales de revisión asincrónica (feature-branching + PRs) y la necesidad de aprobaciones explícitas para avanzar hacia la producción.


Funcionalidades y Código Extra

Este para mi junto con el trabajo parcialmente hecho son el desperdicio más significativo que tenemos en desarrollo de software y productos. Demasiado a menudo, software desarrollado durante meses termina sin usarse o es evitado por los usuarios por no cumplir sus expectativas. Este es el DESPERDICIO en el desarrollo de software. Como dijo Mary Poppendieck, "The biggest cause of failure in software-intensive systems is not technical failure; it's building the wrong thing."

Además de aplicar Lean Software Development, debemos utilizar otras técnicas para realmente entender las necesidades de nuestros usuarios y descubrir qué problemas merecen ser solucionados. Herramientas como Lean Product Management, Continuous Discovery e Impact Mapping son fundamentales en este proceso, aunque no las detallaremos en esta serie de artículos.

Suponiendo que hemos identificado un problema digno de ser solucionado y que tenemos clientes/usuarios con una necesidad clara, nuestro objetivo es resolver este problema/necesidad con la menor cantidad de software posible y lo más rápidamente que podamos. En nuestro caso, usamos las siguientes practicas:

  • Adoptamos el principio ágil de "La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial."
  • Vemos el software como un medio y no como un fin, buscando resolver las necesidades con la menor cantidad de software y tecnología posible.
  • Nos enfocamos en el valor para el cliente, asegurándonos de que cada iniciativa y funcionalidad se alinee con las necesidades reales de los usuarios.
  • Postergamos las decisiones técnicas y de producto tanto como sea posible, para aumentar las posibilidades de nunca tener que implementarlas o por lo menos no implementarlas en su totalidad. Siempre buscamos la versión mínima que nos es suficiente.
  • Empleamos Outside-In TDD, lo que asegura que solo hacemos el código mínimo necesario para implementar el caso de uso.
  • Seguimos el principio de YAGNI  (You Aren't Gonna Need It), centrados en la funcionalidad que es requerida ahora, sin caer en diseño o desarrollo especulativo.
  • Y cuando algo que hemos desarrollado deja de usarse o no cumple con su objetivo, lo eliminamos por completo o lo adaptamos hasta que vuelva a tener un impacto positivo.
  • Trabajamos en pasos muy pequeños (<1.5-2 días), presentando nuevos incrementos a los usuarios para obtener retroalimentación rápida que nos permite adaptarnos y decidir los siguientes pasos. Esto, a menudo, nos permite detener la inversión en una funcionalidad de la aplicación cuando es "lo suficientemente buena" para el usuario, evitando así desarrollos innecesarios.


Cambios de tarea

Cambiar de tarea frecuentemente puede interrumpir significativamente la productividad de un equipo. Cada cambio obliga a reiniciar el proceso mental, retrasando el reingreso al estado de "flujo" de trabajo. Para minimizar estos cambios, aplicamos varias estrategias:

  • Minimizar el WIP: La estrategia más efectiva para prevenir cambios de tarea frecuentes es reducir el Trabajo en Curso (WIP) a nivel de equipo. Nos esforzamos por concentrarnos en una, o máximo dos, iniciativas simultáneamente. El ensemble/mob programming es nuestra técnica predilecta para limitar el WIP, ya que cuando todo el equipo se enfoca en una única tarea, las interrupciones internas se eliminan naturalmente.
  • Revisiones de código continuas y sincronas:  Trabajando en ensemble/mob programming se eliminan todos los cambios de tarea que se generan cuando las revisiones de código son asíncronas. Ver Code reviews (Synchronous and Asynchronous) 
  • Vertical Slicing y Technical Slicing: Aplicando rigurosamente estas técnicas, podemos trabajar en incrementos realmente pequeños. Esto nos ayuda a preservar el flujo de trabajo hasta completar y desplegar un incremento. Naturalmente, después de cada despliegue, surge la posibilidad de cambiar de tarea sin el impacto negativo que implicaría hacerlo en medio de un incremento
  • Completitud de Tareas y Spikes: Nos aseguramos de que las tareas se pueden completar de principio a fin. Si vemos que no es posible hacemos un spike (http://www.extremeprogramming.org/rules/spike.html) para eliminar la incertidumbre o buscamos otras aproximaciones que no requieran interrumpirlas.
  • Técnica Pomodoro: Usamos Pomodoros para periodos de trabajo concentrado y descansos sincronizados del equipo.
  • Calidad a Todos los Niveles: La alta calidad previene interrupciones por fallos. Aplicamos TDD, ensemble/mob programming y otras prácticas de Extreme Programming para mantenerla.
  • Rotaciones en Operaciones/Soporte: Para equipos con funciones de soporte, implementamos rotaciones, concentrando a parte del equipo en trabajo emergente y al resto en iniciativas planificadas.

Esperas

Cuando analizamos en profundidad el proceso de desarrollo de producto, lo más usual es encontrar que cada incremento/idea/backlog item pasa casi todo el tiempo esperando. Esperando para tener respuestas a preguntas, esperando analizar más profundamente el problema, esperando tener feedback sobre el diseño, esperando la aprobación de los cambios de arquitectura, esperando que ciertos especialistas estén disponibles, esperando que alguien apruebe el cambio, esperando que se hagan revisiones de código, esperando que se active el feature toggle, esperando comunicar el cambio... Esperando, esperando, esperando. Evidentemente, si vemos el proceso desde el punto de vista del cliente/usuario, cualquier tipo de espera es simplemente desperdicio.

Para eliminar gran parte de estas esperas, estas son algunas de las tácticas que nos han funcionado en el pasado:

  • Asignar al equipo la responsabilidad de principio a fin para ir desde la definición del problema hasta la puesta en producción y operación de la solución. Y, si es posible, incluso darle la libertad de encontrar el problema que merezca la pena resolver. Esto implica encargarse de la gestión del producto, el desarrollo, la calidad, el despliegue y las operaciones.
  • Incluso aunque el equipo esté empoderado, a veces no dispone de todos los skills necesarios. En esos casos, tenemos que conseguir la colaboración de algún especialista, pero intentar siempre que el especialista nos ayude a mejorar nuestros skills en esa especialidad en vez de resolver el problema por nosotros. Esto no cubrirá todos los casos, pero hará que en los casos más básicos no necesitemos volver a requerir al especialista.
  • Por otro lado, cuanto más multidisciplinar sean los miembros del equipo, más fácil será cubrir las necesidades dentro del propio equipo. Esto no implica que todo el mundo sepa de todo, pero sí que fomentemos los perfiles en T (https://es.wikipedia.org/wiki/Habilidades_en_forma_de_T ).
  • A nivel técnico, la forma de eliminar sistemáticamente la mayor parte de las esperas es avanzar hacia la Entrega Continua / CD, lo que normalmente implica poner bastante peso en las prácticas técnicas ágiles (TDD, CI, Despliegue separado de Activación, etc.) y tener una confianza muy alta en nuestro testing automático.
  • Una de las formas más eficientes (eficiencia de flujo) es trabajar en mob/ensemble programming de forma que todo el conocimiento y los skills disponibles estén a la entera disposición de la única iniciativa en curso (en la que trabaja el mob/ensemble).
  • De nada sirve salir pronto a producción si luego permanecemos de forma pasiva esperando la retroalimentación del cliente/usuario. Es mucho más eficiente buscar esa retroalimentación de forma proactiva y disponer de instrumentación a nivel de producto y sistema para aprender lo antes posible.

Movimiento

Otro de los siete desperdicios básicos que considera Lean Manufacturing es el movimiento. En este contexto, resulta evidente que los movimientos que un operario debe realizar en una fábrica, ya sea entre máquinas, para recoger material o para hacer consultas, constituyen un claro desperdicio. En el caso de Lean Software Development, se decidió mantener también la categoría de movimiento, aunque en nuestro ámbito, este tipo de desperdicio no sea tan directo y evidente. 

En el libro original, el movimiento se refiere al esfuerzo necesario para acceder al cliente, obtener información del dominio, realizar hands-offs entre especialidades (ops, QA, seguridad), etc.

Muchas de las tácticas empleadas para eliminar las esperas también son válidas para reducir el desperdicio de movimiento, especialmente en lo que respecta a los handoff entre especialidades.

Adicionalmente, para eliminar otros tipos de movimientos, nos han resultado útiles las siguientes estrategias:

  • Proporcionar al equipo acceso directo al cliente/usuario final o a su representante más cercano. Una solución práctica puede ser asumir la responsabilidad de las operaciones, de manera que el equipo esté directamente expuesto a las quejas y necesidades de los clientes/usuarios.
  • Desarrollar herramientas específicas que permitan acceder de forma directa y eficiente a la información necesaria, evitando repetir procesos (por ejemplo, herramientas para extracción de datos, observabilidad, etc.).
  • Crear irradiadores de información para que sea fácil visualizar los avances o información relevante sin necesidad de buscar activamente (pizarras de gestión visual, notificaciones automáticas, etc.).

Defectos

Por último, Lean Software Development considera los defectos como una gran fuente de desperdicio. Desde mi experiencia, diría que los defectos son el segundo desperdicio más importante después de realizar actividades que no son necesarias (funcionalidades/código extra). Aunque, bien mirado, podríamos considerar que no hacer lo que necesita el cliente es también un tipo específico de defecto :).

Cada defecto que cometemos no solo genera el desperdicio del tiempo invertido en crear ese código incorrecto, sino también el tiempo dedicado a solucionarlo, el impacto en nuestra credibilidad ante el cliente/usuario y todo el esfuerzo desde la creación del problema hasta su resolución. Por lo tanto, no es solo importante evitar generar defectos, sino también encontrarlos cuanto antes, ya que el desperdicio/coste asociado aumenta de manera exponencial cuanto más tiempo tardamos en detectar el problema.

Con esto en mente, las tácticas y prácticas que solemos usar para minimizar este desperdicio son:

  • Minimizar en todo lo posible el código que necesitamos desarrollar para conseguir el impacto deseado. Como bien sabéis, menos código implica menos posibilidades de cometer errores.
  • Utilizar Outside-In TDD, comenzando por tests de aceptación del caso de uso. Esto, por definición, genera la mínima cantidad de código posible que además está bien testeado desde su creación.
  • Este proceso no cubre todos los escenarios y problemáticas, por lo que también es necesario crear ciertos tests de extremo a extremo y tener estrategias para temas específicos como análisis de seguridad, test de carga, test de rendimiento, etc.
  • Otro punto importante es probar los componentes de terceros que usamos para evitar problemas cuando actualizamos versiones o los utilizamos de manera diferente a la habitual. Ver Thin Infrastructure Wrappers.
  • Con todos los puntos anteriores tenemos un buen punto de partida, pero cada vez es más común depender de infraestructura y servicios de terceros (SaaS, clouds, etc.). En esos casos, se hace más imprescindible que nunca utilizar tácticas de testing en producción. Al fin y al cabo, a nuestros clientes/usuarios les da igual cuál haya sido la fuente del problema; solo les importa el impacto que ha tenido.


Conclusiones

Como se puede observar en las tácticas y prácticas que empleamos para minimizar el desperdicio, muchas de ellas se relacionan con tener prácticas de desarrollo sólidas (pair programming, TDD, BDD, revisiones continuas, CD, CI, etc.) que nos permiten desarrollar de manera sostenible. Otras se centran en evitar en la mayor medida posible realizar tareas innecesarias, enfocándonos en lo que realmente valora el cliente (que no siempre coincide con lo que pide), limitando el software a las necesidades actuales y trabajando en pasos muy pequeños para poder cambiar de dirección o cesar la inversión en algo tan pronto como sea necesario.

Trabajar en estos pasos tan pequeños y adaptarnos de forma continua nos permite aligerar mucho el proceso necesario: necesitamos poca gestión del backlog si tenemos muy poco en él; no hay que coordinar distintos flujos de trabajo si todos trabajamos en lo mismo al mismo tiempo; no hay que estructurar la comunicación ni los handoffs con otros equipos si los gestionamos nosotros mismos. Al final, se trata de simplificar todo lo más posible para hacer solo lo absolutamente necesario, siempre centrados en lo que realmente aporta valor. Esto implica, evidentemente, cuestionarnos constantemente lo que hacemos y cómo lo hacemos. Que algo haya sido útil hace un par de meses no significa que siga siéndolo. No es tan sencillo como parece, ya que requiere una profunda implicación en nuestro trabajo (pasión) y, al mismo tiempo, la capacidad de dejar ir lo que no aporta (desapego). Es vivir centrados en una ventana deslizante de lo que aporta valor ahora, de lo que nos es útil en el presente.

Recuerda que eliminar el desperdicio es solo el primer paso en el camino hacia el Lean Software Development. En nuestro próximo post, exploraremos cómo "Amplificar el aprendizaje" para garantizar la excelencia de nuestros productos. ¡Nos vemos pronto!



Saturday, April 20, 2024

CommitConf 2024 Taller Lean: Posponer decisiones (Defer commitment)

Esta mañana he tenido la suerte de poder facilitar un taller creado por @islomar y yo mismo para practicar el principio Lean de Posponer decisiones.

Me lo he pasado muy bien y se han generado muy buenas conversaciones.





Varias personas de las que han hecho el taller me han pedido las slides, y aunque no aportan mucho sin el taller, pueden venir bien como recordatorio a los que hayan estado, así que las dejo por aquí:


 



El taller es Creative Commons (CC BY-SA 4.0) así que para la gente que me ha preguntado, encantado de que lo puedan facilitar en sus empresas. Si alguien necesita el material original y algún consejo para la facilitación que me contacte y estaré encantado de ayudar.

Soporte


Si te gusta que deje este tipo de talleres en Creative Commons o que genere contenido en mi blog compartiendo mis neuras agradeceria algo de soporte, que siempre hace ilusión ver que a la gente le aporta, y ayuda a pagar el hosting y herramientas que uso. 


Relacionado:


Sunday, April 14, 2024

Conceptos Lean interesantes para desarrollo de software

 En esta entrega de nuestra serie sobre Lean Software Development, nos enfocaremos en explorar una serie de conceptos fundamentales que no solo enriquecerán nuestro diálogo a lo largo de los próximos artículos sino que también aspiran a despertar la curiosidad del lector para profundizar en ellos de manera independiente. El objetivo es doble: dotarnos de un lenguaje común para discutir principios y prácticas Lean en el desarrollo de software y, al mismo tiempo, incentivar una exploración autodidacta que enriquezca nuestra comprensión y aplicación de estos conceptos en el entorno laboral.

Valor

  • Valor en Lean: Se define desde la perspectiva del cliente. Cualquier acción que satisfaga una necesidad del cliente, solucione un problema o nos permita aprender sobre dicho problema o sobre el comportamiento de la solución, se considera de valor. Es crucial identificar y concentrarse en las actividades que generan valor para aumentar la eficiencia. Si algo no está desplegado y activado, su valor es cero. 
  • Cadena de Valor: Representa la secuencia completa de actividades necesarias para entregar un producto o servicio al cliente. En nuestro caso, la cadena de valor abarca desde entender el problema hasta que la solución (software) está en manos del cliente. Si varios equipos intervienen en esta cadena, es vital identificarlos y optimizar la cadena de valor completa. No basta con ser rápidos en el desarrollo si no podemos implementar adecuadamente la solución, o si ésta no es la correcta. Siempre debemos enfocarnos en optimizar toda la cadena de valor.
  • Flujo / Flow: Se refiere a la manera en que el trabajo avanza de forma continua a través de la cadena de valor. Un flujo óptimo se caracteriza por el movimiento constante del trabajo, sin interrupciones, bloqueos, ni cuellos de botella. El objetivo es mantener un flujo continuo y sostenible en el tiempo, poniendo especial atención en mejorar este flujo a lo largo de toda la cadena de valor.

Eficiencia

  • Eficiencia de Flujo: Esta métrica mide la proporción del tiempo que un ítem de trabajo es activamente procesado en comparación con el tiempo total desde que se inicia hasta que se entrega. Un flujo eficiente busca minimizar el tiempo inactivo. En otras palabras, evalúa la relación entre el tiempo activo de trabajo en un cambio y el tiempo que dicho cambio permanece bloqueado o en espera en una cola. El objetivo es reducir al máximo estos periodos de inactividad para agilizar la entrega.
  • Eficiencia de Recursos: A diferencia de la eficiencia de flujo, la eficiencia de recursos se centra en maximizar la utilización de los recursos disponibles, como personas y máquinas. Este enfoque tiende a mantener a los empleados lo más ocupados posible, lo cual frecuentemente conduce a la especialización de tareas y a la formación de colas de espera antes de cada especialidad. Esto garantiza que cada área (front-end, QA, back-end, operaciones, producto) siempre tenga trabajo. Sin embargo, puede resultar en que cada cambio tome más tiempo en estar disponible para el cliente, contraviniendo los objetivos de Lean Software Development.
  • Eficiencia en Lean: Aunque Lean reconoce ambos tipos de eficiencia, da prioridad a la eficiencia de flujo porque maximiza la velocidad de entrega al cliente. Esto no significa que se ignore la optimización de la eficiencia de recursos, pero la prioridad inicial es el cliente a través de la eficiencia de flujo. Adicionalmente, dado que Lean pone un gran énfasis en la eliminación de desperdicios, la eficiencia global alcanzada suele ser muy alta. Traduciendo a desarrollo de software, primero optimizamos el flujo para poder sacar los incrementos en el menor tiempo posible (eficiencia de flujo) y una vez que tenemos ese proceso funcionando de forma sostenible, optimizamos recursos y tiempo de personas (eficiencia de recursos). En siguientes articulos veremos como optimizar ese flujo continuo de entrega de valor mediante la Entrega Continua / CD y los equipos multi disciplinares. Este fantástico video explica perfectamente los tipos de eficiencia en Lean.


Métricas Lean

  • Throughput: El throughput (o tasa/ritmo/frecuencia de entrega) en una cadena de valor mide cuánto valor se genera para el cliente por unidad de tiempo. En un contexto de manufactura, esto podría referirse al número de piezas o elementos producidos por un proceso en una unidad de tiempo específica (día, hora, etc.). En el desarrollo de software, se refiere a cada incremento que desplegamos y que el cliente puede empezar a usar. Maximizar el throughput es crucial para incrementar la eficiencia en la entrega de valor.
  • Lead Time: Este término se refiere al tiempo total que transcurre desde que se identifica la necesidad de un producto o servicio hasta que éste es entregado al cliente. Reducir el lead time es fundamental para la satisfacción del cliente. En el caso de Lean Software Development, corresponde al tiempo desde que detectamos una necesidad hasta que la solución está disponible para el cliente.
  • Tiempo de Ciclo / Cycle Time: Mide el tiempo que tarda en completarse un ciclo de trabajo específico dentro del proceso de producción. Ofrece una perspectiva del rendimiento operativo interno. Para el desarrollo de software, el tiempo de ciclo se mide desde que comenzamos a trabajar en un incremento hasta que está desplegado y activo para el cliente. El objetivo es minimizar el tiempo de ciclo para obtener retroalimentación de manera más frecuente, lo cual es crucial para la mejora continua. Para más información sobre la importancia de trabajar en pequeños lotes, puedes consultar https://www.eferro.net/2021/01/small-batches-for-win-continuous.html.


  • Trabajo en Progreso (WIP): Este término se refiere a todos los ítems de trabajo que se han iniciado pero aún no se han completado. En el contexto del desarrollo de productos y software, el WIP no solo incluye el código en una rama en la que se está trabajando, sino todo el trabajo y contexto de cualquier incremento que no está desplegado y activado para el cliente. Esto abarca elementos en espera de revisión de código, validación de seguridad, o tareas que están analizadas pero aún no han comenzado. Esencialmente, cualquier trabajo del que el cliente aún no se ha beneficiado pero que hemos comenzado de alguna manera. Cuando se usa como métrica, sería el número de tareas que se encuentran en este estado.
  • Límite de Trabajo en Progreso (WIP Limit): Se refiere a la restricción establecida sobre la cantidad máxima de tareas en curso permitidas en un sistema. Este límite es crucial para mantener el enfoque, reducir el tiempo de entrega y mejorar la calidad, ya que previene la sobrecarga de trabajo y promueve la finalización de tareas antes de comenzar nuevas. Establecer estos límites ayuda al equipo a mejorar su forma de trabajar, enfocándose en entregar valor al cliente en lugar de abrir nuevas tareas cuando se encuentran bloqueos. Mantener un bajo nivel de trabajo en curso minimiza la necesidad de cambiar de tarea, reduciendo así el desperdicio asociado con el cambio de contexto frecuente.


Organización del trabajo / Flujo

  • Just-in-Time (JIT): Este principio se centra en producir y entregar exactamente lo que se necesita, en el momento que se necesita y en la cantidad necesaria. En el desarrollo de software, esto implica realizar muchas actividades solo cuando son necesarias y en pequeños lotes. A nivel de desarrollo, el JIT implica trabajar en pasos muy pequeños y siempre en respuesta a la necesidad actual. Por ejemplo, implementamos una funcionalidad solo cuando hay una demanda real, o proponemos una mejora de arquitectura cuando los requisitos del negocio o del cliente lo requieren. Trabajar de esta manera es muy eficiente, pero requiere flexibilidad en el proceso y buenas prácticas técnicas que permitan agilidad en el trabajo.
  • Procesamiento Pull: Este enfoque asegura que la producción se base en la demanda real, en contraposición al procesamiento Push, que produce según lo planificado. En desarrollo de software, trabajar con un enfoque Pull significa que iniciamos las tareas solo cuando existe una demanda específica del cliente o cuando se basan en hipótesis en negocios no validados. Esto mejora la eficiencia y reduce el exceso de producción. Contrastando con el método Push, que define un plan de trabajo y empuja las tareas independientemente de la demanda real.


Desperdicio / waste

  • Muda: Este término japonés significa "desperdicio". En Lean, se identifican siete tipos de muda que deben ser eliminados para optimizar los procesos: sobreproducción, tiempo de espera, transporte, sobreprocesamiento, inventario, movimientos y defectos. En el próximo artículo de esta serie, describiremos los principales tipos de desperdicio en el desarrollo de producto de software y exploraremos prácticas que nos ayudan a eliminarlos o minimizarlos.
  • Muri: Se refiere al concepto japonés de sobrecarga o esfuerzo innecesario. En el contexto Lean, muri implica una presión excesiva sobre los empleados y los procesos, lo que puede desembocar en ineficiencia y desgaste del personal. La meta de eliminar muri es asegurar que el trabajo y los recursos se optimicen sin sobrecargar el sistema, promoviendo un ambiente laboral eficiente y sostenible. En nuestros equipos, muri puede generarse por un exceso de carga cognitiva o por la presión para completar tareas en un proceso Push. En un proceso Pull, es menos probable que ocurra muri, ya que el WIP está limiteado y solo comenzamos una tarea cuando existe la capacidad disponible al haber concluido otra.
  • Mura: Significa inconsistencia o irregularidad. En Lean, mura se asocia con la variabilidad en los procesos de producción que conduce a ineficiencias y desperdicios. La estrategia para abordar mura incluye la estandarización de procesos y la nivelación de la carga de trabajo, lo que resulta en un flujo de trabajo más constante y predecible, mejorando así la eficiencia y la calidad del servicio o producto. Sin embargo, en desarrollo de software donde la alta variabilidad es inherente (demanda irregular, incertidumbre, alta complejidad, desconocimiento, necesidades emergentes), es más prioritario abrazar el cambio y ser adaptable (usando prácticas de desarrollo ágil), en lugar de intentar evitarlo.


Imagen usada con permiso del autor Jose Manuel Beas

Cambio y mejora

  • Kaizen: Esta filosofía japonesa, cuyo significado es "cambio para mejorar", es fundamental en el pensamiento Lean. Kaizen promueve la mejora continua a través de pequeños cambios graduales que, acumulativamente, resultan en grandes mejoras en eficiencia y satisfacción del cliente. Implica a todos los niveles de la organización y se centra en mejorar los procesos diarios, haciendo que cada empleado participe activamente en la sugerencia de mejoras. Una forma de implementar este proceso Kaizen es mediante retrospectivas y generando el espacio para implantar las mejoras identificadas por el equipo.
  • Kaikaku: En contraste con Kaizen, Kaikaku significa "reforma radical". Este enfoque busca implementar cambios grandes y disruptivos que mejoren significativamente el rendimiento y la eficiencia. Generalmente es iniciado desde la dirección de la empresa o de la unidad y puede llevar a innovaciones revolucionarias. Aunque Kaikaku puede resultar en mejoras substanciales, también conlleva mayores riesgos debido a la magnitud de los cambios que propone. Importante mencionar que el Kaikaku NO se refiere a los cambios técnicos u organizativos que son obligados por situaciones de alto riesgo para la supervivencia de la empresa (bancarrota técnica, caos organizativo, incidentes en producción, etc).
  • A3 Thinking: Este es un enfoque sistemático y estructurado para la resolución de problemas, utilizado dentro de la metodología Lean. A3 Thinking se ayuda de un documento del tamaño de una hoja de papel A3 para condensar el problema, el análisis, las soluciones propuestas y los planes de acción en una vista integral. Este proceso no solo fomenta el pensamiento crítico y la colaboración, sino que también mejora la comunicación entre los miembros del equipo, permitiendo abordar desafíos complejos de manera más efectiva y eficiente. En mi experiencia, el A3 Thinking es una muy buena herramienta para cambios significativos en pasos muy pequeños, sobre todo cuando las mejoras requieren un seguimiento muy detallado y continuo.


Recursos altamente recomendados:

Algunos de los conceptos descritos en este artículo, aunque fundamentales, pueden ser inicialmente contraintuitivos. La experiencia muestra que se suelen entender mejor mediante demostraciones visuales. Por esta razón, os recomiendo encarecidamente ver los siguientes videos, la mayoría de los cuales son bastante cortos, para profundizar y realmente comprender estos principios de manera práctica:

Eficiencia de recursos vs Eficiencia de flujo

WIP Limits:

General processes / Team Work:


Con estas recomendaciones terminamos este pequeño artículo sobre conceptos que nos pueden ser útiles para entender el resto de artículos de la serie sobre Lean Software Development.

En nuestra próxima entrega, nos enfocaremos en Eliminar Desperdicios, uno de los principios claves de Lean Software Development.

¡Nos vemos en la próxima entrega!


Recursos relacionados:

Sunday, April 07, 2024

Introducción al Lean Software Development

Descubrí que aceptar el cambio (en lugar de resistirme a él), siendo flexible y adaptable (en vez de aferrarme a un plan fijo), me permite impactar significativamente en el desarrollo de software sin sufrir ansiedad constante. Este descubrimiento me llevó a adoptar entusiastamente el Desarrollo Ágil de Software (https://agilemanifesto.org/iso/es/manifesto.html). Con el tiempo, en este camino de adaptación y mejora continua, los equipos con los que he colaborado hemos refinado las prácticas sostenibles y descartado aquellas que resultaban superfluas o poco beneficiosas. Este proceso, enriquecido por Extreme Programming, Continuous Delivery y, especialmente, por los principios Lean, nos ha permitido desarrollar un enfoque de trabajo muy efectivo. Sin embargo, al conversar con colegas, me sorprendió descubrir que los principios Lean y su aplicación en el desarrollo de software no son ampliamente conocidos. Por ello, he decidido crear una serie de publicaciones para compartir qué es el Lean Software Development y cómo lo implementamos en nuestros equipos.


Una aclaración importante, sé que cada contexto puede requerir aproximaciones diferentes y que el enfoque ágil/Lean no es la mejor opción en ciertos contextos, pero lo cierto es que dado que es la forma de trabajar que me gusta, de forma casi automatica suelo terminar trabajando en entornos en los que tiene sentido.

Orígenes del Lean Software Development

El concepto de Lean Manufacturing, con sus raíces profundamente ancladas en el revolucionario Sistema de Producción de Toyota (TPS) de la década de 1950, es una filosofía enfocada en maximizar el valor mediante la eliminación de desperdicios. Este enfoque no solo transformó la fabricación automotriz sino que también sentó las bases para las metodologías ágiles en el desarrollo de software.

Principios Clave del Sistema de Producción Toyota:

  • Jidoka (Automatización con un toque humano): Este principio enfatiza la importancia de la automatización en la producción no solo para reducir costos, sino también para prevenir defectos. Permite detener la producción ante cualquier problema para evitar la creación de productos defectuosos.
  • Just-in-Time (JIT): Bajo este enfoque, cada proceso produce únicamente lo necesario para el siguiente paso, adoptando un proceso de producción "pull" en lugar de "push".
  • Kaizen (Mejora continua): El Kaizen promueve pequeñas mejoras constantes en el proceso, lo que facilita el aprendizaje y la adaptación continua, mejorando la satisfacción tanto de clientes como de participantes en la producción.

Estos principios, junto con otros del TPS, enfocan en la mejora continua, la eliminación de desperdicios y el respeto por las personas involucradas en los procesos.

La transición hacia el desarrollo de software ágil fue influenciada notablemente por estos ideales, especialmente en lo que respecta a la mejora continua, la calidad del proceso y un flujo de trabajo basado en la demanda real, en contraposición a la producción basada en suposiciones.

Contexto Histórico y Evolución hacia el Desarrollo Ágil:

Posterior a la Segunda Guerra Mundial, Japón enfrentó severas restricciones económicas que hacían inviable la producción en masa al estilo occidental. En este contexto, las ideas de W. Edwards Deming sobre calidad y mejora continua encontraron un terreno fértil. Deming, un estadístico y consultor de gestión estadounidense, enfatizó la calidad y eficiencia en la producción como medios para reconstruir la economía japonesa. Estos principios de control de calidad, junto con el enfoque en minimizar desperdicios y maximizar eficiencia, fueron adoptados y adaptados por Toyota, dando origen al TPS.

"Learning is not compulsory. Neither is survival." W. Edwards Deming

A principios de los años 2000, mientras el desarrollo de software ágil ganaba popularidad, Mary y Tom Poppendieck, quienes tenían experiencia en Lean Manufacturing y estaban involucrados en el desarrollo de software ágil, adaptaron los principios Lean al desarrollo de software. Publicaron el primer libro de una serie que describe la metodología Lean Software Development (Lean Software Development: An Agile Toolkit), marcando así un puente claro entre las prácticas de manufactura y el desarrollo de software ágil.

Los principios de Lean Manufacturing, originados en el TPS y reforzados por la influencia de Deming, no solo revolucionaron la fabricación sino que también trascendieron industrias, modelando profundamente el desarrollo de software ágil. La adaptación de estos principios al mundo del software por los Poppendieck subraya la universalidad de la mejora continua, la calidad, y la eficiencia, demostrando cómo los enfoques orientados a la eliminación de desperdicios y al respeto por las personas pueden conducir a innovaciones significativas.

Principios fundamentales

Lean Software Development se basa en siete principios fundamentales que buscan eliminar el desperdicio y optimizar el proceso de desarrollo:

  1. Eliminar el desperdicio: Cualquier cosa que no agregue valor al cliente se considera desperdicio y debe ser eliminada.
  2. Construir calidad desde el inicio: La calidad debe ser una parte integral del proceso de desarrollo, no una consideración posterior.
  3. Crear conocimiento: El aprendizaje continuo y la mejora del conocimiento son esenciales para el desarrollo de software.
  4. Diferir compromisos: Tomar decisiones lo más tarde posible para mantener la flexibilidad y adaptarse a los cambios.
  5. Entregar rápido: La entrega rápida permite recibir retroalimentación temprana y realizar ajustes necesarios.
  6. Respetar a las personas: Un ambiente de respeto y colaboración es fundamental para el éxito del equipo.
  7. Optimizar el todo: Se debe considerar el proceso de desarrollo en su totalidad para mejorar la eficiencia.

Beneficios de adoptar Lean en el desarrollo de software

La implementación de Lean en el desarrollo de software trae consigo numerosas ventajas, entre ellas, la reducción de costes y tiempo de desarrollo, el incremento en la calidad del producto y la satisfacción del cliente, así como la creación de un ambiente laboral más gratificante para el equipo. Lean fomenta una cultura de mejora constante y adaptabilidad, aspectos cruciales en momentos de alta incertidumbre y evolución acelerada del mercado.

Por primera vez en la historia del desarrollo de software, disponemos de datos que definen cómo debe ser una organización tecnológica de alto rendimiento, gracias a las investigaciones realizadas por el equipo de DevOps Research and Assessment (DORA). Según se detalla en el libro Accelerate, el enfoque lean es fundamental en la creación y el escalado de equipos y organizaciones tecnológicas.

Accelerate research

Al integrar Lean Software Development, XP o la combinación de ambas, con Lean Product Development y Lean Management, se forma un equipo de alto impacto, donde, además, se reduce el estrés y la frustración, elementos que considero tan esenciales como el impacto mismo (https://www.eferro.net/2017/12/how-vs-what.html).


Un breve adelanto de lo que se cubrirá en la serie

En las próximas entradas, detallaremos cada principio de Lean, mostrando su aplicación práctica en los equipos con los que trabajo. Me esforzaré por compartir abundantes ejemplos y explicar nuestro proceso de toma de decisiones.

A medida que se publiquen los distintos artículos de la serie los enlazaré aquí:

Si bien Lean ha influenciado diversos conceptos y métodos, como DevOps, Lean Product Development y Lean Startup, en esta serie profundizaremos en el Lean Software Development. No obstante, es importante mencionar que, a nivel de equipo, buscamos extender la aplicación de los principios Lean más allá, abarcando desde el desarrollo en sí hasta las decisiones de producto y la gestión de otras tareas y procesos. Ya sabéis “Make the right thing, make the thing right”.

El próximo artículo se centrará en explicar algunos conceptos Lean que usaremos durante toda la serie.¡Continuemos aprendiendo y evolucionando juntos hasta entonces!


Recursos: