Jidoka es uno de los elementos básicos del Sistema de Producción de Toyota (TPS). Jidoka significa "automatización con un toque humano". El término viene del Telar Automático Toyota Tipo-G que se detenía automáticamente cuando detectaba un problema, como ser cuando se rompia el hilo. De esta manera, el operador no tenía que estar controlando constantemente a la máquina, y podía intervenir rápidamente cuando alguno de los telares detectaba y señalizaba un problema.
Este mismo principio puede aplicarse a cualquier línea de producción. Cuando una máquina o, más precisamente, un empleado detecta un problema, detienen la línea y señalizan el problema usando un tablero Andon. Todos pueden ver que hay un problema. El líder del equipo puede ayudar a diagnosticar el problema y resolverlo.
Mientras más rápido se detecte al problema, más facil será solucionarlo y menor será el impacto. Por lo tanto, una de las partes más importantes de Lean es ser capaz de detectar problemas, avisarlos rápidamente, analizarlos y resolverlos.
Jidoka y el desarrollo de software
¿Podemos aplicar este principio de líneas de producción al desarrollo de software? Por supuesto.
¿Cómo podemos detectar problemas y defectos? Una buena forma es tener una suite completa de pruebas unitarias e integración continua. Cada vez que subimos cambios al repositorio de código, el servidor de integración continua nos avisa si rompimos algo. El servidor de integración continua es nuestro tablero de Andon. Patrick Debois tiene muchos ejemplos de Andon en su colección Visu-Wall.
También se puede tener una suite de pruebas funcionales automatizadas, pruebas de rendimiento, analizadores de código y otras herramientas que se ejecutan en el servidor de integración continua.
Otra excelente forma de implementar Jidoka es con buenos testers que realmente estén involucrados desde el inicio del proyecto y hagan un seguimiento de los entregables. Los verdaderos buenos testers nos pueden decir con claridad lo que está mal, y como reproducir el problema.
En resumen, vamos a estar implementando Jidoka siempre y cuando tengamos una forma rápida y confiable de saber cuando algo está mal.
Jidoka es una actitud
¿Eso es todo? Por supuesto que no. No alcanza con detectar problemas, además tenemos que hacer algo al respecto.
¿Se rompio el build en integración continua? No subí todos los cambios, no es mi culpa.
¿Cómo que "no funciona"? ¡En mi máquna funciona bien!
¿Quién lo dice? Ah, José... es muy negativo, siempre encuentra algún problema en cualquier cosa.
¿Escucharon frases como estas alguna vez? No alcanza con detectar problemas, también tenemos que hacer algo al respecto. La única respuesta correcta hacia alguien que nos informa de un problema es "¡Gracias!". Y después el equipo corrije el problema.
Cuando correjimos el problema, tenemos la mitad del trabajo terminado. La otra mitad es preguntarnos porqué nuestro sistema de Jidoka actual no detectó al problema a tiempo:
- ¿Por qué ninguno de nuestras pruebas de desarrollo atrapó el problema a tiempo? ¿Cómo podemos mejorar las pruebas en esta área? ¿Es una stiuación que podría pasar en otras partes del código? ¿Lo vamos a detectar ahí?
- ¿Por qué ninguna de las pruebas del cliente detectó el problema a tiempo? ¿Cómo podemos mejorar nuestras especificaciones para esa área? ¿Hay otros puntos ciegos? ¿Cómo podemos mejorar estas especificaciones?
- ¿Por qué no se probó este caso? ¿Entendimos mal lo que se necesitaba? ¿No hicimos lo acordado? ¿Tenemos riesgos de mas malos entendidos?
En IT, el cuello de botella más grande es el aprendizaje. Al reflexionar sobre nuestros problemas, aprendemos a detectarlos antes.
Jidoka necesita transparencia, confianza y colaboración
Resultaría facil implementar Jidoka si tan sólo fuera instalar herrramientas y producedimientos. Pero implementar Jidoka es muy dificil, porque involucra:
- Hacer que cada problema sea visible. Vamos a herir el orgullo al admitir que cometimos un error.
- Recompensar a las personas que admiten errores. ¿No entra en conflicto con la idea de Lean de "Correcto La Primera Vez"? ¿No deberíamos recompensar sólo a las personas perfectas?
- Tomarnos el tiempo para mejorar nuestros sistemas de detección de problemas. ¡Pero tenemos tantos problemas para arreglar y tan poco tiempo para hacerlo!
- Agradecer a las personas que hacen visible los problemas. Si, incluso al molesto que siempre encuentra problemas en todo lugar. Si, incluso al tester que se pone contento de contrar "problemas" en mi querida creación.
- Colaborar como equipo para resolver problemas de forma rápida y completa. Sin importar quien "ocasione" o encuentre el problema, nuestro objetivo común es crear trabajo de alta calidad y alto valor.
Implementar Ágil o Lean es dificil. Implementar todos los Valores Ágiles es dificil.
Y ustedes, ¿ya hicieron algún problema visible? ¿agradecieron hace poco a algún tester? ¿mejoraron sus herramientas de Jidoka ultimamente? Y si no, ¿están haciendo sólo la mitad del trabajo?
