La combinación de DevOps y desarrollo Agile está en auge.

Las empresas
deben hacer entrega de un software de calidad, a la altura de las demandas del
mercado. Para ello, DevOps da un giro y rompe la tradicional línea divisoria
entre los equipos de desarrollo y los de gestión. A través de las metodologías
de desarrollo Agile se desarrollan y se entregan nuevas funcionalidades en
nuevas plataformas como contenedores e infraestructura hiperconvergente en
ciclos mucho más cortos (sprints). Esta combinación ofrece la posibilidad
de añadir más valor a los procesos de negocio, en términos de una mayor
calidad, un tiempo de comercialización más breve y la optimización del coste
total de propiedad.

Para aprovechar las ventajas de combinar DevOps y Agile, los gerentes

deben cambiar su organización actual, aunque esto suponga perder
autoridad o que esta cambie de forma drástica. DevOps es un neologismo
formado a partir de Development y IT Operations. El foco recae sobre la
comunicación, la colaboración (entre clientes, desarrolladores de software y
gestores de TI) y la integración, y se nutre del ideario Agile y Lean IT. No
debería sorprender que el auge de DevOps en combinación con el desarrollo
Agile de aplicaciones (en adelante ‘DevOps’) también tenga un impacto en la
externalización.

Los ejecutivos deberían reflexionar sobre las consecuencias que esto tiene en
el outsourcing. Por ejemplo, los principios estratégicos en materia
de parcelación y métodos de contratación de los servicios de infraestructura y
de desarrollo de aplicaciones son diferentes. Por tanto, esto afectará a aquellos
que deciden externalizar y a los proveedores de servicios. Este White Paper
profundiza en este impacto y proporciona pautas concretas para gestionarlo de
la mejor forma posible.

El impacto de DevOps en la parcelación

DevOps tiene un gran impacto en la parcelación que se determina al establecer
la estrategia de sourcing. En términos cualitativos y financieros, el plan
de sourcing solo será sostenible si los servicios, las aplicaciones y la
infraestructura de TI se internalizan y externalizan de acuerdo a una
parcelación. Asimismo, los límites deben de estar bien definidos, tomando la
arquitectura empresarial como baremo. Muchas grandes empresas y entidades
públicas que buscan economías de escala y una división de responsabilidades
estricta, tienden a escoger una parcelación tradicional. En este fraccionamiento
horizontal, el desarrollo de aplicaciones, su gestión y los servicios de
infraestructura (hosting) se suelen separar en tres divisiones y se asignan a
distintos proveedores. Las divisiones reconocidas solo son las de centro de
servicios, área de trabajo, y seguridad y conectividad. En muchos casos, la
gestión técnica de aplicaciones se adjudica al proveedor de servicios de
infraestructura y se contrata con el mismo la disponibilidad integral de las
aplicaciones. El paso del proveedor de aplicaciones al de infraestructura de una
nueva versión de la aplicación es necesario. Así, el proveedor puede garantizar
la disponibilidad de las aplicaciones sin ver afectado su sistema de
bonificaciones por buena conducta. Y así en ocasiones el cliente podía esperar
la nueva versión meses.
El impacto de DevOps en los equipos
DevOps y Agile rompen la estricta división entre el desarrollo y la gestión, las
aplicaciones y la infraestructura. DevOps se utiliza, sobre todo, en entornos
innovadores donde los ciclos cortos beneficina al negocio. Ejemplos de ello
son: un mercado creciente, de alta competitividad, de alta visibilidad o una
empresa altamente dinámica. Por el contrario, en los entornos heredados, más
estables, se aplica el método de cascada. Por tanto, en una gran empresa
habrá equipos en cascada y equipos DevOps. Para que ambos trabajen
correctamente se debe crear un moderno catálogo de productos y servicios que
facilite el despliegue de ambos. Para ello, DevOps hace una parcelación
vertical (‘cadena de valor’), que tendrá consecuencias para los equipos
DevOps, que se abordarán a continuación.

Equipos de sistemas de negocio

DevOps afronta de forma integral el desarrollo y la gestión de aplicaciones, las
bases de datos y el middleware por cada dominio funcionalmente orientado
(‘cadena de valor’). En estas áreas se externaliza a través de los equipos
Scrum, multidisciplinares y con su propia organización. Sus
miembros comparten las responsabilidades en la entrega del resultado aunque
hay como mínimo un propietario de producto que da las órdenes y es el
responsable del resultado funcional. El Scrum Master es el responsable del
proceso, de la velocidad de entrega, y de proporcionar y mantener la visión
global. La estructura de las de competencias del equipo tiene forma de ‘T’. Es
decir, el equipo tiene experiencia y muchos de los miembros
tienen competencias técnicas y tienen la capacidad de ver más allá de su
propia especialidad. Por último, los arquitectos tienden pago de la deuda
tecnológica que se produce, sobre todo, por diseños y construcciones que al
crecer orgánicamente experimentan mucha presión (‘arreglar ahora, pagar más
tarde’.) Esto provoca una desviación de las normas y los interfaces
arquitectónicos, entre otras consecuencias. La deuda tecnológica puede ser
un freno que impida alcanzar la velocidad deseada de los sprints.

