domingo, 5 de octubre de 2003

Aprendiendo de Toyota

Observar los errores y aciertos de otras industrias es una técnica muy utilizada para mejorar el estado actual del desarrollo de software como disciplina, y pienso que aprovechar años de madurez de industrias como la automotriz puede ser beneficioso siempre que se haga observando con atención hasta donde cada práctica, técnica o principio es adecuado para el nuevo ámbito donde se lo desea aplicar.

Bien, ahora el punto es, ¿a quién observamos para aprender? Muchas empresas en el pasado han aprendido del fenómeno japonés y de Toyota en particular. ¿Observar a Toyota puede aportar algo al desarrollo de software? Podemos pensar que si.

Taiichi Ohno fue contratado por Toyota para instalar un sistema de producción para producir automóviles de alta calidad. Durante 3 décadas, Ohno desarrollo el Toyota Production System, conocido ahora como Lean Manufacturing.

Los valores básicos de Lean Manufacturing son:

* Agregar sólo valor
* Centrarse en las personas que agregan valor
* Generar valor por demanda
* Optimizar a traves de organizaciones

Hay varias factores llamativos en Lean Manufacturing: su aplicación representó un mejoramiento notable de la calidad y productividad, requería un cambio de paradigma porque contradecía buenas prácticas aceptadas hasta su aparición y sus principios han sido exitosamente aplicados en negocios de todo tipo.

Seguramente, estos factores han sido elementos importantes que llevaron a Mary Poppendieck ha escribir un conjunto de artículos y un libro trasladando las enseñanzas de Lean Manufacturing al desarrollo de software. Es un material que merece ser leido.

Algunos extractos de sus artículos para tener una primera aproximación al tema:
“El 'Lean Thinking' observa la cadena de valor y se pregunta: ¿cómo se pueden estructurar las cosas para que la empresa no haga nada además de agregar valor, y que lo haga lo más rápido posible? Todos los pasos intermedios, todos los tiempos intermedios y todas las personas intermedias son eliminadas. Sólo se deja el tiempo, las personas y las actividades que agregan valor para el cliente”

“La medida de madurez de una organización es la velocidad con la cual puede responder repetida y confiablemente a solicitudes de sus clientes.
Si, escucho bien. La madurez no es medida por la amplitud de la documentación de un proceso o la habilidad de hacer planes detallados y ejecutarlos. Es medida por la excelencia operacional, y el principal indicador de la excelencia operacional es la velocidad con la cual la organización puede repetida y confiablemente servir a sus clientes.”

“Por lo tanto, si el cliente quiere algo, ¿qué pasos debe cumplir la solicitud para que el resultado sea entregado al cliente? ¿ Qué tan rápido fluye ese proceso? Si la solicitud de un cliente espera en una cola para aprobación, una cola para diseño, una cola para desarrollo, una cola para testing, y una cola para despliegue, el trabajo no fluye muy rápido. La idea es crear celdas(o equipos) de personas encargadas de tomar cada solicitud desde la cuna hasta la tumba, rapidamente y sin interrumpciones. Entonces el valor fluye.”

“Los documentos, diagramas y modelos producidos como parte de un proyecto de desarrollo de software son productos perecederos, ayudas utilizadas para producir el sistema, pero no necesariamente parte de un producto final. Una vez que un sistema completo es entregado, al usuario le puede importar muy poco estos productos intermedios. Los principios del Lean Thinking sugieren que cada producto intermedio es candidato a escrutinio. La carga sobre cada producto intermedio no es sólo probar que agrega valor para el producto final, sino tambien que es la manera más eficiente de alcanzar este valor.”

“Cuando se observan detalladamente, la mayoría de las teorías sobre como administrar proyectos de software son basadas en la teoría de descomposición: separe el todo en partes individuales y optimice cada una. El Lean Thinking sugiere que optimizar parte individuales casi siempre lleva a sub-optimizar el sistema completo.
Por ejemplo, optimizar el uso de recursos de testing decrementa la aptitud de todo el sistema de producir rapidamente código testeado y funcionando. Medir la habilidad individual de producir código sin defectos ignora la hecho bien conocido que el 80 % de los defectos son causados por la manera en que el sistema funciona, y por lo tanto problemas de management.”

Los artículos: Lean Software Development, Principles of Lean Thinking, Lean Programming , Mary Poppendieck
El libro: Lean Software Development: An Agile Toolkit for Software Development Managers, Mary Poppendieck y Tom Poppendieck.