Está en la página 1de 14

White Paper:

Cuatro vías DevOps


para alcanzar la
Agilidad y la Mejora
Continua en tu
Organización
Cuatro vías DevOps para
alcanzar la Agilidad y la
Mejora Continua en tu
Organización
Desde su comienzo, la era digital ha generado un gran
número de nuevas palabras y conceptos que tienen
impacto en la TI. Agile, Scrum, Lean IT y DevOps son
algunas de ellas. Hemos podido ver que partidarios de
distintas escuelas de pensamiento han entrado a menudo
en conflicto. No obstante, en cuanto examinamos más
de cerca el trasfondo de cada concepto y los fines a los
que apuntan, podemos identificar tres objetivos comunes:
optimizar la agilidad de la organización anticipando
el cambio, reducir el tiempo de venta de nuevas
características, productos y modelos de negocio, y entregar
el máximo valor al cliente con la mejor calidad posible.
Tras leer este White Paper serás capaz de situar los
desarrollos actuales – y las frecuentes discusiones
sobre las acciones siguientes – dentro del contexto
de tu organización, así como de reconocer la relación
que hay entre ellos. DevOps es el desarrollo que une
las necesidades de flexibilidad del mundo Agile con la
necesidad de garantizar la continuidad en la provisión
de servicios. Este documento también aproxima
DevOps a una evolución que surge de la gestión de la
infraestructura para responder a desarrollos propios de
ese dominio. Estos avances se refuerzan entre sí, y, tras
leer este artículo, sabrás el porqué.

www.quintgroup.com 2
DevOps es una
aproximación cohesiva
Primero examinaremos los objetivos de varios conceptos.
Lean, que se creó en la industria del automóvil (The Toyota
Way), pretende optimizar el flujo de valor reduciendo tantas
fases y acciones innecesarias como sean posibles. Para ello,
Lean ofrece un extenso conjunto de herramientas donde
el foco se encuentra en el liderazgo, en el conocimiento del
trabajo y en la mejora continua.
Agile y Scrum emergieron del mundo del desarrollo de
software. Aquí, la mentalidad Lean se traduce en responder
a visiones cambiadas respecto a la viabilidad y al valor del
cliente. Esto es identificado tanto por el propio cliente como
por los desarrolladores durante el proceso de desarrollo
y el uso de un nuevo software. La mejora del proceso y la
reducción de residuos conforman el siguiente paso.
DevOps añade valor al usuario durante el ciclo de vida de
lo anterior. Permitiendo que las operaciones se realicen
por el mismo equipo que desarrolla la funcionalidad, se
crea un bucle de retroalimentación directo. Esto permite al
equipo y a los clientes identificar sus prioridades desde una
perspectiva a largo plazo y desarrollar un software de tal
manera que minimice la carga de operaciones durante el
ciclo de vida de un producto.
Estas diferencias en el origen no tienen por qué ser una
restricción; los conceptos son complementarios y pueden
usarse juntos con efectividad. No obstante, es útil entender
los antecedentes de cada uno y cómo el valor generando
al cliente puede entregarse cuando estos conceptos se
combinan, basándose en sus fortalezas. Operaciones vs
Desarrollo, Aplicación vs Infraestructura: desde la perspectiva
del cliente hay una creciente necesidad de flexibilidad y
fiabilidad en la TI. Es tu decisión la de conocer el desafío
de satisfacer esta necesidad. En ese aspecto, DevOps es
una aproximación cohesiva a cuatro áreas: Operaciones,
Desarrollo, Aplicaciones e Infraestructura. A primera vista,
DevOps es, simplemente, la combinación de Desarrollo &
Operaciones. Sin embargo, detrás de esa fachada, yace
una nueva forma de pensar que facilita hacer óptimo el uso
de nuevas oportunidades tecnológicas, centrándose en la
responsabilidad del equipo e integrando procesos dentro del
grupo de trabajo. Este documento intenta revelar el secreto
detrás del término DevOps y facilitar su entendimiento.
Después de todo, DevOps es un terremoto organizacional
que puede contribuir significativamente al valor añadido
entregado al cliente, con experiencia por parte del personal.
Este artículo ilustra lo que DevOps ofrece desde cuatro
perspectivas, en cuatro vías DevOps.

