Q
Atrás

El impacto de DevOps y Agile en Outsourcing

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 Cloud pú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

devops agile outsourcing

Equipos de sistemas de negocio

Si se quiere tener éxito en las colaboraciones de sourcing, se debe definir la relación cliente-proveedor con 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.

Etiquetas
Agile, DevOps, Outsourcing