La agilidad empresarial engloba una serie de prácticas (design thinking, Lean startup, customer journey, co-creación, prototipado, Agile o DevOps, entre otras) que permiten adaptarse a los retos que la transformación digital y a clientes cada vez más  conocedores y ávidos de soluciones tecnológicas. Estas prácticas permiten:

• Desarrollar capacidades de diseño, desarrollo y lanzamiento rápido de nuevos productos rentables y adecuados a las necesidades de sus clientes.
• Construir organizaciones que sean capaces de adaptarse rápidamente a entornos de gran incertidumbre.

Pero es necesario un buen equilibrio. Si el negocio comienza a experimentar con la
cocreación, el desarrollo iterativo de productos y el prototipado de soluciones digitales, pero sus departamentos de tecnología le requieren una pila completa de requisitos para comenzar a desarrollar, terminaremos generando frustración. En el mismo sentido, si conseguimos implantar metodologías agiles de gestión de proyectos y liberar versiones de los productos digitales de forma incremental, pero los departamentos de pruebas u operaciones no son capaces de ponerlos a disposición del cliente con la misma velocidad, tendremos problemas en los flujos de retroalimentación.

Este último es el punto clave donde incide DevOps. No existe un equivalente al manifiesto ágil para DevOps, como indica Patrick Debois, uno de los padres del concepto DevOps: “I value more the different models people have developed along the years to understand/explain the ‘DevOps’ problem space”. Este “espacio” se asocia fundamentalmente a los límites e ineficiencias surgidos en el flujo de entrega de soluciones digitales entre las actividades de desarrollo, pruebas y operación. El foco que pone DevOps en ese “espacio”, y en crear un flujo extremo a extremo eficiente, es clave y supone un factor diferencial frente a otras prácticas como ITIL, Lean IT o Agile.

DevOps ayuda a entregar valor visible a los clientes de la TI de forma rápida

¿Qué es DevOps?

Surge de la fusión de development y operations. Se refiere a la filosofía de organización de los departamentos de TI que promueve la comunicación, colaboración e integración entre desarrolladores de software y profesionales de operación TI, sin olvidar el resto de integrantes del flujo de entrega de valor del servicio, como ingenieros de pruebas y despliegues.

DevOps considera la interdependencia del desarrollo de software y la operación de TI para crear productos y servicios de mayor calidad. Asimismo, ayuda a entregar valor visible a los clientes de la TI de forma rápida.

El foco de DevOps también está en la entrega de servicios de valor y mantenibles, entendido esto como la facilidad de operar el servicio. Algunos puntos clave son:

• Definición de servicios que sean manejables, con un cliente claro y una responsabilidad asociada a la pila tecnológica que cubrirá el equipo.
• Creación de equipos multidisciplinares que incorporan roles como el de representante del cliente, experto en experiencia de usuario, ingenieros de desarrollo, de pruebas, de despliegue o de operación. Cada miembro del equipo debe ser autónomo en la cobertura del servicio.
• Establecimiento de responsabilidades definidas sobre un servicio y objetivos comunes, que eviten el “rebote” y la búsqueda de culpables entre distintos departamentos.
• Definición del flujo completo del servicio y de los procesos que aseguren su entrega. Debe contemplar desde la planificación hasta la operación del servicio.
• Dotación de las herramientas requeridas para la automatización del flujo.

¿Se aplica a mi organización?

Antes de aplicar esta filosofía de trabajo, debo preguntarme si existe alguno de los problemas que DevOps ayuda a resolver. Por ejemplo:

• ¿Existen servicios sobre los que el negocio requiere entregas más frecuentes de nuevas funcionalidades?
• ¿Las barreras entre desarrollo y producción no están claras y esta falta de definición provoca frecuentes conflictos?
• ¿Tengo problemas en la calidad del software que se cubren con frecuentes parches y generan trabajo adicional a los equipos de producción?
• ¿He conseguido acelerar el desarrollo pero la puesta en producción no sigue el mismo ritmo?

