Lean Software Development: Construyendo con Calidad

Primera parte de una serie sobre cómo construir con calidad desde los principios de Lean Software Development. En esta entrega exploramos qué significa realmente "calidad", cómo se diferencia del enfoque tradicional y qué principios nos ayudan a evitar que los errores se conviertan en defectos.

Lean Software Development: Construyendo con Calidad

Una de las grandes diferencias entre Lean Software Development y los enfoques tradicionales radica en el tratamiento de la calidad, tanto del software o producto resultante como del entorno de trabajo (colaboración, herramientas, comunicación).

Lean Software Development considera la calidad como una parte integral del valor del producto, imprescindible para aportar valor al cliente de la manera más eficiente posible. Desde esta perspectiva, todos los problemas de calidad se consideran uno de los principales desperdicios que debemos eliminar.

En contraste, los enfoques tradicionales suelen centrarse principalmente en la calidad del producto final. Lean, por su parte, pone el foco en la mejora continua de los procesos y del sistema que genera ese producto final.

El control de calidad, que tradicionalmente se enfoca en la inspección del producto al final del proceso, se convierte en Lean en una parte fundamental de cada etapa. Dicho de otro modo, en lugar de inspeccionar y validar la calidad al final, esta se construye desde el principio y se mantiene durante todo el proceso. Esto implica pasar de una aproximación reactiva a los problemas a una más proactiva, visibilizando cualquier inconveniente con el objetivo de solucionarlo de inmediato y atacando las causas raíz (sistema o procesos).

Podemos resumir estas diferencias de la siguiente forma:

Foco

• Tradicional: Principalmente en la calidad del producto final.
• Lean Software Development: Mejora continua de los procesos y sistemas.

Control de calidad

• Tradicional: Inspección al final o en puntos concretos de la producción.
• Lean Software Development: Calidad incorporada en cada paso (jidoka).

Resolución de problemas

• Tradicional: Reactiva, abordando los problemas después de que ocurren.
• Lean Software Development: Proactiva, destacando y resolviendo los problemas inmediatamente.

Al final, Lean Software Development considera que todo el retrabajo (incidentes, resolución de bugs, procesos repetidos, etc.) generado por problemas y defectos es uno de los grandes desperdicios a eliminar. Por ello, se enfoca en introducir calidad en cada paso del proceso, minimizando el desperdicio y fomentando un hábito de trabajar con calidad y mejorar continuamente.

La calidad es un concepto amplio que puede abarcar varios aspectos: la calidad externa (cómo es percibida por el cliente o usuario final), la calidad interna (relacionada con la facilidad de evolución y mantenibilidad del código o sistema) e incluso la calidad de nuestros procesos y entorno de trabajo.

En esta serie de artículos, pondremos especial énfasis en la calidad externa, tal y como la perciben los clientes o usuarios. No obstante, también abordaremos aspectos de calidad interna y de proceso, ya que son fundamentales para sostener una calidad externa alta a largo plazo. Además, dado que Lean Software Development pone un fuerte énfasis en la mejora continua tanto de los procesos como del sistema para garantizar dicha calidad, también abordaremos aspectos relacionados con la calidad de los procesos y el entorno de trabajo.

Conceptos base

Comencemos con algunos conceptos y definiciones que nos serán útiles en el resto de los artículos:

• Error: Consideramos un error como cualquier desviación del resultado esperado. Por ejemplo, en la ejecución de nuestras aplicaciones, un error puede ser un test fallido, código que funcionalmente no cumple con lo esperado, entre otros.
• Problema: En el contexto de Lean Software Development, un problema es cualquier obstáculo que nos impide entregar valor al cliente de la manera más eficiente y efectiva posible. Esto incluye la diferencia entre el estado actual y el estado deseado, pero también abarca situaciones como: Requisitos ambiguos que llevan a una implementación incorrecta. Problemas de comunicación entre el equipo que resultan en malentendidos y retrasos. Limitaciones técnicas que impiden alcanzar el rendimiento deseado.Ineficiencias en el proceso de despliegue que causan demoras
• Defecto: Es un error que impide que el producto cumpla su función o propósito afectando de forma directa a los clientes. Los defectos son una de las principales fuentes de desperdicio identificadas en Lean Software Development (ver Eliminar desperdicios en el desarrollo). Por ello, es prioritario evitarlos siempre que sea posible y eliminarlos de inmediato cuando se detecten. El artículo enlazado explora cómo Lean Software Development adapta los siete tipos de desperdicio del Lean Manufacturing al software, enfocándose en eliminar actividades que no añaden valor al cliente y promoviendo prácticas como reducir el "Trabajo Parcialmente Hecho" y evitar "Funcionalidades y Código Extra". Ver artículo para ampliar. 

