Curso Devops Essentials - Alumno

Devops Essentials
AGILE CHILE
Te hacemos Ágil
Formato del Examen
Requisitos para la Certificación

▸ Se recomienda haber asistido al curso Devops Foundation.
Detalles del Examen

▸ 60 minutos
▸ 40 Preguntas de opción múltiples
▸ Porcentaje de aprobación: 60% (24 de 40)
▸ Material de apoyo, libros, preguntas, etc : No permitido.
2
Ágil Chile - 2020
Contenido
▸ Modulo 1: ¿Qué es la Agilidad?

▸ Modulo 2: ¿Qué es DevOps?
▸ Modulo 3: Beneficios de la adopción de DevOps
▸ Modulo 4: Propósito de DevOps
▸ Modulo 5: Pilares de DevOps
▸ Modulo 6: Desarrollo
▸ Modulo 7: Integración Continua
3
Ágil Chile - 2020
Contenido
▸ Modulo 8: Entrega continua

▸ Modulo 9: DevOps, Otras Prácticas Recomendadas
y Frameworks
▸ Modulo10: Cultura DevOps
▸ Modulo11: Equipo DevOps
▸ Modulo 12: Adopción Incremental
▸ Modulo 13: System Thinking
▸ Modulo 14: Herramientas para el Apoyo de la
Cultura DevOps
4
Ágil Chile - 2020
Modulo 1
¿Qué es la Agilidad?
AGILE CHILE
Te hacemos Ágil
5
¿Qué es la agilidad?
Agilidad es la capacidad de crear y

responder al cambio.
Es una forma de lidiar y, en última

instancia, tener éxito en un entorno
incierto y turbulento.
Los autores del Manifiesto Ágil eligieron

“Ágil” como la etiqueta para toda esta
idea, porque esa palabra representaba la
capacidad de adaptación y la respuesta
al cambio que era tan importante para su
enfoque”.
6
Ágil Chile - 2021
¿Cómo debemos ver la Agilidad?
▸ En cualquier tipo de
disciplina de gestión, ser ágil
es una cualidad, por lo
tanto esto debe ser una
meta que se debe tratar de
alcanzar.
▸ La gestión de proyectos,
Agile especialmente, implica
la adaptabilidad durante la
creación de un producto,
servicio o cualquier otro
resultado.
7
Ágil Chile - 2021
¿Por qué métodos Ágiles?
➢ El 80% de los proyectos emplearán Métodos Ágiles en los

próximos años.
(Fuente: Gartner – año 2009).
➢ Casi tres cuartas partes (71%) de las organizaciones

informan que utilizan enfoques ágiles a veces, a menudo o
siempre.
(Fuente: Project Management Institute – año 2017).
➢ Los proyectos ágiles son 28% más exitosos que aquellos

con estructuras tradicionales.
(Fuente: PwC – año 2019)
➢ El 50% de los miembros de los equipos están más

integrados y motivados al éxito grupal, que al personal
(Fuente: Atlassian).
8
Ágil Chile - 2021
Agile
• Análisis • Análisis • Análisis • Análisis • Análisis

• Diseño • Diseño • Diseño • Diseño • Diseño
• Construcción • Construcción • Construcción • Construcción • Construcción
• Pruebas • Pruebas • Pruebas • Pruebas • Pruebas
Incremento 1
Incremento 2
(Producto)
(Producto) Incremento 3
Incremento 4
(Producto)
(Producto) Incremento 5
Feedback (Producto)
Feedback
Feedback
Feedback
Feedback
9
Ágil Chile - 2021
Adopción de un entorno Ágil
✓ Enfoque en las personas

✓ Software de trabajo como medida de avance
✓ Flexibilidad
✓ Involucramiento del cliente/usuario
✓ Equipos multidisciplinarios y colaborativos
✓ Confianza
✓ Iterativo
✓ Incremental
✓ Maximizar el valor
✓ Time Boxed (en marco de tiempo).
10
Ágil Chile - 2021
Los valores del Manifiesto ágil
“Estamos descubriendo
mejores formas de
desarrollar software tanto
por nuestra propia
experiencia como
ayudando a terceros. A
través de este trabajo
hemos aprendido a
valorar:”
11
Ágil Chile - 2021
Los principios del manifiesto Ágil1
Nuestra mayor prioridad es satisfacer al Los responsables de negocio y los

01 cliente mediante la entrega temprana y
continua de software con valor. 04 Developers trabajamos juntos de forma
cotidiana durante todo el proyecto.
Aceptamos que los requisitos

02 cambien, incluso en etapas tardías
del desarrollo. Los procesos Ágiles 05
Los proyectos se desarrollan en torno a
individuos motivados. Hay que darles el
entorno y el apoyo que necesitan, y
aprovechan el cambio para
proporcionar ventaja competitiva confiarles la ejecución del trabajo.
al cliente.
Entregamos software funcional El método más eficiente y efectivo de

03 frecuentemente, entre dos semanas y
dos meses, con preferencia al periodo 06 comunicar información al Developers y
entre sus miembros es la conversación
de tiempo más corto posible. cara a cara
Ágil Chile - 2021

Los principios del manifiesto Ágil2
La simplicidad, o el arte de maximizar

07 El software Producto funcionando es la
medida principal de progreso. 10 la cantidad de trabajo no realizado, es
esencial.
Los procesos Ágiles promueven el

08 desarrollo sostenible. Los
promotores, Developers y usuarios 11
Las mejores arquitecturas, requisitos y
diseños emergen de equipos
autoorganizados.
debemos ser capaces de mantener
un ritmo constante de forma
indefinida.
La atención continua a la excelencia A intervalos regulares el equipo

09 técnica y al buen diseño mejora la
Agilidad. 12 reflexiona sobre cómo ser más efectivo
para a continuación ajustar y
perfeccionar su comportamiento en
consecuencia
Ágil Chile - 2021

Evolución de la agilidad
En la década de los noventa y a principio del 2000, se originó y obtuvo fuerza una
serie de metodologías Ágiles.
Aunque difieren en una variedad de aspectos, lo que tienen en común se deriva a
su apego al manifiesto Ágil.
14
Ágil Chile - 2021
Otros Frameworks de enfoque Ágil
Ágile cuenta con Marcos Ágiles de Desarrollo, tales como:

▸ Scrum
▸ LEAN
▸ Kanban
▸ Programación XP (eXtreme Programing)
▸ Devops
Todos se caracterizan por aspectos fundamentales como:

▸ Claridad (Información simple)
▸ Transparencia (Información disponible siempre)
▸ Comunicación Osmótica (Transferencia de información directa e
indirecta)
15
Ágil Chile - 2021
Otros Frameworks - LEAN
LEAN (TPS – Toyota Production System)

▸ LEAN es un modelo de mejoramiento de procesos
de producción y de servicio, basado en la
eliminación de desperdicios y actividades que no
agregan valor.
▸ LEAN permite alcanzar resultados inmediatos en

productividad, competitividad y rentabilidad del
negocio.
▸ LEAN se enfoca en incrementar tal valor eliminando

desperdicios de los recursos existentes generando
mayor rentabilidad a bajo costo.
16
Ágil Chile - 2021
Otros Frameworks - Kanban
Kanban
Es una palabra japonesa que significa algo así como “tarjetas visuales” Esta técnica se creó en Toyota, y
se utiliza para controlar el avance del trabajo, en el contexto de una línea de producción. El Kanban está
dentro de la estrategia Kaizen, es decir, la mejora continua.
Las principales reglas de Kanban

son las siguientes:
1. Visualizar el trabajo y las fases del ciclo de
producción o flujo de trabajo
2. Determinar el límite de “trabajo en curso” (o
Work In Progress) y;
3. Medir el tiempo en completar una tarea (lo
que se conoce como “lead time”).
17
Ágil Chile - 2021
Modulo 2
¿Qué es Devops?
AGILE CHILE
Te hacemos Ágil
18
¿Qué es DevOps?
DevOps es una contracción de "Desarrollo" y "Operaciones".

DevOps combina un marco de entrega continua altamente automatizado (o no),
repetible y comprobable, con un equipo unificado que se extiende durante todo el
ciclo de vida de la entrega de capacidades a la producción.
Con un enfoque DevOps, podemos tomar
pequeños lotes de requisitos rápidamente
desde el concepto hasta la implementación,
monitorear los resultados y usar lo que
aprendemos para cambiar el producto y el
proceso.
19
Ágil Chile - 2020
¿Qué es DevOps?
DevOps es una nueva tendencia en la industria TI dirigida a mejorar la agilidad

del servicio de entregas en TI. El movimiento hace énfasis en la comunicación
transparente, la colaboración junto con la integración entre el software de
desarrolladores y las operaciones de TI
DevOps reconoce que los desarrolladores y los operadores de TI son grupos
con relación que pueden interactuar entre sí, pero no realmente trabajar juntos
DevOps ayuda a la organización a crear servicios TI y software de manera
rápida lo que resulta en la reducción del número de iteraciones
Los equipos DevOps logran el éxito por el uso de dos componentes claves
llamados “comunicación” y “visibilidad en tiempo real”.
20
¿Qué es DevOps?
No existe una sola herramienta de DevOps que trabaje en la colaboración e

integración entre los equipos de desarrolladores, testers y operaciones
Se utilizan una cadena de herramientas DevOps que consiste en un número de

herramientas que se ajustan en varias categorías del proceso en las fases desde
desarrollo a la implementación
Estas herramientas son usadas en los procesos que involucran a los equipos de
código, construcción, test, empaque, liberación, configuración y monitorización
21
¿Por qué DevOps?
¿Cuál es el problema? Comunicación tradicional sobre Desarrollo y Operaciones
Muro de la Confusión
¡Nosotros queremos ¡Nosotros queremos
cambiar! Estabilidad!
Desarrollo Operaciones
22
Definiciones de DevOps
No existe un acuerdo claro y universal sobre su

definición.
Hay varias opiniones sobre qué es y qué no es DevOps

generalmente se define como una nueva forma de
organización, una cultura o incluso una nueva forma de
pensar (Filosofía).
23
¿Qué no es DevOps?
DevOps no es una estrategia para todos
No todas las organizaciones están preparadas para utilizar

DevOps, aquellas empresas rígidas que no aprovechan el
cambio no serían buenos candidatos a adoptar DevOps.
DevOps no es automatización
DevOps implica automatización. DevOps es más que

automatización
24
¿Qué no es DevOps?
DevOps no es una herramienta implementada.

➢ Aunque hay herramientas que son usadas en DevOps no deberíamos
limitar su alcance a herramientas específicas como Chefs o Jenkins. Esto
limita el amplio alcance como si una sola herramienta de automatización
se equiparara con DevOps
DevOps no es equipo de trabajo nuevo y separado de las demás

áreas de TI
➢ Tener un equipo DevOps separado, anula el propósito de evitar las
posibles fricciones y falta comunicación entre los desarrolladores y
operadores de TI ya que crea un silo más.
25
Definición de DevOps Según sus Líderes
Nos referimos a DevOps como el resultado de la aplicación de

principios eficientes a la corriente de valor de TI.
Michael Duffy
Autor Libro “DevOps Automation Cookbook”
Una mezcla de patrones destinados a mejorar la colaboración entre

desarrolladores y operadores. DevOps se dirige a compartir metas e
incentivos, así como procesos compartidos y herramientas.
Michael Hüttermann.
Autor Libro “DevOps for Developers”
26
Definición de DevOps Según sus Líderes
Un movimiento de personas quienes se preocupan por desarrollar y

operar sistemas fiables, seguros y de alto rendimiento a escala”
Jez Humble
Autor Libro “devops handbook”
DevOps es una cultura o un movimiento profesional

Adam Jacob, CTO at Chef.
Autor Libro “DevOps for Developers”
27
Los 4 pilares del enfoque devops
CULTURA
• Enfoque colaborativo para encontrar soluciones
1 • Manejo maduro de potenciales conflictos
• Feedback y comunicación continua
• Tolerancia al riesgo
• Aprendizaje continuo
GOBIERNO
• Métricas DevOps
2 • Gestión de nuevos procesos
• Gestionar metodologías
• Gestión de la calidad
01
HERRAMIENTAS
• Herramientas de integración continua
3 • Herramientas de seguimiento de proyectos
• Herramientas de aprovisionamiento
• Herramientas de monitoreo
PROCESOS
• Nuevos procesos
4 • Eliminación de procesos existentes
• Modelo de mejora continua (Kaizen)
Cultura
“No importa lo que parezca a simple

vista, siempre es un problema
relacionado a las personas”
Jerry Weinberg, Secrets of Consulting:

Segunda ley de la consultoría
29
Cultura
Peter Ferdinand Drucker fue consultor y