‘Si lo has construido, lo has de ejecutar’

La gestión técnica de aplicaciones (bases de datos, middleware),
tradicionalmente asignada al proveedor de infraestructura, también se incluye
bajo el paraguas del equipo de sistemas de negocio, bajo el lema ‘si lo has
construido, lo has de ejecutar’. Sin embargo, en la práctica esta actividad sigue
en manos del equipo de plataforma, que se ocupa la gestión del ciclo de vida
de toda la pila técnica, incluido el middleware. Para ello, los equipos
despliegan contenedores e infraestructura hiperconvergente. Por supuesto,
el equipo de sistemas de negocio utiliza servicios de plataforma de
infraestructura altamente estandarizados (la pila técnica). Estos servicios se
seleccionan en base a su valor para el equipo. La mayoría de aplicaciones que
vienen de entornos tradicionales se alojan en servicios de Cloud privados,
mientras que en los entornos de desarrollo y pruebas se utiliza el Cloudpúblico.
 Por último, hay que destacar el cambio en las áreas de producción, que cada
vez usan más la Nube pública.

Los principios de los equipos DevOps

Los equipos DevOps suelen formarse con personal interno y externo.
Cuando empiezan a colaborar estrechamente con los clientes para entregar
funcionalidad de forma continua a través del desarrollo de aplicaciones Agile,
se está ante un abastecimiento completamente diferente al que se produce, por
ejemplo, con la deslocalización de grandes proyectos en cascada. Los equipos
DevOps se ajustan a los siguientes principios:.

1. Orientación al cliente: ciclos de feedback cortos con clientes reales y usuarios

finales; todas las actividades de desarrollo giran en torno al cliente.
2. Crear con la meta en mente: evitar los modelos en cascada y orientados al
proceso en los que se pierde de vista el conjunto.
3. Responsabilidad integral: los equipos DevOps se organizan verticalmente por
sus miembros que son responsables desde el concepto hasta el final del ciclo
de vida, ‘desde el concepto hasta la tumba’. De esta forma, el equipo que
construye y entrega el servicio de TI se encarga también de su gestión. El lema
es ‘si lo has construido, lo has de ejecutar’.
4. Equipos autónomos multidisciplinares: si los equipos se organizan
verticalmente y se hacen responsables de todo el ciclo de vida del producto o
servicio, deben ser autónomos.
5. Mejora continua: el énfasis está en la mejora continua de los productos y
servicios. Para asegurar la mejor calidad, pero también para minimizar el
desperdicio – de nuevo las ideas Lean – y para optimizar la velocidad, los
gastos y la facilidad de entrega.
6. Automatizar siempre que se pueda: la automatización es el resultado de los
esfuerzos del equipo para actualizar y mejorar constantemente la prestación de
sus servicios.

Equipos de plataforma
El equipo de plataforma proporciona un entorno estandarizado que suele
consistir en contenedores PaaS, aunque IaaS es otra alternativa viable.
Cuando se utiliza la Nube pública se puede complementar con otras opciones
de gestión Cloud. Además es importante que el equipo monitorice el proceso
de estandarización para evitar errores y corregirlos. Por estas razones la idea
de ‘automatizar siempre que se pueda’ está a la orden del día. Puesto que el
equipo de sistemas de negocio funciona en base a un autoservicio con
entornos de infraestructura, asignar los costes resulta indispensable. De esta
forma se mantiene un orden para que después de su uso el contador no siga
contando.

Por otro lado, para facilitar la colaboración, el equipo de plataforma tiene un

representante en el de sistemas de negocio que defiende el espíritu de
DevOps. De esta forma, se busca mantener el ritmo del sprint para que en la
entrega final no haya tiempos de espera (flujo de pieza única). Al adoptar
DevOps, el catálogo de servicios necesita elementos nuevos como
herramientas que faciliten la vida del equipo DevOps. Por ejemplo, un portal de
autoservicio, herramientas para la integración continua de sistemas, pruebas
automatizadas, y una implementación y una entrega automatizadas. Con ello
se obliga al cumplimiento de estándares para el conjunto de entornos de
DTAP, para minimizar todo lo posible la deuda técnica desde el equipo de
plataforma. Esto incluye, por ejemplo, continuar con la gestión de parches.