Si la respuesta es afirmativa, el siguiente paso es entender los factores que influyen en la extracción de valor completa, que se analizan a través de nuestro Modelo Integral DevOps (DevOps Integration Model), mediante el cual se evalúa cómo de preparada está la organización para adoptar DevOps.

Algunas herramientas clave de DevOps, como la implantación de métricas “extremo a extremo” para la entrega de servicios y soluciones digitales, soluciones de automatización de pruebas y despliegues (integración, entrega o despliegue continuos) o la mejora de la comunicación entre los departamentos de desarrollo y operación, son prácticas útiles en cualquier organización.

¿Cómo abordo la transformación?

¿Lo que necesito son herramientas, procesos y métricas nuevas, cambios organizativos? La respuesta es clara: si quiero obtener buenos resultados, debo considerar todos esos puntos.

El mencionado Modelo Integral DevOps contempla cinco dimensiones en la adopción de las prácticas DevOps (Figura 1.) Cada dimensión y sus aspectos asociados son evaluados de acuerdo con los cuestionarios y con la definición de los niveles existente. De esta forma, se llegará a un estado actual y se definirá el estado objetivo, siguiendo el modelo como guía para el proyecto de mejora de la adopción.

Por un lado, el modelo de organización debe pasar de uno orientado a la mejora de la eficiencia interna del departamento de TI —mediante silos especializados en pasos del flujo de valor (desarrollo, pruebas, producción) y muchas veces externalizados en proveedores externos— a otros orientados al cliente y a soluciones digitales.

Además, habrá que cambiar las métricas de evaluación del rendimiento. Alineadas con los silos organizacionales, es muy frecuente encontrar métricas enfocadas al funcionamiento de cada departamento sin considerar la visión extremo a extremo del servicio.

Por otro lado, la transformación que supone el enfoque DevOps requiere un cambio en los equipos de TI: trabajar el comportamiento y actitud en los distintos niveles (negocio, desarrollo, operaciones) y crear equipos multidisciplinares enfocados a un servicio o solución digital con objetivos comunes.

Estos nuevos equipos deben incorporar roles que permitan cubrir el ciclo completo del servicio. Estos roles pueden ser desempeñados por distintas personas del equipo en distintos momentos, lo que habilita la autonomía del equipo y es la base de la multidisciplinaridad buscada. Sin embargo, en la realidad de una adopción progresiva, el uso de recursos especialistas compartidos, y la relación con otros equipos, son elementos necesarios y deben establecerse mecanismos que eviten pérdida de eficiencia del equipo.

Por último, para la adopción de DevOps es muy importante entender el flujo completo de los servicios digitales: el modo en que se gestiona la demanda y se toman las decisiones de inversión. En cuanto a los nuevos servicios y evoluciones, ¿qué filosofías o metodologías de gestión de programas y proyectos son las idóneas en función de cada demanda? Además, hay que entender el ciclo de vida de las aplicaciones, desde su diseño inicial a su posterior despliegue.

DevOps se centra, principalmente, en facilitar el flujo entre los pasos de desarrollo, pruebas, puesta en producción y operación. En este sentido, la tecnología está siendo un habilitador muy destacado en su despegue.

Es necesario el equilibrio y la combinación de los distintos factores de cada dimensión para avanzar en la consecución de mejores resultados. Disponer de herramientas de despliegue continuo pero equipos de desarrollo y operaciones sin una comunicación fluida, equipos integrados pero con objetivos diferentes en función del departamento jerárquico al que pertenecen, o una comunicación continua pero sin un soporte de automatización de pruebas y regresión son ejemplos que suponen importantes ineficiencias y la frustración de los equipos.

¿Cuáles serán las principales barreras?

El enfoque planteado en los puntos anteriores supone un profundo cambio en los departamentos de TI, por tanto, un requisito necesario es que exista voluntad de cambio y esponsorización de la dirección.