profesor de negocios, tratadista
austriaco, y abogado de carrera,
considerado el mayor filósofo de la
administración del siglo XX. Fue autor de
más de 35 libros, y sus ideas fueron
decisivas en la creación de la Corporación
Moderna.
30
Gobierno
Es central, para lograr una

implementación sana de DevOps,
construir un propósito conjunto y
maneras de medir como se está
alcanzando ese objetivo. En
nuestro caso proponemos alinear
todo bajo un sistema de OKR´s
y/o MA.
31
Metricas relevantes
▸ Lead Time
▸ Deployment Frecuency
▸ MTTE (Mean time to Restore)
▸ CFP (Change Fall Percentage)
▸ NPS (Net Promoter Score)
▸ Uso de las prácticas y
herramientas
32
Procesos
▸ La habilidad de visualizar el
trabajo tanto visible como
invisible es esencial para
ganar claridad y consenso
acerca de como se están
haciendo las cosas.
▸ DevOps plantea un enfoque

LEAN para mapear y
optimizar procesos.
33
Herramientas
34
Herramientas
▸ Diseñar buenos productos, escribir buen código,

mantener un enfoque colaborativo y Lean, es
independiente de las herramientas usadas.
▸ Las herramientas DevOps tienen como propósito
automatizar el ciclo de vida del desarrollo y delivery de
software
▸ Es clave definir el conjunto que mejor se adecúe a la
realidad del equipo o de la organización que está
adoptando DevOps
35
36
Historia de Devops
2008
Las semillas del movimiento DevOps fueron plantadas durante la conferencia
de Agile 2008 celebrada en Toronto por el desarrollador de software Patrick
Debois, quien tenía experiencia en múltiples funciones en una gran
organización de la industria TI como desarrollador, administrador de sistema,
especialista de red, gerente de proyecto e incluso tester.
Él demostró que podía haber mejores maneras de obtener un gran trabajo al

resolver los conflictos entre los equipos de desarrollo y operaciones. Pronto
fue reconocido como el líder de la idea detrás del concepto de DevOps y otros
continuaron resolviendo estos desafíos.
37
Historia de Devops
2009
John Allspaw y Paul Hammond dos empleados en jefe de Flickr presentaron
una charla clave, titulada Diez despliegues en el día: cooperación de Dev y Ops
en Flickr. En esta charla Allspaw y Hammond señalaron poderosamente como
el conflicto llevó a “apuntarse con el dedo” entre los desarrolladores y
operadores al culparse entre ellos.
También señalaron que la única manera de construir y desplegar un software

viable era hacer a operaciones y desarrollo integrados y transparentes.
Inspirado por esto, Debois organizó su propia conferencia (DevOpsDay) El

nombre de este movimiento fue reducido a DevOps después de esta
convención.
38
Historia de Devops
2010
Primer DevOpsDay organizado en los Estados Unidos tuvo a defensores de
DevOps como Andrew Clay Shafer, Damon Edwards, entre otros. Los eventos
llamaron la atención global y fueron avanzando hacia la comunidad DevOps.
Introducción del hashtag #DevOps que resultó ser una rica fuente de información.
2011
Muchos análisis pronosticaron el surgimiento de DevOps a nivel global para el
2020. Se desarrollaron herramientas de código abierto tales como Vagrant que
funcionaba con Chef Puppet y herramientas de administración de configuraciones
similares.
39
Historia de Devops
2012
Los DevOpsDays fueron organizados alrededor del mundo y se convirtieron en
eventos TI muy concurridos y deliberados sobre el pensamiento innovador en
el dominio DevOps.
2013
Mike Loukides, una figura prominente en el mundo DevOps junto con Debois
editaron algunos textos fundamentales de DevOps. Él afirmó que es fácil
pensar en DevOps en términos de las herramientas que se utilizan en el
mismo. Pero, en realidad este es un acuerdo íntimo entre los equipos de
desarrollo y operaciones.
Gran cantidad de libros sobre DevOps aparecieron. Algunos de los más
notables son “The Phoenix Project”,”Implementing Lean Software
Development“ “Web Operations” y “The Lean Startup”, entre otros.
40
Historia de Devops
2014
El mundo tecnológico en evolución presenta nuevas oportunidades para el
concepto de DevOps en forma de explosión de nuevas aplicaciones,
dispositivos y comunicaciones en entornos móviles y Cloud Computing.
En una encuesta realizada por Puppet Labs, 16% de 1486 encuestados

afirmaron que ellos son parte de DevOps en sus organizaciones.
2015+
DevOps es presente y futuro…
41
Módulo 3
Beneficios
AGILE CHILE
Te hacemos Ágil
42
Beneficios
DevOps garantiza un tiempo más rápido de comercialización de los plazos de

entrega y, por lo tanto, mejora la rentabilidad de las inversiones (ROI)
Fundamentalmente, DevOps es una aplicación del concepto de desarrollo

Agile y por lo tanto el principal beneficio de DevOps es el desarrollo más
rápido de software y la entrega frecuente mejorando la línea de fondo
DevOps trae el mayor beneficio al mejorar la colaboración entre el

desarrollador y los equipos de operación. Esto se logra mejorando la
transparencia que es esencial para una toma de decisiones efectiva
43
Beneficios
Hoy en día, los equipos de desarrollo deben dividir sus silos

departamentales, comunicarse y colaborar con otros equipos de TI en el
entorno dinámico actual
DevOps mejora la agilidad ya que ofrece un entorno de colaboración,

comunicación e integración en equipos diversamente ubicados en una
organización global de TI
Otro beneficio significativo de DevOps es la detección temprana y la

correspondiente corrección más rápida de los defectos que implica
ofrecer los mejores servicios entregados a los clientes
44
Beneficios
Uno de los beneficios clave de DevOps es el lanzamiento,

implementación, supervisión y la corrección continua
El desarrollo de software actual requiere que los equipos se involucren en

la entrega continua sin fallas, en un período reducido para los marcos de
tiempo de salida al mercado y ciclos de lanzamiento más cortos
45
Beneficios de Estabilidad
Existen mejoras en los Mean Time To Recovery (MTTR)

Es el tiempo promedio para reparar un servicio de TI u otro
elemento de configuración después de una falla
El MTTR se mide desde el momento en que el elemento de

configuración falló hasta que fue reparado
El MTTR no incluye el tiempo necesario para recuperar o restaurar.

A veces se usa incorrectamente en lugar del tiempo medio para
restablecer el servicio
46
Resumen
Beneficios Técnicos Beneficios Culturales Beneficios de negocio
Empleados más felices,

Entregas de producto/servicio
Entrega de tecnología continua equipos de trabajo más
más rápidas
productivos
Mayores niveles de
Menor complejidad de gestión Entornos más estables
compromiso en sus empleados
Mayor velocidad en la Nuevas oportunidades de Mejoras en la comunicación y

resolución de problemas desarrollo interno colaboración
47
Módulo 4
Propósito de Devops
AGILE CHILE
Te hacemos Ágil
48
Propósito de DevOps
El mejor propósito ofrecido por DevOps es iterar de manera más

rápida durante la fase de desarrollo.
Esto se logra al evitar la fricción entre los desarrolladores y

operadores tanto como sea posible.
También se logra garantizando la transparencia e integración

entre el equipo de desarrollo y operaciones.
49
El objetivo de DevOps es establecer procesos de negocios

alineados en flujo “justo a tiempo”(JIT por sus siglas en inglés).
DevOps busca maximizar los resultados del negocio, tales como

incrementar las ventas y la rentabilidad, mejorar la velocidad del
negocio, o minimizar costos operativos, al alinear los procesos
empresariales “justo a tiempo” (JIT).
50
Las empresas buscan obtener nuevas aplicaciones o

servicios con propósitos específicos, pero se necesita un
tiempo considerable para codificar el proyecto, algunos días
para asegurar la calidad (Quality Assurance), otros más para
manejar problemas de implementación, mantenimiento y en
muchos casos se necesita regresar atrás debido a la falta de
coincidencia entre lo que se esperaba y lo que se entrega
Muchos proyectos toman meses en esta inevitable ronda de

eventos. En este contexto, DevOps ayuda a realizar la
implementación de manera rápida y sin esfuerzo. Por lo
tanto, el propósito general de DevOps es lograr la rapidez
en el despliegue
51
DevOps desea establecer la cadena de suministros de servicios TI en el

negocio, de la misma manera que la cadena de suministro para otros
productos está incrustado. Es un gran cambio de paradigma desde la
entrega del software hasta la prestación de servicios TI
Desde el punto de vista arquitectónico, DevOps necesita establecer un
sistema de despliegue automatizado rápido
Hay muchas metodologías y herramientas que pueden ser utilizadas
DevOps no tiene un modelo propio para la implementación, cada
organización tiene que pensar y construir su propio proceso DevOps para
mejorar su negocio, aunque hay excepciones a esta regla.
52
Modelos de implementación Devops
Algunos modelos planteados:
▸ DevOps Roadmap
▸ DevOps Maturity Model
▸ DevOps Journey
53
DevOps Roadmap
54
DevOps Roadmap
En lugar de seguir el enfoque tradicional en silos de "transferencia", la metodología

DevOps enfatiza que los equipos de ingeniería y TI trabajen juntos y coordinen
esfuerzos a lo largo de todo un ciclo de lanzamiento de software.
El Roadmap de DevOps implementa un proceso que se basa en la integración e

implementación continua. Esto debería ayudar a los equipos a producir un mayor
nivel de producción, con menos variaciones entre los ciclos de producción y una
visión interfuncional mejorada del ciclo del producto de principio a fin
Los equipos de DevOps pueden construir procesos de desarrollo de productos más

transparentes, colaborativos y eficientes mediante el fomento de un conjunto de
principios (mentalidad de crecimiento, innovación gratificante, cooperación,
experimentación, aprendizaje y empatía del usuario) en lugar de centrarse en la
estructura organizativa.
55
¿Qué es un roadmap de DevOps?
Un Roadmap de DevOps le permiten optimizar los rituales y las herramientas del equipo
para administrar mejor los recursos cada trimestre/semestre. Los jefes de equipo o los
gerentes pueden utilizar la hoja de ruta para crear nuevas formas de mantener bajos los
gastos generales y reducir el trabajo intenso. Idealmente, su equipo se mantiene desafiado
y motivado para encontrar oportunidades de innovación.
DevOps en sí es un proceso que facilita la colaboración entre los equipos de ingeniería que
codifican el software y los equipos de operaciones responsables de entregar el software a
los clientes.
Al colaborar durante todo el proceso de desarrollo de software, los desarrolladores

pueden iterar el código de forma continua en función de los comentarios del equipo de
operaciones. Al igual que la metodología Agile , los procesos de DevOps ayudan a los
equipos a tener menos contratiempos o sorpresas a través de más oportunidades de
pruebas y coordinación integradas en el proceso.
56
Generalmente, los roadmap de DevOps representan:
▸ Un flujo de trabajo circular que define el flujo de entrega de ambos

equipos y el ciclo de retroalimentación continua entre su empresa y
sus clientes.
▸ Una hoja de ruta de DevOps trimestral que describe las prioridades a

corto plazo, con productos y proyectos en cada carril
▸ Un marcador de posición móvil "hoy" para ayudar a su equipo a

realizar un seguimiento de la progresión trimestral
57
La creación de un equipo de DevOps, en lugar de separar a los

desarrolladores y las operaciones de TI en silos de información
discretos, permite a las organizaciones planificar la recuperación
ante desastres. La creación de una hoja de ruta compartida
también ayuda a crear productos escalables, portátiles y seguros.
58
Cuándo usar las hojas de ruta de DevOps
Una hoja de ruta de DevOps bien definida ayuda a los equipos a trabajar juntos y
ofrece oportunidades de aprendizaje cuando los proyectos y productos tienen
éxito o encuentran obstáculos.
Una hoja de ruta de DevOps también puede ayudar a los equipos a:

▸ Comprenda detalles específicos del proceso general, para alinear el desarrollo
y las operaciones en fechas clave e iniciativas para colaborar mejor.
▸ Mantenerse alineado con las prioridades y dependencias para que puedan
administrar su tiempo y anticipar cuándo los equipos entregan los elementos
que necesitan atención.
▸ Mejoran continuamente los productos comunicando y compartiendo
información con regularidad y ofreciendo con frecuencia mejoras y
funcionalidades incrementales a los usuarios.
59
Cuándo usar las hojas de ruta de DevOps
Como referencia visual, la hoja de ruta de DevOps también ayuda a los equipos a tener en cuenta las
prioridades a mediano y corto plazo y a adaptarse a las prioridades cambiantes.
Para priorizar cada elemento en su hoja de ruta, use el marco CALMS:
Cultura: Actividades que mejoran la comunicación y la comprensión mutua de los objetivos y
responsabilidades de los demás
Automatización: actividades que aceleran la entrega e integración continuas al tiempo que ahorran
tiempo, dinero y esfuerzo en todos los equipos, procesos y herramientas
Lean: enfocado en reducir los desperdicios, centrarse en el cliente y generar mejora continua (Kaizen)
Medición: actividades que ayudan a medir si el progreso está sucediendo y si va en la dirección correcta.
Compartir: actividades que ayudan a la transparencia y la apertura, para estrechar los circuitos de
retroalimentación e impulsar la mejora continua
El objetivo final es compartir la responsabilidad y poner a los equipos en la misma página para ayudar al
progreso de la organización.
60
Cómo elaborar un roadmap de DevOps
Crear un roadmap de DevOps es fácil. Existen varias herramientas que apoyan

