DevOps: ¿Dónde empieza el continuo?

DevOps no es una rareza de algunos frikis. Más bien, DevOps es un concepto y un método en uno. Concepto, porque exige una cultura corporativa diferente, lejos de la excesiva división del trabajo hacia el trabajo en equipo interdisciplinar.

porque el enfoque sigue principios y procedimientos claramente definidos y probados, que deben apoyarse en una cadena de herramientas integrada que incluya procedimientos de prueba automatizados, especialmente en el entorno SAP.

DevOps trata de la funcionalidad que impulsa el negocio. Y su desarrollo se ciñe estrictamente al presupuesto, sin controles detallados por parte de los superiores. Lo que nos lleva directamente al tema de la gestión ajustada: Confianza y seguridad en lugar de requisitos máximos de documentación, proyectos gestionables y orientados a objetivos en lugar de grandes obras que aportan mucho prestigio pero resultan el doble de caras de lo previsto.

Pero los propios equipos informáticos también tienen que ser "lean" y ágiles, siguiendo los mismos principios de las prácticas "lean" que los directivos. Pero, ¿qué significa eso realmente? El Lean Enterprise Institute ofrece la respuesta:

No hay DevOps sin principios ágiles

El principio primordial es la orientación al cliente, el beneficio de una nueva funcionalidad para los usuarios. Una vez que los responsables han determinado su valor, deben comprobar a continuación los procesos para ver si añaden valor positivo. Los que no lo hagan deben eliminarse.

En tercer lugar, los procesos deben (re)diseñarse de manera que se acorte la duración media de un ciclo desde el desarrollo hasta la puesta en marcha (sprint).

Esto permite ofrecer funcionalidades de forma continua y, por tanto, comprobar y medir su calidad y su aportación de valor con mayor precisión. En cuarto lugar, la empresa debe determinar la aportación de valor de las TI y no al revés.

Hay que pensar en estos cuatro principios como en las perlas de un collar, la quinta de las cuales cierra el círculo: la "Mejora Continua" permite obtener insights gracias a bucles repetitivos, con ayuda de los cuales se puede optimizar el proceso global con cada sprint.

Pero las mejoras sólo son reconocibles como tales si pueden medirse. El concepto DevOps recomienda incluso la medición continua, es decir, la recopilación de cifras clave en muchos puntos diferentes del proceso de desarrollo.

Los clientes de inventario SAP deben, por ejemplo, contar los transportes y modificaciones entregados a un sistema SAP en determinados periodos de tiempo.

¿Cuánto tardan los requisitos en convertirse en nuevo código de software? ¿Cuántas correcciones hay por sprint? ¿Este número aumenta o disminuye? ¿Se entregan a tiempo las nuevas funciones requeridas?

Todas estas son métricas relevantes que pueden mejorarse continuamente si los equipos de DevOps reflexionan, debaten y optimizan su trabajo con regularidad.

Los clientes actuales de SAP que deseen implantar DevOps deben guiarse por los principios Lean mencionados. Cuál de ellos es más fácil de implantar o es ya una realidad?

El punto de partida podría ser el flujo de valor "requisito a despliegue". Cree ratios y mida dónde está latente el mayor potencial de mejora en este flujo de valor.

¿Son el alcance y el tamaño de los proyectos y los equipos? Redúzcalos y aumente su número al mismo tiempo. Reúna a desarrolladores, administradores y responsables de calidad y ya estará en el mundo DevOps. Los equipos pequeños pero potentes que trabajan de forma autónoma y entre departamentos suman una propuesta de mayor valor.

El motivo concreto de la introducción de DevOps será el cambio a S/4 en los próximos años. Para un proyecto de esta magnitud y relevancia se necesitan nuevos métodos.

SAP también tiene esto en cuenta con su método de implementación SAP Activate (véase también la página 62), que sigue principios ágiles. En nuestra próxima columna, hablaremos de los enfoques para migrar a S/4 Hana y del papel que desempeña la automatización en ello.