Business Intelligence
LAN

TPS o cuando Toyota inventó DevOps

La historia se repite, tantas veces que uno podría dudar si realmente no fue un mito.

 

Hace muchos años en la tierra solo se hablaba una lengua. Los hombres eran felices y conocían el valor de las cosas y cómo nombrarlas. Pero el hombre quiso más. Entonces construyó una torre; debía ser tan alta como para llegar al cielo y desafiar al mismísimo Dios. Su ambición fué castigada y aquella torre de Babel destruida. Y hoy en día la complejidad se extiende sin control y unos hablan de Agile, otros hablan de ITIL, otros de Lean y están, si, los que de un tiempo a esta parte sólo hablan de DevOps.

La historia se repite, tantas veces que si simplificáramos podríamos hasta pensar que no hay tantas cosas nuevas bajo el sol y que los nuevos paradigmas son realmente la cristalización y madurez de principios antiguos; no tanto como aquella torre, pero con su mismo pasado.

Se dice que DevOps se empleó como término por primera vez en los DevOps days, Belgica 2009. Pero, a pesar de nuestra creencia de que un nombre nuevo es sinónimo de algo nuevo, los principios de DevOps se establecieron casi 7 décadas antes.

Japón, año 1950, Toyota, tras la segunda guerra mundial, Edward Deming, Taichii Ohno, Shigeo Shingo y Eiji Toyoda crean el Toyota Production System dando lugar a lo que cuarenta años después se denominaría Lean en la obra The Machine that changed the World, Womack &Jones.

El TPS se basa en tres principios fundamentales a través de los cuales cambiar la forma de pensar y de actuar de las personas:

  • Calidad en la fuente
  • Producción nivelada o Just In Time
  • Mejora Continua

Son tres principios simples, casi elementales, pero de una gran significancia y que, como veremos a continuación constituyen los elementos esenciales que conforman lo que a día de hoy se denomina DevOps.

 

Quality At The Source

El principio de calidad en la fuente, persigue conseguir el resultado correcto de cada acción a la primera; enfocarse en asegurar la calidad en cada paso permitirá reducir los tiempos de entrega y los costes operativos, aspectos esenciales de Devops: entrega rápida de software de calidad al negocio. Para ello se deberá integrar las pruebas en el desarrollo, alterando incluso la forma de programar hacia lo que viene a llamarse el Extreme Programming, algo tan contra-intuitivo como desarrollar el caso de prueba antes que la pieza de código a ser probada ya que de esa forma el desarrollo del código se orienta al resultado esperado de la prueba; o lo que es lo mismo, cambiar la forma de pensar y de actuar del desarrollador para buscar la calidad en la fuente y conseguir integrar la prueba en el desarrollo.

Por tanto, los sistemas de integración continua Devops, para la integración y automatización de las pruebas unitarias y de regresión, de integración, e incluso aceptación y el análisis estático de código son una implementación de principio fundamental de Quality At the Source.

Pero hay más; cuando un equipo DevOps al terminar el día de desarrollo lanza los scripts que automatizan las pruebas y generación de builds y al día siguiente visualizan el nivel de calidad del código, su deuda técnica y los fallos de los tests de cara a poder planificar su resolución el mismo día están aplicando Jidoka, aspecto esencial de Quality At The Souce del TPS: los defectos son visibles, todos pueden ver aquello que es defectuoso y responsabilizarse para su resolución. Es más, cuando un equipo Devops ve que la deuda técnica es superior a la admitida se orientará ese día a refactorizar su código para asegurar la mantenibilidad futura en la operación. De esta forma esta aplicando el mecanismo Andom de parar la cadena de producción para asegurar el quality at the source y no seguir produciendo si el nivel de defecto es superior al admitido.

 

Just In Time

El segundo de los principios fundamentales del TPS es la producción nivelada o Just In Time, de manera que todos los pasos de la cadena de producción se nivelen al ritmo de la demanda del cliente, evitando pasos que sobre-producen y otros que sean cuellos de botella y en los que se quedará acumulado el inventario, provocando que los niveles de WIP sean superiores a los tolerables y se produzcan esperas y costes innecesarios.

Uno de los aspectos esenciales para asegurar el JIT se conoce como la aplicación del WIP Cap, poner un límite a la cantidad de trabajo en progreso dentro de la cadena de valor para reducir los niveles de inventario y controlar la entrada de unidades de trabajo, asegurando la adecuada nivelación de cada paso de la cadena al ritmo de la demanda y cambiando la forma de pensar y de actuar de las personas que intervienen en la misma para enfocarles a terminar el trabajo en curso antes de asumir nuevas unidades de trabajo.