esta actividad, por ejemplo, Miro funciona muy bien.
▸ Primer paso: Defina claramente los objetivos de su roadmap. Antes de

agregar cualquier contenido al roadmap, determine por qué lo necesitan
sus equipos. Algunos ejemplos incluyen: "Mejorar la coordinación entre
los equipos de ingeniería y operaciones" o "Crear una única fuente de
información para el trabajo de DevOps".
▸ Segundo paso: Establezca metas o planes específicos a corto plazo.

Generalmente se suele abordar año tras año con una división trimestral.
Sin embargo, al igual que los procesos ágiles, la recomendación es no
planificar por adelantado sino que ir generando metras logrables.
61
▸ Tercer paso: Utilice señales visuales para que la hoja de ruta sea más fácil
de entender. También es importante definir las prioridades dejando
evidencia de aquello, por ejemplo: "Prioridad alta", "Prioridad media" y
"Prioridad baja". También puede codificar con colores cada elemento de
acuerdo con los valores CALMS (Cultura, Automatización, LEAN, Medición,
Compartir).
▸ Cuarto paso: Pídale a su equipo que agregue productos y proyectos a la

hoja de ruta. Cada objeto de la hoja de ruta está codificado por colores de
acuerdo con su principio de alineación en CAMS. También puede agregar
una etiqueta para marcar su estado de prioridad, de mayor a menor.
62
▸ Quinto paso: Mantenga su hoja de ruta actualizada según sea

necesario. Configure sesiones de revisión periódicas para realizar
ajustes en el flujo de trabajo de DevOps o en las prioridades de la hoja
de ruta a medida que cambian los planes. También puede alentar a
sus colegas a que revisen la hoja de ruta por su cuenta para
mantenerse actualizados con los cambios o las prioridades.
63
Nivel de Madurez DevOps
DevOps ha transformado la industria de TI al cambiar la forma en que los equipos

operan y colaboran en la cadena de procesos y el flujo de trabajo
A estas alturas, la mayoría de las organizaciones habrán alcanzado algún nivel de

implementación de DevOps en su recorrido por el software
Si bien hay algunos problemas en el proceso de comprender el impacto de DevOps,

la mayoría de las personas/empresas aún no se han dado cuenta del potencial
completo de DevOps
El concepto erróneo más común en torno a la adopción de DevOps sigue

existiendo, es decir, "entenderlo no como un viaje si no como un destino"
¡De esto es de lo que habla precisamente el Modelo de madurez DevOps !
64
Comprender la madurez de DevOps
Por definición, la madurez de DevOps se describe como un modelo que determina la

posición de una organización en el viaje de DevOps junto con la decisión de qué más se
debe lograr para lograr los resultados deseados.
Entender la adopción de DevOps 'como un viaje continuo, no como un destino' es crucial

para lograr la madurez de DevOps.
El modelo de madurez de DevOps determina el crecimiento a través del aprendizaje

continuo desde las perspectivas de los equipos y de la organización. A mayor capacidad
y destreza, mayor será la capacidad para manejar problemas de escala y complejidad.
Como recomiendan los expertos, la madurez de DevOps organizacional se puede medir

por sus habilidades en las siguientes cuatro áreas:
65
1. Cultura y estrategia
DevOps debe entenderse como un enfoque impulsado por la cultura que
reúne a diferentes equipos y los impulsa hacia un objetivo común. La
transición a DevOps significa una transformación en la cultura operativa
de la organización respaldada por un conjunto de políticas y marcos de
procesos. Entonces, eso necesita una planificación adecuada y una
estrategia perfecta.
2. Automatización
La automatización es clave para la entrega continua y los mecanismos de
implementación continua en el proceso de DevOps. Al automatizar las
tareas repetitivas, el proceso de automatización facilita el desarrollo, las
pruebas y la producción en un ciclo de DevOps, lo que ahorra tiempo y
mejora la eficiencia de los recursos.
66
3. Estructura y proceso
El funcionamiento de la TI de hoy en día está orientado a procesos e
involucra procesos en todas las etapas del ciclo de vida de desarrollo de
software. Esto ha avanzado en un entorno DevOps, donde cada etapa es
un conjunto de procedimientos en línea con las políticas corporativas y
los objetivos comerciales.
4. Colaboración e intercambio
Este es el aspecto más crítico de la cultura DevOps . La colaboración y el
intercambio son clave para DevOps y los equipos (en la misma ubicación
o en una ubicación diferente) deberán alinear herramientas y recursos
para lograr metas y objetivos comunes.
67
Según la investigación de Forbes, las organizaciones comúnmente se encuentran en una de

las siguientes etapas como parte de su viaje DevOps:
▸ Incompetencia inconsciente: las organizaciones no comprenden DevOps y sus ventajas

▸ Incompetencia consciente: las organizaciones aún ven procesos aislados incluso
después de 12 a 18 meses de viaje de DevOps con algo de automatización.
▸ Competencia consciente: después de cuatro años de trayectoria de DevOps y
automatización exitosa, las organizaciones se enfocan en la colaboración entre equipos
y agilizan el mecanismo de intercambio.
▸ Competencia inconsciente: aquí, las organizaciones están configuradas con marcos
estructurados, colaboración en profundidad, el proceso concreto para compartir de
manera efectiva
68
¿Qué constituye un modelo de madurez de
DevOps?
Un modelo de madurez de DevOps perfecto determina la madurez de

DevOps de tres formas:
▸ Evaluación del estado actual de las capacidades

▸ Identificación de áreas de mejora
▸ Describir los pasos para lograr los objetivos de DevOps deseados
De acuerdo con estos tres pasos, el bloque de madurez de DevOps verifica

la madurez en las etapas de construcción, implementación y prueba en
los niveles de aplicación, datos e infraestructura:
69
¿Qué constituye un modelo de madurez de
DevOps?
1. Madurez de DevOps para la aplicación: determina la madurez de DevOps

por la facilidad en el movimiento del código desde la fase de desarrollo a la de
producción. Lograr esto requiere tener compilaciones, pruebas, cobertura de
código, escaneos de seguridad y monitoreo como componentes
automatizados de la canalización de implementación.
2. Madurez de DevOps por datos: determina la madurez de DevOps por la

capacidad de despejar el camino para automatizar los cambios en los datos y
validar la funcionalidad con regularidad, a través de DataOps.
3. Madurez de DevOps por infraestructura: determina la madurez de DevOps

por la capacidad de facilitar la infraestructura utilizando capacidades en torno
a la automatización, optimizando y habilitando el autoservicio para
aprovisionar entornos, entre otras tareas.
70
Cinco niveles de madurez
Se maneja el entorno tradicional con

INICIAL
1 separaciones de desarrollo y operaciones
El comienzo de la mentalidad de cambio se

centró en la agilidad en Desarrollo y la
2 automatización inicial en Operaciones, con
énfasis en la colaboración.
OPTIMIZADO ADMINISTRADO
La transformación de toda la organización
3 comienza con procesos definidos y
automatización establecida.
Una mejor comprensión de los procesos y la

4 automatización, seguida de una mejora
continua.
MEDIDO DEFINIDO Los logros son visibles, las brechas en el

5 equipo desaparecen y los empleados
obtienen reconocimiento.
71
Ágil Chile - 2021
¿Qué medir en un modelo de madurez de
DevOps?
Hay un conjunto de parámetros que se deben medir en cada etapa del modelo de madurez de
DevOps para confirmar el nivel de madurez de DevOps de una organización. Estas medidas
definen idealmente la dirección en la que avanza la organización en su viaje DevOps. Son:
▸ El número de proyectos completados y la frecuencia de publicación deben ser idealmente

altos, lo que da como resultado un ROI
▸ El porcentaje de implementaciones exitosas debe mantener una ventaja sobre las
infructuosas
▸ El tiempo medio de recuperación (MTTR) de un incidente / falla inesperado desde el
momento en que ocurrió, debe ser nulo o lo más bajo posible
▸ El tiempo de espera, desde el desarrollo del código hasta la implementación en
producción, debe ser satisfactorio
▸ Frecuencia de implementación para determinar la frecuencia de implementaciones de
código nuevo
72
Madurez de DevOps vinculada a la seguridad
La madurez de DevOps está directamente relacionada con la seguridad de DevOps.

A medida que las organizaciones avanzan en el camino de DevOps, la ventaja
competitiva se convierte en una demanda urgente que exige ciclos de lanzamiento
más rápidos y la innovación digital exige un tono sólido.
Aquí es donde el desafío de la seguridad comienza a volverse más serio y es por eso
que la madurez de DevOps requiere reconsiderar las prácticas de seguridad.
Eventualmente, las organizaciones tendrán que hacer de la seguridad una parte

integral de su proceso de DevOps y acercarlo a todas las etapas de desarrollo de
aplicaciones.
73
Madurez de DevOps vinculada a la seguridad
Los expertos en DevOps trabajan con el personal de seguridad para la integración

temprana de la seguridad en el nivel de madurez en todas las partes del ciclo de
vida del desarrollo de software.
Esto puede suceder mediante una implementación eficaz de DevSecOps. Las

soluciones como la contenedorización también pueden ayudar hasta cierto punto
a abordar los problemas de forma continua al limitar los recursos vulnerables.
Además, los equipos de seguridad y DevOps pueden colaborar en la aplicación de

políticas y marcos de seguridad a todas las herramientas y recursos de DevOps .
74
Beneficios comerciales de la madurez de
DevOps
Al brindar una imagen completa de la posición de DevOps de una

organización, el modelo de madurez de DevOps presenta una amplia
gama de beneficios comerciales:
▸ Mayor adaptabilidad al cambio

▸ Capacidad para aprovechar oportunidades
▸ Identificar áreas de cumplimiento
▸ Escalabilidad mejorada
▸ Eficiencia operacional
▸ Mayor velocidad de entrega
▸ Calidad mejorada
75
¿Cómo evaluar el nivel de madurez Devops?
1. Junta un equipo de trabajo multidisciplinario,

idealmente que pertenezcan al área de Desarrollo,
Operaciones y de ser posible, al negocio.
2. Genera pregunta tras pregunta, puedes utilizar la
técnica del Planning póker para poder llegar a un
consenso, es importante evaluar aspectos
asociados a Personas, Procesos y Herramientas.
3. Evalúa el nivel de madurez asociado a cada ítem
4. Define un plan de acción a implementar.
76
Nivel de
Personas Procesos Herramientas
Madurez
• Basado en silos
• Procesos manuales • Construcción e implementaciones manuales
Nivel 1 • Culpar y señalar con el dedo
• Poco conocimiento de las normas • Testing manual
Ad-hoc • Depende de expertos
• Impredecible y reactivo • Inconsistencia entre ambientes
• Falta de responsabilidad
• Automatizar las construcciones

• Procesos establecidos en silos
• Comunicaciones gestionadas • Automatizar las pruebas y parte del
Nivel 2 • Pueden repartir el conocimiento
• intercambio limitado de desarrollo de las historias
Repetible pero no pueden reaccionar sobre
conocimientos • lanzamientos dolorosos pero repetibles
lo no conocido
• Ciclo de prueba y compilación automatizado

• Existe colaboración • Procesos automáticos
Nivel 3 para cada Commit
• Toma de decisiones compartida • Procesos estándar en toda la
Definido • Liberación con solo botones
• Se comparten responsabilidades organización
• Automatizar las pruebas de usuario
• Crear métricas visibles y sobre las que se

actúe
• Monitoreo proactivo
Nivel 4 • Colaboración basada en • Liberaciones orquestadas que incluyen
• Recolección y análisis de métricas
comportamiento de las métricas con rollback automático
Medible basado en los objetivos del negocio
foco en remover los impedimentos • Requerimientos no funcionales definidos y
• Visibilidad y predictibilidad
medidos
• Cero indisponibilidad al liberar

Nivel 5 • Automatización del autoservicio
• Una cultura de mejora continua • Infraestructura inalterable
• Optimización de riesgo y costos
Optimizado permanente en toda la organización • Hacer cumplir activamente la resiliencia
• Alto grado77
de automatización
forzando fallas
Barreras para DevOps empresarial
Los beneficios de DevOps empresariales son claros,

