El salto de calidad del software: tres lecciones del enfoque Dantotsu de Toyota para reducir los defectos a escala en Theodo

Cerrando la brecha entre la fabricación y el software, el cofundador y director de tecnología de Theodo, Fabrice Bernhard, explica el viaje transformador de la empresa al aplicar los métodos de calidad dantotsu de Toyota a la ingeniería de software. Descubra cómo estos métodos pueden remodelar los estándares de desarrollo de software y reducir drásticamente los defectos del código.

El software se está comiendo el mundo. Eso significa que el sector del software no puede seguir produciendo el promedio estimado de 10 defectos por cada 1.000 líneas de código.

Una solución es adoptar los estándares de la industria aeroespacial. El equipo de ingeniería de software del transbordador espacial produjo un defecto en 400.000 líneas de código, un estándar de calidad 4.000 veces mejor. ¿Pero a qué precio? Sus procesos incluyen escribir cuatro páginas de especificaciones por cada diez líneas de código. Este no es un enfoque escalable para escribir el volumen de software que el mundo necesita.

Buscando soluciones alternativas para lograr calidad y escala, nos topamos con el libro de Sadao Nomura The Toyota Way of Dantotsu Radical Quality Improvement, donde describe sus increíbles logros de calidad en Toyota Logistics & Forklift (TL&F).

Sadao Nomura había estado en Toyota Motor Corporation desde 1965 cuando los ejecutivos lo asignaron para mejorar la calidad en TL&F en 2006. No era la primera vez que lideraba programas de mejora de la calidad; había logrado rehabilitar una planta de GM en Australia y había ayudado a Toyota Sudáfrica a alcanzar los niveles de calidad que la sede central de Toyota necesitaba para autorizar la exportación global. Hizo todo desde dentro, construyendo relaciones sólidas con los equipos durante muchos años.

En TL&F, trabajó como asesor de siete plantas en cinco países, la mayoría de las cuales la empresa había adquirido recientemente. Comenzó el típico estilo lean yendo con frecuencia al gemba. Capturó sus conocimientos sobre resolución de problemas en los A3 y los compartió con la gerencia. Pero no ocurrió ningún cambio. Parecía que nadie estaba prestando atención a su consejo. No ayudó que la calidad de las plantas fuera relativamente buena en comparación con los estándares de la industria.

Nomura intentó dos veces más compartir su sabiduría sin éxito. Después de que el tercer intento fracasó y pasó un año, cambió su estrategia para asegurarse de que la calidad se convirtiera en una prioridad para todos. Con el apoyo de la sede, creó un programa llamado "Actividades de calidad Dantotsu". Dantotsu es un término japonés que significa "extremo", "radical" o "incomparable". El programa tenía como objetivo motivar y capacitar a los trabajadores para lograr el ambicioso objetivo de reducir a la mitad los defectos anualmente. Mediante una adherencia incesante a las actividades de dantotsu, el equipo debería alcanzar el objetivo de tres años de reducir los defectos en un 88 por ciento.

Los equipos sobre el terreno habían visto fallar programas de calidad antes, por lo que solo confiaban a medias en este nuevo. Sin embargo, se dieron cuenta de la necesidad de algo diferente y el enfoque dantotsu de Nomura fue decididamente diferente. Al centrarse obsesivamente en mejorar la calidad, finalmente trajo cambios a las fábricas. Después de ocho años, las siete plantas redujeron los defectos entre un 91 y un 98 por ciento. Raymond Corporation, la planta estadounidense, ganó el “Premio a la Mejor Planta” de la revista Industry Week.

La historia de Nomura trata sobre la mejora de la calidad en las plantas de fabricación. No obstante, inspiró a Theodo a adoptar un enfoque correcto a la primera en ingeniería de software. Aquí hay tres ideas que tomamos del libro y transpusimos al software.

Un nuevo enfoque para medir defectos

La forma de mejorar la calidad es sencilla: disminuir el número de defectos. Pero la forma más sencilla de disminuir el número de defectos es dedicar menos esfuerzo a buscarlos. Para evitar esto, Nomura clasifica los problemas por etapa de detección y enfatiza no reducir la cantidad de defectos sino detectarlos lo antes posible en la producción. Aplicamos esto a la ingeniería de software con las siguientes etapas de detección:

• Etapa A si fue detectado por el desarrollador en una revisión final antes de impulsar el código;
• Etapa B si fue detectado por alguien más del equipo o por el proceso de integración continua antes de llegar a un cliente interno;
• Etapa C si se detectó después de llegar a un cliente interno (propietario del producto, control de calidad, etc.) y antes de pasar a producción;
• Etapa D si se detectó después de pasar a producción, donde podría haber afectado a un cliente externo, y antes de recibir una queja;
• Etapa E si resultó en una queja del cliente.

Esta categorización proporciona un objetivo saludable. Los equipos se esfuerzan por detectar defectos en las etapas A y B antes de que afecten a los usuarios finales. También es más fácil y económico reparar defectos en estas etapas. Al hacerlo, los equipos pueden evitar defectos en las etapas D y E antes de que afecten a los usuarios finales. Esto se conoce como enfoque shift-left.

Analizar sistemáticamente los defectos

Al tener un enfoque sistemático para analizar los defectos que producen, los equipos pueden identificar rápidamente el origen de los problemas de calidad y cómo prevenirlos. También ayuda a los líderes del equipo a enmarcar el desafío de la calidad como una oportunidad de aprendizaje. El análisis de defectos revela lagunas de conocimiento que luego pueden abordarse con capacitación.

Ejemplo de análisis de dantotsu en Theodo.

El libro de Nomura ha mejorado significativamente nuestro enfoque para analizar los defectos, incluso zanjando un viejo debate sobre si debemos centrarnos en prevenir un defecto o detectarlo antes. La respuesta de Nomura es sencilla: deberíamos analizar cómo el equipo podría haber evitado el defecto y cómo podrían haberlo detectado antes.

Adopción de la gestión de puntos débiles

Al analizar sistemáticamente los defectos, los equipos comienzan a ver patrones e identificar categorías de causas. Nomura los llama "puntos débiles". Una vez que los equipos aclaran los puntos débiles, pueden elegir uno para abordar y erradicar de una vez por todas.

Por ejemplo, llevábamos bastante tiempo sufriendo fallos intermitentes en las pruebas automatizadas de nuestro código. Estos no estaban relacionados con problemas subyacentes en nuestro código, sino con problemas más profundos en la biblioteca de prueba de código abierto Jest que estábamos usando. Los equipos los habían descartado como "debilidad inevitable". Dado que se trataba de un problema conocido que afectaba a muchos de nuestros equipos y a otros en todo el mundo, decidimos investigar más a fondo. Fue un problema difícil de resolver. Pero con un esfuerzo concentrado, ideamos una solución permanente, que aportamos a la biblioteca de código abierto. El problema ahora está resuelto permanentemente no solo para nuestros equipos sino para todos los demás usuarios de la biblioteca, sin mencionar el ahorro de energía que resultaría al evitar millones de ciclos de CPU desperdiciados.

Después de dos años de implementar dichos aprendizajes en Theodo, el 80 por ciento de nuestros proyectos ahora miden la cantidad de defectos categorizados por las etapas de detección A a E. Hemos perfeccionado un estándar para analizar eficazmente esos defectos para ayudar a los líderes tecnológicos a adoptarlo dentro de sus equipos. Y estamos trabajando para que el análisis de defectos forme parte de la rutina del equipo para acelerar su aprendizaje e identificar los problemas recurrentes que se beneficiarían de una solución organizacional.

Algunos equipos incluso están experimentando con un análisis sistemático de defectos en la Etapa A. Los equipos marcan una contribución de código como defectuosa si falla en la primera verificación humana. Este es un enfoque original, ya que los ingenieros codifican de forma iterativa con múltiples rondas de escritura de código y comprobando visualmente que funciona. Pero esos equipos decidieron apuntar a un código correcto a la primera. Los resultados son prometedores. Un equipo creó una aplicación médica con 6.000 líneas de código y solo detectó dos defectos de producción. Esto es 30 veces menos que el promedio de la industria sin tener que documentar cada línea de código en cientos de páginas.

Todavía estamos en las primeras etapas de nuestro viaje hacia la transposición del libro de Sadao Nomura al software, pero ver mejoras tan espectaculares ha sido inspirador. Es otro ejemplo de cómo Lean es una fuente indispensable de aprendizaje (sin importar la industria) cuando se trata de lograr calidad a escala.