Es importante recordar que los defectos son un subconjunto de errores, y los problemas pueden incluir múltiples errores y defectos.

Aunque esta clasificación puede parecer confusa al principio, distinguir entre problema (una situación genérica que incluye errores y defectos), error (cualquier desviación de lo esperado, como un test fallido, un nombre incorrecto para una variable o una funcionalidad mal implementada) y defecto (un error que afecta al cliente o al propósito del sistema y fuente fundamental de desperdicio) nos ayuda a comprender mejor la situación y a definir procesos adecuados para abordar cada caso.

Enfoque Lean para la reducción de errores y defectos:

• Jidoka: También conocido como "autonomación", este principio busca detectar y corregir defectos automáticamente, deteniendo la producción en cuanto se identifica un error. Un ejemplo clásico de esto en Lean Manufacturing son las "Andon Cards", sistemas de señalización visual que permiten a cualquier trabajador detener la línea de producción al detectar un problema. En nuestro contexto de desarrollo de software, esto se traduce en testing automatizado en distintas etapas, alarmas y monitorización, el uso de un pipeline de CI que detiene el despliegue si las pruebas fallan, entre otros mecanismos.
• Poka-Yoke: Traducido como "a prueba de errores", este enfoque se basa en sistemas y diseños que previenen errores humanos. En el contexto del desarrollo de software, Poka-Yoke se aplica tanto a nuestros procesos internos como a la interacción del usuario con el producto. En el proceso de desarrollo, implementamos Poka-Yoke a través de prácticas como el uso de tipado fuerte en lenguajes de programación, herramientas con valores predeterminados óptimos, tests automatizados, el uso de ValueObjects y precondiciones. Estas técnicas ayudan a prevenir errores de codificación y diseño. En la usabilidad del software, aplicamos Poka-Yoke mediante sistemas anti-error, mensajes de ayuda contextual efectivos y diseños intuitivos. Aquí es donde la Experiencia de Usuario (UX) juega un papel crucial. Aunque la UX no es un mecanismo Poka-Yoke directo en el sentido técnico (como un sensor físico que detiene una máquina), comparte el objetivo fundamental de prevenir errores del usuario. Un buen diseño de UX anticipa posibles errores, guía al usuario de manera clara y ofrece retroalimentación inmediata, reduciendo significativamente la probabilidad de que cometa errores. En este sentido, la UX complementa y refuerza los principios de Poka-Yoke, asegurando que el software sea lo más intuitivo y libre de errores posible para el usuario final.
• Kaizen: Es el principio de mejora continua aplicado a nuestros procesos y sistemas. Como uno de los pilares de Lean, fomenta la búsqueda constante de formas de reducir errores y mejorar la calidad, tanto en el producto como en los procesos y herramientas que utilizamos.

Evitar que los errores se conviertan en defectos

En todos los equipos con los que he trabajado, cometemos errores de forma continua. Algunos son simplemente errores en el proceso de desarrollo, mientras que otros son errores de entendimiento. Estos últimos surgen porque vamos aprendiendo sobre el problema de manera continua. Esta es la realidad: cometemos errores constantemente, y todas las personas que conozco en esta profesión los cometen. Unos se equivocan más, otros menos, pero nadie está libre de errores. 

Si reconocemos y asumimos esta realidad, lo importante es entender que el objetivo no es evitar completamente los errores (algo imposible), sino asegurarnos de que esos errores no se conviertan en defectos que impacten la experiencia del usuario final. El artículo "Be humble, no rockstars allowed" aboga por la humildad y el trabajo en equipo en el desarrollo de software, enfatizando que el aprendizaje continuo y la gestión efectiva de errores son cruciales, en lugar de depender de "rockstars" individuales. Ver artículo para ampliar.

Esa es la aproximación de Lean Software Development: reconocer y aceptar que cometemos errores, y enfocarnos en tener un proceso que nos permita detectarlos, protegernos de ellos de forma continua, solventarlos y evitar que se conviertan en defectos.

¿Cómo lo conseguimos?

1. Incorporando calidad en cada fase del desarrollo, de forma automatizada siempre que sea posible (Jidoka + Poka-Yoke).
2. Mejorando continuamente los mecanismos y técnicas que garantizan la calidad en cada etapa (Kaizen).

En la siguiente entrega, exploraremos cómo detectar errores lo antes posible, detener el flujo cuando aparecen y aprender de ellos sin buscar culpables. Esto podría significar detener el pipeline de CI/CD si una prueba de integración falla, bloquear la subida de código si no pasa los tests unitarios, detener una sesión de pairing si se descubre un error crítico, o incluso detener temporalmente el desarrollo de nuevas funcionalidades para abordar un problema de rendimiento grave. Porque trabajar con calidad implica también tener una estrategia para que los errores no lleguen a convertirse en defectos.