Algunos de los retos para abordar la adopción de prácticas DevOps  suelen estar, por ejemplo, en la estrategia de sourcing y en la existencia de contratos que dificultan su adopción. Muchas compañías han optado por la externalización de sus silos de especialización técnica (factorías de desarrollo, oficinas de pruebas, distintos niveles de operadores). Si, al menos para determinados servicios digitales, se busca una mayor orientación al cliente y mejorar la calidad y velocidad de evolución de los servicios, se deben diseñar para estos estrategias de Agile sourcing, lotes y contratos dirigidos a la cobertura extremo a extremo de los mismos.

Otro reto viene por el peso de lo existente (el legacy): las soluciones que habilitan el flujo de integración, entrega, despliegue y regresión automática no cubren de la misma manera todas las tecnologías. En este sentido, en la fase de análisis es aconsejable considerar servicios soportados por aplicaciones basadas en lenguajes de programación más recientes que minimicen este efecto. En cualquier caso, en el análisis y estructuración de los equipos deben planificarse posibles contramedidas sobre este riesgo.

Por otro lado, debemos hablar de la resistencia al cambio en la organización. Sin duda se trata del principal reto del proceso de transformación. Esta gestión del cambio tiene, además, particularidades en diferentes ámbitos de la organización:

• Gestores: los roles tradiciones evolucionan hacia gestores de soluciones digitales o áreas transversales de gobierno o arquitectura. Es necesario gestionar esta evolución y escalar la esponsorización del proyecto a niveles más altos en caso de encontrar resistencia en los ámbitos intermedios de gestión.
• Equipos de tecnología: la base del funcionamiento de la transformación consiste en que los propios equipos se empoderen y asuman la responsabilidad sobre el no dividir. Supone sacar de la zona de confort a personas que pueden llevar varios años con una responsabilidad limitada a su área de experiencia y, por tanto, implica trabajo de acompañamiento y coaching notable.
• Negocio: la involucración del cliente es fundamental, ya que todos los esfuerzos deben estar dirigidos a asegurar el servicio óptimo para cada cliente.

Otro reto está en el ajuste de las capacidades de los equipos. El objetivo es el diseño de equipos multidisciplinares y autónomos; sin embargo, en la práctica es necesario recorrer el camino para llegar a esta situación, en la que ciertos perfiles escasos y especialistas se compartan entre equipos hasta que estos adquieran suficiente conocimiento. Los recursos especializados típicamente deben evolucionar a un ámbito de arquitectura más transversal.

Por tanto, existe un período de convivencia del modelo tradicional y el orientado a servicios que se debe diseñar en las fases de análisis y estructura.

Por último, podemos hablar de falta de entendimiento de las ventajas de la adopción de DevOps. En este punto es importante entender qué aporta, cómo encaja con las necesidades de mi organización y aprovechar aquellas ventajas que resulten rentables. No busquemos un nivel determinado de adopción, sino un flujo de entrega óptimo, mejoras organizativas y herramientas útiles, y utilicemos los modelos para medir los logros y las mejoras de forma consistente.

Para su adopción es vital entender el flujo completo de los servicios digitales

¿Cómo mido los resultados?

Antes de iniciar la adopción de DevOps debo asegurar que soy o seré capaz de disponer de métricas de entregas de soluciones digitales extremo a extremo, que permitan medir la mejora obtenida en la transformación.

Estas métricas deben alinearse con los objetivos que marco al proyecto, por ejemplo:

• Disminución del tiempo total desde que el usuario realiza una solicitud de un nuevo servicio hasta que puede utilizar en producción una primera versión. Esta primera versión tendrá un mínimo número de funcionalidades básicas acordadas y un máximo de errores por transacción acordados (se pueden especificar tipologías de errores críticos).
• Diminución del tiempo total desde que el usuario reclama una modificación o cambio en un servicio hasta que dispone del mismo en producción.
• Disminución del tiempo medio de recuperación del servicio, desde que el usuario reclama la corrección de una incidencia hasta que esta es eliminada del sistema de forma satisfactoria para el usuario.