www.quintgroup.com 3
¿Qué es DevOps?
DevOps es la fusión de las responsabilidades de
desarrollo y operaciones para que, juntas, garanticen la
salud de los servicios de TI al usuario de la compañía.
En sus inicios apuntaba a que el nuevo software
fuera desarrollado basándose en nuevos lenguajes
de programación. En la práctica, DevOps se aplica a
sistemas existentes (incluidos los sistemas de legado
y ERP) y ha demostrado ser igualmente exitoso. No
obstante, en este aspecto, es esencial que el desarrollo
sea guiado por criterios de aceptación testeados; la
transparencia y la mejora en la calidad de la fuente son
puntos vitales.
Otro factor es que el éxito de DevOps está, en
gran medida, determinado por la mentalidad y el
comportamiento real del personal y de la dirección. No
es algo que se pueda, simplemente, implementar sin
ninguna dificultad.
Los desafíos y los problemas se tienen que resolver con
tenacidad y creatividad para una aproximación al objetivo
de “responder rápidamente al cambio de necesidades
de los clientes, proveyendo soluciones con un alto nivel
de calidad”. El liderazgo Lean, que también se usa en
los equipos de Agile, también juega un gran papel en
DevOps. Aprender de los errores, con el foco puesto en
generar valor al cliente, es un factor clave del éxito.

GRANDES DIFICULTADES
PARA IMPLANTAR DEVOPS

VALOR DE DEVOPS NO SE ENTIENDE


FUERA DE MI GRUPO 48%

ESTRUCTURA NO COMÚN
ENTRE DEV Y OPS
43%

FALTA DE HERRAMIENTAS 33%

FALTA DE TIEMPO PARA


31%
IMPLEMENTAR DEVOPS

FALTA DE APOYO PARA EL ÉXITO 19%

MUY CARO 5%

www.quintgroup.com 4
Esto nos lleva a una organización de trabajo con equipos
multidisciplinares que tienen plena responsabilidad sobre
la “salud” del servicio ofrecido. Para mantener esta salud,
un factor importante es el de formar a los equipos de tal
manera que las competencias requeridas estén presentes.
No obstante, la dinámica del equipo es también un elemento
a tener en cuenta. Un punto interesante al respecto es
que un ratio hombre-mujer equilibrado contribuye a la
calidad del servicio y al crecimiento que DevOps persigue.
La diversidad en los grupos de trabajo es esencial para la
entrega continua de resultados mejores.
DevOps se centra en operaciones y procesos de cambio con
su posterior automatización. Esto conlleva a algo más que
una combinación de operaciones y desarrollos: hay también
un interés en la calidad de la fuente y en hacerlo bien a
la primera, como el ingrediente activo para los servicios
operativos, sin tener que volver a realizar el trabajo, y para
mover los servicios rápidamente a través de DTAP (Desarrollo
– Testeo – Aceptación – Producción). Esto significa que
asegurar la calidad constituye el tercer elemento de DevOps.
Integración continua, testeo automático y promoción
automática a través de DTPA, el cual se basa en criterios
de aceptación predefinidos y en la versión del control de
todo lo que la TI apila, incluyendo plataformas subyacentes
e infraestructura, capitalización en los antes mencionados
factores de éxito y reducción en el plazo de ejecución del
cambio, con su debida recuperación y manejo de incidentes.

Asegurar
Calidad

DevOps

Operaciones Desarrollo