entonces, ¿qué se interpone en el camino para el 90%
de las organizaciones que aún no lo han logrado? Todo
se reduce a la esencia de DevOps: personas y cultura,
procesos y prácticas, y herramientas y tecnología.
Cuando las organizaciones intentan una
transformación DevOps sin considerar los tres, a
menudo se enfrentan a expectativas no satisfechas.
78
Considere una organización que descarta el cambio cultural

como un requisito, pero busca acelerar la entrega de
software de mayor calidad utilizando solo herramientas y
tecnología. Realiza importantes inversiones en herramientas
automatizadas para pruebas, pero carece de una cultura de
calidad primero. Los equipos siguen los movimientos, pero
no toman medidas activas para garantizar la calidad. Pero si
enfatizaran el cambio cultural, la organización habría
establecido objetivos de calidad e implementado la
automatización y la colaboración entre silos para corregir
los problemas de manera temprana y rápida.
79
Por el contrario, una organización que está

comprometida con el cambio cultural pero que no
adopta métodos ágiles y herramientas automatizadas
encontrará los cambios culturales demasiado difíciles
de mantener. Se verá afectado por demasiados pasos
manuales, procesos pesados, herramientas heredadas
engorrosas, etc. La organización no logrará una
entrega más rápida y la iniciativa fracasará.
80
Por lo tanto, concéntrese en los procesos que necesita

implementar, la tecnología que necesita para que esos
procesos sean perfectos y los cambios culturales que
necesita para que su iniciativa despegue de manera
sostenible.
81
La forma correcta de comenzar con DevOps
Al lanzar una iniciativa de DevOps, sea pragmático, no

dogmático. No puede saber todo al comenzar, así que
acérquese y planifique su iniciativa utilizando el
conocimiento que tiene y ajústelo en el camino.
La paciencia es clave para determinar qué procesos son

adecuados para sus equipos. Trate la transformación como
una evolución persiguiendo un progreso gradual que su
equipo pueda sostener en el tiempo. Si sus equipos no
pueden mantenerse al día, cometerán errores.
82
Elija sabiamente su primer proyecto. Elija uno que sea de alto

valor y bajo riesgo y asígnelo a un equipo que pueda demostrar lo
que DevOps puede hacer. El equipo adecuado será innovador,
impulsará constantemente el cambio en el proceso de desarrollo
de productos, estará dispuesto a probar nuevas herramientas y
procesos y estará abierto al cambio.
Por último, muestre el valor de DevOps a la alta dirección y a otros

equipos. Lleve un registro de las mejoras y documente todo para
que pueda mostrarle a la gerencia que su iniciativa es exitosa y
debe expandirse. La gente verá rápidamente los beneficios y usted
estará un paso más cerca de DevOps empresarial.
83
Ya sea que esté muy avanzado en su viaje de DevOps o

simplemente esté comenzando, el modelo de madurez
del cuadrante de DevOps es una excelente manera de
ver dónde se encuentra y trazar un mapa hacia dónde
debe ir. Y no se trata solo de seguir los movimientos e
invertir en las herramientas adecuadas, así que sea
dedicado y paciente con el proceso. El proceso no es
fácil, pero definitivamente vale la pena.
84
DevOps Journey Map
Así como existe el Customer Journey Map, se

recomienda utilizar un DevOps Journey Map para
analizar, verificar y definir las acciones necesarias para
implementar o mejorar la adopción de DevOps en la
organización.
85
Qué es el Customer Journey y cuál es su
importancia
Se trata de una herramienta de Design Thinking que

permite plasmar en un mapa cada una de las etapas,
interacciones, canales y elementos por los que
atraviesa un cliente durante todo el Ciclo de Compra
Este conjunto de momentos por lo que pasa cada
usuario es de vital importancia para tu negocio. La
percepción que el cliente tiene de tu firma en cada uno
de ellos puede determinar la compra de tu producto o
el de la competencia.
86
Qué es el Customer Journey y cuál es su
importancia
El Customer Journey Map te servirá no solamente para

conocer cada instancia por la que pasa el usuario durante su
Ciclo de Vida, sino también para averiguar exactamente
dónde, cuándo y cómo actuar para lograr que tu firma sea la
elegida a la hora de concretar una compra.
La clave de este diagrama es que no se trata de un análisis
objetivo de cada uno de los puntos que conforman el Ciclo
de Vida del cliente, si no que el foco está puesto en cómo se
siente él en cada uno de ellos con relación a la marca.
87
¿Y que tiene que ver con DevOps?
Realizar un Customer Journey Map a conciencia puede

servirte para entender y rediseñar la experiencia de tus
clientes, alinear la visión que ellos tienen con la tuya y
construir de forma más efectiva el Embudo de Conversión.
Lo mismo sucede con DevOps, si somos consientes y

hacemos un buen DevOps Journey Map podremos
identificar lo necesario para tener una buena adopción.
88
Cómo crear un Customer Journey Map
En primer lugar, se dibuja un gráfico en el que el “Eje X”

muestra las fases por la que pasa el cliente a lo largo
del tiempo y en el “Eje Y”, se define cómo siente las
experiencias, desde la más negativa, en rojo, hasta la
más positiva, en verde
En el siguiente ejemplo, considera las etapas más
críticas, desde que el cliente ingresa al local hasta que
paga. Entonces, para conocer su experiencia en cada
fase, se pensó en consultarle antes de retirarse cómo se
ha sentido en cada una de ellas.
89
90
Otro dato a considerar, además de las fases y los sentimientos o

sensaciones de los clientes, pueden ser los puntos críticos del
negocio, ya que pueden determinar la concreción o no de la
compra.
Entonces, en el gráfico que puedes ver a continuación se
observan:
➢ Puntos positivos: Entrada al local, comida y comer postre

➢ Puntos negativos: Elección de la mesa y pagar
➢ Stops o puntos críticos: El primer vistazo al local, la carta y
la comida.
91
A continuación, se analiza cómo se pueden mejorar los puntos

negativos y qué está ocurriendo con los críticos. El objetivo es
determinar cómo se sienten los clientes en estas fases clave y
cómo se podría elevar el valor de sus experiencias.
Por último, se definen las interacciones en las que la empresa

toma parte. En este caso, se dividieron entre directas (visibles para
el cliente) e indirectas (invisibles para él).
Ahora el mapa quedaría así.
92
93
DevOps Journey Map
Entonces, ¿cómo lo
llevamos a DevOps?
94
DevOps Journey Map
▸ Primero debemos posicionarnos sobre 3 perspectivas claras

personas y cultura, procesos y prácticas, y herramientas y
tecnología.
▸ Luego, debemos definir las etapas de nuestro proceso
▸ Definiremos las actividades significativas de cada etapa
▸ Definiremos los equipos que trabajan en cada etapa
▸ Con todo lo anterior, analizaremos como avanza cada
requerimiento / User Stories / PBI por nuestro flujo, donde
debemos detectar las fortalezas y dolores.
95
Adopción de DevOps
El enfoque incremental se centra en la idea de minimizar Dev Ops

el riesgo y el costo de una adopción de DevOps al tiempo
que se construyen las habilidades necesarias y el impulso
necesario para lograr una implementación exitosa en toda
la empresa
Los "Principios de tres maneras" de Gene Kim establecen Dev Ops
esencialmente diferentes formas de adopción incremental
de DevOps:
○ La primera manera: Acelerar el flujo
○ La segunda manera: Amplificar bucles de
retroalimentación Dev Ops
○ La tercera manera: La cultura de la
experimentación continua y el aprendizaje.
96
La Primera Vía - Acelerar el flujo
Se trata de un conjunto de principios y prácticas que aceleran la entrega de servicios de

TI. Es el flujo de izquierda a derecha.
La atención se centra en todos los flujos de valor de negocio que están habilitados por TI.
Es decir, se inicia cuando se identifican los requisitos (por ejemplo, por el negocio o TI),
se construyen en el Desarrollo, y durante la transición hacia operaciones de TI, en los que
se entrega a continuación el valor para el cliente como una forma de servicio.
Esta vía incluye conceptos como:
▸ El Mapeo de flujo de Valor (VSM), la entrega continua y los principios que conducen a
un flujo acelerado, como:
▸ Hacer visible el trabajo Dev Ops
▸ Equilibrar la carga de trabajo
▸ Limitar el trabajo en proceso
▸ Eliminar el desperdicio y Reducir los cuellos de botella.
97
La segunda manera: Amplificar bucles de
retroalimentación
Es el flujo de derecha a izquierda Dev Ops
Se trata de un conjunto de principios y prácticas que amplifican los bucles

de retroalimentación, enfocadas a generar una cultura de vigilancia y
resolución de problemas de seguridad y respuesta rápida.
El objetivo de casi cualquier iniciativa de mejora de procesos es acortar y

amplificar los bucles para, mediante las correcciones necesarias,
mantener continuamente la retroalimentación.
98
La Tercera Vía - Cultura de experimentación
continua y aprendizaje
Es la parte más importante de DevOps, se trata del flujo de círculo completo,

llamada Kaizen en la terminología Lean. En terminología normal sería: lo que
se necesita para ser una organización de aprendizaje.
Consiste en la creación de una cultura que fomente dos cosas: la

experimentación continua, correr riesgos y aprender de los fracasos; y la
comprensión de que la repetición y la práctica es el requisito previo para la
maestría.
Esta vía incluye conceptos como: autopsias sin

culpa, la ingeniería de la resiliencia, y el
pensamiento sistémico. Dev Ops
99
Módulo 5
Pilares de DevOps
AGILE CHILE
Te hacemos Ágil
100
JIT
101
Just in time (JIT) o Justo a Tiempo
La fabricación Justo a Tiempo también conocida como producción justo a

tiempo o el sistema de producción Toyota (TPS) es una metodología dirigida
principalmente a reducir los tiempos de flujo dentro de la producción, así
como los tiempos de respuesta de los proveedores y los clientes
JIT permite reducir costos, especialmente de bodega de materias, partes para
el embalaje y de los productos finales
La esencia de JIT es que los insumos llegan a la fábrica o los productos al
cliente, "Justo a tiempo", eso siendo poco antes de que se usan y solo en las
cantidades necesarias. Esto reduce o hasta elimina la necesidad de almacenar
y luego mover los insumos de la bodega a la línea de producción (en el caso de
una fábrica).
102
TPS
103
Sistema de Producción Toyota (TPS)
El TPS o Sistema de Producción Toyota, es un sistema integral de producción y

gestión surgido en la empresa japonesa automotriz del mismo nombre
En origen, el sistema se diseñó para fábricas de automóviles y sus relaciones con

proveedores y consumidores, sin embargo, este se ha extendido hacia otros
ámbitos. Este sistema es un gran precursor para el genérico Lean Manufacturing
El desarrollo del sistema se atribuye fundamentalmente a tres personas el

fundador de Toyota, Sakichi Toyoda su hijo Kiichiro y el ingeniero Taiichi Ohno
quienes crearon este sistema entre 1946 y 1975. Originalmente llamado
"Producción Justo a tiempo” Los principios de TPS son mencionados en el libro
“The Toyota Way“.
104
Kaizen
105
Kaizen
Kaizen término japonés para “Mejora”

Cuando se utiliza en el sentido comercial y se aplica al lugar de
trabajo, Kaizen se refiere a actividades que mejoran
continuamente todas las funciones e implican a todos los
empleados desde el CEO a los trabajadores de la línea de montaje
También se aplica a procesos, tales como compras y logística que
cruzan los límites de la organización en la cadena de suministro.
Se ha aplicado en la asistencia sanitaria, psicoterapia,
entrenamiento de vida, gobierno, banca, telcos y otras industrias.
106
BiModal
107
BIMODAL - Gartner
Bimodal es una estrategia introducida hace unos años por la

consultora Gartner. En su definición, se explica que bimodal se
refiere al mantenimiento, dentro de una empresa, de dos estilos
de trabajos distintos pero coherentes, llamados modos:
➢ Modo 1, para aquellas áreas tecnológicas de la empresa

más maduras, tradicionales y predecibles, en las cuales el
objetivo es la fiabilidad.
➢ Modo 2, apto para explorar nuevas funcionalidades y dar
respuesta altamente innovadoras a nuevas necesidades
de negocio, para las cuales prima la velocidad.
108
Para qué sirve bimodal
Cada día se pone más énfasis en la transformación digital y en la

necesidad de abrazar tecnologías como la Nube, el Big Data y
metodologías ágiles. En el caso de empresas pequeñas o start-
ups, el salto al digital es relativamente sencillo, y, para la mayor
parte de ellas, se trata de empresas que son ya nativas digitales.
Sin embargo, para empresas grandes y complejas, que llevan

muchos años funcionando y que han hecho enormes inversiones
para desarrollar sus sistemas TI, la transformación digital puede
representar un gran reto en términos de tiempo y coste. Es en
estos casos que entra en juego la estrategia bimodal.
109
Para qué sirve bimodal
Para estas empresas, bimodal conlleva las siguientes ventajas:
▪ Desarrollar rápidamente nuevos modelos de negocio sin tener

que modificar sus sistemas “core”.
▪ Permite garantizar el rendimiento y la fiabilidad y al mismo
tiempo dar rápida respuesta a nuevas demandas de negocio.
▪ Destinar equipos reducidos a explorar nuevas soluciones
innovadoras, mientras que el equipo TI se responsabiliza del
correcto funcionamiento de los sistemas de misión crítica.
▪ Llegar a poder competir en igualdad de condiciones con
empresas nativas digitales.
110
Bimodal como primer paso hacia DevOps
Una manera para superar las críticas y los retos de bimodal es

asumir de que se trata de una estrategia temporal. Así, el modo 2
representaría un estado de transición de una empresa hacia la
completa digitalización y la adopción de metodologías ágiles.
En este sentido, filosofías como DevOps se configuran como el

siguiente paso natural después de bimodal. DevOps, gracias a la
cultura colaborativa entre equipos de desarrollo y operaciones,
permite alcanzar una alta velocidad de entrega sin comprometer
la calidad.
111
BIMODAL - Gartner
112
DevSecOps
113
DevSecOps
DevSecOps permite utilizar de manera óptima la agilidad y la rapidez de reacción que

ofrece el enfoque DevOps. En este sistema, los mecanismos de seguridad están
integrados en el proceso ya desde el inicio del desarrollo.
Esta es una de las claras diferencias

entre el sistema DevSecOps y los
enfoques convencionales, en los
que los equipos de seguridad
suelen aplicar las medidas
correspondientes una vez se ha
finalizado el producto en sí.
114
115
Si DevOps no presta atención a la seguridad puede facilitar
la rápida introducción de las vulnerabilidades
116
Scrum
117
¿Qué es Scrum?
Scrum es un marco ligero que ayuda a las personas, equipos y

organizaciones a generar valor a través de soluciones adaptables para
problemas complejos.
En pocas palabras, Scrum requiere un Scrum Master para fomentar un

entorno donde:
1. Un Product Owner ordena el trabajo de un problema complejo en un trabajo pendiente del
producto (Product Backlog).
2. El Scrum Team convierte una selección del trabajo en un Incremento de valor durante un
Sprint.
3. El Scrum Team y sus partes interesadas inspeccionan los resultados y se ajustan para el
próximo Sprint.
4. Repetir.
118
Ágil Chile - 2021
Teoría de Scrum
Scrum se basa en el empirismo y el pensamiento Lean

El empirismo afirma que el conocimiento proviene de
la experiencia y la toma de decisiones basadas en lo
que se observa
El pensamiento Lean reduce los desperdicios y se
centra en lo esencial.
119
Ágil Chile - 2021
Empirismo
▸ El empirismo se basa en tomar decisiones basados en la información concreta

obtenida de la observación que muestra el progreso del desarrollo de
producto, los cambios en el mercado y los comentarios de los cliente
▸ Se implementa un proceso empírico en el que el progreso se basa en la
observación y la experimentación en lugar de los detalles
▸ Lo contrario al empirismo es usar planificación previa, procesos definidos,
planes predictivos, hechos no concretos.
Definidos Control de procesos Empírico
Conocimientos Desconocido
Waterfall Agile Lean StartUp
Pasos Innovación
Simple Complejo
120
Ágil Chile - 2021
Lean Thinking
▸ Lean Thinking es una metodología de negocios basada en la historia de

las técnicas de fabricación japonesas que se han aplicado en todo el
mundo en muchos tipos de industrias
▸ Lean se centra en proporcionar altos niveles de valor al cliente mediante
la mejora continua de los procesos empresariales
▸ Lean tiene sus raíces en la industria manufacturera de automóviles,
particularmente en el Sistema de Producción Toyota. La compañía
japonesa fue capaz de crear un ecosistema sostenible para el trabajo,
donde son capaces de minimizar sus costos, asegurar la eficiencia en sus
procesos y vender sus productos a un precio competitivo
▸ Los dos pilares de Lean proporcionan los fundamentos necesarios para
desarrollar el Lean Thinking. Estos son la Mejora Continua y el Respeto por
las Personas.
121
Ágil Chile - 2021
5 Principios del Pensamiento Lean
Especificar el valor del producto

Valor
1 desde el punto de vista del cliente
Identificar cadena de valor para

2 cada producto
Perfección Value Stream

Hacer un flujo de valor eliminando
3 los residuos
Deja que el cliente tire del flujo.

Facilitar que el cliente obtenga lo que
4 desea, cuándo lo desea, cómo lo
desea, y en la cantidad que desea.
Flow
Pull
Flujo de valor Mejorar continuamente en la
5 búsqueda de la perfección.
También conocida como Kaizen
122
Ágil Chile - 2021
Definición de Scrum en la Guía v2020
“Pruébelo como está y determine si su filosofía, teoría y

estructura ayudan a lograr objetivos y crear valor.”
“El marco de trabajo Scrum es incompleto de manera

intencional, solo define las partes necesarias para
implementar la teoría de Scrum.”
123
Ágil Chile - 2021
▸ Scrum es gratuito
▸ El marco de Scrum es inmutable
▸ Aunque la implementación de sólo algunas partes
de Scrum es posible, el resultado final no es Scrum
▸ Scrum sólo existe en su totalidad y funciona bien
como un contenedor para otras técnicas,
metodologías y prácticas.
124
Ágil Chile - 2021
▸ Omitir elementos de Scrum, no seguir las reglas de

Scrum, cambiar el diseño o las ideas esenciales de
Scrum, oculta los problemas y limita los beneficios
de Scrum, e incluso potencialmente lo vuelve
inútil.
▸ A medida que se utiliza Scrum, se pueden encontrar,
aplicar y diseñar patrones, procesos y enfoques que
se ajusten al marco de trabajo.
125
Ágil Chile - 2021
Pilares y Valores de
Scrum
126
Pilares de Scrum
Transparencia Inspección Adaptación
127
Ágil Chile - 2021
Valores de Scrum
El uso exitoso de Scrum depende de

que las personas sean más
competentes en vivir los cinco valores 01 02
Coraje Foco
05 03
Apertura Compromiso
Respeto 04
128
Ágil Chile - 2021
Estructura de Scrum
129
Estructura de Scrum
Scrum Product
Developers
Master Owner
Sprint
Sprint Sprint Planning Daily Scrum Sprint Review
Restrospective
Product Sprint Product

Backlog Backlog Increment
130
Ágil Chile - 2021
Responsabilidades en Scrum
Scrum Product
Developers
Master Owner
131
Ágil Chile - 2021
Scrum Team
La unidad fundamental de Scrum es un

pequeño equipo de personas. Un Scrum
Team
El Scrum Team consta de un Scrum Master,
un Product Owner y Developers
Dentro de un Scrum Team no hay subequipos ni jerarquías

Es una unidad cohesionada de profesionales enfocados en un objetivo a la
vez, el Objetivo del Producto.
132
Ágil Chile - 2021
Eventos de Scrum
5 1
Eventos 2
3
SCRUM RECONOCE 5
EVENTOS FORMALES 4 Sprint Review
Es un evento de máximo 4
horas para Sprint de un mes.
Todos los eventos se caracterizan por

tener Time-Box definidos. 5
133
Ágil Chile - 2021
El Sprint
El Sprint es un contenedor para todos los eventos

Sprint
Sprint Sprint
Daily Scrum Sprint Review
Planning Retrospective
134
Ágil Chile - 2021
Artefactos de Scrum
Product Sprint
Increment
Backlog Backlog
135
Ágil Chile - 2021
¿Cómo se ve Scrum?
136
Ágil Chile - 2021
WIP
137
Work in Progress, WIP (Trabajo en proceso)
▸ Un límite WIP (work in progress) es una estrategia para prevenir

cuellos de botella.
▸ Se acuerda por el equipo de desarrollo trabajar en progresos
limitados antes de que un proyecto comience y sean ejecutados por el
facilitador del equipo
▸ Por ejemplo, un equipo puede dividir las tareas que deben realizarse
para una característica en el diseño, código, prueba y despliegue.
Cuando se alcanza un límite WIP para una determinada tarea, el
equipo se detiene y trabaja en conjunto para eliminar el cuello de
botella. El objetivo de trabajar de esta manera es asegurar que todo el
equipo se apropie del proyecto y produzca códigos de alta calidad
138
SLA
139
Acuerdo de Nivel de Servicio (SLA) y OLAS
▸ Un Acuerdo de Nivel de Servicio (Service level agreement o

SLA) se define como un compromiso oficial que prevalece
entre un proveedor de servicios y el cliente
▸ Aspectos particulares del servicio (disponibilidad,
responsabilidades) son acordados entre el proveedor de
servicios y el usuario del servicio
▸ Acuerdos de Nivel Operacional (Operational level agreements
u OLAs) pueden ser utilizados por grupos internos para apoyar
SLAs
140
Ciclo PDCA
141
Ciclo PDCA
▸ PDCA (Planear, Hacer, Verificar y Actuar), es un método de

gestión de cuatro pasos iterativo utilizado en los negocios para
el control y la mejora continua de procesos y productos
▸ También se conoce como ciclo Deming
▸ Otra versión de este ciclo PDCA es OPDCA El " agregado para la
observación o como algunas versiones dicen “Comprender la
condición actual” Este énfasis en la observación y la condición
actual tiene relación con la fabricación Lean o la literatura del
sistema de producción de Toyota
142
Ciclo PDCA
Planear (Plan)
▸ Formular los objetivos: el qué, los resultados a alcanzar
▸ Definir las estrategias: el cómo, el camino para lograr los resultados
▸ Determinar las actividades a realizar: el plan de acción
▸ los índices que permitirán monitorear el desarrollo posterior de lo definido en esta
etapa
Hacer (Do)
▸ Poner en práctica lo planeado
▸ Reflejar la capacidad de la organización y de su talento humano para tomar decisiones
▸ Liderar el desarrollo de procesos
▸ Trabajar en equipo
▸ Asignar adecuadamente los recursos
143
Ciclo PDCA
Verificar (Check)
▸ Medir lo ejecutado frente a lo planeado, aplicando los índices establecidos
▸ Evaluar los resultados y el proceso desarrollado.
Actuar (Act)
▸ Establecer las medidas correctivas, en el caso de existir diferencias entre el hacer y el
planear.
▸ Analizadas las causas del problema, establecer un plan de mejoramiento basado en las
medidas correctivas para volver a tomar el rumbo indicado.
▸ Cuando esto último se da de manera consistente se procede a estandarizar, con el fin de
proporcionar una guía de como hay que hacer las cosas en la organización.
144
Definition Of Done
DoD
145
Definición de Listo (DoD)
▸ Definición de Listo (DoD), cuando un artículo del Product Backlog o un

Incremento se describe cómo “Listo”, todo el mundo debe entender lo
que eso significa.
▸ Aunque esto varía considerablemente según el Equipo Scrum los
miembros deben tener un entendimiento compartido de lo que significa
que el trabajo sea completo, para asegurar la transparencia
▸ Esta es la definición de “terminado” para los Scrum Teams y se utiliza
para evaluar cuándo se completa el incremento del trabajo. La misma
definición guía a los Developers para saber cuántos elementos de la
cartera de productos se pueden seleccionar durante una planificación de
Sprint
▸ El propósito de cada Sprint es entregar incrementos de funcionalidad
potencialmente liberable que se adhieran a la definición actual del Scrum
Team de “Terminado”
146
Kanban para DevOps
147
Kanban para Equipos DevOps
El método Kanban puede ayudar a los equipos de

DevOps a poner un poco de orden en su trabajo diario y
la teoría Lean definitivamente puede ser apalancada
para mejorar el flujo a través de los equipos de DevOps.
A continuación se muestra un tablero Kanban de
muestra que los técnicos de TI pueden usar para
ponerse al día con Kanban:
148
149
Kanban para Equipos DevOps
▸ Problemas de producción: esta es la pesadilla de todo equipo de DevOps. Los

problemas de producción significan usuarios insatisfechos y esto es lo peor
que puede suceder. Si tiene algo en este carril, debe dejar de hacer lo que sea
que esté haciendo y abordar el problema de la producción. Una vez que se
solucione el problema y se marque como Listo, puede continuar con sus tareas
habituales.
▸ Automatización: gran parte del trabajo en un equipo de DevOps consiste en
automatizar tareas repetibles o al menos debería serlo. Tener este carril en su
tablero Kanban es una forma de decir "Sí, entendemos la automatización, le
damos un lugar especial en nuestro tablero Kanban y queremos medir cuántos
trabajos automatizamos y cuánto tiempo lleva".
▸ Operaciones: aquí es donde entran los tickets de soporte o donde colocas
algunas tareas administrativas como reuniones, llamadas telefónicas, etc.
Intenta mantener este carril lo más vacío posible, dará espacio para la
automatización o proyectos estratégicos.
150
Módulo 6
Desarrollo
AGILE CHILE
Te hacemos Ágil
151
Ciclo de Vida del Desarrollo del Software
El ciclo de vida del software significa desarrollar el software, desde la etapa inicial
hasta la etapa final
El objetivo principal es:

▸ Definir todas las fases intermedias necesarias para validar el desarrollo de la
aplicación y asegurar que el software cumpla con los requisitos para la
implementación y verificación de los procedimientos de desarrollo
asegurando la utilización de métodos apropiados
▸ Al final de cada etapa se realiza una prueba para que se puedan arreglar las
revisiones
152
Desarrollo Agile del Software
No existe un enfoque universal para dirigir exitosamente cualquier proyecto de

desarrollo de software
Toda metodología debe adaptarse al contexto del proyecto (recursos técnicos y
humanos, tiempo de desarrollo, tipo de sistema, etc.)
Históricamente, los métodos tradicionales han tratado de abordar el mayor número
de situaciones del proyecto, lo que requiere un esfuerzo considerable para adaptarse,
especialmente en los pequeños y muy cambiantes requisitos de los proyectos
Las metodologías Agile ofrecen una solución para casi todos los proyectos que tienen
estas características
Una de las cualidades más notables de una metodología Agile es su simplicidad lo que
reduce los costos de implementación en un equipo de desarrollo
153
Desarrollo Agile del Software
La metodología Agile da mayor valor a lo individual, la colaboración con los

clientes y el desarrollo de software de forma incremental mediante iteraciones
cortas
Este enfoque se ha encontrado eficaz en proyectos que tienen requisitos
dinámicos y la necesidad de reducir drásticamente el tiempo de desarrollo,
mientras mantiene la alta calidad
Los enfoques de desarrollo Agile han revolucionado las formas de producir
software. Ha generado un debate entre sus seguidores y escépticos como un
enfoque alternativo a las metodologías tradicionales
154
Modelo en Cascada
El modelo de ciclo de vida en

cascada se comenzó a diseñar
en 1966 y se terminó alrededor
de 1970.
Se define como una secuencia

de fases donde al final de cada
una de ellas se reúne la
documentación para garantizar
que cumple las especificaciones
y los requisitos antes de pasar a
la fase siguiente
155
Módulo 7
Integración Continua
AGILE CHILE
Te hacemos Ágil
156
¿Qué es la integración continua (CI)?
La integración continua es el nombre que se le da a la

automatización de las labores de compilación, test y
análisis del código. Esto se puede conseguir de muchas
maneras, y podemos llamar integración continua a
todo lo que hay entre un script que periódicamente
ejecuta el trabajo y un servicio online que lo haga.
157
¿Cómo funciona?
Código Fuente
Independientemente
del sistema que
Resultados y Control de
utilicemos para Reportes Versiones
iniciarlo, el proceso
como mínimo seguirá
el siguiente camino:
Pruebas Build
Automatizadas Automático
158
Más simple aún
1. Descargará el código fuente desde el repositorio de

control de versiones (git, SVN, u otro).
2. Compilará el código según sea necesario.
3. Realizará las pruebas unitarias y/o de integración.
4. Publicará los resultados de modo que sea
accesibles.
159
¿Cuándo debería ejecutar CI)
Lo ideal, es ejecutarla siempre que se añadan cambios

al repositorio principal. Pero esto tiene un coste.
Compilar cada cambio que hacemos nos da cierta
seguridad, pero puede hacer que nuestro sistema de CI
trabaje más de la cuenta y suponga un coste adicional.
En cambio, aplicarla a todos los pull request nos
garantiza que todos los cambios sobre la línea principal
de trabajo van a funcionar bien. Aquí se trata de
encontrar un equilibrio entre coste y beneficio.
160
Beneficios de la Integración Continua
▸ Detectar rápidamente los posibles errores de compilación de nuestro

código. (en mi máquina funcionaba...)
▸ Detectar funcionamientos anómalos en nuestro software. (es un bug, no
una nueva característica)
▸ Mejorar la calidad de nuestros productos
▸ Nos permite compilar/testear nuestro código en diferentes plataformas.
El objetivo principal de la Integración Continua es que los miembros del

equipo conozcan la necesidad del trabajo integrado. Las pruebas
automatizadas pueden detectar errores siempre que un miembro del
equipo trate de realizar un cambio
161
▸ CI requiere que los desarrolladores trabajen integrando códigos en un

repositorio compartido varias veces en el día
▸ Cada chequeo pasará a ser verificado a través de la compilación
automatizada
▸ CI permite a los equipos detectar rápidamente los problemas tan
pronto como estos aparecen
▸ Con CI los errores son detectados de manera temprana
▸ Algunas compañías o equipos creen que es posible construir y entregar
sin CI pero hoy día puede ser un requerimiento
▸ Se puede creer que es posible desarrollar más rápido sin la
implementación de CI
162
▸ Con proyectos en aumento y creciendo ni la compañía ni el equipo se harán más

eficientes sin CI
▸ Con CI se detectan errores rápidamente, la confianza aumenta y esto lleva a una
mayor eficiencia en la entrega del software
▸ La Integración Continua es costo eficiencia, es decir, es económico. Evitar la
integración continua es costoso
▸ No seguir el enfoque continuo significa periodos de tiempo más largos entre
integraciones, por lo que es exponencialmente más difícil encontrar los
problemas y resolverlos
163
Módulo 8
Entrega Continua
AGILE CHILE
Te hacemos Ágil
164
¿Qué es la entrega continua (CD)?
La Entrega Continua, o Continuous Delivery en inglés, es un enfoque en el

que los equipos producen software en ciclos de vida cortos, asegurando
que el software se puede entregar en cualquier momento y, cuando se
haga, hacerlo manualmente.
La entrega continua es la habilidad de facilitar cambios de todo tipo

(incluyendo nuevas características, cambios de configuración, soluciones
de bugs y experimentos) a producción, o a los usuarios, de forma rápida,
segura y sostenible.
Jez Humble en su libro Continuous Delivery
165
Uno de los objetivos es que se puedan hacer despliegues de forma

predecible, sin resultados inesperados (que tanto odiamos )
Para conseguirlo, es imprescindible que el equipo de desarrollo tenga claro

que el código podrá ser entregado en producción en cualquier momento
Por supuesto, dentro de este enfoque se cuentan con pruebas

automatizadas, encargadas de asegurar un mínimo de calidad en el
producto.
166
La entrega continua se puede considerar como una evolución de la integración

continua, ya que ofrece una serie de pasos adicionales centrados en el que el producto
llegue a manos del usuario.
Como viene siendo habitual en DevOps, la automatización es una de las claves para
sustituir un desarrollo tradicional en cascada por estos enfoques más ágiles.
167
¿Qué ventajas tiene la entrega continua?
Las ventajas vienen de la mano de comprender que si finalmente despliegas con mayor
frecuencia, vas a obtener un mayor número de resultados y de feedback.
Es por esto que gracias la práctica de la entrega continua puedes:
▸ Reducir el riesgo de lanzar nuevas versiones: Gracias a la mentalidad de que el

código puede entrar en cualquier momento en producción y se pueden realizar más
pruebas debido a la automatización, los lanzamientos son más seguros y previsibles.
▸ Reducir el tiempo de entrega a producción: En comparación a desarrollos
tradicionales en cascada, se puede obtener el producto mucho antes, por lo que las
nuevas características que implementes llegarán más rápido a los usuarios. En un
mundo tecnológico tan competitivo, esta ventaja es clave para superar a la
competencia.
168
¿Qué ventajas tiene la entrega continua?
▸ Aumentar la calidad de tus productos: La automatización de pruebas ofrece la

gran ventaja de poder comprobar una mayor parte del código en menos tiempo y
con menos esfuerzo. Por eso, puedes recibir el feedback de las pruebas antes,
detectar errores a tiempo, y corregirlos mucho antes de que lleguen a los usuarios
▸ Reducir costes de desarrollo: Y es que un producto (no solo de software) tiene que
ser rentable. Si consigues producir más en menos tiempo, consigues más productos
en menos tiempo, lo que es igual a conseguir más resultados con menos dinero
▸ Usuarios más satisfechos con tu software: Ya que la agilidad en entregarles
nuevas funcionalidades, repercute en agilidad para que ellos te devuelvan
feedback, y por lo tanto, podrás crear productos más adaptados a sus necesidades
▸ Equipos más felices trabajando: Como consecuencia de todo lo anterior (mejores
resultados, más rápido, sin contratiempos) te da una tranquilidad que desemboca
en una gran satisfacción. Y todos trabajamos mejor cuando trabajamos contentos
169
Fases de la entrega continua
El ciclo de vida de la entrega continua contiene 3 fases:

Integración continua
En la integración continua, los equipos de desarrollo integran su
trabajo de forma muy frecuente.
De esta forma, se pueden conseguir builds de forma muy rápida,

que ya incluyen los test unitarios y de integración.
Una vez finalizada esta fase, tenemos un producto sencillo,

pendiente de realizar más pruebas y entregar.
170
Pruebas de aceptación automatizadas

Las pruebas no son exclusivas de la entrega continua, ya se deben haber
realizado pruebas unitarias y de integración.
Pero en este caso se añaden las pruebas de aceptación, que son aquellas que
se confirman que el software cumple los requisitos que nos han solicitado.
Aunque este tipo de pruebas también se puede realizar de forma manual en

fases posteriores, en esta fase se realiza de forma automatizada.
Este tipo de pruebas incluyen las pruebas de interfaz, y se pueden basar en

las historias de usuario para validar que el producto es correcto.
171
Aprobar implementación
Después de acabar con las fases anteriores, ya tenemos un producto «entregable», con
un buen número de pruebas superadas (y si no las ha superado, lo podremos arreglar
antes, que es una de las cosas que más gusta de la entrega continua)
Es entonces el momento de realizar la implementación, de forma manual, en el entorno

que deseemos.
En estos casos, puedes por ejemplo entregar en un entorno de pruebas o preproducción,

para la realización de pruebas manuales, o realizar alguna demostración de producto.
También puedes hacer el despliegue en producción de forma más segura y rápida por
haber hecho un buen trabajo en las fases anteriores.
172
Entrega Continua
La entrega de software no es un simple proceso de entrega a la

producción. Hay una serie completa de ciclos de entregas de
software en múltiples entornos por los que tiene que pasar.
Se llama la línea de entrega. Estos ambientes son:
▸ DEV → Comienza con el entorno de desarrollo
▸ BUILD → El proceso de construcción de software
▸ QA → También esta el entorno de control de calidad y por lo
general hay más de uno en tales ambientes, cada uno para
apoyar cada tipo de entorno que se utiliza para el software que
se entrega
173
Entrega Continua
Otros entornos de pre producción o no producción podrían incluir

➢ SIT (Prueba de Integración del Sistema)
➢ UAT (Prueba de aceptación del usuario), Preproducción y varios otros que
podrían ser útiles en su entrega en función de cómo la organización está
estructurada.
El entorno final en el ciclo de vida es el entorno de producción, donde se ejecuta

el software, el cliente lo utiliza y donde el software realmente debe llegar
El despliegue automatizado es la posibilidad de que el software se despliegue en
cualquier entorno en un momento dado
La entrega continua representa la capacidad de desplegar el software en
cualquier entorno específico en un momento específico.
174
Módulo 9
DevOps , Otras Prácticas
Recomendadas y Frameworks
175
DevOps y Agile
▸ DevOps con Agile es una combinación interesante. Siempre

comienza con un usuario, el cliente, luego algún concepto para
ser llevado al mercado. Esto se conoce como ciclo concepto a
efectivo
▸ Para conseguir esto del usuario al desarrollo, la gente
desarrolla productos, generalmente que responden a los
requisitos del cliente y a sus necesidades
▸ Y a través de las operaciones, Agile te lleva del usuario al
desarrollo y DevOps te lleva desde el desarrollo hasta las
operaciones en las que tendrás algo que realmente puedas
proporcionar a tus clientes
176
DevOps y Agile
DevOps tiene varios componentes, algunos de ellos incluyen:

▸ Fuerte control de los fuentes
▸ Automatización (automatización del software)
▸ Pruebas tempranas y frecuentes
▸ Los pequeños incrementos en la entrega
▸ Mejoras continuas
▸ Equipos cohesivos. Significa trabajar en estrecha colaboración
para producir valor, para sacar productos al mercado
177
DevOps y Agile
Estos componentes pueden sonar familiar si usted es un practicante ágil.

Por ejemplo, en XP/Agile Engineering Practices estos componentes ya
existen:
▸ Test Driven Development (TDD): Similar a las pruebas tempranas y
frecuentes
▸ Pequeñas Entregas: Similar a la entrega de pequeños incrementos
▸ Integración Continua: Similar a la automatización
▸ Equipo Completo: Al igual que el equipo cohesivo o el trabajo en
equipo que sucede entre los desarrolladores y los clientes
▸ Estándares de Codificación: Similar al fuerte control de fuentes
178
DevOps y Agile
Puede utilizar las prácticas de Ingeniería Agile junto con la

capacidad de operar y puede terminar con DevOps
Esta es la capacidad de desarrollar y operar productos y software
de manera rápida para luego llevarlos al mercado
Comienza con un concepto y el objetivo de convertirlo en efectivo
Usted tiene el puente entre los usuarios y los desarrolladores,
Agile y DevOps enlaza desarrolladores y operadores
179
DevOps y Scrum
Scrum fue originalmente formulado para proyectos de

desarrollo de software
Se trata de un marco de trabajo Agile que permite
completar más rápidamente proyectos complejos
Sin embargo, con Scrum las posibilidades son infinitas,
se puede utilizar para cualquier ámbito innovador y
proyecto/tarea compleja. Este marco es muy simple,
pero sin duda debe estar trabajando en la creación de
la cultura DevOps
180
DevOps y Scrum
Al aprender a implementar las prácticas de DevOps junto con las

prácticas de Scrum es necesario decidir cuánto tiempo tomará
cada iteración: se denominan Sprints en Scrum
Cada Sprint es una representación del tiempo necesario para que
el equipo desarrolle y luego pruebe el código. El equipo debe
comprometerse a tener una aplicación ejecutable en cada
conclusión del Sprint
El Sprint de dos semanas es el más común para algunos equipos
Scrum
181
DevOps e ITSM (ITIL)
DevOps e ITIL se necesita mutuamente ¿Por qué? Porque tienen

funciones que benefician a ambos.
DevOps puede proporcionar:

▸ Trabajo colaborativo
▸ Tiempos de despliegue rápido y continuo
▸ Entrega más rápida de funciones
▸ Enfoque en el trabajo importante
▸ Estabilidad en el ambiente
182
ITIL por otro lado, puede proporcionar

➢ Estructura con su ciclo de vida
➢ Relaciones de negocio
➢ Mejor calidad y fiabilidad de los servicios
Aunque DevOps por sí solo, es un proceso ya muy útil, se puede mejorar
cuando une fuerzas con ITIL
Con ITIL y DevOps una organización disfrutará de más beneficios, como
un alcance de servicios más vigoroso, una mejor perspectiva de las
estrategias, mayores perspectivas sobre las mejoras, mejores
perspectivas sobre la actividad de transición y los rigores de los procesos
de diseño de servicios
183
Otra percepción es que ITIL y DevOps no pueden trabajar juntos porque no

son compatibles
Siempre se ha considerado que la organización debe elegir uno y luego

permanecer en ese carril. No es así cómo debería ser
En realidad, hay más sinergias entre estos dos que diferencias. Sin embargo,
muchas organizaciones no se han dado cuenta de esto
Por lo tanto, están perdiendo mucho en las mejoras de servicio, que podrían
introducir y desarrollar con sólo mirar cómo pueden aprovechar y equilibrar
estos marcos
184
Módulo 10
Cultura DevOps
185
Cultura DevOps
El mundo de la tecnología es un entorno en constante cambio y

por lo tanto, el desarrollo de software es justo como este. Entre
estos cambios está la cultura DevOps
No se puede negar que, con el tiempo, el impacto de DevOps ha
crecido significativamente. Específicamente en el entorno de TI de
ritmo rápido y competitivo de hoy
La amplia disponibilidad de herramientas de programación,
idiomas y servicios de software hizo posible crear opciones casi
ilimitadas para los desarrolladores de software en la creación de
aplicaciones innovadoras. Ser el desarrollador y el creador
permite que uno se mantenga ágil
186
Cultura DevOps
Hoy en día, hay una delgada línea entre los roles que los desarrolladores
hacen y ya no basta con tener una sola experiencia
Las pequeñas, medianas y grandes empresas ahora están adoptando esta
nueva cultura DevOps para impulsar sus aplicaciones y programas hacia
adelante y ser capaz de responder rápidamente a los cambios
En la construcción de DevOps hay factores clave a tener en cuenta. En
primer lugar, es importante ser generalista. Ser un experto en un campo
(tecnología o software) simplemente no funciona más
Productos y empresas están cambiando con el tiempo, por lo tanto, es
necesario tener la capacidad de saber cómo trabajar en múltiples áreas y
crear un mejor valor
187
Cultura DevOps
▸ La integración continua también es esencial. Esto significa poder

enviar código directamente a los usuarios. Este es un proceso de
probar el código mientras está en la etapa de desarrollo
▸ También permite a los desarrolladores actuar de inmediato en cuanto
se devuelven los comentarios. Los códigos probados continuamente
son menos propensos a errores, y son más fáciles de liberar también
▸ Otros factores incluyen el monitoreo continuo, el despliegue continuo
(conseguir el nuevo código en el proceso de producción lo más rápido
posible) y la resiliencia (la construcción de aplicaciones resilientes
para que pueda responder a los errores de forma cuidadosa y
exhaustiva)
188
Cultura Orientada en DevOps
▸ Alta cooperación (un solo equipo)

▸ Responsabilidades compartidas y riesgos
▸ Entrenamiento continuo
▸ Comunicadores recompensados
▸ Falla = descubrimiento y mejora
▸ La innovación es continua
▸ Compromiso.
189
Módulo 11
Equipo DevOps
190
Organización tradicional - Legado
Rendimiento, optimización de recursos, estructura y

líneas de reporte, comando y control
CIO
Desarrollo Operaciones Soporte
191
Operadores y Desarrolladores Tradicionales
192
Cambios a realizar en los equipos
193
DevOps Total
194
Roles de los Equipos
▸ Master de Procesos
▸ Master de Servicios
▸ Ingeniero de DevOps
▸ Delivery Managers
▸ Ingeniero de calidad
▸ Equipo de Desarrollo
▸ Equipo de Operación
Fuente Amazon’s “Two Pizzas Rule”
195
Oficina de Gestión de Servicios SMO
La buena gestión del servicio no tiene por qué ser compleja.
Debe centrarse en la experiencia de usuario y en la

generación de valor para el cliente.
La clave del buen funcionamiento de una SMO es entender

cómo los servicios de TI crean valor para sus clientes
196
Oficina de Gestión de Servicios SMO
Una SMO podría manejar las siguientes estructuras:

1. El SMO se encargaría de la gestión del servicio en todas las áreas de la organización.
2. El SMO manejaría el catálogo de SLAs y controlaría los niveles de servicio.
3. El SMO puede ser un área que especifica las políticas y estándares de la gestión de
servicios y entrena a los gerentes de servicio del negocio.
4. O un área que solamente brindaría soporte en la gestión de servicios.
Los objetivos del SMO podrían agruparse en 3 actividades:

1. Controlar y monitorear el ciclo de vida del servicio en la organización
2. Alinear procesos entre el negocio y TI
3. Monitorear la implementación de metodologías de gestión de servicios
197
Módulo 13
Adopción Incremental
198
Un enfoque alternativo para la adopción agresiva de DevOps es una adopción

incremental aunque esto puede tomar más tiempo, representará un riesgo
significativamente menor y garantizará una implementación exitosa
El enfoque comienza con la fijación de objetivos pequeños, como la
implementación de DevOps en aplicaciones individuales mantenidas por un
equipo pequeño de desarrolladores
Una vez que esto se ha hecho con éxito, las lecciones aprendidas se pueden
aplicar para objetivos cada vez más grandes hasta que finalmente hay un
equilibrio saludable entre las mejoras del proceso y la ejecución del proceso
El desafío clave sigue siendo encontrar un balance entre los complejos
entornos de TI de la organización, la velocidad de implementación y el riesgo,
que deben hacerse para que trabajen juntos
199
Por lo tanto, DevOps debe planearse para la mejora continua y no hacer la

implementación de un evento de una sola vez
Una estrategia incremental tiene que preferiblemente ser hecha en un
acercamiento cíclico, escalonado que minimice riesgos y costes de la
adopción de DevOps para construir los conjuntos de habilidades internas
necesarias y el ímpetu para implementar ciclos más grandes y más rápidos
Cada paso se construirá en el paso previo, en materia de inversión y
preparación durante todo el ciclo global
Las horas dedicadas al desarrollo serán realistas para la mayoría de las
empresas y variarán ampliamente de acuerdo con la cultura y la política de
una organización
200
Módulo 13
System Thinking
AGILE CHILE
Te hacemos Ágil
201
System Thinking
Lo más importante es que las organizaciones de DevOps siempre

piensan en términos de Sistemas. Sistemas significa conjuntos de
procesos integrados que trabajan hacia objetivos comunes
Para las organizaciones de DevOps. Sistema significa el negocio como
un todo, no sus departamentos o equipos específicos
Organizar actividades de confianza en el desarrollo del software
implica procedimientos y procesos variados
Los equipos de desarrolladores escriben el código y después los
Testers los prueban y los operadores proporcionan la infraestructura
para ejecutarlos y finalmente los clientes los consumen.
202
System Thinking
Puede haber muchas personas y procedimientos involucrados en este proceso

El pensamiento de Sistemas significa que cada equipo debe ser consciente de
las acciones de todos los demás equipos que trabajan en las líneas de
desarrollo y en última instancia las entregas se realizan al cliente
DevOps define cómo las acciones pueden afectar no solo al equipo sino a todo
el Sistema. Esto significa que los desarrolladores podrían tener una mayor
visibilidad en el ciclo de vida completo de las piezas del código que escriben
Esto también significa tomar conciencia de las posibles ramificaciones de un
cambio en lugar de olvidarse de las modificaciones después de que se hayan
terminados los códigos
203
System Thinking
También significa que los administradores de Sistemas deben entender

completamente el impacto del rendimiento en las aplicaciones una vez que se
liberan a los clientes
El pensamiento sistemático forma un excelente enfoque para pensar también
sobre la culpa
Tradicionalmente, cuando alguien forzaba partes de código hacia la
producción, que causaban interrupciones importantes del servicio, eran
señalados, reprendidos e incluso potencialmente despedidos
Un pensamiento sistemático ha sido capaz de eliminar estas inclinaciones
iniciales para la culpa individual
204
System Thinking
Se trata de no culpar a un individuo que fue lo suficientemente desafortunado

al pulsar el botón, sino al sistema que permitió que esto sucediera
El pensamiento sistemático tratará incidentes como éstos como fallas en el

Sistema
El equipo de DevOps investigará inmediatamente las causas no por personas

que hicieron esto, sino cómo esto podría producirse en absoluto. Se puede
mirar en las causas de por qué las pruebas automatizadas no pudieron atrapar
la falla que lleva al principio de aprendizaje y experimentación.
205
Experimentación y Aprendizaje
Las organizaciones DevOps siempre experimentan y aprenden de

errores anteriores
En un caso en que un desarrollador para el sistema, el incidente se

investigaría a fondo reuniendo a personas apropiadas e
incorporando arreglos para evitar futuras caídas
El incidente sería arreglado así que incluso si alguien hace la

misma cosa otra vez, el sistema lo evitaría.
206
Experimentación y Aprendizaje
La gente aprende de sus errores y la organización permite a todos

experimentar en lugar de obligarlos a centrarse en un conjunto
restringido de tareas
Las organizaciones de DevOps siempre están fomentando la creatividad y
el pensamiento fuera de la caja en lugar de preservar los enfoques de la
mentalidad de las viejas maneras
Esto, naturalmente, animaría a todos a ser humildes, no hay ideas
perfectas todas se podrían desafiar
DevOps ha sido capaz de establecer precedentes en la experimentación
siendo aceptable, incluso si terminan en los fracasos, ya que
eventualmente los fracasos son las mejores maneras de aprender
207
Feedback
AGILE CHILE
Te hacemos Ágil
208
Feedback
Sin ningún tipo de retroalimentación, el aprendizaje sería ineficiente, por lo

que la implementación de DevOps siempre anima a diferentes tipos de
retroalimentación
La retroalimentación ocurre entre los pares en los mismos equipos y entre
negocio en la forma de retroalimentación de los clientes
DevOps mantiene los canales de comunicación abiertos para facilitar la
retroalimentación y permitir una infiltración de los clientes a los niveles de
desarrollo y operación
DevOps alienta el desarrollo rápido y sus ciclos de retroalimentación no son
diferentes
Para proporcionar las características al cliente en el tiempo posible más corto
es crítico que la retroalimentación se reciba lo más pronto posible
209
Feedback
Los enfoques de DevOps han revertido los enfoques tradicionales y los clientes
controlan el desarrollo a través de canales de retroalimentación abiertos
Los clientes son capaces de proporcionar retroalimentación inmediata que es
cribada y priorizada y se convierte en nuevos códigos que se aplican a la
infraestructura para salir a los clientes de nuevo a través de un bucle de
retroalimentación
Es igualmente importante para la participación y la interacción de las personas que
ofrecen la aplicación como los analistas de negocio, ingenieros de red,
desarrolladores, probadores, etc.
Los riesgos de la producción se mitigan con la prueba de conceptos en múltiples
fases y la superación de la resistencia al cambio
Aunque un enfoque de proceso incremental lleva años, los resultados son siempre
transformadores, el punto final es que DevOps es dinámico
210
Módulo 14:
Herramientas para el Apoyo de la
Cultura DevOps
AGILE CHILE
Te hacemos Ágil
211
Herramientas DevOps
El uso de herramientas no es hacer DevOps

▸ Hacer DevOps sin el uso de herramientas es complejo si entendemos que
DevOps tiene componentes de automatización. DevOps es y será un tema
cultural y no será tan solo el conjunto de herramientas
▸ Miremos un ejemplo, las herramientas no hacen cultura, pensemos en una
empresa que desea hacer que sus reuniones internas inicien a tiempo. Si la
compañía compra un software de gestión de reuniones, ¿logrará que las
reuniones inicien a tiempo?
▸ Si la cultura interna es iniciar reuniones tarde, se deberá trabajar en cambiar la
cultura interna primero La herramienta por más buena que sea no logrará
hacer que la cultura cambie
▸ ¿Qué herramientas para DevOps o llamadas DevOps conocen los candidatos a
la Certificación DevOps Essentials? ¿Qué hacen puntualmente esas
herramientas? 212
Herramientas DevOps
Sin herramientas adecuadas, la fusión de roles

y deberes de DevOps puede crear caos y
resultados no deseados que incluyen
problemas relacionados con escalabilidad,
confiabilidad y administración de carga
213
Herramientas DevOps - GIT
▸ GIT fue producido siguiendo los requerimientos de la comunidad Linux para

SCM es decir, el software Source Control Management que podría soportar
sistemas distribuidos
▸ Esta es la herramienta más comúnmente utilizada para el manejo de fuentes
que está disponible hoy en día
▸ Su ventaja consiste en tener grandes características adicionales en las
solicitudes de bifurcación y tracción. Además GitHub también proporciona
plugins que son capaces de conectar Jenkins y facilitar la integración y
despliegue
▸ Las pruebas de velocidad que se ejecutan en una operación de red GIT
generan resultados impresionantes, ya que los protocolos GIT para la
transferencia de datos están altamente optimizados
▸ Sin embargo, con el tiempo, las implementaciones internas de GIT revelan
limitaciones que pueden tener impactos en la velocidad y eficiencia de las
tuberías de entrega
214
Cloud
▸ La automatización de la nube se compone de objetos de automatización

discreta o tareas que realizan cosas como la hilatura de servidores de VM la
instalación de imágenes de SO y el despliegue de aplicaciones y funciones de
red
▸ Las tareas en la automatización de la nube son realizadas por muchas
herramientas de automatización como scripts y herramientas de gestión local
para la gestión de la configuración
▸ La automatización de DevOps utiliza funciones de automatización discreta
como herramientas de integración, compilación y administración continuas
para configuraciones de software
▸ Las orquestas de DevOps son una coordinación automatizada por procesos de
DevOps personalizados en las herramientas y tareas de organización y
automatización que se están llevando a cabo en el proceso
215
Cloud
▸ La infraestructura de la nube juega junto con las herramientas de DevOps para

la automatización y orquestación de despliegues de aplicaciones, además
coordina el apoyo a los procesos deseados
▸ La orquestación va más allá de la simple tracción de la infraestructura de nube
conjuntamente para abarcar tareas de automatización de DevOps en
coordinación con la infraestructura para obtener la orquestación de DevOps
▸ Los desarrolladores que utilizan Docker crean entornos Docker en el portátil
para desarrollar y probar localmente aplicaciones en los contenedores
▸ Dentro de este entorno se realizan ensayos en pilas de servicio compuestas
con múltiples contenedores Docker
▸ Los múltiples contenedores de Docker convergen como pilas de un solo
servicio, como las pilas LAMP y tardan segundos en crear una instancia
216
Docker
▸ Docker aporta portabilidad a las aplicaciones a través de la tecnología

de contenedores, donde las aplicaciones pueden ejecutarse en
unidades autónomas que se mueven a través de las plataformas
▸ Se compone de un motor Docker (una herramienta de tiempo de
ejecución y de embalaje ligero, y un Docker Hub) que son servicios en
la nube para el uso compartido y automatización de flujo de trabajo
▸ Docker ha formado una parte vital de la próxima generación de
pruebas e infraestructura para la gestión de servicios
▸ El aislamiento dependiente y los rápidos arranques de los
contenedores permiten un ciclo de desarrollo más corto y aumentan
las velocidades de prueba en más del 400 %
217
Docker
Algunos entornos pueden ejecutar el host

Docker dentro de otro host Docker (Docker
in Docker) en los entornos de compilación
Docker puede aumentar la velocidad de

una tubería de CI utilizando Union-
FileSystems y Copy on Write (COW)
Para lograr velocidades incrementadas

para dar Entrega Continua (CD) del
software, se pueden usar muchas técnicas
de Docker
218
JS
▸ JS permite la creación sencilla de aplicaciones de red rápidas y

escalables
▸ Las plataformas JS tienen bibliotecas que permiten a las
aplicaciones servir como servidores web sin necesidad de
software como el Apache HTTP Server o el Microsoft IIS sin
tener que hacer que los servidores web acorten las listas de
tareas pendientes de DevOps y optimicen el flujo de código
desde el desarrollo hasta el despliegue. Además, el JavaScript
se puede utilizar tanto en cliente como en servidor
219
JS
▸ Los desarrolladores encuentran una ventaja de eficiencia

debido a la reutilización del código Las aplicaciones NODE JS
pueden ejecutarse en tiempo de ejecución NODE JS en
Microsoft Windows OSX Linux y FreeBSD
▸ Ha sido diseñado para una operación rápida con gran
experiencia del usuario Un modelo de E/S sin bloqueo y
controlado por eventos en NODE JS permite aplicaciones
ligeras que son altamente eficientes
▸ Muchas organizaciones líderes de pensamiento abarcaron
NODE JS como SAP, Groupon, LinkedIn, PayPal y WalMart.
220
Chef
▸ Las herramientas Chef DevOps proporcionan marcos para

automatizar y administrar la infraestructura a través de DSL
simple
▸ El activo real es un código que trae los servidores y servicios
que proporcionan vida
▸ Chef pone una confianza en sus definiciones reutilizables
llamados libros de cocina y recetas escritas en Ruby
▸ Este nivel de abstracción aumenta la productividad y permite a
los desarrolladores crear fácilmente configuraciones
personalizadas para aplicaciones
221
Chef
▸ Las recetas se ejecutan de forma independiente mediante el

uso de CHEF SOLO o un servidor que tenga CHEF SERVER que
actúe como hubs para los datos de configuración
▸ Los servidores almacenan libros de cocina o políticas
aplicadas a los nodos y los metadatos que describen el nodo
registrado administrado por chef client
▸ Chef es una herramienta de gestión multi plataforma para
Windows Linux Mac OS etc y puede integrarse con los
principales proveedores de cloud
222
Jenkins
▸ Este es un motor para la integración extensible y continua que se

utiliza como una de las principales herramientas de los ingenieros de
DevOps que desean monitorear repetidas ejecuciones de trabajo
▸ Con Jenkins el ingeniero de DevOps encuentra más fácil integrar los
cambios en los proyectos y puede acceder a las salidas fácilmente
cuando encuentran que algo va mal
Las características clave son sus enlaces

permanentes, la integración de RSS correo
electrónico/mensajería instantánea, un
etiquetado después de los hechos, su informe
de prueba Junit TestNG y las compilaciones
distribuidas
223
Puppet
▸ Puppet permite la gestión de la configuración y del software durante la

realización de cambios rápidos y repetibles Puppet impone automáticamente
la coherencia en entornos y puede trabajar en máquinas físicas y virtuales
▸ Tiene cadenas de herramientas comunes y respalda las mejores prácticas
clave en DevOps que incluyen la entrega continua
▸ Puppet Enterprise ofrece la orquestación de centros de datos mediante la
automatización de la configuración y gestión de las máquinas y software
▸ También existen versiones de Puppet de fuente abierta disponibles que han
sido utilizadas por la Universidad de Stanford para colmar las lagunas en el
desarrollo de software para su servicio de biblioteca digital y administración
del sistema, necesarias para mantener los servicios funcionando de manera
segura
224
Referencias
225
Referencias
▸ Libro “Proyecto Phoenix”

▸ Libro “Devops Handbook”
▸ Libro “Lean Devops”
▸ Agile Manifiesto
▸ Scrum Guide
▸ ITSM – Itil
▸ Kanban Guide
▸ Libro “La máquina que cambió al mundo”.
226
Devops Essentials

Curso Devops Essentials - Alumno

Cargado por

Copyright:

Formatos disponibles

Curso Devops Essentials - Alumno

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Curso Devops Essentials - Alumno

Cargado por

Copyright:

Formatos disponibles

Devops Essentials

Requisitos para la Certificación

Detalles del Examen

▸ Modulo 1: ¿Qué es la Agilidad?

▸ Modulo 8: Entrega continua

Agilidad es la capacidad de crear y

Es una forma de lidiar y, en última

Los autores del Manifiesto Ágil eligieron

➢ El 80% de los proyectos emplearán Métodos Ágiles en los

➢ Casi tres cuartas partes (71%) de las organizaciones

➢ Los proyectos ágiles son 28% más exitosos que aquellos

➢ El 50% de los miembros de los equipos están más

• Análisis • Análisis • Análisis • Análisis • Análisis

✓ Enfoque en las personas

Nuestra mayor prioridad es satisfacer al Los responsables de negocio y los

Aceptamos que los requisitos

Entregamos software funcional El método más eficiente y efectivo de

Ágil Chile - 2021

La simplicidad, o el arte de maximizar

Los procesos Ágiles promueven el

La atención continua a la excelencia A intervalos regulares el equipo

Ágil Chile - 2021

Ágile cuenta con Marcos Ágiles de Desarrollo, tales como:

Todos se caracterizan por aspectos fundamentales como:

LEAN (TPS – Toyota Production System)

▸ LEAN permite alcanzar resultados inmediatos en

▸ LEAN se enfoca en incrementar tal valor eliminando

Las principales reglas de Kanban

DevOps es una contracción de "Desarrollo" y "Operaciones".

DevOps es una nueva tendencia en la industria TI dirigida a mejorar la agilidad

No existe una sola herramienta de DevOps que trabaje en la colaboración e

Se utilizan una cadena de herramientas DevOps que consiste en un número de

¿Cuál es el problema? Comunicación tradicional sobre Desarrollo y Operaciones

No existe un acuerdo claro y universal sobre su

Hay varias opiniones sobre qué es y qué no es DevOps

DevOps no es una estrategia para todos

No todas las organizaciones están preparadas para utilizar

DevOps implica automatización. DevOps es más que

DevOps no es una herramienta implementada.

DevOps no es equipo de trabajo nuevo y separado de las demás

Nos referimos a DevOps como el resultado de la aplicación de

Una mezcla de patrones destinados a mejorar la colaboración entre

Un movimiento de personas quienes se preocupan por desarrollar y

DevOps es una cultura o un movimiento profesional

“No importa lo que parezca a simple

Jerry Weinberg, Secrets of Consulting:

Peter Ferdinand Drucker fue consultor y

Es central, para lograr una

▸ DevOps plantea un enfoque

▸ Diseñar buenos productos, escribir buen código,

Él demostró que podía haber mejores maneras de obtener un gran trabajo al

También señalaron que la única manera de construir y desplegar un software

Inspirado por esto, Debois organizó su propia conferencia (DevOpsDay) El

En una encuesta realizada por Puppet Labs, 16% de 1486 encuestados

DevOps garantiza un tiempo más rápido de comercialización de los plazos de

Fundamentalmente, DevOps es una aplicación del concepto de desarrollo

DevOps trae el mayor beneficio al mejorar la colaboración entre el

Hoy en día, los equipos de desarrollo deben dividir sus silos

DevOps mejora la agilidad ya que ofrece un entorno de colaboración,