El impacto de DevOps en la contratación

El impacto de DevOps en la parcelación y en el enfoque de equipo es evidente.
¿Cómo afecta a la contratación? Si las organizaciones quieren que la
combinación DevOps y Agile funcione tendrán que contratar de una manera
diferente. Lo más importante es pasar de una contratación de alcance
cerrado a una de alcance abierto, y que la innovación y la gestión ocupen un
lugar en esa misma colaboración. De todos modos, los equipos DevOps no se
entienden muy bien con la manera habitual de contratación. DevOps, en
combinación con el desarrollo Agile de aplicaciones, no conoce un alcance fijo,
sino que utiliza una fragmentación diferente centrada en la generación de
valor y se mueve con las ideas del cliente. Es interesante compararlo con las
definiciones tradicionales de divisiones y las largas descripciones de diseños
funcionales y técnicos, o de servicios orientados a resultados,
responsabilidades y herramientas. Esta forma de trabajar surge de una
situación más o menos estática y de un proceso controlado, no de un mercado
que está en constante cambio en el que el cliente busca sacar provecho. Si se
quiere ser campeón del mundo de Fórmula 1, no se puede planear la carrera
por adelantado si no que habrá que ajustar el coche entre las carreras. Este es
un punto fundamental. Daremos algunas pautas.

CONTRATACIÓN DE DEVOPS Y AGILE SOURCING

FIGURA 1. EL CONO DE INCERTIDUMBRE

 Equipos de sistemas de negocio
Si se quiere tener éxito en las colaboraciones de sourcing, se debe definir la
relación cliente-proveedorcon el “cono de incertidumbre” (ver figura 1). El
cliente y el proveedor ocupan una posición propia en la contratación de
servicios que viene determinada, entre otras cosas,por el grado de
incertidumbre de cada uno. Para determinar la incertidumbre se plantean las
siguientes cuatro preguntas:

1. ¿Quién asume qué riesgos (empresariales, sociales, financieros, de tiempo de

comercialización, técnicos)?
2. ¿Qué alcance se puede contratar que se garantice un caso de negocio Agile?
3. ¿Cuál es el importe de contratación razonable dada la cantidad de trabajo?
4. ¿Cuándo y cómo podemos acordar los ajustes del alcance?
 Si el riesgo es alto, el cliente y el proveedor no podrán acordar un importe de
contratación rápidamente. Ante esta situación el proveedor se reserva de
antemano un margen de alto riesgo (‘plus de contingencia’) previo a la
negociación. Esto, desde la perspectiva del cliente, es un resultado indeseable.
Por otro lado, una contratación en base a tiempo y materiales es como un
cheque en blanco: es el cliente quien asume todos los riesgos. Este dilema
puede resultar en una contratación no equilibrada y en un comportamiento
no deseado en la colaboración prevista entre el cliente y el proveedor
(negociación en vez de colaboración).

División en fases
Proponemos dividir la contratación Agile en fases, en base al cono de
incertidumbre.

 Si la incertidumbre es alta o si la confianza mutua es baja, es aconsejable que

las partes se comprometan con pequeñas iniciativas en, por ejemplo, los
primeros tres sprints. Se acuerdan indicadores de rendimiento clave (KPI) y se
mide la satisfacción del cliente. Aun así, el cobro final se realiza en base al
tiempo y los materiales. Tras hacer esta prueba la colaboración siempre puede
ir a más. En los primeros sprints surge una visión de producto definida y se
aclaran las prioridades de desarrollo (representadas visualmente en la primera
pila de producto). Asimismo, en los primeros sprints mejora la velocidad de
entrega del equipo de sistemas de negocio. Nótese que a veces el cliente
ejecuta esta primera fase con múltiples proveedores con el objetivo de
seleccionar al que más le convenga. A veces esto se hace en una ‘olla a
presión’, conocida como hackathon.
 Después de este cortejo, es el momento del compromiso: una contratación
Agile. La incertidumbre ha disminuido y la colaboración ya ha pasado la
prueba. En este período intermedio – entre el sprint 4 y el 12 – se introduce el
concepto del bono por desempeño. El equipo todavía recibe su remuneración
en un 70% en base al tiempo y los materiales. Para el 30% restante se
acuerdan compromisos orientados a los resultados, relacionados con la
satisfacción del cliente, la deuda técnica y la velocidad del equipo. Otra opción
son los compromisos adicionales de bonificación, con los que el proveedor,
finalmente, puede ganar, por ejemplo, hasta el 110%. El objetivo es construir
experiencia a través de los KPIs y los correspondientes ajustes.
 Finalmente es hora de que el equipo DevOps experimentado y maduro