www.quintgroup.com 5
Las 4 vías DevOps
En la práctica, lo que la gente piensa de DevOps está
basado en la experiencia que esas personas tienen dentro
de su propia organización. En este documento usamos
cuatro vías de DevOps para unir estas experiencias distintas
como piezas de un gran puzle. Cada una de ellas describe
el desarrollo de DevOps desde una perspectiva concreta
y puede ser considerado como el arquetipo que una
organización puede hacer.
Estas vías, además, sirven como marco de referencia para
charlas o discusiones sobre el significado de cambios
organizativos.
Probablemente te hayas dado cuenta de que dentro de
tu organización la gente está intentando encontrar una
solución a la creciente necesidad de un sistema de TI ágil
y confiable. Cada área de la empresa hace esto desde
su propia perspectiva. Sin embargo, es como tratar de
transmitir cómo es un elefante describiendo únicamente su
cuerpo, cola o pie.
Todas estas partes de la organización están en lo cierto de
alguna manera. El truco está en hacer una combinación
de descripciones que proporcionen una imagen clara de
un elefante. Entendiendo todas las diferentes perspectivas,
uno puede combinarlas con fuerza porque el objetivo
subyacente es común.
Applications

2
Lean IT

4
Infrastructure

Operations Development

www.quintgroup.com 6
Vía 1: De la cascada a
DevOps
Tradicionalmente, los nuevos sistemas se desarrollan en
proyectos, en un proceso en cascada. Al final, el proyecto
entrega un sistema (después de meses o incluso años) a las
operaciones de la organización, la cual formalmente lo acepta.
En la práctica, sin embargo, estos nuevos sistemas se “lanzan
sobre la pared”, y los puntos remanentes y algunos temas de
calidad acaban siendo resueltos en la fase de operaciones.
No obstante, una tendencia muy reciente es desarrollar (o
fomentar) sistemas en ciclos cortos usando métodos Agile,
como el Scrum. Scrum puede ser muy exitoso pero, en la
realidad, resulta que el despliegue efectivo de la producción
es un gran obstáculo: la “pared” a la que hacíamos referencia
antes es más alta o más sólida de lo que habíamos pensado.
Las reglas básicas de Operaciones son complicadas de
establecer en la “Definición de Hacer” y son difíciles de
transmitir con la antelación suficiente para los equipos de
Scrum en forma de requisitos.
Este camino de DevOps empieza cuando el equipo de Scrum
toma la responsabilidad de resolver incidentes y, como
resultado, adquiere una visión de la funcionalidad y se vuelve
corresponsable de establecer esa funcionalidad disponible
en el entorno de producción. Tener responsabilidad sobre
asuntos “al otro lado de la pared” hace que nos movamos

Agile/
ASL
Scrum
Applications

Lean IT
Infrastructure

ITIL ITIL

Operations Development

www.quintgroup.com 7
hacia un diferente estado de consciencia en la calidad. La
deuda técnica y el número de incidentes, las preguntas de los
usuarios y las cuestiones operativas harán daño; impiden – y
continuarán impidiendo – que el equipo de Scrum entregue
valor rápidamente. Una baja calidad conlleva un retraso. Esto
puede ser el punto de partida para asignar múltiples tareas
de operaciones dentro del equipo Scrum; por ejemplo, el
equipo monitorizará y optimizará (automatizará) la eficiencia
del sistema. Además, se vuelve importante para el equipo que
la deuda técnica se contenga y reduzca.
El equipo de desarrollo no solo se vuelve responsable de
la entrega del software, sino también de la entrega del
servicio entero, para que un grupo usuario pueda utilizar
esta funcionalidad óptimamente en su propio proceso
de negocio. Este cambio es el más común en DevOps: la
transición de desarrollo a operaciones.

Vía 2: De la gestión de
aplicaciones a DevOps
Este camino empieza con la gestión de aplicaciones. En este
dominio, los miembros del personal están en su mayoría
organizados en silos, de acuerdo a su experiencia. Esto
significa que los gestores de prestación del servicio, de la
funcionalidad de la aplicación, los técnicos de la aplicación
y los administradores de la base de datos constituyen
departamentos o equipos separados. Los procesos se basan
en canalizar el trabajo mediante diferentes equipos.

Agile/
ASL
Scrum
Applications

2
Lean IT
Infrastructure

ITIL ITIL

Operations Development

www.quintgroup.com 8
Para facilitar esto, los responsables de procesos ITIL y los
coordinadores ITIL se añaden a la organización como parte de
la función.
Para empezar, basándose en caracteres compartidos
(incluidos caracteres personalizados), las aplicaciones se
agrupan en líneas de producto, dominios de información,
flujos de valor, etc. La clave está en producir paquetes de
trabajo cohesivos para grupos de clientes identificables.
Subsecuentemente, las competencias necesarias se combinan
en los equipos multidisciplinares de operaciones. Esta
segunda fase empieza cuando el equipo de operaciones no
solo se centra en el funcionamiento y la dotación del servicio
contratado, sino que también se centra en incrementar la
responsabilidad de realizar nuevas funcionalidades en servicios
ya existentes y, activamente, tomar el rol de propietario en
relación a la innovación del servicio. A cambio, dentro de estos
equipos maduros de operaciones permanentes, se produce un
incremento de la consciencia y se adquieren las competencias
necesarias para que los propios equipos puedan realizar esta
innovación. Tareas de desarrollo tales como diseñar, construir
y testear pueden realizarse dentro de un mismo grupo de
trabajo. Como consecuencia, el reflejo de la gestión de darse
cuenta de todas las innovaciones en proyectos con equipos
ad-hoc puede ser anulado. El enfoque cambia de asignación
de recursos, que es tradicionalmente uno de los procesos
que más tiempo consumen dentro de una organización, a la
priorización de tareas.

Vía 3: De la gestión de
infraestructura a DevOps
La tercera vía DevOps es relativamente desconocida dentro
del mundo DevOps, pero esencial para facilitar todo el
conjunto (se ejecuta mediante el cambio de infraestructura
para proporcionar una infraestructura de autoservicio).
Infraestructura como código y plataforma como código son
términos que escucharás en este sentido. El aprovisionar
una infraestructura virtual disponible para los equipos
DevOps permite que estos respondan con flexibilidad
a sus necesidades de cambio con una infraestructura
más adecuada. La otra cara es que esta flexibilidad solo
puede ser conseguida si las plataformas e infraestructuras
subyacentes han sido estandarizadas y la gestión del ciclo
de vida del hardware, OS, bases de datos y “middleware”
han sido implementados explícitamente. Esta flexibilidad y
el mantenimiento de la plataforma y de la infraestructura
proporcionada yacen en el corazón de la infraestructura
basada en provisión del servicio.
Los procesos forzados (gestión de cambios y despliegues,
promoción automática de software a través del DTAP,
basados en pruebas y criterios de aceptación) hacen que los
equipos de DevOps permanezcan dentro de las normas de la
organización.

www.quintgroup.com 9
Agile/
ASL
Scrum

Applications

Lean IT

4
Infrastructure

ITIL ITIL

Operations Development

Frecuentemente vemos que sobre el papel los procesos


ITIL parecen adecuados, pero en realidad están aplicados
insuficientemente. En el mundo DevOps es conveniente
que los equipos DevOps aseguren que ellos, y el resto de
equipos, sigan los procesos. Esto es mucho más sencillo
porque todo el mundo involucrado en el proceso está en
el mismo barco y, por consiguiente, los procesos son muy
cortos y eficientes, en lugar de ser largos y pesados. Lo que
es más, los procesos están cada vez más descritos en el
manual de reglas de comportamiento y acuerdos, más que
en documentos de procesos. Esto también se aplica a los
procesos en las otras tres vías.
En este sentido, se ha dado un paso gigantesco en dirección
a la gestión de infraestructuras, en línea con la necesidad
de que los servicios de TI sean ágiles y estén disponibles.
Este paso se ha hecho posible gracias a una amplia gama
de herramientas y métodos (a menudo de código abierto)
que tienen por objeto automatizar partes del proceso de
desarrollo y del proceso de implantación. Como resultado de
la virtualización de la infraestructura – infraestructura como
código – los estándares del dominio del desarrollo (control
de la versión, completo encriptado tanto de la promoción de
software como de la modificación de la infraestructura y de
las plataformas) se aplican a estándares compatibles.
¿Significa esto que el Dev (Desarrollo) se ha impuesto
sobre el Ops (Operaciones)? ¡No! No es este el caso.

www.quintgroup.com 10
Aunque el compromiso hacia la innovación dentro de la
infraestructura ha sido reforzado, el éxito es igualmente
distribuido entre el pensamiento en el dominio de las
operaciones en términos de disponibilidad, continuidad y
estabilidad. Es esto lo que ha unido Desarrollo y Operaciones.
La calidad en la fuente permite que la división entre
Desarrollo y Operaciones se vaya cerrando cada vez más.

Vía 4: El paso a Lean IT


Ese acercamiento nos lleva a la cuarta vía de DevOps.
El equipo DevOps persigue responder a la necesidad de
reducir el tiempo de comercialización. La infraestructura
ayuda a los equipos óptimamente, con plataformas
modificadas e infraestructura de servicios. Como la
calidad está bajo control, el valor añadido de la división
entre la marcha y el cambio se vuelve cada vez más bajo.
Esto conlleva a que aparezcan nuevas posibilidades para
una mayor expansión del cambio. Después de todo, la
continuidad de la entrega del servicio está a salvo. A
través de la optimización de flujos de valor (Lean IT), se
crean nuevas posibilidades para acortar los procesos.
Hemos llamado a este punto Lean IT (consiste en una
delegación) porque optimiza el flujo de valor de Lean
IT. Lo que vemos es que desde una perspectiva Lean, el
foco está en crear valor añadido y las actividades que

Agile/
ASL
Scrum
Applications

Lean IT

4
Infrastructure

ITIL ITIL

Operations Development

www.quintgroup.com 11
no proporcionen esto se han de reducir. Automatizando
grandes partes de los procesos de operaciones y de
actividades, se crea una mayor transparencia en relación
al estatus de las operaciones y las actualizaciones.
De hecho, el efecto de los estándares de operaciones
se incrementa porque estos estándares se aplican
con rutina y el corte es medido y minimizado (mejora
continua).
Un paso fuera de la gestión operativa consiste en
supervisar reactivamente los componentes para llegar a
una gestión proactiva de todo el servicio de la cadena.
Por supuesto, ésta siempre ha sido la intención, y, en
principio, siempre ha sido posible. Sin embargo, cuando
miramos hacia cómo salen las cosas en la práctica, a
menudo no es el caso. A través de la normalización y el
acortamiento de los procesos de operaciones, la recogida
de datos monitorizados (big data) y la disponibilidad
de los equipos DevOps que son responsables de la
salud del servicio con acceso a estos datos, hacen que
la gestión proactiva se convierta en un aspecto clave
para aumentar continuamente el ritmo de cambios y no
ahogarse en incidencias y extinción de incendios.
Los equipos maduros de operaciones gestionan y
actualizan los servicios diariamente. En esta situación,
operaciones (o infraestructura de operaciones) puede
dar al equipo DevOps la clave sin poner en peligro la
disponibilidad del servicio. Lo que es más, si esta clave
no es transmitida, la entrega de valor al cliente estará
en riesgo. Hoy en día, los clientes requieren servicios
alineados con sus necesidades actuales, las cuales no
son necesariamente las necesidades que tenían hace
unos años. El cambio se ha convertido en norma, pero
estos servicios deben permanecer disponibles.
Este cuarto punto muestra cómo el dominio de las
aplicaciones y el de la infraestructura trabajan juntos

www.quintgroup.com 12
para incrementar la agilidad de la TI como un todo,
sin comprometer la necesidad básica de salvaguardar
la continuidad. Los puntos DevOps mencionados
proveen un marco de referencia de consulta para
varias partes, sobre los objetivos que una organización
quiere conseguir, y cómo las diferentes partes de la
organización pueden contribuir a conseguirlos. Una
visión y un lenguaje común son vitales para ello. Además,
es útil si las personas aprenden entre ellas de sus propias
contribuciones. Los desarrolladores deberían aprender
que los requerimientos de continuidad y las tareas
de operaciones tienen valor y pueden – y deben – ser
optimizadas para proteger la agilidad a largo plazo. Al
mismo tiempo, en infraestructura aprenden a usar los
estándares de desarrollo a la hora de desarrollar y de
mantener infraestructuras compatibles con la nube.
El objetivo común de entregar más valor y más rápido
requiere nuevos pasos y nuevos métodos de trabajo
desde cada perspectiva. Es esencial romper “los muros”
y facilitar el flujo dentro de varios dominios de TI y entre
el negocio y TI.

El Negocio también puede


coger la iniciativa
Queda aún una última vía: aquella que empieza por
el proceso de negocio (BusDevOps). En este punto, en
la transición hacia DevOps, la TI es considerada como
una función de apoyo al negocio. Este quinto elemento
cae fuera del ámbito de este documento y será tratado
separadamente.

Conclusión
DevOps es una nueva forma de trabajar y de organizar
pero, sobre todo, es una nueva forma de pensar.
Está hecho para el cambio. DevOps consigue que la
organización esté lista para el cambio. Es un concepto
que está perfectamente alineado con nuestro, cada
vez más, mundo digitalizado, dado que las diferentes
funciones, silos e islas se fusionan en una sola
responsabilidad. Es un paso inevitable para maximizar la
calidad de la experiencia del cliente.

www.quintgroup.com 13
QUINT WELLINGTON REDWOOD
Quint se centra en dos grandes cambios que tienen lugar en el mundo:
la transformación digital y la creciente necesidad de sostenibilidad.
La tecnología es una de las fuerzas motrices del cambio. Muchas
organizaciones tienen dificultades para adaptarse a los sucesivos
cambios actuales y aplicarlos con éxito. Se preguntan si son lo
suficientemente flexibles para implementar cambios y si seguirán siendo
un actor relevante dentro de unos años. Vemos que las organizaciones
tienen que tomar decisiones fundamentales acerca de los modelos de
negocio, la gestión y la tecnología bajo la presión del cambio.

En nuestra visión, la tecnología no es el único factor decisivo: son


incluso más importantes el conocimiento, la cultura y el liderazgo;
imprescindibles para que las organizaciones reconozcan qué tecnología
es relevante y la apliquen para aportar valor a su organización y entorno.
Quint apoya a las organizaciones en el diseño y la ejecución de su
estrategia digital. Junto con nuestros clientes, desarrollamos hojas de ruta
que facilitan el cambio rápido y eficaz, para anticiparse o responder a
las oportunidades y amenazas. Hacemos que la tecnología, así como su
aplicación, sea una realidad viva.

Estrategia Digital y Lean IT, Agile y Gestión y Gobierno Liderazgo


Transformación DevOps del Dato Transformacional

Estrategia de Gobierno de TI, Integración de los Formación y


Sourcing, Contrata- Riesgo y Cumpli- Servicios, Automati- Coaching
ción y Transición miento zación y Gestión

© Copyright 2017, Quint Wellington Redwood. All rights reserved. No part of this publication may be reproduced, PLEASE
transferred and/or shown to third parties without prior written consent of The Quint Wellington Redwood Group. RECYCLE

www.quintgroup.com 14