Los equipos Devops implementan métodos ágiles para nivelar el rimo de producción al ritmo del negocio, de manera que planifican sprint de duración específica y conforman una pila de sprint ajustada a las prioridades del negocio y a la capacidad estimada del equipo Devops, haciendo necesaria la existencia de un product owner que asegure la adecuada gestión de la demanda y maneje las prioridades del negocio. Todo esto es posible porque los equipos Devops reducen el tamaño de lote para trabajar con unidades de trabajo atómicas, que entregan valor al negocio, aplicando así el principio Lean de reducción del tamaño de lote para asegurar la adecuada nivelación e integrar el cambio en el día a día de los equipos.

De esta forma, tanto los métodos ágiles, como Devops se sirven de la reducción del tamaño de lote y el WIP Cap para habilitar una producción nivelada y asegurar el Single Piece Flow, concepto esencial del ADN del TPS.

Otro de los aspectos del JIT que se incorpora en los equipos DevOps es la necesidad de reducir la inflexibilidad y, por tanto, la interrupción del flow debido a la falta de nivelación de los Skills y Conocimientos dentro del equipo. De manera que un equipo DevOps trabaja con matrices de S&K, presentes en el TPS y en Lean, para balancear el nivel de skills y conocimiento de los miembros del equipo y la demanda del cliente, consiguiendo equipos multiskilled capaces de absorber picos y valles de demanda al trabajar como un sistema nivelado.

DevOps incorpora el principio TPS del JIT basado en la nivelación de la capacidad de trabajo y de los skills a la demanda del cliente; cada miembro dentro del equipo DevOps cambiando la forma de pensar y de actuar incorporando un System Thinking: cada miembro se responsabiliza de su trabajo y piensa en el sistema, trabaja por el sistema, persigue la nivelación, la colaboración y comunicación con el resto de miembros del sistema –equipo Devops- con quien comparte el reto de entregar software de calidad rápidamente al negocio.

 

Mejora continua

Para completar nuestro estudio, no podemos dejar de señalar cómo la mejora continua a través del aprendizaje diario de las personas del equipo, comportamiento esencial del TPS, es parte consustancial de los equipos DevOps, los cuales, basándose en la gestión visual diaria son capaces de visualizar y aprender de sus errores y dedicar tiempo a retrospectivas que les permitirán ajustar sus métodos de estimación de esfuerzo, adecuar el uso de las herramientas, aprender a identificar y eliminar sus desperdicios, incrementar su eficiencia de proceso, reducir sus niveles de defecto y alcanzar cotas desafiantes de alto rendimiento capaces de entregar valor al negocio rápidamente y cuando el negocio lo requiere.

El aprendizaje diario es una cualidad que distingue un sistema de producción TPS. Para aprender el equipo deberá pensar y actuar que el aprendizaje colectivo basado en la comunicación y colaboración y el uso de herramientas de gestión visual contribuirá a mejorar su día a día e incrementará la satisfacción del cliente.

El liderazgo será una pieza esencial para generar el clima de confianza y compromiso en los equipos que favorezca el cambio de la forma de pensar y actuar y el compromiso diario con la mejora continua, la reducción de desperdicios y el ajuste sostenible del sistema.

La historia se repite. Las circunstancias actuales son únicas, nuestro sector está en un momento de cambio evolutivo, pero los principios son los mismos, son principios simples, casi podríamos decir que elementales, pero de una gran significancia.

 

Guillermo López Moratinos

Es ingeniero informático por la UAM; auditor certificado en Sistemas de Gestión ISO 20000, 27001, 22301, 15504, CISA, CRISC por ISACA; Lean IT Coach, Six Sigma Black Belt; Agile Coach, ITIL Expert, DevOps certified; con experiencia en consultoría y auditoría, gestión de proyectos y servicios TIC; Fundador de Coach Organizativo: Profesor acreditado de ITIL, Lean, DevOps, Kanban, Scrum, Six Sigma y profesor del Máster de Auditoría de Seguridad y Derecho de las TIC en la UAM; Autor del libro "Gestión de proyectos" PMP-Prince2 del IPECC, Madrid; Colaborador habitual de AENOR; Miembro del "itSMF ISO20000 GT Difusión". Madrid, España.



Revistas Digitales

DealerWorld Digital

 

También es noticia...

ciberseguridad Ciberseguridad

Documentos Computerworld

Registro:

Eventos: