Del Taylorismo a DevOps

Resumen
La revolución industrial ha transformado profundamente nuestra sociedad desde principios del siglo XX, la influencia del pensamiento tayloriano para el ensamblaje en línea ha marcado nuestra manera de resolver los problemas tecnológicos con relativo éxito. Este artículo es una reflexión sobre el impacto en la industria del software de la metodología tayloriana hasta nuestro días, la evolución de la línea de ensamblaje de principios del siglo pasado hasta DevOps.


Metodología
Existe la tendencia de confundir la metodología con las herramientas y los procesos particulares. Una definición de la metodología indica que es el conjunto de procesos de lógica e inferencia para realizar una tarea específica.

A diferencia del uso de herramientas y de los  conocimientos específicos, la metodología posee una característica transversal. Es más llamado a ser un state of mind o una filosofía, y merece este concepto más que otro. El espíritu de la metodología debe ser abierto y de permanente cuestionamiento, es además un conjunto de conocimientos que permite la mejora y la optimización de procesos, y como toda filosofía es contraria a todo principio dogmático.

Nuestra referencia inequívoca de una metodología, en este caso una metodología de trabajo, es el estudio del trabajo de Taylor, nuestra sociedad actual como la conocemos está profundamente impregnada de procesos taylorianos: especialización del trabajo, producción en línea, toma de tiempos, etc. desde principios del  siglo XX la empresa humana, en casi todas sus especializaciones han sido guiada por esta metodología, y esta influencia persiste hasta nuestros días.

En la definición científica de Taylor “división sistemática de las tareas, la organización racional del trabajo en sus secuencias y procesos, y el cronometraje de las operaciones, más un sistema de motivación mediante el pago de primas al rendimiento, suprimiendo toda improvisación en la actividad industrial.”, no se aplica solamente en las líneas de montaje de todas las industrias, la sociedad aplica este concepto en las diferentes ramas de la actividad humana: hospitales, la distribución jerárquica de los trabajadores, etc. 

​

Build failed : Taylor 

En el mundo IT, Taylor está presente, si hacemos un análisis de los procesos metodológicos en el desarrollo del software, el método cascada o waterfall, es la representación de un ensamblaje de un coche en la línea de producción. 

En la industria del software esta metodología de desarrollo y concepción ha demostrado en más de 30 años su fracaso para satisfacer los exigentes requisitos de calidad y productividad, de manera independiente de los atributos no tangibles del software, la concepción tayloriana es inadecuada para el desarrollo de software.

La línea de ensamblaje concebida por Taylor, todas las interacciones que son necesarias para realizar el ensamblaje de diferentes piezas, siguen un esquema y un patrón exacto y finito, que asegura la homogeneidad en la calidad del producto final: para un mismo modelo de producto final, no existe variación posible en el conjunto de piezas montadas. En la línea de ensamblaje de software, no existe un esquema definido puesto que las piezas que se ensamblan no son las mismas (variabilidad), para alcanzar la elaboración del producto final (build)  la línea de montaje en el desarrollo del software es única, efímera e irreproducible. 

Cada componente de software, tiene una complejidad intangible, la lógica business es tan particular que cambia de cliente a cliente en el mismo sector de actividad. Hay, sin embargo, una constante que es subjetiva y permanente: La calidad.

Un análisis superficial podría reducir la diferencia entre la línea de ensamblaje típico y de software por  la naturaleza intrínsecamente intangible del software, a diferencia de una pieza industrial que posee características de peso, dimensiones, etc. La calidad  para un producto típico se basa en la medida de estos atributos. Para un componente de software la calidad se mide sobre la propia calidad del software, es decir sobre sus valores intangibles de los usuarios que son transcritos en un documento de análisis funcional.

“Out of Crisis” de W. Edwards Deming que ha sido escrito en el auge del Taylorismo. Demming propone algo diferente a Taylor cuando habla de la modificación de management (Principles of transformation of western management) y el paralelo entre Agile es innegable cuando habla de eliminar las barreras entre los departamentos y entre los equipo de trabajo, de institucionalizar la cultura del trabajo y el auto aprendizaje.

Agile

En los últimos 20 años, de metodologías emergentes han tratado de mejorar la productividad en el desarrollo industrial del software, para la metodología Agile el epicentro de todo el proceso de producción es el ser humano. Y la propuesta es audaz, porque es el ser humano el actor más flexible y versátil de esa línea de producción pero el más inestable también. La metodología Agile propone reducir al mínimo necesario todos los procesos que se encuentran alrededor del verdadero objetivo: la calidad. Los valores primordiales son la comunicación, la responsabilidad, la iniciativa personal, y evidentemente la improvisación del día a día.

Agile, es una metodología que no es perfecta, en la misma medida de proponer disminuir el “ruido” y los procesos administrativos a los que el equipo de desarrollo, testing e infraestructura están confrontados, en Agile no hay una explicación explícita como ponerlo en práctica. Y es normal: es una metodología, son los ingenieros de procesos los llamados a optimizar el ser humano con las herramientas y el procedimiento. Ese es el reto en Agile, esa es su dificultad. Sus valores son:

• Proactividad individual e interacciones son más importante que los procesos y las herramientas
• Software que funciona (BUILD) es más importante que una documentación extensa
• Colaboración con el cliente es más importante que una negociación
• Improvisación más que seguir un plan

En estos valores, lo que resalta es la importancia de la interacción humana que debe producir el software ejecutable (BUILD) esta dinámica tiene como único objetivo de optimizar todos los procesos para encontrar la línea de proceso más óptima.


DevOps

La década del 2000 fue una etapa importante en el reconocimiento de la industria del software que la única forma de desarrollar software de manera correcta en términos de calidad y productividad es alejarse del método tayloriano. La adopción de Agile fue un paso en esa dirección, pero recordemos nuestra definición de metodología, el rechazo absoluto a los valores dogmáticos. Agile demuestra que no es una metodología perfecta, su concepción orientada sobre el código de programación es su punto más débil, la ausencia del concepto Testing Funcional, la falta de la implicación de otros servicios de Testing, Infraestructura, Perfomance, Monitoring, y un sistema de calidad orgánica son simplemente obviados.

La presión de entregar software funcional, de alta calidad forzó a los tecnólogos a resolver este desafío, la respuesta fue formalmente presentada en una exposición en Bélgica en 2008. DevOps, una abreviación de Desarrollo y Operaciones en Inglés. Esta metodología es mucho más orgánica y sistémica que Agile, no es solo una evolución natural de Agile, es todo una filosofía alrededor del concepto Lean, si bien todo el punto de equilibrio de esta metodología se soporta sobre los valores comunes de Agile, es una evolución importante en la concepción y soporte al desarrollo del software.

DevOps es el esfuerzo de integrar en un solo ciclo o iteración Agile los procesos y operaciones que siguen el proceso de desarrollo: testing, operaciones, infraestructura, y soporte. 

Requisitos para aplicar Devops.

Es una pregunta lógica, la respuesta es compleja por el grado de compromiso así como las habilidades tecnológicas de los diferentes equipos de desarrollo, testing, infraestructura, especialistas de build & deployment, es lo que se conoce como “ALM Maturity”, un equipo debe ubicarse entre el nivel de “Competencia Funcional” y “Excelencia Funcional”

Además un equipo que aspira a plicar DevOps debe contar: 

• Comprobada experiencia Agile de los equipos : Ser un equipo Agile no es una meta en sí, es un esfuerzo constante por lograr la Agilidad en el Equipo, demanda mucho esfuerzo y en concreto el equipo debe poseer una madurity en :
  • Test Unitarios y de Integración automatizados
  • Build y Deployment automatizado
  • Opcional : Test de regresión y aceptación automatizados
• Un sólido equipo de Infraestructura y Operaciones con experiencia en automatización 
• Un equipo de Testing dedicado
• Una estructura jerárquica horizontal que permita la eliminación de silos y falta de comunicación

No existe una receta que garantice el éxito de DevOps. La parte más difícil no es el aspecto tecnológico, sino de conceptualización y cuestionamiento continuo del aspecto metodológico. Una vez más es la metodología establece la línea a seguir.

Resumen

• El taylorismo es una metodología de trabajo que no es óptima para el desarrollo de software, los ciclos de trabajo son largos y rígidos, y no existe el concepto de iteración en la línea de producción, el cliente se encuentra al final de la línea, él no participa activamente en el proceso de desarrollo del producto.
• Agile es una metodología de desarrollo de software que propone de cortos ciclos de desarrollo e incorpora al cliente en la validación de la calidad. Agile es una metodología centrada en el desarrollador o programador y el cliente. Uno de los puntos débiles en este enfoque es el hecho que Testing, las Operaciones de soporte no están incluidas en el ciclo o iteración (sprint).  
• DevOps es el intento de introducir en el mismo ciclo Desarrollo, Testing y Operaciones, es muy importante la automatización para disminuir las variaciones en el proceso. Actualmente DevOps es una buena opción metodológica para el desarrollo, testing y deployment de aplicaciones de software.
  ​