contraiga matrimonio: la contratación DevOps. Después de 12-15 sprints, la
contratación se puede basar (al 100%) en los compromisos de desempeño
como la satisfacción de cliente, la deuda técnica, la disponibilidad, el plazo de
entrega para un cambio, los números de incidencias por cada lanzamiento
(siendo el estándar 0) y la medición de la productividad/el burndown. Pero
el índice de felicidad del equipo tampoco puede faltar.

La contratación DevOps es una forma de contratación a la que el cliente y el

proveedor han llegado tras un proceso de crecimiento conjunto. Además, los
KPIs están directamente relacionados con el negocio emergente como una
traducción directa del valor de negocio. Ejemplos prácticos son la disminución
del tiempo de entrega de un proceso de negocio, el aumento de los ratios de
conversión (de cliente potencial a cliente) y el aumento del Net Promotor Score.

Equipo de plataforma
En el dominio de la infraestructura no hay grandes cambios en cuestión de
contratación, aparte de la ampliación del catálogo de servicios con todo tipo de
herramientas y mediciones. Esto se convierte en parte de un cuadro de
mandos integral, que también es visible en su totalidad para los equipos de
sistemas de negocio. En el caso de la infraestructura de suministros se aplica
un precio por unidad dependiendo del uso, la tecnología y el peso del
suministro correspondiente. Con esto, se aumenta o disminuye la escala de la
infraestructura en base al precio por unidad, sin aplicar bandas de precio o
volúmenes de compra garantizados. Además, para proyectos de infraestructura
se contrata una tarjeta de tarifas por perfil/hora de trabajo, y así es posible
calcular los proyectos con precios fijos. Para las herramientas se aplica una
remuneración aparte, a veces por licencia corporativa o por cada usuario. En
ocasiones, los costes ya forman parte del suministro contratado. No hace falta
decir que los controladores financieros están vigentes aquí para hacer cumplir
la estandarización buscada. En la fase de transición y transformación se siguen
viendo precios fijos por subproyecto para migraciones, transformaciones,
traslado de personal, costes de armonización, etcétera.

El impacto de DevOps en el SLA

Pero, ¿qué significa todo eso para el acuerdo de nivel de servicio (SLA)?
Definitivamente tendrá un aspecto diferente. Habrá un desplazamiento hacia
unos SLA de equipo de sistemas de negocio, con unos puntos de partida
completamente diferentes. DevOps gira en torno a la creación de valor
sostenible para los clientes basado en un alcance abierto y redefinible, en
contraste con el alcance cerrado de los SLA tradicionales. El foco en DevOps
está mucho más en la minimización del tiempo de comercialización de las
nuevas funcionalidades, en la contribución a los KPI de negocio integrales, en
la reducción del tiempo medio para reparar y recuperar, y en la deuda técnica
adquirida. Los informes mensuales de hecho ya han pasado de moda; la norma
es monitorizar en tiempo real. Y si aun así se sigue informando, entonces esos
informes son mucho más ‘ligeros’ y frecuentes que una mirada retrospectiva
mensual y detallada, que es lo habitual en los SLA tradicionales. Porque, a fin
de cuentas, un informe mensual a un ritmo de sprint de dos semanas lleva un
retraso de dos iteraciones. El SLA y los KPI asociados van en línea con el cono
de incertidumbre, pero no, desde luego, con el objetivo de limitar o sancionar.
Los KPI deben contribuir a tres metas básicas: la optimización del resultado
(calidad, tiempo de comercialización, valor empresarial), la optimización de los
aspectos financieros (costes y valor añadido) y la reducción de los riesgos.

Por último aunque no menos importante: el cliente y el proveedor están en el

mismo barco. La fuerte combinación de DevOps y desarrollo Agile consiste en
la gestión de una colaboración, no en el control de un proveedor. Desde esta
perspectiva no puede faltar un KPI para el cliente: plazo de entrega a decidir. El
flujo en los equipos debe garantizarse: si un cliente se entretiene,
automáticamente reduce la velocidad de todo el equipo.

Conclusión
DevOps y Agile tienen un impacto significativo en la parcelación en la
externalización, la manera de contratar y el modo de cooperación. Subestimar
ese hecho significaría un desajuste entre los esfuerzos en el campo de la
externalización y el valor añadido de DevOps y Agile. Estos equipos no se
entienden muy bien con la forma tradicional de contratación utilizada por el
mundo del sourcing. Las organizaciones realmente deben anticipar las
necesidades de DevOps y de la contratación Agile para estar preparadas para
el mundo de… hoy.

Sobre los autores

Frank de Vries y Pamela Verkijk trabajan en Quint Wellington Redwood como

consultores.