WEBVTT

1
00:00:10.139 --> 00:00:11.742
[Orador 1]: Buenas tardes a todos.

2
00:00:11.942 --> 00:00:14.828
Como Luis ha dicho, me llamo Carlos.

3
00:00:15.028 --> 00:00:17.593
Tenéis mi correo en la presentación,
podéis anotarlo si queréis.

4
00:00:17.793 --> 00:00:21.620
Si no, pues Luis lo puede facilitar sin
mayor problema.

5
00:00:21.820 --> 00:00:26.807
Bueno, yo por presentarme, yo en
Microfocus soy líder de ventas a nivel

6
00:00:26.807 --> 00:00:28.974
EMEA para lo que es Microfocus.

7
00:00:29.174 --> 00:00:34.241
Líder de ventas consiste en un individuo
que intenta ayudar a la fuerza de ventas a

8
00:00:34.241 --> 00:00:39.371
vender los productos de la compañía de una
forma estructurada, a ser posible exitosa

9
00:00:39.371 --> 00:00:41.782
y ayudarnos a ganar dinero entre todos.

10
00:00:41.982 --> 00:00:44.945
Entonces, bueno, llevo trabajando en el
grupo de ADM.

11
00:00:45.145 --> 00:00:49.196
El grupo de ADM es un grupo dentro de
Micro Focus que se llama Application

12
00:00:49.196 --> 00:00:53.581
Delivery Management e incluye todos los
productos que tienen que ver con DevOps,

13
00:00:53.581 --> 00:00:57.355
ciclo de vida de desarrollo software,
pruebas funcionales, pruebas de

14
00:00:57.355 --> 00:01:01.129
rendimiento, automatización de
despliegues, monitorización, etcétera,

15
00:01:01.129 --> 00:01:02.129
etcétera, etcétera.

16
00:01:02.304 --> 00:01:06.976
En fin, soluciones que tienen que ver con
lo que damos en llamar DevOps de una forma

17
00:01:06.976 --> 00:01:07.976
o de otra.

18
00:01:07.930 --> 00:01:09.272
Llevo en Micro Focus cuatro años.

19
00:01:09.472 --> 00:01:14.310
Empecé como director técnico de España,
Portugal y América Latina, lo cual me dio

20
00:01:14.310 --> 00:01:18.423
grandes momentos en América Latina también
y grandes viajes de avión.

21
00:01:18.623 --> 00:01:22.467
Y bueno, básicamente ahora mi ámbito es
menor, es Europa, África.

22
00:01:22.667 --> 00:01:27.129
Yo siempre aquí digo, si tenéis una línea
desde Vladivostok hasta Irlanda, luego

23
00:01:27.129 --> 00:01:31.649
hasta Suráfrica y hasta Middle East, pues
más o menos es donde estamos trabajando

24
00:01:31.649 --> 00:01:32.649
con esta parte, ¿no?

25
00:01:32.759 --> 00:01:36.650
Micro Focus es una compañía no muy
conocida en el mundo, no sé cuántos de

26
00:01:36.650 --> 00:01:40.973
vosotros es una compañía que os suena,
pero Micro Focus es una compañía que es la

27
00:01:40.973 --> 00:01:45.296
séptima por ingresos en el mundo de puro
software, es decir, solamente fabricamos

28
00:01:45.296 --> 00:01:49.400
software, vendemos software y soportamos
software, que es el lema de Micro Focus.

29
00:01:49.600 --> 00:01:55.550
nuestro CEO, hacemos unos 4.400 millones
por ingreso, somos unas 15.000 personas y

30
00:01:55.550 --> 00:01:57.854
tenemos unos 40.000 clientes.

31
00:01:58.054 --> 00:02:02.862
Esto para daros una idea de dónde estamos
operando en este mercado.

32
00:02:03.062 --> 00:02:06.581
Soy diplomado universitario por la
Universidad de Málaga en el año 93, por

33
00:02:06.581 --> 00:02:10.294
cierto que mi proyecto fin de carrera fue
de redes neuronales artificiales con

34
00:02:10.294 --> 00:02:11.294
conexionado recurrente

35
00:02:11.335 --> 00:02:15.847
Algo muy al tanto de lo que ha dicho
Alejandro anteriormente y por el cual me

36
00:02:15.847 --> 00:02:20.359
siento muy orgulloso y fue un proyecto
magnífico que nadie más siguió, por lo

37
00:02:20.359 --> 00:02:23.860
tanto, bueno, me valió a mí y poco más, no
valió para nada más.

38
00:02:24.060 --> 00:02:27.980
Bueno, hoy he pasado por un montón de
compañías, empezando por el mainframe,

39
00:02:27.980 --> 00:02:30.542
como decía Luis al principio y terminando
pues por

40
00:02:30.742 --> 00:02:35.425
esta actividad que hago ahora, que
básicamente me convierte en un buen

41
00:02:35.425 --> 00:02:38.376
periodista tecnológico más que en otra
cosa.

42
00:02:38.576 --> 00:02:41.958
Entonces, yo lo que aspiro con la
presentación de hoy es que cuando nos

43
00:02:41.958 --> 00:02:45.920
vayamos por esa puerta, todo el mundo al
menos sepa en qué consiste esto de DevOps,

44
00:02:45.920 --> 00:02:49.834
por qué es importante para la industria,
en qué momento estamos y cómo se aplica a

45
00:02:49.834 --> 00:02:50.897
las grandes compañías.

46
00:02:51.097 --> 00:02:55.078
Con que eso sea así, yo estaría contento.

47
00:02:55.278 --> 00:02:58.899
Entonces vamos a ver estos cinco puntos,
en qué consiste, antecedentes,

48
00:02:58.899 --> 00:03:03.090
referencias, que es una parte que siempre
me gusta mucho porque hablo de la teoría

49
00:03:03.090 --> 00:03:07.436
de las limitaciones, os pido que levantéis
la mano, nadie la levanta y entonces yo me

50
00:03:07.436 --> 00:03:09.661
explayo, es una cosa que es muy
interesante.

51
00:03:09.861 --> 00:03:14.395
Luego hablaremos de las prácticas de
DevOps y qué hacemos con métricas, que es

52
00:03:14.395 --> 00:03:18.341
muy importante, y el concepto también en
el cual mi compañía apuesta

53
00:03:18.341 --> 00:03:21.521
fundamentalmente, que es el DevOps a nivel
empresarial.

54
00:03:21.721 --> 00:03:27.311
porque DevOps es una forma de intentar
hacer que los equipos de desarrollo y los

55
00:03:27.311 --> 00:03:32.701
equipos de operación convivan y trabajen
juntos de una forma lo más armoniosa

56
00:03:32.701 --> 00:03:38.158
posible para conseguir un objetivo común y
esto es algo que visto a una escala

57
00:03:38.158 --> 00:03:44.015
pequeña funciona conceptualmente muy bien,
visto a la escala de un banco grande o de

58
00:03:44.015 --> 00:03:45.652
una organización grande

59
00:03:45.852 --> 00:03:51.060
puede llegar a ser un cóctel que puede
abonar un caos importante.

60
00:03:51.260 --> 00:03:57.260
Entonces estos matices y daros esta idea
de en qué momento estamos en la adopción

61
00:03:57.260 --> 00:04:01.594
de DevOps a nivel empresarial es también
importante.

62
00:04:01.794 --> 00:04:07.794
La cosa consiste en transformar una idea,
un concepto que tiene una compañía o un

63
00:04:07.794 --> 00:04:10.813
equipo de una compañía en dinero.

64
00:04:11.013 --> 00:04:13.057
Digo dinero para simplificar las cosas.

65
00:04:13.257 --> 00:04:18.506
Podría decir valor si fuera una compañía
tipo ONG o tipo, digamos, de punto de

66
00:04:18.506 --> 00:04:23.376
vista organización estatal o lo que sea,
servicio al ciudadano, lo que sea.

67
00:04:23.576 --> 00:04:28.536
Al final es, ¿cuán rápido soy de
transformar una idea que tengo a través de

68
00:04:28.536 --> 00:04:30.810
un conjunto de aplicaciones en valor?

69
00:04:31.010 --> 00:04:35.529
Entonces, lo que vemos, que esta
definición, que es la que más me gusta a

70
00:04:35.529 --> 00:04:40.677
mí, es, si alguno pensaba que iba a venir
aquí a ver cosas tecnológicas muy chulas,

71
00:04:40.677 --> 00:04:45.510
lo siento, esto realmente es un problema
de organización del trabajo, es donde

72
00:04:45.510 --> 00:04:47.111
tenemos el verdadero retorno.

73
00:04:47.311 --> 00:04:51.514
Y como decía Luis, que también participé
de ITSMF, lo malo que tiene también DevOps

74
00:04:51.514 --> 00:04:54.641
es que no hay un cuerpo de conocimiento
muy bien estructurado.

75
00:04:54.841 --> 00:04:59.130
O sea, que tú cuando puedes leer, hablas
de ITIL, y algunos de vosotros habéis

76
00:04:59.130 --> 00:05:03.531
estado en ITSMF hoy, hay una cosa que se
llama ITIL V3, que para mi gusto es una

77
00:05:03.531 --> 00:05:07.988
patata, ITIL V2, que está muy bien, y a
partir de ahí te lo lees, lo estudias, te

78
00:05:07.988 --> 00:05:10.662
certificas, y oye, eres alguien en este
mundillo.

79
00:05:10.862 --> 00:05:14.817
Con DevOps lo que hay es un conjunto de
mejores prácticas, una bibliografía

80
00:05:14.817 --> 00:05:15.817
bastante...

81
00:05:15.728 --> 00:05:20.705
amplia, con muchos autores distintos, pero
no hay un instituto que esté recibo y que

82
00:05:20.705 --> 00:05:24.724
esté emitiendo unos certificados creíbles
y reconocidos en este ámbito.

83
00:05:24.924 --> 00:05:29.049
Entonces, bueno, realmente adoptar DevOps
es adoptar un conjunto de prácticas y un

84
00:05:29.049 --> 00:05:31.315
sentido común, razonable, que es de lo que
trata.

85
00:05:31.515 --> 00:05:34.440
A mí la definición me gusta leerla, porque
si no, ¿para qué las escribes?

86
00:05:34.640 --> 00:05:36.463
Entonces, las voy a leer.

87
00:05:36.664 --> 00:05:39.407
Voy a leer tres cosas, por lo cual esta es
la primera de ellas.

88
00:05:39.607 --> 00:05:42.671
Modelo de organización del trabajo para el
desarrollo y operación de aplicaciones.

89
00:05:42.871 --> 00:05:45.735
Desarrollo y operación de aplicaciones.

90
00:05:45.935 --> 00:05:49.039
Ojo, que estamos teniendo la idea, pero
también estamos operando la idea.

91
00:05:49.239 --> 00:05:53.778
No nos quedamos solamente en entregarle la
idea a otro para que acabe quedándose con

92
00:05:53.778 --> 00:05:54.778
el problema.

93
00:05:54.806 --> 00:05:59.018
Es desarrollo y operación que pretende
poner a disposición del usuario software

94
00:05:59.018 --> 00:06:02.255
de alta calidad, y aquí meto dentro del
concepto de alta calidad,

95
00:06:02.455 --> 00:06:06.670
todo lo que podáis imaginar en estos
términos es decir, tú cuando le das a la

96
00:06:06.670 --> 00:06:10.997
aplicación y le das para que sume 2 y 2
suma y suma 4 pero además lo hace en un

97
00:06:10.997 --> 00:06:15.380
tiempo razonable y además lo hace de una
manera en que el usuario no necesita un

98
00:06:15.380 --> 00:06:19.540
manual de usuario para sumar 2 y 2 y
además si resulta que eres daltónico lo

99
00:06:19.540 --> 00:06:20.497
ves

100
00:06:20.697 --> 00:06:25.682
Y si tienes que levantar la aplicación, no
tarda 32 segundos en que aquello te dé un

101
00:06:25.682 --> 00:06:27.965
panel para que puedas sumar dos y dos.

102
00:06:28.165 --> 00:06:32.296
Y además, cuando alguien intenta hackearlo
desde fuera, el sistema se defiende lo

103
00:06:32.296 --> 00:06:35.033
suficientemente bien como para que eso no
sea posible.

104
00:06:35.233 --> 00:06:39.483
Es decir, hay conceptos de usabilidad, hay
conceptos de rendimiento, hay conceptos de

105
00:06:39.483 --> 00:06:43.329
calidad funcional, por supuesto, hay
conceptos de seguridad imbuido dentro de

106
00:06:43.329 --> 00:06:45.404
lo que sería el concepto de alta calidad.

107
00:06:45.604 --> 00:06:47.868
Pero además, lo más rápidamente posible.

108
00:06:48.068 --> 00:06:53.658
Y claro, esto pasa, podéis preguntar, ¿por
qué esto de lo más rápidamente posible?

109
00:06:53.858 --> 00:06:58.312
A nivel empresarial lo que sucede es que
muchas veces la ganancia de velocidad o de

110
00:06:58.312 --> 00:07:02.387
rapidez que puede tener una empresa de un
determinado tamaño es una ganancia

111
00:07:02.387 --> 00:07:03.387
determinada.

112
00:07:03.374 --> 00:07:06.679
A mí me gusta llamarle el DevOps de lo
posible.

113
00:07:06.879 --> 00:07:09.384
Es decir, yo tengo una organización que
produce y opera software

114
00:07:09.584 --> 00:07:13.148
Y va a mejorar un 15% con respecto a lo
que antes hacía.

115
00:07:13.348 --> 00:07:14.209
No está ni tan mal.

116
00:07:14.409 --> 00:07:17.508
No hay que buscar otro tipo de referencias
que no sean más que las referencias

117
00:07:17.508 --> 00:07:18.313
internas.

118
00:07:18.513 --> 00:07:20.455
Esto es algo que también es importante.

119
00:07:20.655 --> 00:07:24.654
Hay otras definiciones, que hay un montón
de ellas que os dejo, y casi todas os

120
00:07:24.654 --> 00:07:28.757
están evocando o evocan a un conjunto de
prácticas de principio y de una cosa muy

121
00:07:28.757 --> 00:07:30.526
interesante que es el cambio cultural.

122
00:07:30.726 --> 00:07:32.448
Y ahora veréis por qué hablo de esto, del
cambio cultural.

123
00:07:32.648 --> 00:07:36.665
El cambio cultural en el ámbito de DevOps
es tremendamente importante porque implica

124
00:07:36.665 --> 00:07:37.665
cambiar un paradigma

125
00:07:37.613 --> 00:07:42.167
estático en el cual hay un departamento de
desarrollo que tiene un equipo de

126
00:07:42.167 --> 00:07:45.750
desarrollo que tiene una misión que es
entregar aplicaciones

127
00:07:45.950 --> 00:07:50.300
Y hay otro equipo de operación que tiene
otro equipo específico que tiene una

128
00:07:50.300 --> 00:07:53.621
misión que es contradictoria, que es
operar con fiabilidad.

129
00:07:53.821 --> 00:07:56.785
Cada vez que hay un cambio, se produce un
potencial error.

130
00:07:56.985 --> 00:07:58.928
Entonces, ¿qué quiere el departamento de
operación?

131
00:07:59.128 --> 00:07:59.809
No tener cambios.

132
00:08:00.009 --> 00:08:01.632
¿Qué es lo que quiere el departamento de
desarrollo?

133
00:08:01.832 --> 00:08:04.259
Cambiar lo más rápidamente posible para
dar cobertura a las necesidades del

134
00:08:04.259 --> 00:08:04.916
negocio.

135
00:08:05.116 --> 00:08:06.819
Y en todo esto, ¿qué tienes?

136
00:08:07.019 --> 00:08:10.216
Pues una organización que tiene una
estructura determinada y que le pasan por

137
00:08:10.216 --> 00:08:13.414
la izquierda startups y por la derecha
otras grandes compañías que sí que han

138
00:08:13.414 --> 00:08:15.669
invertido en el modelo y están haciendo
sus experimentos.

139
00:08:15.869 --> 00:08:20.409
Entonces el estrés que provoca la no
adecuación a un modelo más ágil, más

140
00:08:20.409 --> 00:08:22.499
rápido, es un estrés muy importante.

141
00:08:22.699 --> 00:08:27.482
Y esto por ello DevOps siempre se define
en términos de un camino, de un modelo en

142
00:08:27.482 --> 00:08:32.029
el cual estás en una situación actual y
tienes que ir a una situación futura y

143
00:08:32.029 --> 00:08:36.635
tienes que hacer X cosas para que eso
suceda, etc. Y un conjunto de adopción de

144
00:08:36.635 --> 00:08:41.006
mejores prácticas, pero siempre con la
idea de tener un camino más rápido y

145
00:08:41.006 --> 00:08:42.006
siendo más rápido.

146
00:08:42.089 --> 00:08:43.395
Y todo esto...

147
00:08:43.595 --> 00:08:48.441
para compañías y al menos a nivel
empresarial que llevan 20 años, 40 años

148
00:08:48.441 --> 00:08:50.888
operando con un sistema determinado.

149
00:08:51.088 --> 00:08:54.785
Yo siempre he trabajado en mejora de
procesos durante mucho tiempo, he

150
00:08:54.785 --> 00:08:59.179
trabajado en CMMI, he trabajado en ETIL,
he trabajado en ISO 20000, he trabajado en

151
00:08:59.179 --> 00:09:02.983
modelos de estos que llegan, tienen un
hype, luego caen y luego viene el

152
00:09:02.983 --> 00:09:04.733
siguiente modelo cada cierto tiempo.

153
00:09:04.933 --> 00:09:07.458
Ahora tenemos DevOps y Agile lo tuvimos
hace algún tiempo.

154
00:09:07.658 --> 00:09:11.819
Entonces, lo que te das cuenta es que
muchas veces llegas a clientes, nosotros

155
00:09:11.819 --> 00:09:14.684
lo hacemos, y ya hablamos de DevOps y nos
dicen, otro.

156
00:09:14.884 --> 00:09:16.686
Porque vienen a dar doctrina.

157
00:09:16.886 --> 00:09:21.807
Mira qué malo eres, que no estás haciendo
algo que deberías estar haciendo y esto va

158
00:09:21.807 --> 00:09:22.791
en contra tuya.

159
00:09:22.991 --> 00:09:26.652
Y claro, los departamentos de operación,
sobre todo, son bastante renuentes a

160
00:09:26.652 --> 00:09:30.218
escuchar a determinados cantamañanas que
llegamos a contar estas historias.

161
00:09:30.418 --> 00:09:34.127
Porque lo que dicen es, yo llevo 20 años
aquí, yo no sé dónde vas a estar tú dentro

162
00:09:34.127 --> 00:09:35.943
de 20 años, pero yo creo que tengo una
noción.

163
00:09:36.143 --> 00:09:39.407
Entonces, todo esto es válido, todo este
concepto es válido.

164
00:09:39.607 --> 00:09:43.999
Y yo siempre les digo, acercarse a DevOps
con un modelo humilde y dentro del DevOps

165
00:09:43.999 --> 00:09:47.837
de lo que pueda llegar a ser posible para
cada organización en cada momento.

166
00:09:48.037 --> 00:09:50.500
Que igual no es lo que necesita, pero sí
lo que puede tragar.

167
00:09:50.700 --> 00:09:54.605
Porque tú muchas veces lo que no puedes
hacer es coger y plantear una revolución

168
00:09:54.605 --> 00:09:58.363
absoluta y hacer que la gente, bueno,
acabe teniendo rescisión de contratos y

169
00:09:58.363 --> 00:09:59.363
demás.

170
00:09:59.310 --> 00:10:02.906
Hay que hacer siempre las cosas un poquito
más, digamos, dentro de lo que sería el

171
00:10:02.906 --> 00:10:03.795
modelo posible.

172
00:10:03.995 --> 00:10:05.306
¿Mejorar qué?

173
00:10:05.506 --> 00:10:10.836
Pues bueno, hablamos de... ¿para cuántos
de vosotros un modelo waterfall tiene

174
00:10:10.836 --> 00:10:12.034
sentido?

175
00:10:12.257 --> 00:10:13.257
Una persona.

176
00:10:13.138 --> 00:10:19.329
[Orador 6]: ¿No sabéis lo que es un modelo waterfall
de desarrollo de software?

177
00:10:19.529 --> 00:10:20.651
[Orador 1]: ¿Sí?

178
00:10:20.851 --> 00:10:24.949
Entonces sois tímidos, no levantéis la
mano porque realmente no os suena o porque

179
00:10:24.949 --> 00:10:26.077
lo habéis olvidado ya.

180
00:10:26.740 --> 00:10:31.306
Bueno, un modelo waterfall lo que hace es
poner en producción cosas que se

181
00:10:31.306 --> 00:10:32.745
imaginaron hace un año.

182
00:10:32.945 --> 00:10:34.968
Es un resumen que a mí me encanta.

183
00:10:35.168 --> 00:10:40.928
Tú dices, yo imagino algo, lo pongo en un
papel, el papel es totémico, este papel es

184
00:10:40.928 --> 00:10:46.622
el plan, y en ese plan, con un conjunto de
requisitos específicos, estructurados de

185
00:10:46.622 --> 00:10:52.315
una manera determinada, tengo una serie de
etapas, hago un proyecto, un concepto de

186
00:10:52.315 --> 00:10:56.876
proyecto, y un año después, más o menos,
pongo algo en producción.

187
00:10:57.076 --> 00:11:02.758
Esto, como podéis imaginar, en los tiempos
de las apps no funciona demasiado bien, no

188
00:11:02.758 --> 00:11:04.167
encaja demasiado bien.

189
00:11:04.367 --> 00:11:05.367
¿Por qué?

190
00:11:04.728 --> 00:11:09.894
Porque realmente no tengo la capacidad de
innovar, no tengo capacidad de acercarme a

191
00:11:09.894 --> 00:11:14.438
mi cliente y tener, poder, antes
hablábamos de inteligencia artificial, la

192
00:11:14.438 --> 00:11:16.866
inteligencia artificial necesita datos.

193
00:11:17.066 --> 00:11:20.955
Si no eres capaz de recoger esos datos y
luego en base a esos datos que recoges

194
00:11:20.955 --> 00:11:24.894
tomar nuevas decisiones y volver a poder
hacer nuevas propuestas a tus clientes,

195
00:11:24.894 --> 00:11:26.323
estás congelado en el tiempo.

196
00:11:26.523 --> 00:11:30.424
Entonces, realmente este modelo es donde
están muchos de los clientes que están

197
00:11:30.424 --> 00:11:31.595
evolucionando hacia DevOps.

198
00:11:31.795 --> 00:11:35.909
Pero dicho eso, este modelo se adapta bien
a lo que sería un modelo organizativo

199
00:11:35.909 --> 00:11:38.410
dentro de tecnologías de la información en
silos.

200
00:11:38.610 --> 00:11:41.797
Es decir, departamento de desarrollo está
ahí, tienen una misión,

201
00:11:41.997 --> 00:11:45.567
cogen, lo decía en la descripción de la
ponencia, cogen al cerdo, una vez que ya

202
00:11:45.567 --> 00:11:48.820
se ha terminado, lo lanzan por encima de
la tapia y ahora es tu problema,

203
00:11:48.820 --> 00:11:50.086
departamento de operaciones.

204
00:11:50.286 --> 00:11:53.969
Y el departamento de operaciones coge ese
animal, tu yido por lo general, y empieza

205
00:11:53.969 --> 00:11:57.653
a intentar hacer que aquello funcione en
los nuevos entornos y empezamos a escuchar

206
00:11:57.653 --> 00:12:01.202
cosas como, ay, pero esto funciona en
desarrollo, pero no funciona en operación,

207
00:12:01.202 --> 00:12:02.820
o en producción, o en preproducción.

208
00:12:03.020 --> 00:12:06.306
Y esto siempre lo hacemos porque, claro,
aquí veis que el tiempo parece lineal,

209
00:12:06.306 --> 00:12:07.306
¿no?

210
00:12:07.124 --> 00:12:10.556
Las etapas están organizadas en el tiempo
y la distancia entre las distintas etapas

211
00:12:10.556 --> 00:12:12.255
en el eje de las X es más o menos estable.

212
00:12:12.455 --> 00:12:13.658
Esto es mentira.

213
00:12:13.858 --> 00:12:17.707
Realmente, el tiempo corre mucho más lento
en la parte izquierda y corre mucho más

214
00:12:17.707 --> 00:12:18.990
rápido en la parte derecha.

215
00:12:19.190 --> 00:12:21.965
O sea, cuando estás llegando a la fase de
prueba, integración y puesta en

216
00:12:21.965 --> 00:12:22.965
producción,

217
00:12:22.717 --> 00:12:27.151
Ahí los calendarios están ya tan
comprimidos que empezamos a levantar

218
00:12:27.151 --> 00:12:32.303
salvaguardas, a hacer menos pruebas, a
tener más prisa porque tenemos una frecha

219
00:12:32.303 --> 00:12:37.455
comprometida y ahí se producen realmente
situaciones de estrés que acaban con el

220
00:12:37.455 --> 00:12:39.257
cerdo muy tullido, muy tullido.

221
00:12:39.457 --> 00:12:43.732
Entonces, bueno, esto se adecua bien en
general para lo que serían modelos

222
00:12:43.732 --> 00:12:47.773
organizativos de DevOps por separado y un
modelo lento por naturaleza.

223
00:12:48.014 --> 00:12:50.539
Claro, si tú eres lento y te va bien, pues
fantástico.

224
00:12:50.739 --> 00:12:52.623
Oye, eres lento, te va bien, no hay ningún
problema.

225
00:12:52.823 --> 00:12:54.366
Pero, ¿qué sucede a día de hoy?

226
00:12:54.566 --> 00:12:56.490
Ahora sucede, por ejemplo, eso lo veis en
el sector financiero.

227
00:12:56.690 --> 00:13:00.418
El sector financiero es un claro adoptante
de DevOps.

228
00:13:00.618 --> 00:13:05.087
En modelos híbridos, porque esto no
desaparece, esto simplemente se mitiga y

229
00:13:05.087 --> 00:13:09.616
se queda en un determinado sistema, un
sistema que luego veremos que llamamos

230
00:13:09.616 --> 00:13:14.145
sistemas de registro, que son los sistemas
de toda la vida donde realmente la

231
00:13:14.145 --> 00:13:18.693
operación está residiendo y donde está la
lógica de negocio del negocio más core.

232
00:13:18.893 --> 00:13:22.857
Pero los sistemas que son más de
compromiso o de engagement con el cliente,

233
00:13:22.857 --> 00:13:24.565
ahí funciona muy mal este modelo.

234
00:13:24.765 --> 00:13:28.476
Entonces necesitas un modelo mucho más
rápido que sea capaz de consumir toda la

235
00:13:28.476 --> 00:13:32.330
información que te puedan dar los sistemas
que se han mantenido y se mantienen con

236
00:13:32.330 --> 00:13:33.282
este modelo legado.

237
00:13:33.482 --> 00:13:35.046
Bien.

238
00:13:35.246 --> 00:13:38.420
Claro, Operación está contento con esto
por lo general.

239
00:13:38.620 --> 00:13:39.902
con el número de puestas en producción.

240
00:13:40.143 --> 00:13:42.927
No está demasiado contento con la calidad
de lo que se pone en producción.

241
00:13:43.127 --> 00:13:47.168
Tenemos algunos clientes dentro de Micro
Focus que dicen que esto de DevOps, que no

242
00:13:47.168 --> 00:13:51.160
lo quieren ni ver, que lo que quieren es
tener una hojita donde venga lo que tengo

243
00:13:51.160 --> 00:13:54.627
que poner en producción y el trabajo de
desarrollo es que aquello no falle.

244
00:13:54.827 --> 00:14:00.647
Y claro, eso nunca pasa y al final siempre
acabas teniendo errores en producción que

245
00:14:00.647 --> 00:14:02.602
acabas de intentar evitar

246
00:14:02.802 --> 00:14:07.130
De alguna manera, llamando a la gente de
desarrollo que vaya allí a tu consola a

247
00:14:07.130 --> 00:14:11.678
las 4 de la mañana y de esto sabemos algo,
a poder arreglar aquello porque, bueno, y

248
00:14:11.678 --> 00:14:12.813
esto es algo que sucede.

249
00:14:13.013 --> 00:14:17.699
Muchas veces esto también pasa porque las
puestas en operación en este modelo son

250
00:14:17.699 --> 00:14:19.340
puestas en operación únicas.

251
00:14:19.540 --> 00:14:21.542
El concepto de único es un concepto muy
interesante.

252
00:14:21.742 --> 00:14:26.513
Si tú repites una puesta, un cambio de
entorno con la misma estrategia 27 veces,

253
00:14:26.513 --> 00:14:28.870
la número 28 es muy probable que funcione.

254
00:14:29.070 --> 00:14:31.931
Ahora, si tú haces un cambio de entorno
una vez,

255
00:14:32.131 --> 00:14:33.534
es probable que vaya mal.

256
00:14:33.734 --> 00:14:35.357
Si lo haces dos veces, a lo mejor aprendes
algo.

257
00:14:35.557 --> 00:14:39.318
A partir de la tercera se puede decir que
tienes alguna oportunidad de que el cambio

258
00:14:39.318 --> 00:14:42.629
de entorno funcione y que controles todas
las variables entre una cosa y otra.

259
00:14:42.829 --> 00:14:45.033
Entonces, es un concepto muy de sentido
común, ¿verdad?

260
00:14:45.253 --> 00:14:52.165
Pero es algo que en este tipo de modelo no
se usa, no se da.

261
00:14:52.365 --> 00:14:55.167
Una magnífica slide en blanco.

262
00:14:57.545 --> 00:14:58.687
Al final, este tipo de coches funcionan.

263
00:14:58.887 --> 00:15:00.129
No sé si alguno de vosotros ha estado en
Cuba.

264
00:15:00.329 --> 00:15:02.872
Es un verdadero museo de los coches de los
años 50.

265
00:15:03.072 --> 00:15:06.918
Este tipo de coches funcionan y son
operativos.

266
00:15:07.118 --> 00:15:08.219
Ahora, consumen que te cagas.

267
00:15:08.419 --> 00:15:13.847
Son absolutamente lentos y no son muy
fiables.

268
00:15:14.047 --> 00:15:18.032
Es muy normal encontrar coches de estos
tirados por allí, por el sitio.

269
00:15:18.232 --> 00:15:22.298
Claro, partimos de que el coche funciona y
que queremos mejorar un coche como este.

270
00:15:22.498 --> 00:15:23.720
Es un poco la idea.

271
00:15:23.920 --> 00:15:25.843
La naturaleza del conflicto es esta.

272
00:15:26.043 --> 00:15:31.566
El manager de desarrollo de aplicaciones
tiene una responsabilidad parcial sobre el

273
00:15:31.566 --> 00:15:34.157
problema de operación de aplicaciones.

274
00:15:34.357 --> 00:15:36.681
Eso es lo que es el valor que entrega, lo
que os enseñaba al principio.

275
00:15:36.881 --> 00:15:41.505
Y el manager de operaciones, nuestra
manager de operaciones siempre se llama

276
00:15:41.505 --> 00:15:42.505
Sally.

277
00:15:42.450 --> 00:15:44.173
Sally siempre tiene una responsabilidad.

278
00:15:44.373 --> 00:15:47.699
responsabilidad parcial sobre la
aplicación total.

279
00:15:47.899 --> 00:15:51.650
Entonces, estas responsabilidades
parciales y contradictorias, uno lo que

280
00:15:51.650 --> 00:15:55.610
está medido es por entregar el máximo
número de cambios en el menor número de

281
00:15:55.610 --> 00:15:59.778
tiempo y que no falle, el otro está medido
porque aquello no falle nunca y por la

282
00:15:59.778 --> 00:16:00.778
alta disponibilidad.

283
00:16:00.861 --> 00:16:03.886
La alta disponibilidad está en contra del
número de errores, está claro.

284
00:16:04.086 --> 00:16:06.819
Cuando tú al coche que hemos visto antes,
este animal,

285
00:16:07.019 --> 00:16:11.666
pues le dices que corra, se produce un
conflicto inmediato.

286
00:16:11.866 --> 00:16:14.030
Y entonces hay que cambiar muchas más
cosas.

287
00:16:14.230 --> 00:16:18.216
Hay que hacer que el coche ya no sea ese
coche, que sea otro tipo de coche.

288
00:16:18.416 --> 00:16:21.080
O le cambias el motor, o le cambias algo,
le tienes que cambiar.

289
00:16:21.280 --> 00:16:25.566
Y nuevamente, el qué le cambias es de lo
que va DevOps.

290
00:16:25.766 --> 00:16:30.148
De intentar identificar un conjunto de
áreas de proceso y de modelos de

291
00:16:30.148 --> 00:16:33.498
organización que te ayude a que de verdad
el coche cambie.

292
00:16:33.698 --> 00:16:34.760
Este funciona.

293
00:16:34.960 --> 00:16:38.463
Esto es lo que pasa cuando le pides que
corra, que se rompe y que tienes al cubano

294
00:16:38.463 --> 00:16:39.463
haciendo esto.

295
00:16:39.349 --> 00:16:43.778
Por cierto, si tenéis algún amigo cubano,
son unos cracks de la mecánica de los años

296
00:16:43.778 --> 00:16:44.680
50, 60.

297
00:16:44.880 --> 00:16:46.931
Y además, me encanta.

298
00:16:47.131 --> 00:16:49.856
Es un pueblo que adoro.

299
00:16:50.056 --> 00:16:51.518
Bueno, ¿para qué mejoras?

300
00:16:51.718 --> 00:16:54.162
Lo que están pidiendo los negocios es,
primero, velocidad.

301
00:16:54.362 --> 00:16:55.362
Time to market.

302
00:16:55.103 --> 00:16:56.726
¿Y por qué piden velocidad?

303
00:16:56.926 --> 00:17:01.554
En el sector financiero hay un tipo de
empresa que se llama vintage.

304
00:17:01.754 --> 00:17:04.939
No sé para cuántos de vosotros una vintage
significa algo.

305
00:17:05.139 --> 00:17:09.128
Una vintage es una startup que lo que hace
normalmente es utilizar desintermediación,

306
00:17:09.128 --> 00:17:13.023
que le llaman, para poder coger y ponerse
entre lo que es la entidad financiera que

307
00:17:13.023 --> 00:17:13.973
publica datos.

308
00:17:14.173 --> 00:17:15.315
No sé si habéis visto últimamente una...

309
00:17:15.515 --> 00:17:20.445
Una app que publica BBVA en la que tú
puedes consultar los datos de tu banco

310
00:17:20.445 --> 00:17:22.041
cuando tu banco no es BBVA.

311
00:17:22.241 --> 00:17:25.998
Es decir, puedes tener otros bancos
vinculados a tu cuenta, con lo cual es

312
00:17:25.998 --> 00:17:30.013
como tener el anillo único del señor de
los anillos para controlarlos a todos a

313
00:17:30.013 --> 00:17:31.229
través de la tecnología.

314
00:17:31.429 --> 00:17:32.671
Es fantástico, ¿no?

315
00:17:32.871 --> 00:17:35.593
Esto se hace a través de un modelo de
engagement acelerado.

316
00:17:35.793 --> 00:17:37.295
De hecho, esto está muy claro.

317
00:17:37.495 --> 00:17:40.343
El time to market te lleva a que las
fintechs son capaces de hacer que

318
00:17:40.343 --> 00:17:43.260
determinados servicios que los bancos no
pueden llegar a prestar, se presten.

319
00:17:43.460 --> 00:17:46.700
Y esto lo hacen con básicamente un equipo
no demasiado grande, una buena idea de

320
00:17:46.700 --> 00:17:49.818
negocio y luego la interacción con lo que
son los servicios financieros y por

321
00:17:49.818 --> 00:17:50.967
supuesto con capital riesgo.

322
00:17:51.167 --> 00:17:54.590
Entonces, por la izquierda a los bancos
les pasan las fintechs.

323
00:17:54.790 --> 00:18:00.167
Por la derecha les pasa BBVA, que ha hecho
una inversión en DevOps muy importante y

324
00:18:00.167 --> 00:18:01.156
muy relevante.

325
00:18:01.356 --> 00:18:04.446
Y te encuentras con que si tú eres un
banco estás en medio y en tierra de nadie,

326
00:18:04.446 --> 00:18:06.481
con tu modelo waterfall y que tienes que
evolucionar.

327
00:18:06.681 --> 00:18:10.495
Entonces, lo primero que buscas es llegar
antes y hacer que tu idea llegue antes al

328
00:18:10.495 --> 00:18:11.495
mercado.

329
00:18:11.425 --> 00:18:13.247
Lo segundo es minimizar el número de
errores.

330
00:18:13.447 --> 00:18:17.611
esto debería ser aquí un dogma, no sé si
tenéis una foto de esta foto, la tenéis en

331
00:18:17.611 --> 00:18:21.421
algún sitio, aquí puesta en un marco,
debería estar, en cualquier escuela de

332
00:18:21.421 --> 00:18:23.656
informática, es el primer bug de la
historia.

333
00:18:23.856 --> 00:18:28.670
Este es un bug que se encontró en una
máquina, la primera máquina.

334
00:18:28.870 --> 00:18:33.227
Aquí lo que intentamos es hacer que la
calidad esté embebida en el propio proceso

335
00:18:33.227 --> 00:18:37.694
y lo intentamos porque lo que se pretende
es hacer que las unidades de trabajo sean

336
00:18:37.694 --> 00:18:42.161
lo suficientemente pequeñas como para que
no nos podamos desviar demasiado ni de lo

337
00:18:42.161 --> 00:18:46.032
que el cliente necesita ni de lo que sería
la calidad técnica del producto.

338
00:18:46.232 --> 00:18:50.662
Es decir, trabajamos en incrementos
pequeños y hacemos comprobaciones rápidas

339
00:18:50.662 --> 00:18:53.882
para saber si efectivamente estamos
cometiendo errores o no.

340
00:18:54.082 --> 00:18:59.713
Seguro que todos tenéis un smartphone y
tenéis un GPS y el GPS lo usáis a veces

341
00:18:59.713 --> 00:19:02.079
para ir andando a los sitios.

342
00:19:02.279 --> 00:19:04.876
Muchas veces vais caminando y queréis para
allá y estáis yendo para el otro lado,

343
00:19:04.876 --> 00:19:05.526
¿no?

344
00:19:05.726 --> 00:19:09.474
Porque el GPS no tiene suficiente
capacidad como para...

345
00:19:09.674 --> 00:19:14.480
localizaron a pie en un metro, entonces
tenéis que caminar unos 20 metros y hasta

346
00:19:14.480 --> 00:19:18.686
que ya veis para dónde va la flechita y
dices, coño, es para el otro lado.

347
00:19:18.886 --> 00:19:22.520
Eso es lo que pasa normalmente cuando se
trabaja en grandes paquetes, por eso

348
00:19:22.520 --> 00:19:25.772
Waterfall es tan malo haciendo
predicciones, porque primero hace unas

349
00:19:25.772 --> 00:19:29.645
estrellas de asunciones sobre cosas que no
sabe y segundo hace grandes paquetes de

350
00:19:29.645 --> 00:19:30.645
asunciones

351
00:19:30.582 --> 00:19:35.443
Claro, en el modelo DevOps, que es Agile
en esencia más automatización, y ahora lo

352
00:19:35.443 --> 00:19:39.645
veremos, lo que hace son asunciones
pequeñas y luego las vas chequeando

353
00:19:39.645 --> 00:19:40.966
conforme pasa el tiempo.

354
00:19:41.166 --> 00:19:43.452
Con lo cual, si te equivocas, te equivocas
pronto.

355
00:19:43.652 --> 00:19:47.140
Fallar pronto y fallar barato es uno de
los objetivos que tiene Agile, ¿no?

356
00:19:47.390 --> 00:19:51.413
Entonces, bueno, aquí lo que intentamos es
que la calidad esté embebida, que cada vez

357
00:19:51.413 --> 00:19:55.340
que hacemos un paso por algún entorno, a
los entornos intermedios, haya un conjunto

358
00:19:55.340 --> 00:19:58.836
de controles bien estructurados y
automatizados, de forma que cada vez que

359
00:19:58.836 --> 00:20:02.668
damos un paso, damos un paso adelante, o
intentamos que sea dar un paso adelante.

360
00:20:02.868 --> 00:20:08.584
Y esto exige una estructura organizativa
dentro de la organización de desarrollo de

361
00:20:08.584 --> 00:20:12.900
TI, de operación de TI, que no es la que
tenemos a día de hoy.

362
00:20:13.100 --> 00:20:14.882
Y ahí se produce la tensión.

363
00:20:15.082 --> 00:20:19.252
Y el tercero, hay muchos más beneficios,
pero a mí me encanta este, porque al final

364
00:20:19.452 --> 00:20:24.228
Si estamos trabajando en una organización
clásica de TI, en el modelo Waterfall, y

365
00:20:24.228 --> 00:20:29.064
tenéis la desgracia de caer en un equipo
de testing, veréis que la mitad del tiempo

366
00:20:29.064 --> 00:20:33.664
estáis esperando, la otra mitad del tiempo
estáis con el aliento del jefe en tu

367
00:20:33.664 --> 00:20:36.377
cogote porque te está diciendo que
termines ya.

368
00:20:36.577 --> 00:20:40.607
Porque realmente no tenéis tiempo de hacer
la actividad que tienes que hacer con la

369
00:20:40.607 --> 00:20:41.705
información que necesitas.

370
00:20:41.905 --> 00:20:45.029
Siempre te falta algo, te faltan las
pruebas, o te faltan las pruebas, pero hay

371
00:20:45.029 --> 00:20:46.029
cosas tuyas.

372
00:20:45.811 --> 00:20:48.734
Te faltan los datos, te falta la
infraestructura, te falta la aplicación

373
00:20:48.734 --> 00:20:50.861
que no te la han liberado en la versión
que tú necesitas.

374
00:20:51.061 --> 00:20:52.484
Todo eso te puede llegar a pasar.

375
00:20:52.684 --> 00:20:57.587
Entonces, DevOps lo que intenta es hacer
que el modelo de trabajo sea un modelo

376
00:20:57.587 --> 00:21:02.616
eficiente y uno de los objetivos que se
plantea este grupo de filósofos alrededor

377
00:21:02.616 --> 00:21:04.848
es que la gente sea feliz y que viva...

378
00:21:05.048 --> 00:21:06.130
feliz en lo que es el trabajo.

379
00:21:06.330 --> 00:21:07.330
¿Por qué?

380
00:21:06.590 --> 00:21:10.738
Porque aporte el valor que se espera,
porque no esté trabajando para la basura,

381
00:21:10.738 --> 00:21:15.153
porque realmente esté aportando beneficio
a la compañía y luego pueda irse a su casa

382
00:21:15.153 --> 00:21:16.962
a las 5 de la tarde si es posible.

383
00:21:17.162 --> 00:21:19.405
Este también es uno de los objetivos que
tiene DevOps.

384
00:21:19.605 --> 00:21:25.605
Pero es incorrecto pensar que porque esto
esté en el ideario, DevOps tiene menos

385
00:21:25.605 --> 00:21:28.136
control que otros modelos.

386
00:21:28.336 --> 00:21:32.339
El control que tiene tanto Agile como
DevOps, y más en organizaciones a escala,

387
00:21:32.339 --> 00:21:35.983
es un control que igual no es de arriba a
abajo, pero que sí es lateral.

388
00:21:36.183 --> 00:21:40.858
Porque el compromiso y la propiedad de la
cosa, de la aplicación que se intenta

389
00:21:40.858 --> 00:21:45.833
desarrollar, pertenece a todo el equipo y,
por lo tanto, si uno falla, fallan todos.

390
00:21:46.033 --> 00:21:51.044
Entonces se producen situaciones donde sí
que hay un estrés importante entre los

391
00:21:51.044 --> 00:21:52.044
propios equipos.

392
00:21:52.080 --> 00:21:54.002
Pero luego acaba todo en cervezas, claro,
evidentemente.

393
00:21:54.202 --> 00:21:55.503
Si no, la cosa no funciona.

394
00:21:55.703 --> 00:21:57.305
Entonces, algunos principios.

395
00:21:57.505 --> 00:22:00.369
Agile en marca DevOps es necesario.

396
00:22:00.569 --> 00:22:02.110
Si no trabajas con Agile, no trabajas con
DevOps.

397
00:22:02.310 --> 00:22:05.734
Agile también será doctrina aquí de alguna
forma, ¿no?

398
00:22:05.984 --> 00:22:06.906
Entiendo que sí, ¿no?

399
00:22:07.106 --> 00:22:09.249
Todo el mundo aquí sabe de esto.

400
00:22:09.449 --> 00:22:12.634
Entonces, cosas que yo he encontrado con
clientes.

401
00:22:12.834 --> 00:22:14.056
DevOps te pide visibilidad.

402
00:22:14.276 --> 00:22:17.501
Es decir, ¿cuál es el backlog que hemos
comprometido para la siguiente iteración?

403
00:22:17.701 --> 00:22:18.843
¿En qué estamos?

404
00:22:19.043 --> 00:22:20.205
¿Cuál es el compromiso?

405
00:22:20.405 --> 00:22:22.148
¿Cuándo vamos a tener?

406
00:22:22.348 --> 00:22:23.690
¿Qué es lo que está incluido?

407
00:22:23.890 --> 00:22:24.890
¿Qué no?

408
00:22:24.431 --> 00:22:27.175
Las discusiones que hemos tenido son
públicas, etcétera, etcétera.

409
00:22:27.375 --> 00:22:28.597
Y te dicen los clientes.

410
00:22:28.797 --> 00:22:29.797
Esto es muy interesante.

411
00:22:29.959 --> 00:22:30.959
Pero...

412
00:22:30.740 --> 00:22:34.801
A lo mejor a mí no me interesa que mi
unidad de negocios vea tanto como que yo,

413
00:22:34.801 --> 00:22:39.070
por ejemplo, estoy no haciendo algo que sí
que me he comprometido a hacer con ellos

414
00:22:39.070 --> 00:22:42.923
porque he adelantado otro tipo de
actividades o he desviado recursos a otro

415
00:22:42.923 --> 00:22:43.919
tipo de proyectos.

416
00:22:44.119 --> 00:22:45.491
Esto te lo puedes encontrar.

417
00:22:45.691 --> 00:22:48.477
La visibilidad es un problema en
organizaciones tradicionales.

418
00:22:48.677 --> 00:22:53.845
O sea, si tú tienes el problema clásico de
visibilidad es que yo soy desarrollo,

419
00:22:53.845 --> 00:22:59.079
tengo en mi plan, imaginaos que son 150
proyectos en paralelo y tengo que hacer X

420
00:22:59.079 --> 00:23:03.528
puestas en producción o la utilización de
X entornos y eso colisiona.

421
00:23:03.728 --> 00:23:05.893
Uno necesita el entorno a la misma vez que
lo utiliza otro, ¿no?

422
00:23:06.093 --> 00:23:09.795
Si tienes un modelo de visibilidad y eres
capaz de organizar todo ese trabajo de una

423
00:23:09.795 --> 00:23:11.669
forma estructurada, tienes menos
problemas.

424
00:23:11.869 --> 00:23:17.034
Bien, pues no es sencillo llegar a un
acuerdo en el cual las organizaciones

425
00:23:17.034 --> 00:23:18.086
opten por esto.

426
00:23:18.286 --> 00:23:20.878
Hacer equipo y propiedad es tremendamente
importante también.

427
00:23:21.078 --> 00:23:23.722
Porque, lo he dicho antes, es la propiedad
del equipo.

428
00:23:23.922 --> 00:23:29.922
A ti no pertenece la calidad, a tu
departamento no le pertenece el desarrollo

429
00:23:29.922 --> 00:23:33.277
funcional, es la aplicación completa.

430
00:23:33.477 --> 00:23:38.252
Y por eso se habla del concepto de
productizar, que es otro palabra que

431
00:23:38.252 --> 00:23:40.447
empleamos también los fabricantes.

432
00:23:40.647 --> 00:23:43.906
Si tú en lugar de ejecutar proyectos, que
son peticiones de cambio que se

433
00:23:43.906 --> 00:23:47.165
estructuran de una forma determinada, lo
que tienes son administración de

434
00:23:47.165 --> 00:23:49.481
productos, tienes un producto que tiene un
backlog que ha

435
00:23:49.681 --> 00:23:51.964
de coordinarse con otros productos.

436
00:23:52.164 --> 00:23:56.189
Eso sí es el enfoque que Dev tendría
dentro del paradigma.

437
00:23:56.389 --> 00:24:01.023
Y ahí la productización implica romper el
silo y hacer que haya equipos

438
00:24:01.023 --> 00:24:02.016
transversales.

439
00:24:02.216 --> 00:24:04.859
Y hay muchas organizaciones que se vuelven
locas.

440
00:24:05.059 --> 00:24:06.059
¿Qué me están diciendo?

441
00:24:05.640 --> 00:24:08.686
¿Que dentro del mismo equipo gente de
operación, gente de calidad, gente de

442
00:24:08.686 --> 00:24:10.686
desarrollo y que trabajen todos de forma
coordinada?

443
00:24:10.886 --> 00:24:12.428
Sí, eso no va a pasar.

444
00:24:12.628 --> 00:24:16.113
Te encuentras con rechazos sobre esto.

445
00:24:16.313 --> 00:24:17.313
Cooperación.

446
00:24:17.474 --> 00:24:21.403
El concepto de capacitación sobre rol,
porque el rol es un concepto del modelo

447
00:24:21.403 --> 00:24:25.588
waterfall, al menos en lo que sabemos, es
un rol que se aloca a un departamento que

448
00:24:25.588 --> 00:24:29.824
tiene unas misiones, aquí lo que hablamos
son más de capacidades y de individuos que

449
00:24:29.824 --> 00:24:33.142
tienen esas capacidades y que participan
en ese tipo de proyectos.

450
00:24:33.342 --> 00:24:36.208
Un enfoque a medición bastante importante,
con lo cual,

451
00:24:36.408 --> 00:24:41.635
El modelo es un modelo, es como cuando uno
quiere bajar de peso, lo primero que tiene

452
00:24:41.635 --> 00:24:46.737
que hacer es medirse y hacer un plan de un
conjunto de objetivos y trabajar para la

453
00:24:46.737 --> 00:24:47.737
medición.

454
00:24:47.722 --> 00:24:52.152
Si eres capaz de hacer esto, estarás en un
modelo de mejora continua con la calidad

455
00:24:52.152 --> 00:24:54.151
en bebida automatización y diversión.

456
00:24:54.351 --> 00:24:59.245
Estos son un poco los principios que
podemos observar dentro de cualquier

457
00:24:59.245 --> 00:25:01.160
modelo de adopción de bebidas.

458
00:25:01.360 --> 00:25:02.360
Sobre antecedentes.

459
00:25:01.720 --> 00:25:03.445
Ágil, manifiesto ágil.

460
00:25:03.645 --> 00:25:06.172
Si no hay Agile, no hay DevOps.

461
00:25:06.372 --> 00:25:07.415
Olvidadlo.

462
00:25:07.615 --> 00:25:12.096
Agile, se puede decir que DevOps es Agile
más automatización, donde la

463
00:25:12.096 --> 00:25:15.020
automatización es un elemento
superimportante.

464
00:25:15.220 --> 00:25:16.883
Esto es allá y ya lo habéis visto un
montón de veces.

465
00:25:17.083 --> 00:25:21.131
Al final es intentar hacer que el cliente
tenga, lo de arriba es waterfall, no

466
00:25:21.131 --> 00:25:22.551
tienes nada hasta el final.

467
00:25:22.751 --> 00:25:26.165
Lo de abajo es, bueno, pues vas teniendo
un patinete, ahora los patinetes están muy

468
00:25:26.165 --> 00:25:28.039
de moda y puedes ir en patinete a todos
lados.

469
00:25:28.239 --> 00:25:31.749
Entonces, bueno, pues haciendo un
patinete, un monopatín, todo te

470
00:25:31.749 --> 00:25:36.248
transporta, todo funciona desde el primer
momento, pero, bueno, no es el coche full

471
00:25:36.248 --> 00:25:38.173
equip que es lo que quería el cliente.

472
00:25:38.373 --> 00:25:42.265
Como decía el otro, lo mejor es enemigo de
lo bueno y en este caso es la

473
00:25:42.265 --> 00:25:44.130
implementación del paradigma, ¿no?

474
00:25:44.330 --> 00:25:49.234
No voy a contar esto, esto ya lo sabéis
medianamente, lo que son los distintos

475
00:25:49.234 --> 00:25:51.719
principios ágiles y los modelos ágiles.

476
00:25:51.919 --> 00:25:53.799
Sí, es importante ver

477
00:25:53.999 --> 00:25:59.341
como probablemente la creación del backlog
de producto sí que tiene que hacerse de

478
00:25:59.341 --> 00:26:04.221
una forma dinámica y ágil, y luego
hablaremos de la planificación ágil, que

479
00:26:04.221 --> 00:26:09.366
es una necesidad dentro de DevOps, y luego
el concepto de incremento, potential

480
00:26:09.366 --> 00:26:14.576
shipable increment, incremento que puede
ser entregado, que tiene que ver con la

481
00:26:14.576 --> 00:26:17.940
entrega continua, con el modelo de entrega
continua.

482
00:26:18.140 --> 00:26:21.523
Pero bueno, entiendo que esto para
vosotros es familiar, ¿no?

483
00:26:22.231 --> 00:26:23.231
¿Sí?

484
00:26:22.371 --> 00:26:23.714
¿Es familiar?

485
00:26:23.914 --> 00:26:24.696
¿No es familiar?

486
00:26:24.896 --> 00:26:29.364
Si es que no le dedico un minuto, es muy
importante, ¿no?

487
00:26:29.564 --> 00:26:32.470
Bueno, a ver, ¿cómo trabajamos en un
modelo waterfall?

488
00:26:32.670 --> 00:26:34.133
¿Defines un proyecto?

489
00:26:34.333 --> 00:26:35.333
[Orador 4]: A ver.

490
00:26:34.994 --> 00:26:40.745
¿Quién no ha visto el tema de agilidad
circulatoria?

491
00:26:40.945 --> 00:26:42.949
¿Quién no lo ha visto?

492
00:26:43.149 --> 00:26:45.302
[Orador 1]: Vale, pues lo explico yo creo, ¿no?

493
00:26:45.502 --> 00:26:46.645
Decidlo porque si no salto, ¿eh?

494
00:26:46.845 --> 00:26:50.191
Yo estoy suponiendo que a estas alturas
está.

495
00:26:50.391 --> 00:26:52.825
La verdad es que las alturas las estoy
suponiendo también porque no sé si está en

496
00:26:52.825 --> 00:26:54.259
primero, en segundo, en tercero, en
cuarto, en máster.

497
00:26:54.459 --> 00:26:55.459
Está en submáster.

498
00:26:55.080 --> 00:26:56.080
[Orador 4]: Está en submáster.

499
00:26:55.962 --> 00:26:56.962
Madre de Dios.

500
00:26:56.563 --> 00:26:57.626
Estos señores son ingenieros.

501
00:26:57.826 --> 00:26:58.826
[Orador 1]: Vale, vale.

502
00:26:58.347 --> 00:27:01.353
Bueno, pues si son ingenieros tenéis que
saber esto, ¿eh?

503
00:27:01.553 --> 00:27:03.577
Por Dios.

504
00:27:03.777 --> 00:27:07.661
A ver, el agilismo lo que dice o el modelo
ágil lo que te propone es

505
00:27:07.861 --> 00:27:11.909
Es que tú en lugar de tener, entonces voy
a volver atrás, claro.

506
00:27:12.109 --> 00:27:15.421
En lugar de tener un conjunto de, las
organizaciones que han desarrollado

507
00:27:15.421 --> 00:27:18.964
software durante el siglo XX, sobre todo
primeros del siglo XXI, han trabajado

508
00:27:18.964 --> 00:27:22.598
mayoritariamente en un modelo estructurado
por procesos o por áreas de procesos,

509
00:27:22.598 --> 00:27:24.351
donde había un área de procesos que tenía.

510
00:27:24.551 --> 00:27:27.557
Hay un modelo por ahí que seguro que,
espero que conozcáis, que se llama CMMI.

511
00:27:27.757 --> 00:27:31.918
Un modelo en el que te dice cuál es la
mejor práctica para planificar software,

512
00:27:31.918 --> 00:27:36.239
cuál es la mejor práctica para la gestión
de las configuraciones, cuál es la mejor

513
00:27:36.239 --> 00:27:38.214
práctica y te dan una serie de guías.

514
00:27:38.414 --> 00:27:39.776
Y luego ese modelo es certificable.

515
00:27:39.976 --> 00:27:42.675
Esto lo inventaron los americanos, el
departamento de defensa en su momento,

516
00:27:42.675 --> 00:27:44.763
para certificar a los vendors que iban a
venderle software.

517
00:27:45.004 --> 00:27:49.440
Ellos querían tener algún modelo que fuera
estándar como para poder saber si ese

518
00:27:49.440 --> 00:27:50.793
vendor era bueno o era malo.

519
00:27:50.993 --> 00:27:55.288
Bueno, pues esto acabó en un modelo
certificable por la Carnegie Mellon y al

520
00:27:55.288 --> 00:27:59.462
final ha habido gente que ha hecho mucha
pasta con el tema este de CMMI, ¿no?

521
00:27:59.662 --> 00:28:00.883
Esto tú lo sabes, ¿no?

522
00:28:01.083 --> 00:28:05.465
Entonces, también tiene niveles, desde el
nivel 1 hasta el nivel 2 hasta el nivel 5

523
00:28:05.465 --> 00:28:07.069
y bueno, pues es un poco el tema.

524
00:28:07.269 --> 00:28:11.896
Cuanto más alto es el nivel, pues más
estructurado es el proceso, más predecible

525
00:28:11.896 --> 00:28:15.718
eres a la hora de decir cuándo vas a
entregar un determinado producto,

526
00:28:15.918 --> 00:28:21.571
tienes un mejor control del riesgo, tienes
un mejor control de la calidad, etc.

527
00:28:21.771 --> 00:28:24.117
Digamos que es un modelo que es bastante
estructurado.

528
00:28:24.317 --> 00:28:27.894
Entonces, lo que pasa es que este modelo
está muy orientado a procesos, es decir,

529
00:28:27.894 --> 00:28:30.755
alguien ha escrito algo, hay un
departamento de procesos, hay una

530
00:28:30.755 --> 00:28:34.466
metodología normalmente con nombre, cuando
vais a un cliente, cuando vayáis a buscar

531
00:28:34.466 --> 00:28:35.466
empleo,

532
00:28:35.341 --> 00:28:39.880
o si ya lo tenéis si llegas a un cliente
la metodología tiene nombre están

533
00:28:39.880 --> 00:28:44.979
trabajando en este tema están trabajando
en un modelo de waterfall rabios y nada lo

534
00:28:44.979 --> 00:28:49.954
que dice es que antes de coger y fiarnos
de lo que serían procesos escritos en un

535
00:28:49.954 --> 00:28:52.691
libro y que yo tengo que implantar
preferimos

536
00:28:52.891 --> 00:28:55.275
personas que hablan y que interactúan.

537
00:28:55.475 --> 00:29:00.183
Es decir, vamos a ver cuando tengamos una
necesidad de implementar algún tipo de

538
00:29:00.183 --> 00:29:05.071
proceso, en lugar de coger y escribirlo,
vamos a hablarlo y a asumirlo como proceso

539
00:29:05.071 --> 00:29:07.813
y luego vamos a interactuar de forma
frecuente.

540
00:29:08.013 --> 00:29:12.720
Porque los procesos, por lo general, nunca
son óptimos para hacerlo todo.

541
00:29:12.920 --> 00:29:15.524
Por lo tanto, bueno, vamos a reinventar
ese proceso.

542
00:29:15.724 --> 00:29:19.230
Lo que tiene son prácticas, cosas que
asumimos que están bien y que sí creemos

543
00:29:19.230 --> 00:29:20.230
que son...

544
00:29:20.110 --> 00:29:23.857
Entonces, allá le acaban rituales, más que
en práctica.

545
00:29:24.057 --> 00:29:26.001
Luego, software funcionando sobre
documentación.

546
00:29:26.201 --> 00:29:29.712
Lo que dicen es que cuando yo te quiero
decir, en vez de que me documentes todo lo

547
00:29:29.712 --> 00:29:33.136
que está pasando, pues yo lo que te voy a
hacer es enseñarte el producto y si el

548
00:29:33.136 --> 00:29:36.734
producto es lo que cubre tus necesidades,
pues oye, ya tenemos un pequeño incremento

549
00:29:36.734 --> 00:29:37.734
de trabajo.

550
00:29:37.641 --> 00:29:41.949
Claro, esto en un modelo Waterfall donde
la planificación es de...

551
00:29:42.149 --> 00:29:45.808
un millón de líneas de código, el software
funcionando, es muy caro de enseñar, pero

552
00:29:45.808 --> 00:29:49.202
cuando estamos hablando en pequeños
incrementos, ese pequeño incremento sí que

553
00:29:49.202 --> 00:29:50.830
se puede hacer de una forma estructurada.

554
00:29:51.030 --> 00:29:52.334
¿Qué te lo puedo enseñar?

555
00:29:52.534 --> 00:29:56.390
Te lo enseño y tú, pues coges y
directamente me dices si es lo que quieres

556
00:29:56.390 --> 00:29:57.426
o no es lo que quieres.

557
00:29:57.626 --> 00:30:00.393
No tengo por qué explicártelo y hacer un
montón de documentos.

558
00:30:00.593 --> 00:30:04.546
Los documentos además están por lo general
muertos, es decir, cuando tú haces un

559
00:30:04.546 --> 00:30:08.299
documento de este tipo, el cliente lo
puede leer o el negocio lo puede leer,

560
00:30:08.299 --> 00:30:11.572
pero lee una vez y luego ya no vale para
nada, mucho, ya se queda ahí.

561
00:30:11.772 --> 00:30:15.588
Entonces, bueno, al documento hay que
tenerle respeto por lo general, pero

562
00:30:15.588 --> 00:30:16.588
cariño lo justo.

563
00:30:16.540 --> 00:30:19.665
Luego, colaboración con el cliente sobre
negociación contractual.

564
00:30:19.865 --> 00:30:23.063
Esto tiene que ver con los contratos que
se hacen, porque claro, cuando hay un

565
00:30:23.063 --> 00:30:26.469
equipo de desarrollo y un equipo, un área
de negocio, se establece una relación que

566
00:30:26.469 --> 00:30:27.577
puede llegar a ser contractual.

567
00:30:27.777 --> 00:30:29.861
Entonces, ¿qué contratos queremos tener?

568
00:30:30.061 --> 00:30:31.143
Pues vamos a negociar más.

569
00:30:31.343 --> 00:30:32.785
¿Qué es lo que puede entrar en la
siguiente release?

570
00:30:32.985 --> 00:30:37.207
Que ahora es el siguiente nivel de
patinete a bicicleta o de patinete a

571
00:30:37.207 --> 00:30:38.414
bicicleta con motor.

572
00:30:38.614 --> 00:30:41.841
Y esto lo podemos gestionar de una forma
estructurada y vamos a hacerlo de una

573
00:30:41.841 --> 00:30:42.841
forma ágil.

574
00:30:42.700 --> 00:30:44.623
Es decir, no me cierres un contrato con un
alcance perfecto,

575
00:30:44.823 --> 00:30:48.470
predeterminado que igual no puedo
entregarte a tiempo y de forma adecuada

576
00:30:48.470 --> 00:30:49.534
porque igual fracaso.

577
00:30:49.734 --> 00:30:53.363
Entonces, ¿para qué voy a fracasar cuando
puedo no hacerlo en este mundo?

578
00:30:53.563 --> 00:30:55.968
Y luego, respuesta ante el cambio sobre
seguir un plan.

579
00:30:56.168 --> 00:31:00.369
Normalmente los planes en metodología
tradicional están escritos en piedra y con

580
00:31:00.369 --> 00:31:01.369
un contrato detrás.

581
00:31:01.360 --> 00:31:02.360
Toma.

582
00:31:02.521 --> 00:31:04.264
Y además con penalizaciones.

583
00:31:04.464 --> 00:31:09.160
Yo tenía un outsourcer en la Generalitat
de Cataluña que ya te enviaban la factura

584
00:31:09.160 --> 00:31:10.952
y la penalización todos los meses.

585
00:31:11.152 --> 00:31:12.534
Porque incumplían todos los meses.

586
00:31:12.734 --> 00:31:17.487
Con lo cual, se saltaban el comité de
análisis de penalización y cogían y

587
00:31:17.487 --> 00:31:20.344
directamente era esto y además la
penalización.

588
00:31:20.544 --> 00:31:23.769
Bueno, pues lo que dicen es vamos a tener
un modelo que ya esté pensado para

589
00:31:23.769 --> 00:31:24.769
cambiar.

590
00:31:24.649 --> 00:31:28.224
O sea, que el modelo de planificación, la
planificación misma pueda cambiar

591
00:31:28.224 --> 00:31:29.916
respondiendo a eventos específicos.

592
00:31:30.166 --> 00:31:34.072
Realmente es un modelo más avanzado y está
muy en línea con Agile.

593
00:31:34.272 --> 00:31:37.617
Esto DevOps lo implementa de forma
directa.

594
00:31:37.817 --> 00:31:40.434
Pero esto, por ejemplo, es particularmente
difícil de implementar con los

595
00:31:40.434 --> 00:31:41.161
outsourcers.

596
00:31:41.361 --> 00:31:45.676
Si te vas a trabajar para Indra o te vas a
trabajar para Everest, pues bueno, si han

597
00:31:45.676 --> 00:31:48.772
sido capaces de negociar este tipo de
contratos, pues ole ellos.

598
00:31:48.972 --> 00:31:53.639
Pero por lo general hay contratos con
alcances pactados y fechas pactadas.

599
00:31:53.839 --> 00:31:55.782
Y eso lo que te lleva es 15 de mayo.

600
00:31:55.982 --> 00:31:56.982
¿Qué vas a hacer el día 14?

601
00:31:56.863 --> 00:31:57.183
Estar allí.

602
00:31:57.383 --> 00:32:00.240
Está más claro que todo.

603
00:32:00.440 --> 00:32:05.222
Entonces, dicho eso, lo que dicen es que
aunque valoran aquello que está en normal,

604
00:32:05.222 --> 00:32:08.251
lo que está en morado, en negrita, lo
valoran mucho más.

605
00:32:08.451 --> 00:32:10.334
Una forma de decir que es lo que
pretenden.

606
00:32:10.534 --> 00:32:12.998
Y este es el modelo que os decía antes.

607
00:32:13.218 --> 00:32:18.081
En el modelo Waterfall, la persona no
puede desplazarse hasta el punto 4 y a lo

608
00:32:18.081 --> 00:32:23.194
mejor el coche ni es rojo, ni es ovalado,
ni tiene dos ventanillas por lateral, que

609
00:32:23.194 --> 00:32:25.502
no es lo que él quería o ella quería.

610
00:32:25.702 --> 00:32:27.205
Pero bueno, oye, al menos sí que anda,
¿no?

611
00:32:27.405 --> 00:32:32.115
Mientras que en el modelo de abajo lo que
tiene son ese incremento implementable,

612
00:32:32.115 --> 00:32:36.943
potencialmente implementable, en el cual
la persona puede desplazarse en monopatín,

613
00:32:36.943 --> 00:32:41.476
puede desplazarse en patinete, puede
desplazarse y sí que va teniendo un grado

614
00:32:41.476 --> 00:32:42.831
de felicidad creciente.

615
00:32:53.225 --> 00:32:59.225
[Orador 5]: lo primero que llega una empresa y me dice
que si podemos hacer una auditoría de un

616
00:32:59.225 --> 00:33:05.225
software porque un cliente muy importante
de desarrollo de software de este país

617
00:33:05.225 --> 00:33:10.909
estaba absolutamente enfrentado con un
cliente del mercado del agua muy

618
00:33:10.909 --> 00:33:16.909
importante de este país y me estaban
tirando el trasto a la cabeza los trastos

619
00:33:16.909 --> 00:33:20.261
a la cabeza porque uno había pagado

620
00:33:20.461 --> 00:33:26.461
Como dos millones de euros por un
desarrollo que valía y tenía que cobrar

621
00:33:26.461 --> 00:33:39.870
12, el otro decía que lo había entregado,
pero la situación era la siguiente.

622
00:33:40.070 --> 00:33:45.523
Cuando se hizo la oferta, el proveedor del
servicio...

623
00:33:45.723 --> 00:33:51.907
...contestó al 75% de los requerimientos
del cliente.

624
00:33:52.309 --> 00:33:58.309
Cuando se entrega el desarrollo un montón
de años después......la entrega solamente

625
00:33:58.309 --> 00:34:04.217
respondía al 45% de los requerimientos.

626
00:34:05.019 --> 00:34:13.507
Y el cliente decía que solamente le
funcionaban el 25% de los requerimientos.

627
00:34:13.707 --> 00:34:16.134
Después de años...

628
00:34:16.334 --> 00:34:20.257
Después de años, estamos hablando de casi
10.

629
00:34:22.563 --> 00:34:28.563
Si eso hubiese sido, como dice Carlos, con
metodologías ágiles, en absoluto se

630
00:34:28.563 --> 00:34:33.538
hubiese producido ese desfase.

631
00:34:33.738 --> 00:34:37.022
También digo una cosa, yo he sido director
de producción del mayor data center de

632
00:34:37.022 --> 00:34:38.022
este país.

633
00:34:37.864 --> 00:34:45.176
Y lo que más odiaba es que me tirasen el
cerdo mutilado...

634
00:34:45.376 --> 00:34:46.718
Por encima de la valla.

635
00:34:46.918 --> 00:34:52.918
Porque cuando hay que dar servicio, el que
corre el riesgo no es el de desarrollo, es

636
00:34:52.918 --> 00:34:55.952
el que da el servicio.

637
00:34:56.152 --> 00:35:00.159
Por lo tanto, es un trabajo conjunto hacer
que eso funcione.

638
00:35:00.359 --> 00:35:03.081
El problema es de las dos partes.

639
00:35:04.105 --> 00:35:06.843
No sé si me estoy explicando y estoy
aclarando algo.

640
00:35:07.043 --> 00:35:11.727
[Orador 1]: que es el concepto de propiedad, al final
la propiedad es de las dos partes y claro,

641
00:35:11.727 --> 00:35:16.356
el equipo tiene que estar constituido o el
equipo que administra y que gestiona ese

642
00:35:16.356 --> 00:35:20.872
producto tiene que estar constituido por
individuos de las dos partes que sientan

643
00:35:20.872 --> 00:35:22.402
además el concepto de propiedad

644
00:35:22.602 --> 00:35:26.339
Es decir, que el señor director de
operaciones tampoco me acogote al

645
00:35:26.339 --> 00:35:30.970
individuo que está en el equipo de Agile o
de equipo DevOps porque entonces se crean

646
00:35:30.970 --> 00:35:34.026
situaciones complicadas, igual con el
equipo de desarrollo.

647
00:35:34.226 --> 00:35:39.313
A lo que voy es que esto, si te equivocas
y no querías transportarte sobre ruedas,

648
00:35:39.313 --> 00:35:42.956
que lo que querías eran patas, te enteras
en el minuto uno.

649
00:35:43.156 --> 00:35:44.679
¿Vale?

650
00:35:44.879 --> 00:35:48.647
Hice un proyecto yo de ruedas y patas en
la universidad muy chulo, por cierto.

651
00:35:48.847 --> 00:35:50.470
Segundo, en robótica.

652
00:35:50.670 --> 00:35:52.053
Segundo, en arriba no.

653
00:35:52.253 --> 00:35:56.487
Arriba, eso es al final y pasarán 10 años
y pasarán 20 años y muchos más y hay

654
00:35:56.487 --> 00:36:00.666
ejemplos, el Atlas famoso vuestro, el
Puff, que eso no acabó nunca, el, ¿cómo

655
00:36:00.666 --> 00:36:01.666
era?

656
00:36:01.611 --> 00:36:03.916
El Sigir aquel, que también me acuerdo de
aquel proyecto.

657
00:36:04.116 --> 00:36:05.116
¿Vale?

658
00:36:04.402 --> 00:36:06.445
Otro que acabó con el rosario de la
aurora.

659
00:36:06.645 --> 00:36:09.268
Porque realmente es que no sabemos en el
minuto uno.

660
00:36:09.468 --> 00:36:15.129
No somos capaces de, ni el vendedor, ni el
comprador, son capaces de abarcar la

661
00:36:15.129 --> 00:36:17.118
complejidad del problema.

662
00:36:17.318 --> 00:36:22.033
Muchas veces el desarrollo de software se
revela el problema conforme se va

663
00:36:22.033 --> 00:36:23.446
construyendo el software.

664
00:36:23.646 --> 00:36:26.250
Lo vamos entendiendo conforme lo vamos
construyendo y operando.

665
00:36:26.450 --> 00:36:28.272
Entonces es cuando nos damos cuenta de lo
que tenemos entre manos.

666
00:36:28.472 --> 00:36:31.877
Pero antes son todo elucubraciones.

667
00:36:32.077 --> 00:36:35.980
Si estáis en un proyecto y os ofrecen un
trabajo para un proyecto que dura cinco

668
00:36:35.980 --> 00:36:38.667
años y que va a ser entregado dentro de
dos años, pensadlo.

669
00:36:38.867 --> 00:36:41.071
Porque igual os divorciáis.

670
00:36:41.271 --> 00:36:42.794
O no os casáis.

671
00:36:42.994 --> 00:36:43.994
O lo que sea.

672
00:36:43.975 --> 00:36:49.060
En este mundo, el proyecto ágil
funciona... A ver, voy a intentar, porque

673
00:36:49.060 --> 00:36:50.766
no vamos a tratar mucho.

674
00:36:50.966 --> 00:36:53.350
Entonces es, tenemos un backlog de
producto.

675
00:36:53.550 --> 00:36:57.407
Como funcionamos por producto, un backlog
consiste en una lista de cosas que tenemos

676
00:36:57.407 --> 00:36:58.407
que implementar.

677
00:36:58.317 --> 00:37:00.542
y que están priorizadas con criterios de
negocio.

678
00:37:00.742 --> 00:37:03.786
Lo que más le interesa a negocio está
primero, lo que menos le interesa a

679
00:37:03.786 --> 00:37:05.774
negocio está... Y además este backlog está
vivo.

680
00:37:05.974 --> 00:37:09.118
Es decir, cuando entran nuevas cosas,
imaginaos que viene un error que se ha

681
00:37:09.118 --> 00:37:10.118
producido en operación.

682
00:37:10.183 --> 00:37:12.048
Pues ese error hay que fijarlo, hay que
arreglarlo.

683
00:37:12.248 --> 00:37:13.248
¿Cómo lo hacemos?

684
00:37:12.729 --> 00:37:16.798
Lo metemos en el backlog y lo planificamos
en el siguiente sprint.

685
00:37:16.998 --> 00:37:18.822
Lo que hacen los equipos es que trabajan
con negocio.

686
00:37:19.022 --> 00:37:22.900
Hay un señor, el product owner o el
product manager, dependiendo del volumen,

687
00:37:22.900 --> 00:37:27.136
que trabaja con lo que sería el backlog de
producto y que hace que el individuo, ese

688
00:37:27.136 --> 00:37:28.136
backlog, pues, crezca.

689
00:37:28.279 --> 00:37:29.903
O sea, baje o suba.

690
00:37:30.103 --> 00:37:31.425
Luego, hay un concepto de sprint.

691
00:37:31.625 --> 00:37:34.972
El sprint es, normalmente, algo que dura
entre tres semanas, un mes.

692
00:37:35.172 --> 00:37:39.193
dos semanas a veces, y es una cantidad de
tiempo que para un equipo que tiene una

693
00:37:39.193 --> 00:37:43.165
velocidad determinada, una capacidad de
producir historias de usuario, que es la

694
00:37:43.165 --> 00:37:46.885
unidad que se utiliza determinada, pues
son capaces de sacar X historias de

695
00:37:46.885 --> 00:37:49.279
usuario y ponerlas a disposición de sus
clientes.

696
00:37:49.479 --> 00:37:51.746
Entonces cogen esas X historias de usuario

697
00:37:51.946 --> 00:37:53.790
Claro, si la gente es muy junior, pues
tiene menos capacidad.

698
00:37:53.990 --> 00:37:56.294
Si la gente es muy senior, pues tiene algo
más de capacidad.

699
00:37:56.494 --> 00:37:58.739
Si la gente acaba de empezar con el
proyecto, tiene menos capacidad.

700
00:37:58.939 --> 00:38:01.765
Si lleva tres años, tiene más capacidad.

701
00:38:01.965 --> 00:38:06.086
Pues básicamente trabajan por sprints, de
forma que hay una ejecución del sprint,

702
00:38:06.086 --> 00:38:07.916
hay un ritualaje que es el daily scrum.

703
00:38:08.116 --> 00:38:11.082
El daily scrum es que todos los días por
la mañana decimos, ¿dónde estás?

704
00:38:11.282 --> 00:38:12.282
¿Qué vas a hacer hoy?

705
00:38:11.883 --> 00:38:13.607
¿Y qué te comprometes a terminar?

706
00:38:13.807 --> 00:38:14.949
Bueno, pues eso se hace todos los días.

707
00:38:15.149 --> 00:38:18.656
Y cuando termina el sprint se hace un
review, se hace una retrospectiva, se dice

708
00:38:18.656 --> 00:38:22.030
que ha ido bien, que ha ido mal, que hemos
entregado y se entrega, siempre se

709
00:38:22.030 --> 00:38:23.030
entrega.

710
00:38:22.938 --> 00:38:25.835
O sea, siempre se entrega aunque tengas
que quitar historias de usuario que no has

711
00:38:25.835 --> 00:38:28.733
sido capaz de implementar del sprint y que
tienes que devolver al backlog para que

712
00:38:28.733 --> 00:38:29.733
luego se reprioricen.

713
00:38:29.505 --> 00:38:31.187
Pero siempre hay algo que se puede
entregar.

714
00:38:31.387 --> 00:38:35.372
Y eso que entregas es algo que es
potencialmente entregable al cliente.

715
00:38:35.572 --> 00:38:36.974
No quiere decir que se vaya a entregar.

716
00:38:37.174 --> 00:38:40.042
Quiere decir que caso de que venga una
necesidad urgente,

717
00:38:40.242 --> 00:38:41.984
lo podrías llegar a entregar.

718
00:38:42.184 --> 00:38:43.365
Esa sería la idea.

719
00:38:43.565 --> 00:38:44.565
Normalmente, ¿qué pasa?

720
00:38:44.146 --> 00:38:46.477
Que tienes historias de usuario, que es la
unidad que se utiliza aquí, igual muy

721
00:38:46.477 --> 00:38:47.477
grandes.

722
00:38:47.168 --> 00:38:48.168
Pues, ¿qué haces?

723
00:38:47.809 --> 00:38:48.809
La rompes.

724
00:38:48.890 --> 00:38:53.600
Una historia de usuario tiene que ser
fácil de entender, mesurable, puedes medir

725
00:38:53.600 --> 00:38:57.058
cuánto va a medir y luego tienes que ser
capaz de probarla.

726
00:38:57.258 --> 00:38:59.080
Si no cumple ninguna de estas tres
características, no vale.

727
00:38:59.280 --> 00:39:00.441
Hay que hacerla más pequeña.

728
00:39:00.641 --> 00:39:01.322
Así de sencillo.

729
00:39:01.522 --> 00:39:06.025
Normalmente, acaban en tableritos, en
post-its, acaban en las paredes, cuajando

730
00:39:06.025 --> 00:39:07.768
las paredes de las organizaciones.

731
00:39:07.968 --> 00:39:11.962
Y luego ya si tienes herramientas y tal,
pues acaban en alguna herramienta puesta

732
00:39:11.962 --> 00:39:15.856
con visibilidad, con transparencia, todo
el mundo sabe qué vamos a implementar,

733
00:39:15.856 --> 00:39:19.851
quién tiene cada historia de usuario, cuál
es el esfuerzo que se requiere de cada

734
00:39:19.851 --> 00:39:23.695
historia de usuario y en modelos más
elaborados, pues qué historias de usuario

735
00:39:23.695 --> 00:39:27.790
dependen de qué otras historias de usuario
y cuáles son los modelos de dependencia.

736
00:39:27.990 --> 00:39:29.732
Así trabajan los equipos ágiles.

737
00:39:29.932 --> 00:39:31.494
Esto es un equipo ágil.

738
00:39:31.694 --> 00:39:35.960
Ahora, las organizaciones como Telefónica
igual tienen la torta de equipos ágiles

739
00:39:35.960 --> 00:39:37.861
que tienen que coordinarse entre ellos.

740
00:39:38.061 --> 00:39:39.122
Ahí es donde viene el problema.

741
00:39:39.322 --> 00:39:43.464
Cómo se coordinan todo esto de equipos
ágiles y cómo se coordinan con el resto

742
00:39:43.464 --> 00:39:44.809
del mundo que no es ágil.

743
00:39:45.009 --> 00:39:47.051
Porque siga habiendo subcontratistas,
¿verdad, Luis?

744
00:39:47.251 --> 00:39:52.929
Y siga habiendo Indras de turno, siga
habiendo, bueno, digo Indra Everest,

745
00:39:52.929 --> 00:39:56.722
porque es lo más conocido, IBM, sepa Dios,
que...

746
00:39:56.922 --> 00:39:59.944
tienen contratos que entregan en
determinados momentos y que tienen que

747
00:39:59.944 --> 00:40:00.808
convivir contigo.

748
00:40:01.008 --> 00:40:02.952
Esto es algo que también tiene que ver.

749
00:40:03.152 --> 00:40:04.835
Luego, lo que decía, tres roles
fundamentales aquí.

750
00:40:05.035 --> 00:40:08.898
El Product Owner, que es el que se encarga
de ese Product Backlog y el que llega a

751
00:40:08.898 --> 00:40:10.043
acuerdos con el cliente.

752
00:40:10.243 --> 00:40:13.862
Hay un señor, el Scrum Master, que es
básicamente el que se encarga de los

753
00:40:13.862 --> 00:40:17.729
rituales ágiles dentro de la organización
y se encarga de seguir los principios

754
00:40:17.729 --> 00:40:18.997
ágiles dentro del equipo ágil.

755
00:40:19.197 --> 00:40:23.569
Hay una certificación de Scrum Master, si
alguno está interesado en esto puede

756
00:40:23.569 --> 00:40:25.386
buscarla por ahí y se certifica.

757
00:40:25.586 --> 00:40:29.006
Es una cuestión divertida porque son
dinámicas más o menos divertidas y tú eres

758
00:40:29.006 --> 00:40:32.296
el dueño de la dinámica, con lo cual te lo
pasas bien dentro de este ámbito.

759
00:40:32.496 --> 00:40:37.464
Y luego está el equipo ágil, que son los
individuos que trabajan dentro de lo que

760
00:40:37.464 --> 00:40:41.569
serían estas dinámicas para poder
gestionar el software y el servicio.

761
00:40:41.769 --> 00:40:43.112
Yo de estos dos libros...

762
00:40:43.312 --> 00:40:48.854
los he leído ambos el de la izquierda el
de la familia Popendiek es facilito y muy

763
00:40:48.854 --> 00:40:54.397
interesante de leer fue lo primero que yo
leí cuando empecé con todo esto luego si

764
00:40:54.397 --> 00:40:59.693
buscáis en internet hay toneladas de cosas
dentro de lo que sería agilismo ¿vale?

765
00:40:59.893 --> 00:41:03.443
el de la derecha es más esotérico pero
también lo cito porque también lo leí y

766
00:41:03.443 --> 00:41:07.040
luego DevOps en particular trabaja con
esto ¿quién conoce aquí la teoría de las

767
00:41:07.040 --> 00:41:07.963
limitaciones?

768
00:41:08.184 --> 00:41:11.129
dije que iba a hacer esta pregunta y ahora
me reafirmo ¿tú conoces la teoría de las

769
00:41:11.129 --> 00:41:12.129
limitaciones?

770
00:41:11.948 --> 00:41:13.706
fantástico ¿alguno más?

771
00:41:13.906 --> 00:41:16.810
La teoría de las limitaciones puede
cambiar vuestra vida.

772
00:41:17.010 --> 00:41:18.312
[Orador 6]: De verdad.

773
00:41:18.512 --> 00:41:18.853
[Orador 1]: De verdad.

774
00:41:19.073 --> 00:41:24.301
Esto lo digo porque yo leí el primer libro
de teoría de limitaciones, La Meta, que

775
00:41:24.301 --> 00:41:28.303
además está accesible a través de
internet, no voy a decir más.

776
00:41:28.726 --> 00:41:33.953
Es algo que a mí me cambió un poco mi
forma de entender la vida.

777
00:41:34.153 --> 00:41:35.195
¿Esto qué es lo que dice?

778
00:41:35.395 --> 00:41:36.857
Son cosas del sentido común.

779
00:41:37.057 --> 00:41:41.263
Es una teoría que dice que todo sistema
tiene al final un único eslabón

780
00:41:41.463 --> 00:41:45.470
o un único cuello de botella que es lo que
está limitando su rendimiento.

781
00:41:45.670 --> 00:41:49.722
Es decir, solamente hay una cosa que
tenemos que enviar en esta sala, si

782
00:41:49.722 --> 00:41:54.346
actuamos como un sistema, que enviaríamos
a una factoría para ver si, por ejemplo,

783
00:41:54.346 --> 00:41:58.456
las unidades de producto terminado
queremos que crezcan hasta determinado

784
00:41:58.456 --> 00:41:59.412
nivel.

785
00:41:59.612 --> 00:42:03.381
En la fábrica lo que dice la teoría es que
solamente hay un eslabón que es lo que

786
00:42:03.381 --> 00:42:05.242
está haciendo que esa producción sea
menor.

787
00:42:05.442 --> 00:42:08.507
Y lo que hay que hacer es encontrar el
eslabón y trabajar sobre ese eslabón.

788
00:42:08.707 --> 00:42:15.076
Entonces, claro, DevOps es teoría de las
limitaciones pura dentro de este modelo.

789
00:42:15.276 --> 00:42:16.398
Esta es en esencia.

790
00:42:16.598 --> 00:42:18.541
Hay una limitación cada vez, ¿vale?

791
00:42:18.741 --> 00:42:22.065
Que puede haber dos limitaciones que
actúan a la vez y que tengan el mismo

792
00:42:22.065 --> 00:42:23.067
factor limitante, ¿no?

793
00:42:23.267 --> 00:42:26.006
Si imaginaos que hay dos cuellos de
botella que son exactamente los mismos

794
00:42:26.006 --> 00:42:27.573
limitantes de flujo, pues, oye, pasa esto,
¿no?

795
00:42:27.773 --> 00:42:29.556
Pero es raro.

796
00:42:29.756 --> 00:42:32.422
Y que para esto lo que tenemos que hacer
es coger ese cuello de botella e

797
00:42:32.422 --> 00:42:34.163
incrementar el flujo sobre el cuello de
botella.

798
00:42:34.363 --> 00:42:36.223
Luis.

799
00:42:41.268 --> 00:42:44.556
[Orador 5]: En una factoría de 8 horas al día.

800
00:42:44.756 --> 00:42:48.321
Si tengo más pedidos, ¿qué hago?

801
00:42:49.286 --> 00:42:54.633
Y la limitación, por ejemplo, puede ser el
estatuto de los trabajadores que no me

802
00:42:54.633 --> 00:42:56.980
dejen trabajar más de 8 o 10 horas.

803
00:43:01.062 --> 00:43:04.584
[Orador 1]: Pues contratas a otro, pero igual
contratas a otro y no incrementas el

804
00:43:04.584 --> 00:43:08.565
flujo, porque dos personas, o sea, como
era, dos mujeres no tienen a un niño en

805
00:43:08.565 --> 00:43:09.893
cuatro meses y medio, ¿no?

806
00:43:10.093 --> 00:43:11.575
Pues esto pasa a veces.

807
00:43:11.775 --> 00:43:13.878
Entonces tú quieres incrementar el flujo,
pero no puedes.

808
00:43:14.078 --> 00:43:15.078
Pero lo que dice la teoría es esto.

809
00:43:15.119 --> 00:43:15.881
Cuatro puntos.

810
00:43:16.081 --> 00:43:16.842
Identifica que falla.

811
00:43:17.042 --> 00:43:21.688
Segundo, decide cómo eliminar o mitigar la
limitación.

812
00:43:21.888 --> 00:43:25.280
Tercero, todo el sistema tiene que
subyugarse a eso.

813
00:43:25.480 --> 00:43:30.159
y aquí es donde los departamentos de
operación y desarrollo se pelean porque

814
00:43:30.159 --> 00:43:35.088
igual la subyugación a esto ahora es un
problema de disponibilidad de entornos y

815
00:43:35.088 --> 00:43:40.080
quien tiene que ceder determinado poder y
control es el departamento de operación

816
00:43:40.280 --> 00:43:44.186
Y mañana el problema es que la calidad del
software es una patata y tengo que poner

817
00:43:44.186 --> 00:43:47.902
más recursos ahí o más metodología ahí o
más lo que sea y es el departamento de

818
00:43:47.902 --> 00:43:49.618
desarrollo el que tiene que pagarlo.

819
00:43:49.818 --> 00:43:53.205
Y claro, somos expertos en mínimos
locales.

820
00:43:53.405 --> 00:43:58.401
Obtener mínimos locales y optimizaciones
locales es realmente donde yo siempre digo

821
00:43:58.401 --> 00:43:59.336
lo mismo.

822
00:43:59.536 --> 00:44:03.063
Yo me mejoro a mí y a este señor que está
mirando interesadamente...

823
00:44:03.263 --> 00:44:07.828
lo que sea, pues no lo sé si tenemos que
ponernos de acuerdo para que nuestro

824
00:44:07.828 --> 00:44:12.694
sistema funcione bien a veces tendré que
ceder yo, a veces tendrá que ceder a él y

825
00:44:12.694 --> 00:44:17.440
esto es una negociación compleja y luego
lo último, ejecuta la mejora y vuelve a

826
00:44:17.440 --> 00:44:22.126
empezar todo esto es así el modelo es como
este que hay aquí en la figura si yo

827
00:44:22.126 --> 00:44:26.812
quiero incrementar el flujo por lo que
sería este tubo lo que me está limitando

828
00:44:26.812 --> 00:44:31.498
el flujo es ese agujero que hay en el
centro del diagrama si yo invierto más yo

829
00:44:31.498 --> 00:44:32.493
para que tengo

830
00:44:32.693 --> 00:44:36.728
digamos esas unidades productivas con
capacidad ociosa en el centro, pues no me

831
00:44:36.728 --> 00:44:37.728
valen para nada.

832
00:44:37.720 --> 00:44:39.703
Y a lo mejor son caras, pero no me valen
para nada.

833
00:44:39.903 --> 00:44:44.286
Si quiero incrementar el flujo tengo que
trabajar sobre la pelotita roja, hacer que

834
00:44:44.286 --> 00:44:48.562
esa pelotita roja tenga mayor ancho de
banda o hacer que de alguna forma fluya el

835
00:44:48.562 --> 00:44:51.984
líquido, porque no siempre todo se arregla
poniendo más máquinas.

836
00:44:52.184 --> 00:44:54.267
Es un clásico, ¿no?

837
00:44:54.467 --> 00:44:55.467
La aplicación va lenta, ¿qué hago?

838
00:44:55.488 --> 00:44:56.488
Pon más máquinas.

839
00:44:56.489 --> 00:44:58.993
Esto lo hace cualquier departamento de
operaciones, ¿no?

840
00:44:59.193 --> 00:45:01.556
Ahora es más servicios en la nube o lo que
sea, ¿no?

841
00:45:01.756 --> 00:45:03.919
Pero paga más al final.

842
00:45:04.119 --> 00:45:06.482
Hay un ejemplo en...

843
00:45:06.682 --> 00:45:08.325
Ahora os voy a poner un...

844
00:45:08.525 --> 00:45:11.903
No os voy a poner el vídeo porque no
tenemos tiempo, pero hay un link dentro de

845
00:45:11.903 --> 00:45:14.452
lo que os paso ahora y hay un vídeo que
sale justo a la derecha.

846
00:45:14.652 --> 00:45:16.575
Y este es muy ilustrativo.

847
00:45:16.775 --> 00:45:18.157
Es una botella de agua que le dan la
vuelta.

848
00:45:18.357 --> 00:45:21.722
Entonces, el cuello de botella es claro el
cuello de la botella de agua.

849
00:45:21.922 --> 00:45:26.479
Entonces hay tres técnicas para que salga
el agua en un mínimo número de minutos y

850
00:45:26.479 --> 00:45:27.479
de segundos.

851
00:45:27.450 --> 00:45:30.828
Y si no hacen nada, pues el agua va a
trompicones saliendo y el aire va a

852
00:45:30.828 --> 00:45:34.301
trompicones entrando y la diferencial de
presión hace que el agua se vacíe.

853
00:45:34.501 --> 00:45:35.501
Eso es poco eficiente.

854
00:45:35.142 --> 00:45:39.231
Pero si creas un vórtice, el vórtice crea
un canal estructurado de entrada de aire y

855
00:45:39.231 --> 00:45:41.892
eso hace que la botella se vacíe mucho más
rápidamente.

856
00:45:42.092 --> 00:45:45.377
Pero si pones una pajita y soplas,

857
00:45:45.577 --> 00:45:48.589
Eso crea un diferencial de presión que
hace que la botella se vacíe brutalmente

858
00:45:48.589 --> 00:45:49.589
rápido.

859
00:45:49.482 --> 00:45:51.225
Y el cuello de botella no lo has tocado.

860
00:45:51.425 --> 00:45:52.928
Es igual capacidad.

861
00:45:53.128 --> 00:45:56.492
Por lo tanto, no siempre añadiendo más
máquinas se arreglan las cosas.

862
00:45:56.692 --> 00:46:00.378
Hay veces que hay otras técnicas para
arreglar estas cosas.

863
00:46:00.578 --> 00:46:02.341
Y esto es lo que decía de los máximos y
los mínimos.

864
00:46:02.541 --> 00:46:04.968
Devox lo que dice es que hay que buscar

865
00:46:05.168 --> 00:46:09.618
óptimos globales no locales pero el
departamento de operación va inicialmente

866
00:46:09.618 --> 00:46:14.361
contra su presupuesto y está dispuesto a
hacer cosas que le afecten a él y acceder

867
00:46:14.361 --> 00:46:18.695
cuando pero claro si mi mejora al final
que beneficia es al departamento de

868
00:46:18.695 --> 00:46:23.438
desarrollo pues igual me lo pienso porque
el presupuesto de quién es entonces este

869
00:46:23.438 --> 00:46:27.713
concepto de trabajar por silos el trabajar
por silos funciona muy bien con

870
00:46:27.713 --> 00:46:31.344
optimizaciones locales pero muy mal con
optimizaciones globales

871
00:46:31.544 --> 00:46:33.547
Y aquí tenéis algunas referencias chulas.

872
00:46:33.747 --> 00:46:38.013
El primer libro es el que os decía, leedlo
encarecidamente.

873
00:46:38.213 --> 00:46:41.577
Es muy fácil, es novelado, con lo tanto
está chupado.

874
00:46:41.777 --> 00:46:43.700
Y el resto ya son consecuencias y tal.

875
00:46:43.900 --> 00:46:47.215
El link de abajo es el link que os decía
que puede llegar a ser interesante por lo

876
00:46:47.215 --> 00:46:48.526
que decía de la botella de agua.

877
00:46:48.726 --> 00:46:51.049
Estos dos son referencias de DevOps.

878
00:46:51.249 --> 00:46:57.249
El proyecto Phoenix es otro más de lectura
y es la teoría de las limitaciones

879
00:46:57.249 --> 00:46:59.492
aplicado a DevOps.

880
00:46:59.692 --> 00:47:02.541
O sea, si no queréis leer la meta, pues no
lo hagáis, pero este sí que lo deberíais

881
00:47:02.541 --> 00:47:03.541
de leer.

882
00:47:03.257 --> 00:47:06.596
Yo os recomendaría que leyerais los dos
porque son muy chicos y la verdad es que

883
00:47:06.596 --> 00:47:08.584
funcionan muy bien y se entienden
perfectamente.

884
00:47:08.784 --> 00:47:13.054
Y el otro es un poco la biblia del
concepto este de Continuous Delivery y de

885
00:47:13.054 --> 00:47:14.054
DevOps también.

886
00:47:14.051 --> 00:47:18.024
Este también es, yo lo tengo en la mesilla
de noche, os puedo decir, y consulto, hay

887
00:47:18.024 --> 00:47:21.711
cosas de cuando en cuando para cuando voy
a un cliente que tiene una necesidad

888
00:47:21.711 --> 00:47:25.226
específica, yo lo recomiendo también
porque también se lee razonablemente bien.

889
00:47:25.426 --> 00:47:29.531
Dicho eso, seguramente iré fatal de
tiempo, porque no pensaba gastar tanto

890
00:47:29.531 --> 00:47:30.515
tiempo en Agile.

891
00:47:30.715 --> 00:47:35.803
Así que, 18.07, tenemos un cuarto de hora
y demás, si tenéis tiempo.

892
00:47:36.003 --> 00:47:42.214
¿Puedo seguir hasta 10 minutillos más?

893
00:47:42.414 --> 00:47:43.414
¿Sí?

894
00:47:42.514 --> 00:47:45.881
Bueno, este es mi marco de referencia
favorito para DevOps.

895
00:47:46.081 --> 00:47:49.942
marco de referencia, framework, una...
Como veis, os traigo la presentación en

896
00:47:49.942 --> 00:47:51.367
español, que me ha costado, ¿eh?

897
00:47:51.567 --> 00:47:52.567
Espero que lo valoréis, ¿eh?

898
00:47:52.548 --> 00:47:53.950
Porque esto me ha costado hacerlo.

899
00:47:54.150 --> 00:47:57.645
O sea, habréis visto, los que hayáis
brujuleado un poco en internet, el marco

900
00:47:57.645 --> 00:47:59.937
de referencia normal es el que se ve ahí
arriba, ¿no?

901
00:48:00.137 --> 00:48:01.899
Este dibujito que es una especie de
infinito.

902
00:48:02.099 --> 00:48:03.301
Pero a mí me gusta mucho más este.

903
00:48:03.501 --> 00:48:05.544
Porque aquí hay dos cosas que quedan
claras.

904
00:48:05.744 --> 00:48:07.506
Primero, que todo es continuo en el mundo
de DevOps.

905
00:48:07.706 --> 00:48:09.962
Es decir, todo es de a poquito continuo.

906
00:48:10.162 --> 00:48:14.218
Era como José Mota iba a invadir Portugal
haciendo así con el mojón que separa las

907
00:48:14.218 --> 00:48:15.290
fronteras de a poco, ¿no?

908
00:48:15.490 --> 00:48:18.816
Pues igual, igual soy muy joven para esto.

909
00:48:19.016 --> 00:48:23.487
Entonces, hay un concepto de planificación
continua donde eso que os decíamos antes

910
00:48:23.487 --> 00:48:28.013
de la planificación escrita en piedra, que
había un documento que era lo que marcaba

911
00:48:28.013 --> 00:48:32.430
nuestras vidas y hacía que no fuéramos a
la cena de Navidad de dentro de dos años,

912
00:48:32.430 --> 00:48:33.519
seguro, pues ya no pasa.

913
00:48:33.719 --> 00:48:38.795
lo que tenemos que tener es un modelo de
planificación continua, donde los

914
00:48:38.795 --> 00:48:44.338
incrementos y las negociaciones con el
cliente son constantes en línea con lo que

915
00:48:44.338 --> 00:48:46.215
decía el manifiesto ágil.

916
00:48:46.415 --> 00:48:50.733
Un modelo de integración continua, es
decir, vosotros cuatro, que sois

917
00:48:50.733 --> 00:48:55.614
desarrolladores, estáis trabajando y de
forma continua estáis integrando lo que

918
00:48:55.614 --> 00:48:59.557
estáis haciendo en algún otro sitio, que
puede ser ese servidor,

919
00:48:59.757 --> 00:49:03.809
Y esto está compilando constantemente y
pasando una serie de pruebas que os dan un

920
00:49:03.809 --> 00:49:07.661
mínimo de visibilidad sobre si lo que
estáis trabajando en conjunto funciona o

921
00:49:07.661 --> 00:49:08.661
no.

922
00:49:08.616 --> 00:49:09.616
Porque ¿qué os pasa a vosotros?

923
00:49:09.437 --> 00:49:14.036
Que cada uno vive en su mundo y está
implementando sus historias de usuario.

924
00:49:14.236 --> 00:49:18.057
Lo que estamos diciendo es, integremos
rápidamente y hagámoslo de una forma

925
00:49:18.057 --> 00:49:21.852
recurrente y hay una serie de prácticas
asociadas a la integración continua.

926
00:49:22.052 --> 00:49:25.038
Es importante, porque es un poco la base
de todo.

927
00:49:25.238 --> 00:49:28.131
Luego, el concepto de integración
continua, una vez que termina,

928
00:49:28.131 --> 00:49:31.714
teóricamente se ha compilado y hemos
generado un entregable algo, un documento,

929
00:49:31.714 --> 00:49:32.714
una build,

930
00:49:32.613 --> 00:49:36.957
y esa build la hay que integrar luego con
otros sistemas porque el acoplamiento de

931
00:49:36.957 --> 00:49:41.247
sistemas es algo que existe en el mundo
luego habrá que probarla por un equipo de

932
00:49:41.247 --> 00:49:45.270
calidad o por un conjunto con las
interfaces no ya solamente con la parte de

933
00:49:45.270 --> 00:49:49.721
código como tal habrá que hacer X escanes
de código, etc. todo eso habrá que pasarlo

934
00:49:49.721 --> 00:49:53.851
por un conjunto de entornos que alguien
tendrá que suministrar normalmente los

935
00:49:53.851 --> 00:49:57.766
señores de operación son los que
suministran estos entornos los señores de

936
00:49:57.766 --> 00:49:58.755
operación son

937
00:49:58.955 --> 00:50:02.787
muy cuidadosos y muy buenos y muy al foco
cuando hablan de poner cosas en

938
00:50:02.787 --> 00:50:06.512
producción, cuando hablan de poner cosas
en preproducción o en entornos

939
00:50:06.512 --> 00:50:09.653
preproductivos, pues igual hay que
perseguirlos un poco más.

940
00:50:09.853 --> 00:50:13.808
Entonces, todo ese modelo de perseguir en
la parte preproductiva y de entornos

941
00:50:13.808 --> 00:50:17.917
sucios es una cosa que intenta evitar,
hacer que los entornos no estén sucios, no

942
00:50:17.917 --> 00:50:21.872
tengan aplicaciones que estén a medio
funcionar o que tengan problemas y hacer

943
00:50:21.872 --> 00:50:25.299
que sea algo que ayude a que los entornos
y el movimiento entre entornos

944
00:50:25.499 --> 00:50:27.061
sea algo que esté automatizado.

945
00:50:27.261 --> 00:50:32.889
La automatización de lo que llamamos
deployment y de la gestión de la release

946
00:50:32.889 --> 00:50:35.871
está en el core de lo que sería DevOps.

947
00:50:36.071 --> 00:50:38.114
Y por último lo que tiene que ver con la
operación continua.

948
00:50:38.314 --> 00:50:42.085
La operación continua significa una vez
que ya tenemos el producto, ya este

949
00:50:42.085 --> 00:50:46.060
producto hemos sido capaces de moverlo en
producción, hay que entender qué está

950
00:50:46.060 --> 00:50:47.895
haciendo el cliente con el producto.

951
00:50:48.095 --> 00:50:52.854
Hay que entender qué uso le está dando y
si de verdad esa característica tan chula

952
00:50:52.854 --> 00:50:57.671
que imaginamos, que pusimos en el backlog
con obligación número uno que tuvimos que

953
00:50:57.671 --> 00:51:01.784
hacer tal, de verdad está generando un
solo euro o si de verdad se está

954
00:51:01.784 --> 00:51:02.784
utilizando.

955
00:51:02.782 --> 00:51:08.060
Os sorprenderíais de la cantidad de basura
que tienen las aplicaciones que están

956
00:51:08.060 --> 00:51:09.060
publicadas.

957
00:51:09.053 --> 00:51:13.887
Nosotros tenemos decenas de productos y
ahora hace algunos años hemos empezado a

958
00:51:13.887 --> 00:51:18.231
hacer analítica del uso de los productos
por parte de los clientes y hay

959
00:51:18.231 --> 00:51:20.071
características que no usa nadie.

960
00:51:20.271 --> 00:51:25.770
Son barcos gigantescos de funcionalidad
que sobre el papel hay algunas partes que

961
00:51:25.770 --> 00:51:30.669
son, la usa el 95% de los clientes y otro
utiliza un 2% de los clientes.

962
00:51:30.869 --> 00:51:34.976
Me la podía haber ahorrado, no me lo
hubiera comprado usted señor.

963
00:51:35.176 --> 00:51:36.338
Esto es una cosa que pasa.

964
00:51:36.538 --> 00:51:40.733
Entonces, entender cómo el cliente está
utilizando tu producto y qué te abre, qué

965
00:51:40.733 --> 00:51:44.720
otras necesidades te abre, es quizá lo que
más aporta en modelos de operación

966
00:51:44.720 --> 00:51:45.720
continua.

967
00:51:45.688 --> 00:51:50.151
Un ejemplo muy fácil con esto es, por
ejemplo, cuando estás publicando una app y

968
00:51:50.151 --> 00:51:54.501
tú estás pensando que quien va a utilizar
tu app es gente que utiliza iPhone y

969
00:51:54.501 --> 00:51:55.501
demás.

970
00:51:55.460 --> 00:51:57.723
Por lo tanto, igual estás pensando en un
nivel

971
00:51:57.923 --> 00:52:01.980
medio alto individuo, y tú además has
publicado tu app y has hecho un conjunto

972
00:52:01.980 --> 00:52:06.090
de pruebas sobre iPhone X, que son la
leche, porque es donde va el futuro y tal

973
00:52:06.090 --> 00:52:07.090
y tal.

974
00:52:07.043 --> 00:52:10.616
Si no sabes desde qué plataformas están
utilizando tu aplicación,

975
00:52:10.816 --> 00:52:15.274
Pues igual vives en Bavia, porque igual
iPhone X, pues no hay prácticamente nadie

976
00:52:15.274 --> 00:52:17.448
que esté utilizando iPhone X para esto.

977
00:52:17.648 --> 00:52:21.846
Además, de hecho, el móvil más popular en
España es un Huawei, un modelo de Huawei,

978
00:52:21.846 --> 00:52:24.201
porque nuestro nivel económico está donde
está.

979
00:52:24.401 --> 00:52:27.894
Entonces, claro, si tú no pruebas en
Huawei, pues ya me contarás tú que estás

980
00:52:27.894 --> 00:52:29.330
probando, estás publicando a ciegas.

981
00:52:29.530 --> 00:52:34.500
Todo esto es algo que necesitas saber y el
modelo de operación continua pues te da.

982
00:52:34.700 --> 00:52:37.640
Evidentemente los modelos de operación
también incluyen todo lo que tiene que ver

983
00:52:37.640 --> 00:52:39.955
con la monitorización de la
infraestructura, etcétera, etcétera,

984
00:52:39.955 --> 00:52:42.822
etcétera, que es el negocio de siempre de
operación, pero que tiene que ver con

985
00:52:42.822 --> 00:52:43.822
esto.

986
00:52:43.578 --> 00:52:45.799
Muy rápidamente.

987
00:52:46.270 --> 00:52:49.095
Planificación continua.

988
00:52:49.295 --> 00:52:50.898
La pelotilla interesante es la número uno.

989
00:52:51.098 --> 00:52:56.851
Hay un evento que dispara lo que sería una
necesidad de replanificación y es algo que

990
00:52:56.851 --> 00:52:59.071
está dentro del propio proceso.

991
00:52:59.271 --> 00:53:03.675
Es decir, tenemos un plan, el plan es el
backlog que tenemos comprometido y ese

992
00:53:03.675 --> 00:53:06.843
backlog lo podemos revisar cuando suceden
determinadas cosas.

993
00:53:07.043 --> 00:53:10.083
Y esto es algo que pasa con la
involucración de determinadas personas que

994
00:53:10.083 --> 00:53:13.377
normalmente no tienen mucho tiempo, que
son la gente de negocio, que tienen que

995
00:53:13.377 --> 00:53:15.151
estar también muy alineada con este
modelo.

996
00:53:15.351 --> 00:53:19.593
Pero si al final tienes este modelo
estructurado, luego lo que le vas

997
00:53:19.593 --> 00:53:23.960
entregando al equipo de desarrollo son
elementos relevantes para todos.

998
00:53:24.160 --> 00:53:28.614
No le estás dando necesidades muertas, son
necesidades vivas y son las necesidades

999
00:53:28.614 --> 00:53:32.409
más vivas que tienes en el momento en que
vas a hacer cualquier tipo de...

1000
00:53:32.609 --> 00:53:35.012
de orden de implementación.

1001
00:53:35.212 --> 00:53:39.043
Y por eso es muy importante, porque
realmente estás haciendo que el

1002
00:53:39.043 --> 00:53:43.746
departamento que se encarga del desarrollo
trabaje en lo que es importante para la

1003
00:53:43.746 --> 00:53:44.701
compañía.

1004
00:53:45.965 --> 00:53:50.143
Bueno, no os voy a aburrir con esto, pero
básicamente el concepto del compromiso, de

1005
00:53:50.143 --> 00:53:54.120
qué nos comprometemos a hacer, es algo
vivo y por lo tanto tiene que ser visible

1006
00:53:54.120 --> 00:53:55.116
para todo el mundo.

1007
00:53:55.316 --> 00:54:00.287
Y es algo que tiene que estar publicado en
algún sitio.

1008
00:54:00.487 --> 00:54:06.120
La integración continua es que vosotros
estáis trabajando con vuestro IDE, sacáis

1009
00:54:06.120 --> 00:54:11.620
el código del gestor de versiones, que
probablemente sea un Git, un Subversion,

1010
00:54:11.620 --> 00:54:17.319
un Dimensions, y sacáis este código, lo
modificáis y lo empaquetáis y lo devolvéis

1011
00:54:17.319 --> 00:54:18.973
al gestor de versiones.

1012
00:54:19.173 --> 00:54:20.173
Eso generalmente genera

1013
00:54:20.315 --> 00:54:23.694
un proceso de integración continua, el
Jenkins de toda la vida hace la

1014
00:54:23.694 --> 00:54:27.661
compilación, luego te ejecuta lo que son
las pruebas unitarias y al final te dice,

1015
00:54:27.661 --> 00:54:29.539
oye, esto ha funcionado o no ha
funcionado.

1016
00:54:29.739 --> 00:54:31.946
Aquí hay una serie de prácticas que son
importantes.

1017
00:54:32.146 --> 00:54:32.923
Primero.

1018
00:54:33.123 --> 00:54:35.166
Todo está en control de versiones.

1019
00:54:35.366 --> 00:54:36.828
No hay nada que no esté en control de
versiones.

1020
00:54:37.028 --> 00:54:42.416
O sea, tienes un dibujillo así pequeño que
lo vas a utilizar en algún sitio de la

1021
00:54:42.416 --> 00:54:44.559
web, está en control de versiones.

1022
00:54:44.759 --> 00:54:45.759
Está ahí, ¿vale?

1023
00:54:45.099 --> 00:54:49.243
Segundo, compilas una únicamente una vez y
lo haces para todos los entornos por los

1024
00:54:49.243 --> 00:54:50.507
que vas a pasar tu build.

1025
00:54:50.707 --> 00:54:53.431
Es decir, no tienes X compilaciones cada
vez.

1026
00:54:53.631 --> 00:54:56.815
Si necesitas tener X compilaciones cada
vez, cambia el código.

1027
00:54:57.015 --> 00:54:58.978
Mete un parámetro y haz que vaya por
parámetros.

1028
00:54:59.178 --> 00:55:01.704
la típica cadena de conexión que dejas
dentro del código.

1029
00:55:01.904 --> 00:55:04.831
Sácala fuera y esa cadena de conexión la
cambias por parámetro cada vez.

1030
00:55:05.031 --> 00:55:11.550
Así haces que una herramienta de deploy no
necesite que tú intervengas para nada.

1031
00:55:11.750 --> 00:55:14.114
Segundo, haz un check-in frecuentemente.

1032
00:55:14.314 --> 00:55:17.680
Tú haces check-in de tus cambios con
cierta frecuencia.

1033
00:55:17.880 --> 00:55:22.408
Luego, si tienes código que te falla en tu
local, no lo subas.

1034
00:55:22.608 --> 00:55:24.251
Hasta que tú lo arregles, no lo subas.

1035
00:55:24.451 --> 00:55:27.055
Segundo, si no lo has probado, no lo
subas.

1036
00:55:27.255 --> 00:55:29.720
Aunque yo te esté dando ahí, no lo subas.

1037
00:55:29.920 --> 00:55:32.865
Tercero, no hagas check-in mientras la
build está rota.

1038
00:55:33.065 --> 00:55:36.655
Porque si él sube código y resulta que
rompe la build, luego le va a tocar

1039
00:55:36.655 --> 00:55:37.655
arreglarlo.

1040
00:55:37.552 --> 00:55:41.029
arreglarlo o devolverlo al estado
anterior, que para eso está en control de

1041
00:55:41.029 --> 00:55:42.029
versiones todo, ¿vale?

1042
00:55:42.083 --> 00:55:46.213
Y entonces, si mientras está arreglando tú
subes código, tú vas a fallar igual y tal.

1043
00:55:46.413 --> 00:55:51.329
Los sistemas de control de integración
continua frustran al equipo cuando la vida

1044
00:55:51.329 --> 00:55:52.927
está permanentemente rota.

1045
00:55:53.127 --> 00:55:55.311
Cuando la piel está permanentemente rota,
estamos muertos.

1046
00:55:55.511 --> 00:55:58.936
No tenemos práctica, no estamos trabajando
con esto, olvídate.

1047
00:55:59.136 --> 00:56:00.839
Aquí hay alguien que no hace su trabajo.

1048
00:56:01.039 --> 00:56:06.288
Y por eso decía que los modelos ágiles son
de mucha presión lateral.

1049
00:56:06.488 --> 00:56:11.448
Es decir, tú no puedes hacer tu trabajo
porque aquel señor, y perdón que señale,

1050
00:56:11.448 --> 00:56:15.602
no sé ni quién eres, pero todavía, pero no
has hecho la que te tocaba.

1051
00:56:15.802 --> 00:56:19.926
Entonces, bueno, pues este señor tenía que
ir más tarde a su casa ese día.

1052
00:56:20.498 --> 00:56:24.553
Y el último, no te vayas a casa después de
un check-in que rompe la vida.

1053
00:56:24.753 --> 00:56:25.376
No lo hagas.

1054
00:56:25.576 --> 00:56:30.810
Arréglalo, porque si no, mañana por la
mañana nadie va a poder trabajar.

1055
00:56:31.079 --> 00:56:35.666
Lo que es continuous delivery, o entrega
continua, de un vistazo es un poco esto.

1056
00:56:35.866 --> 00:56:37.389
Es decir, ya se ha hecho la build, ¿no?

1057
00:56:37.589 --> 00:56:40.774
Ya tenemos algo que se ha compilado, que
han pasado las pruebas unitarias.

1058
00:56:40.974 --> 00:56:43.878
Normalmente las pruebas unitarias se
asocian a nivel de build, están ahí.

1059
00:56:44.078 --> 00:56:48.027
Una prueba unitaria, como Dios manda,
según dicen los libros, no toca el sistema

1060
00:56:48.027 --> 00:56:49.787
de archivos, no toca la base de datos.

1061
00:56:49.987 --> 00:56:52.752
Es decir, toca lo que es el código como
tal.

1062
00:56:52.952 --> 00:56:54.674
Si sumas 2 más 2, te da 4 y ahí te quedas.

1063
00:56:54.874 --> 00:56:57.419
Llamas con un JUnit a la clase y te da 4.

1064
00:56:57.619 --> 00:57:00.765
Pero no te vas a buscar los datos a ningún
sitio.

1065
00:57:00.965 --> 00:57:04.295
Pero lo que sí que tienes es, a partir de
lo que sería la build, un conjunto de

1066
00:57:04.295 --> 00:57:07.242
entornos donde ya sí, ahí vas a hacer
pruebas de interfaz, donde vas a

1067
00:57:07.242 --> 00:57:10.786
automatizar cosas contra la interfaz, vas
a mirar cosas en las bases de datos, vas a

1068
00:57:10.786 --> 00:57:12.016
cargar datos, etcétera, etcétera.

1069
00:57:12.216 --> 00:57:13.237
Y hay un conjunto de entornos.

1070
00:57:13.437 --> 00:57:17.280
Entonces, la parte de automatización de
pruebas es tremendamente importante aquí.

1071
00:57:17.480 --> 00:57:21.603
Si la automatización de pruebas no
funciona, lo que es la definición de DAN,

1072
00:57:21.603 --> 00:57:25.128
que es otro paradigma del modelo, pues
tampoco se puede implementar.

1073
00:57:25.328 --> 00:57:29.842
La definición de DAN, hecho, es cuando
entre todos llegáis a la conclusión de que

1074
00:57:29.842 --> 00:57:31.140
una tarea ha terminado.

1075
00:57:31.340 --> 00:57:35.861
Y eso normalmente se toma a nivel
corporativo, es decir, la integración está

1076
00:57:35.861 --> 00:57:40.864
ok cuando todas las pruebas unitarias han
pasado y tenemos pruebas unitarias para el

1077
00:57:40.864 --> 00:57:45.506
90% de los métodos que estamos utilizando
Por ejemplo, algo así podría ser una

1078
00:57:45.506 --> 00:57:50.088
definición de hecho, bueno, para la parte
de integración, pues igual para las

1079
00:57:50.088 --> 00:57:54.850
pruebas que se harían a continuación Una
vez que esto pasa, y aquí hay deploys o

1080
00:57:54.850 --> 00:57:58.308
modelos de deploy automáticos, es decir,
cuando se produce que

1081
00:57:58.508 --> 00:58:01.978
Aquí hay un modelo que se llama de
propagación, es decir, yo he hecho las

1082
00:58:01.978 --> 00:58:05.930
pruebas de integración, han funcionado, se
puede propagar esto al siguiente entorno

1083
00:58:05.930 --> 00:58:07.293
que sea las pruebas de interfaz.

1084
00:58:07.493 --> 00:58:10.665
Las pruebas de interfaz normalmente son un
conjunto de pruebas automatizadas y luego

1085
00:58:10.665 --> 00:58:11.665
algunas otras manuales.

1086
00:58:11.605 --> 00:58:13.310
Normalmente las pruebas que

1087
00:58:13.510 --> 00:58:17.109
Tu prueba de forma manual solo que
modificas en lo que sería cada uno de los

1088
00:58:17.109 --> 00:58:20.805
incrementos y las pruebas, digamos,
regresivas o no regresivas son lo que hace

1089
00:58:20.805 --> 00:58:21.861
de forma automatizada.

1090
00:58:22.061 --> 00:58:23.944
Es algo que es muy común en el mercado.

1091
00:58:24.144 --> 00:58:29.274
Entonces, esto pasa así, hay un deploy a
un entorno que debe existir, que es el

1092
00:58:29.274 --> 00:58:33.616
entorno de UAT o el entorno de staging,
que le llaman los ingleses.

1093
00:58:33.816 --> 00:58:36.480
Ahí se produce una validación, alguien lo
firma y eso se va.

1094
00:58:36.680 --> 00:58:37.680
a producción.

1095
00:58:37.861 --> 00:58:42.964
El irse a producción le llaman release y
también el conjunto de cambios que se

1096
00:58:42.964 --> 00:58:48.398
producen en una release concreta también
le llaman release, lo cual a veces crea un

1097
00:58:48.398 --> 00:58:49.398
conflicto.

1098
00:58:49.413 --> 00:58:52.656
Pero bueno, se entrega y se entrega.

1099
00:58:52.856 --> 00:58:56.963
El delivery pipeline son todos los
entornos por los cuales tiene que pasar

1100
00:58:56.963 --> 00:59:00.564
una aplicación antes de que esa aplicación
pueda ir a producción.

1101
00:59:00.764 --> 00:59:04.728
Y eso depende del modelo de calidad que
cada organización se haya dado.

1102
00:59:04.928 --> 00:59:07.191
Y ahí pues estamos.

1103
00:59:07.391 --> 00:59:13.109
Entonces, hay un concepto interesante que
es el de Continuous Deployment, que es lo

1104
00:59:13.109 --> 00:59:15.581
que hace gente como Netflix y demás.

1105
00:59:15.781 --> 00:59:20.273
Y lo que hacen es que ellos tienen
automatizado todo el proceso y se hace el

1106
00:59:20.273 --> 00:59:24.765
código, se hacen las pruebas unitarias, se
integran, se hacen las pruebas de

1107
00:59:24.765 --> 00:59:28.958
aceptación automatizadamente y se pone en
producción automatizadamente.

1108
00:59:29.158 --> 00:59:31.121
Entonces, esto es un modelo de Continuous
Deployment.

1109
00:59:31.321 --> 00:59:36.267
Entonces, hay veces en los que un modelo
de Continuous Deployment, que da mucho

1110
00:59:36.267 --> 00:59:41.213
miedo a operaciones, por lo general, pues
tiene sentido cuando la has hecho 300

1111
00:59:41.213 --> 00:59:43.380
veces y la 301, pues ya confías, ¿no?

1112
00:59:43.580 --> 00:59:44.822
Esto funciona, ¿no?

1113
00:59:45.022 --> 00:59:48.260
Entonces, nosotros lo que le decimos a
nuestros clientes es que cuando tienes

1114
00:59:48.260 --> 00:59:51.455
cambios que tienen una naturaleza
cosmética, sobre aplicaciones no críticas,

1115
00:59:51.455 --> 00:59:54.906
hay muy pocas situaciones de negocio donde
una organización empresarial se meta en

1116
00:59:54.906 --> 00:59:55.759
este jardín, ¿no?

1117
00:59:55.959 --> 00:59:57.682
Lo que sí funciona es el modelo de
Continuous Delivery.

1118
00:59:57.882 --> 01:00:01.880
El modelo de continuous delivery lo que
dice es que la aplicación en el entorno de

1119
01:00:01.880 --> 01:00:05.138
UAT debe ser posible de ponerla en
producción en cualquier momento.

1120
01:00:05.338 --> 01:00:09.938
O sea, si el negocio dice, me pasa esto,
ponla en producción, debe ser posible ser

1121
01:00:09.938 --> 01:00:11.071
puesta en producción.

1122
01:00:11.271 --> 01:00:17.325
Es el modelo de constante entrega que esto
plantea.

1123
01:00:17.525 --> 01:00:23.525
Aquí prácticamente lo clave es que los
movimientos entre entornos se hagan

1124
01:00:23.525 --> 01:00:30.102
siempre con modelos que sean consistentes,
siempre se hace de la misma manera.

1125
01:00:30.302 --> 01:00:34.891
Si tienes que pasar del entorno A al
entorno B, hay un modelo de scripting, hay

1126
01:00:34.891 --> 01:00:39.304
algo que se ha hecho de alguna manera,
algún tipo de solución, de deployment

1127
01:00:39.304 --> 01:00:43.380
automation, que es capaz de hacer esa
migración de una forma automatizada.

1128
01:00:43.580 --> 01:00:45.483
Y normalmente esto, ¿quién lo automatiza?

1129
01:00:45.683 --> 01:00:46.683
Pues los señores de operación.

1130
01:00:46.685 --> 01:00:51.049
Por lo general ellos ya lo hacen de forma
muchas veces manual, otras veces lo hacen

1131
01:00:51.049 --> 01:00:55.413
con scripting que ellos mismos se cocinan,
algunas veces con scripting interactivo,

1132
01:00:55.413 --> 01:00:59.725
que está muy bien porque les pide cosas,
con lo cual ya no es escalable para nada,

1133
01:00:59.725 --> 01:01:04.089
y normalmente es el librillo de alguien, y
aquí lo que se plantea es decir, no, no,

1134
01:01:04.089 --> 01:01:08.134
siempre que haya un cambio entre un
entorno y otro, esto se va a automatizar,

1135
01:01:08.134 --> 01:01:10.403
y se va a automatizar de una forma
determinada.

1136
01:01:10.603 --> 01:01:12.403
Ya, ya, ya, ya.

1137
01:01:13.685 --> 01:01:17.895
Bien, bueno, métricas y luego decimos,
vale, todo esto, imaginaos que lo hacemos,

1138
01:01:17.895 --> 01:01:22.317
tenemos pruebas automatizadas, tenemos una
integración continua, tenemos un modelo de

1139
01:01:22.317 --> 01:01:26.422
planificación continua, tenemos a los
equipos organizados de una manera que nos

1140
01:01:26.422 --> 01:01:29.243
permiten colaborar entre desarrollo y
operación y QA, ¿no?

1141
01:01:29.443 --> 01:01:30.443
Y vale, ¿qué hacemos?

1142
01:01:30.425 --> 01:01:31.425
Medimos.

1143
01:01:31.353 --> 01:01:34.834
Me acuerdo una vez en Turquía que un
cliente me decía, después de hacer todo

1144
01:01:34.834 --> 01:01:36.599
esto, tengo peores métricas que antes.

1145
01:01:36.799 --> 01:01:39.883
Claro, porque todos los modelos son, esto
también puede llegar a pasar, claro.

1146
01:01:40.083 --> 01:01:43.047
O sea, tengo peores métricas de referencia
que antes, ¿no?

1147
01:01:43.247 --> 01:01:46.685
Y claro, puede pasar, puede pasar, pero yo
le achacaba el problema a que la

1148
01:01:46.685 --> 01:01:49.983
implementación había sido una
implementación un poquillo así sui generis

1149
01:01:49.983 --> 01:01:52.818
y que había un AS400 de por medio que no
facilitaba las cosas.

1150
01:01:53.018 --> 01:01:56.469
Pero en cualquier caso, a este señor yo le
tengo mucho cariño, el que inventó la

1151
01:01:56.469 --> 01:01:57.469
calidad total.

1152
01:01:57.323 --> 01:01:59.610
Si no habéis leído nada de él, hacedlo.

1153
01:01:59.810 --> 01:02:01.675
Es muy importante para vuestras vidas.

1154
01:02:01.875 --> 01:02:05.086
Él lo que dice es que él cree en Dios,
todos los demás que vengan con

1155
01:02:05.086 --> 01:02:06.692
información, que vengan con datos.

1156
01:02:06.892 --> 01:02:12.892
y de hecho lo que tiene que ver con la
mejora de la calidad total basada en datos

1157
01:02:12.892 --> 01:02:18.892
le debe mucho a este individuo Aquí hay un
informe que habla de cuatro métricas clave

1158
01:02:18.892 --> 01:02:24.892
dentro de lo que sería esta industria que
sería la frecuencia de despliegue, cada

1159
01:02:24.892 --> 01:02:31.177
cuánto tiempo eres capaz de hacer un
despliegue si el negocio lo necesita

1160
01:02:31.377 --> 01:02:36.975
El tiempo desde que alguien te pide algo
hasta que ese algo esté implementado en

1161
01:02:36.975 --> 01:02:38.308
producción.

1162
01:02:38.508 --> 01:02:39.910
¿Cuánto es?

1163
01:02:40.110 --> 01:02:44.731
El último es, el tercero es el mean time
to recover, que es el tiempo desde que un

1164
01:02:44.731 --> 01:02:47.641
error se produce hasta que eres capaz de
levantarlo.

1165
01:02:47.841 --> 01:02:49.164
¿Cuánto tiempo pasa en medio?

1166
01:02:49.364 --> 01:02:53.570
Y el último es el ratio de errores tras
cambio.

1167
01:02:53.770 --> 01:02:58.432
A veces le llamamos la cola del cambio, es
decir, tú pones un cambio en producción y

1168
01:02:58.432 --> 01:02:59.781
eso luego tiene errores.

1169
01:02:59.981 --> 01:03:01.444
¿Cada cuántas veces te pasa esto?

1170
01:03:01.644 --> 01:03:03.007
¿Cómo se organiza esto?

1171
01:03:03.207 --> 01:03:06.655
Entonces, cuando llegues a una
organización que trabaja tipo waterfall y

1172
01:03:06.655 --> 01:03:09.439
le preguntas estos datos, por lo general
no te lo saben decir.

1173
01:03:09.639 --> 01:03:10.639
No te lo saben decir.

1174
01:03:10.280 --> 01:03:13.756
Yo tuve un proyecto que hicimos hace muy
poco tiempo, el año pasado, y empezamos a

1175
01:03:13.756 --> 01:03:16.271
trabajar con esto y le dijimos, venga,
dame esta información.

1176
01:03:16.471 --> 01:03:17.471
Y era...

1177
01:03:17.513 --> 01:03:21.119
tengo que verme 150 peticiones que se
empaquetan entre índices que claro muchas

1178
01:03:21.119 --> 01:03:24.771
veces la petición está hecha pero como no
voy a poner en producción hasta el mes

1179
01:03:24.771 --> 01:03:28.563
siguiente pues como si estuviera esperando
para la puesta en producción entonces lo

1180
01:03:28.563 --> 01:03:32.308
contamos no lo contamos pues sí claro lo
cuentas porque realmente el cliente te ha

1181
01:03:32.308 --> 01:03:36.099
pedido algo hoy y lo estás poniendo dentro
de dos meses pero sólo cuentas aunque lo

1182
01:03:36.099 --> 01:03:37.099
tengas hecho

1183
01:03:37.004 --> 01:03:40.191
Si te lo pido hoy, tengas hecho mañana, da
lo mismo.

1184
01:03:40.391 --> 01:03:42.896
Realmente es cuando el cliente lo puede
utilizar.

1185
01:03:43.096 --> 01:03:44.559
Bueno, pues, eso son un poco las medias.

1186
01:03:44.759 --> 01:03:48.646
Y, bueno, en el informe que os cito, pues,
se habla de high performance y low

1187
01:03:48.646 --> 01:03:49.670
performance y demás.

1188
01:03:49.870 --> 01:03:53.620
En general, lo que se dice de los high
performance es que, hombre, eres capaz de

1189
01:03:53.620 --> 01:03:55.822
poner en producción bajo demanda cuando te
lo piden.

1190
01:03:56.022 --> 01:04:01.327
que realmente el tiempo medio del lead
time es menor de una hora, esto es una

1191
01:04:01.327 --> 01:04:06.900
barbaridad bajo mi punto de vista, y que
luego eres capaz de recuperarte en menos

1192
01:04:06.900 --> 01:04:12.339
de una hora y que realmente tienes un
ratio de errores tras fallos entre un 0 y

1193
01:04:12.339 --> 01:04:13.579
un 15%.

1194
01:04:13.779 --> 01:04:17.186
Son cosas que cuando voy a organizaciones
les digo, mira,

1195
01:04:17.386 --> 01:04:18.408
¿Qué tenéis a día de hoy?

1196
01:04:18.608 --> 01:04:19.608
¿Qué podemos mejorar?

1197
01:04:19.570 --> 01:04:22.775
Y vamos a trabajar sobre esto y vamos a
ver cuál es el cuello de botella con el

1198
01:04:22.775 --> 01:04:23.775
modelo de DevOps.

1199
01:04:23.617 --> 01:04:26.582
Y en base a eso vemos si lo que hay que
hacer es mejorar en planificación o

1200
01:04:26.582 --> 01:04:28.105
mejorar el modelo de integración continua.

1201
01:04:28.305 --> 01:04:32.527
Integración continua es un candidato claro
de empezar a trabajar por ahí o un modelo

1202
01:04:32.527 --> 01:04:35.428
de despliegue continuo dependiendo de cuál
sea la madurez.

1203
01:04:35.628 --> 01:04:38.633
Estos de aquí los tenéis que conocer si
queréis meternos en este jardín.

1204
01:04:38.853 --> 01:04:40.476
Básicamente, el lead time ya lo he
definido.

1205
01:04:40.676 --> 01:04:44.936
Cycle time consiste en desde que te pones
a trabajar en algo hasta que lo terminas,

1206
01:04:44.936 --> 01:04:45.936
¿vale?

1207
01:04:45.845 --> 01:04:47.448
Hasta que lo entregas al cliente.

1208
01:04:47.648 --> 01:04:50.727
Y luego el wait time es el tiempo que
desde que te han pedido algo hasta que has

1209
01:04:50.727 --> 01:04:53.197
empezado a trabajar, pues, bueno, pues
todo ese tiempo de espera, ¿no?

1210
01:04:53.397 --> 01:04:56.720
que normalmente ese tiempo de espera es
una especie de inventario en términos de

1211
01:04:56.720 --> 01:04:57.562
stock.

1212
01:04:57.803 --> 01:05:01.295
Es decir, es algo que se acumula delante
de una máquina y que no somos capaces de

1213
01:05:01.295 --> 01:05:02.295
ejecutar.

1214
01:05:02.209 --> 01:05:07.490
Normalmente cuando tenemos grandes tiempos
de espera, tenemos como podencos, sabuesos

1215
01:05:07.490 --> 01:05:11.020
o podencos, que apuntan a lo que sería el
cuello de botella.

1216
01:05:11.220 --> 01:05:13.984
Normalmente ahí lo tenemos.

1217
01:05:14.184 --> 01:05:15.184
Y algunas otras más.

1218
01:05:15.025 --> 01:05:16.448
Una interesante es WIP.

1219
01:05:16.648 --> 01:05:20.910
El WIP es el trabajo que está en curso, es
decir, todas las historias de usuario que

1220
01:05:20.910 --> 01:05:23.016
están en curso en un momento determinado.

1221
01:05:23.266 --> 01:05:28.648
Entonces, hay modelos como Scrum que lo
que hacen es crear un modelo de backlog de

1222
01:05:28.648 --> 01:05:33.518
sprint y tienes que ejecutar ese sprint en
base a la velocidad que ya tienes.

1223
01:05:33.718 --> 01:05:36.066
Estás suponiendo que vas a ser capaz de
ejecutarlo en el tiempo que dura el

1224
01:05:36.066 --> 01:05:37.066
sprint.

1225
01:05:36.721 --> 01:05:40.558
Y hay modelos como Kanban que lo que hacen
es decirte, bueno, pues yo lo que tengo es

1226
01:05:40.558 --> 01:05:43.892
un WIP, yo tengo una capacidad de
ejecución de tareas en paralelo y yo voy

1227
01:05:43.892 --> 01:05:46.773
tirando de lo que sería ese backlog de
producto y voy implementando.

1228
01:05:46.973 --> 01:05:52.038
Y cuando llega el momento de cortar, pues
cortamos y hacemos el incremento

1229
01:05:52.038 --> 01:05:53.238
entregable.

1230
01:05:53.438 --> 01:05:55.461
Bueno, esto ni lo cito.

1231
01:05:55.661 --> 01:06:00.833
Esto es, a ver, estuve en una conferencia
no hace mucho que era la DevOps Summit que

1232
01:06:00.833 --> 01:06:05.756
se hace en Londres todos los años y estas
cuatro métricas que os he contado, las

1233
01:06:05.756 --> 01:06:09.478
principales que salían en el informe este,
las repetían todos.

1234
01:06:09.678 --> 01:06:14.484
Hemos sido capaces de pasar de una entrega
cada dos meses a una entrega al mes.

1235
01:06:14.684 --> 01:06:19.241
Ese tipo de cosas se utilizan un poco para
comparar organizaciones la una con la

1236
01:06:19.241 --> 01:06:20.241
otra.

1237
01:06:20.151 --> 01:06:23.839
Y aquí en particular lo que habla es que
los high performers han rescatado un

1238
01:06:23.839 --> 01:06:26.960
montón de tiempo y lo han hecho súper bien
y que están muy contentos.

1239
01:06:27.160 --> 01:06:31.985
Es un poco injusto porque no tienes mucho
el contexto de lo que es la organización,

1240
01:06:31.985 --> 01:06:34.630
cómo está organizado y luego qué partes
trabajan.

1241
01:06:34.830 --> 01:06:37.114
Entonces, bueno, es algo que por ahí va.

1242
01:06:37.314 --> 01:06:41.315
Entonces, por último, y ya para que ya os
aburráis del todo

1243
01:06:41.515 --> 01:06:43.658
Esto es chulo para un grupo, ¿verdad?

1244
01:06:43.858 --> 01:06:47.762
Porque para un grupo, aquí entre los que
somos, estamos ya en el límite, ¿eh?

1245
01:06:47.962 --> 01:06:52.228
Nos montamos un grupo y podemos trabajar
en un modelo DevOps más o menos bien.

1246
01:06:52.428 --> 01:06:55.451
Nos montamos una fintech y ganamos pasta.

1247
01:06:55.651 --> 01:07:01.651
Pero, ¿qué pasa si es Telefónica quien lo
hace o es el banco de Bilbao o es Deutsche

1248
01:07:01.651 --> 01:07:07.425
Bank o Express Bank o cualquiera de estos
que son monstruos de tecnología?

1249
01:07:07.625 --> 01:07:10.374
Bueno, pues si pasa eso, esto es lo que
decía antes,

1250
01:07:10.574 --> 01:07:16.128
Gartner en 2014 decía que el año pasado el
75% de las compañías iba a tener un modelo

1251
01:07:16.128 --> 01:07:21.485
bimodal, es decir, que iban a convivir los
modelos de Waterfall con los modelos de

1252
01:07:21.485 --> 01:07:22.477
Agile.

1253
01:07:22.677 --> 01:07:24.160
Eso está ya sobrepasado.

1254
01:07:24.360 --> 01:07:28.588
Casi todas las organizaciones tienen ya
equipos que trabajan en metodología Agile.

1255
01:07:28.789 --> 01:07:32.902
En banca es muy típico trabajar en banca
móvil, banca online con todo esto.

1256
01:07:33.102 --> 01:07:34.102
¿Por qué?

1257
01:07:33.382 --> 01:07:36.800
Porque la banca móvil es un sistema de
diferenciación, de innovación o de

1258
01:07:36.800 --> 01:07:37.800
diferenciación.

1259
01:07:37.767 --> 01:07:42.428
Es decir, BBVA utiliza su app como
elemento clave de vinculación con los

1260
01:07:42.428 --> 01:07:43.413
clientes.

1261
01:07:43.613 --> 01:07:47.215
Y es porque, claro, como los préstamos y
los tipos de interés no los puede utilizar

1262
01:07:47.215 --> 01:07:50.730
al precio que está el dinero, tiene que
buscar alternativas, que puedas pagar con

1263
01:07:50.730 --> 01:07:54.201
el móvil, que tengas información de si
alguien te ha cobrado en tiempo real algo

1264
01:07:54.201 --> 01:07:57.409
en tu tarjeta de crédito, etcétera,
etcétera, etcétera, que es algo que te

1265
01:07:57.409 --> 01:07:59.430
permite estar mucho más cerca de tu
entidad bancaria

1266
01:07:59.630 --> 01:08:04.452
no ya por lo duro del negocio, que es el
préstamo, sino por algo que tiene que ver

1267
01:08:04.452 --> 01:08:08.082
con las emociones y la vinculación que tú
tengas con la compañía.

1268
01:08:08.282 --> 01:08:11.198
Entonces, el sistema de diferenciación o
de innovación, los sistemas de innovación

1269
01:08:11.198 --> 01:08:12.198
son sistemas de exploración.

1270
01:08:12.287 --> 01:08:16.563
Yo invento, creo algo, que lo publico, no
tengo mucha información, creo que aquello

1271
01:08:16.563 --> 01:08:20.474
puede ayudarme y voy viendo si me va
ayudando o no y si me va ayudando, pues

1272
01:08:20.474 --> 01:08:23.583
oye, ya lo voy formalizando y creando algo
un poco más serio.

1273
01:08:23.783 --> 01:08:27.088
Pero necesito que sea algo rápido, porque
si no es algo rápido no me funcionará.

1274
01:08:27.288 --> 01:08:28.288
¿Vale?

1275
01:08:27.608 --> 01:08:31.429
Bueno, pues todo esto son trabajado
básicamente con modalidad ágil y

1276
01:08:31.429 --> 01:08:35.936
básicamente los sistemas de registro, que
son los mainframes, los SAP de toda la

1277
01:08:35.936 --> 01:08:40.499
vida, pues bueno, que tienen la operativa
bancaria, reglas de negocio, las reglas

1278
01:08:40.499 --> 01:08:44.949
del scoring de clientes, lo que está
operando el backbone, todo esto, pues esto

1279
01:08:44.949 --> 01:08:49.113
está a la facturación, procesos que corren
en batch muchas veces, eso está

1280
01:08:49.113 --> 01:08:53.514
normalmente en sistemas de registro y se
sigue trabajando con un modelo Waterfall.

1281
01:08:53.714 --> 01:08:58.595
Los que empezaron a trabajar con esto y
empezaron a dar la brasa con DevOps fueron

1282
01:08:58.595 --> 01:08:59.595
estos tres.

1283
01:08:59.566 --> 01:09:03.771
Spotify en particular tiene un caso que
podéis buscar en internet si os interesa

1284
01:09:03.771 --> 01:09:07.923
sobre cómo organizar equipos y empezaron a
crear por sus propios rituales y sus

1285
01:09:07.923 --> 01:09:08.923
propias formas.

1286
01:09:08.924 --> 01:09:14.272
Netflix, Facebook, ellos hacen despliegues
masivos de una forma automatizada y ahora

1287
01:09:14.272 --> 01:09:16.464
veremos por qué pueden hacer esto.

1288
01:09:16.664 --> 01:09:21.165
Pero la verdad es que cuando tú esto lo
comparas con compañías como las que he

1289
01:09:21.165 --> 01:09:25.257
dicho antes, pues se produce el hartazgo
de los directores de los CIOs.

1290
01:09:25.457 --> 01:09:26.457
Dicen, bueno, ¿qué me estás contando?

1291
01:09:26.419 --> 01:09:27.560
Yo no soy Netflix.

1292
01:09:27.760 --> 01:09:28.760
¿Por qué?

1293
01:09:27.981 --> 01:09:32.607
Pues porque Netflix en particular es una
aplicación única, mientras que los señores

1294
01:09:32.607 --> 01:09:37.120
que hemos dicho antes o las mujeres que
hemos dicho antes que están dirigiendo el

1295
01:09:37.120 --> 01:09:40.680
Santander, por ejemplo, pues tienen
cientos de aplicaciones, no una.

1296
01:09:40.880 --> 01:09:45.956
porque los equipos están normalmente aquí
todos en el mismo sitio en las grandes

1297
01:09:45.956 --> 01:09:50.583
compañías son equipos que están
distribuidos porque la infraestructura es

1298
01:09:50.583 --> 01:09:55.338
normalmente única en Netflix es algo que
es muy concreto en nuestro caso la

1299
01:09:55.338 --> 01:10:00.093
compañía está operando con múltiples
aplicaciones con múltiples entornos en

1300
01:10:00.093 --> 01:10:03.022
Mainframe incluido algunos muy altamente
acoplados

1301
01:10:03.222 --> 01:10:05.588
Es decir, realmente no estamos hablando de
lo mismo.

1302
01:10:05.828 --> 01:10:10.135
Cuando coges el paradigma de Netflix y te
lo llevas al Banco de Santander, pues te

1303
01:10:10.135 --> 01:10:11.944
hacen con el paradigma de Netflix.

1304
01:10:12.144 --> 01:10:14.530
Más de hecho, yo he tenido conversaciones
con miembros de...

1305
01:10:14.730 --> 01:10:16.758
Tuve una con BBVA muy interesante en...

1306
01:10:16.958 --> 01:10:20.481
en Londres, que era en el evento este, que
me decían, claro, estos tíos me están

1307
01:10:20.481 --> 01:10:24.004
diciendo que organice equipos de Scrum y
que meta aquí técnicos de sistemas y de

1308
01:10:24.004 --> 01:10:24.896
bases de datos.

1309
01:10:25.096 --> 01:10:29.111
Pero si yo no tengo 25.000 técnicos de
bases de datos Oracle para trabajar en

1310
01:10:29.111 --> 01:10:30.111
esto.

1311
01:10:30.007 --> 01:10:31.007
O DB2.

1312
01:10:31.129 --> 01:10:32.129
Es que no tengo los recursos.

1313
01:10:32.092 --> 01:10:33.435
¿Qué me está diciendo?

1314
01:10:33.635 --> 01:10:34.798
¿Cómo lo puedo implementar?

1315
01:10:34.998 --> 01:10:38.565
Entonces, bueno, los modelos ágiles de
compañías más pequeñas o más startups no

1316
01:10:38.565 --> 01:10:42.088
tienen mucho que ver con los modelos
ágiles que se pueden llegar a implementar

1317
01:10:42.088 --> 01:10:43.369
dentro de grandes compañías.

1318
01:10:43.610 --> 01:10:48.697
Hay que llegar a compromisos de una forma
un poco determinada.

1319
01:10:48.897 --> 01:10:52.041
Hay retos que son sobre todo culturales.

1320
01:10:52.241 --> 01:10:57.666
Yo cuando me acerco a una compañía, el
último assessment que hice que fue hace un

1321
01:10:57.666 --> 01:11:03.025
año, en una banca media aquí en España, en
el norte, el problema era básicamente

1322
01:11:03.025 --> 01:11:04.498
cultural y organizativo.

1323
01:11:04.698 --> 01:11:08.883
Ellos tenían contratos de outsourcing con
un departamento de operación que tenía

1324
01:11:08.883 --> 01:11:13.334
además un modelo de SLA que no les impedía
hacer ningún tipo de transformación dentro

1325
01:11:13.334 --> 01:11:14.334
de ese departamento.

1326
01:11:14.414 --> 01:11:17.498
Con lo cual ellos decían yo tengo un
contrato, si quieres cambiar tu forma de

1327
01:11:17.498 --> 01:11:20.445
trabajar conmigo tienes que cambiar el
contrato y tengo cinco años de contrato.

1328
01:11:20.645 --> 01:11:24.674
Con lo cual era todo muy complicado de
gestionar y llevarlo a un modelo de

1329
01:11:24.674 --> 01:11:25.674
DevOps.

1330
01:11:25.591 --> 01:11:29.596
A nivel de cultura, todo el concepto este
de culpa o mejora es algo que tiene que

1331
01:11:29.596 --> 01:11:31.038
estar dentro de la organización.

1332
01:11:31.238 --> 01:11:34.998
No puedes estar buscando culpables todo el
rato porque si no, de verdad, un modelo

1333
01:11:34.998 --> 01:11:36.624
basado en la confianza no funciona.

1334
01:11:36.824 --> 01:11:41.648
Y luego, lo que más se ve, que son las
herramientas y los stacks de herramientas

1335
01:11:41.648 --> 01:11:44.458
de DevOps, es quizás el menor de los
problemas.

1336
01:11:44.658 --> 01:11:45.661
Porque hay tanta variedad.

1337
01:11:45.861 --> 01:11:51.861
Quizá aquí el reto es de verdad elegir un
stack que sea medianamente corporativo y

1338
01:11:51.861 --> 01:11:54.420
por el cual apostemos.

1339
01:11:54.620 --> 01:11:56.344
Esto por ejemplo lo que ha hecho BBVA.

1340
01:11:56.544 --> 01:12:00.372
BBVA se ha montado su pirámide, todo
basado en open source, pero es...

1341
01:12:00.605 --> 01:12:02.849
Son talibanes en ese aspecto, es la
pirámide.

1342
01:12:03.049 --> 01:12:04.973
No vamos aquí a inventar la rueda.

1343
01:12:05.173 --> 01:12:09.106
Porque lo que dicen estos modelos es que
para que estos cuatro tengan su compromiso

1344
01:12:09.106 --> 01:12:12.848
tienen que tener cierta capacidad de
decidir cómo van a trabajar y por lo tanto

1345
01:12:12.848 --> 01:12:16.878
al final se eligen utilizar un determinado
IDE, utilizan un determinado producto para

1346
01:12:16.878 --> 01:12:20.620
gestionar el backlog y utilizan subversión
porque Git les da grima, lo que sea.

1347
01:12:20.820 --> 01:12:23.625
Pero es que aquellos cuatro de allí han
elegido otra cosa, ¿no?

1348
01:12:23.825 --> 01:12:27.992
Y luego resulta que yo, que soy el gestor,
bueno, para algo soy el que habla, pues

1349
01:12:27.992 --> 01:12:30.333
digo, ¿y cómo consolido yo la información
de todo?

1350
01:12:30.533 --> 01:12:32.935
¿Y cómo puedo comunicarme con todos a la
vez?

1351
01:12:33.135 --> 01:12:35.498
Porque realmente se producen este tipo de
gaps.

1352
01:12:35.698 --> 01:12:39.356
Entonces, la parte tecnológica, donde de
verdad está el reto, es en la

1353
01:12:39.356 --> 01:12:43.545
estandarización y en el poder llevar a
escala soluciones que son suficientemente

1354
01:12:43.545 --> 01:12:47.681
buenas, pero que no tienen por qué ser
tampoco las mejores, no hay que volverse

1355
01:12:47.681 --> 01:12:48.633
locos.

1356
01:12:48.833 --> 01:12:54.730
Este es el modelo de Spotify, que habla de
tribus.

1357
01:12:54.930 --> 01:12:55.930
Ellos han creado su propio lenguaje.

1358
01:12:56.013 --> 01:12:59.934
Lo que dicen es que las distintas
aplicaciones tienen que organizarse por

1359
01:12:59.934 --> 01:13:03.635
esto que llaman squads, que son como
barcas, por decirlo de alguna forma.

1360
01:13:03.835 --> 01:13:07.746
piraguas, y que luego hay individuos que
están relacionados entre ellos que forman

1361
01:13:07.746 --> 01:13:11.030
parte de lo que sería el concepto de
propiedad pero que luego hay una

1362
01:13:11.030 --> 01:13:14.700
organización transversal también, es
decir, que hay como una especie de secta

1363
01:13:14.700 --> 01:13:18.564
de los administradores de bases de datos y
que estos tienen sus mejores prácticas

1364
01:13:18.564 --> 01:13:22.330
asociadas dentro de lo que llaman capítulo
y que luego hay un modelo también de

1365
01:13:22.330 --> 01:13:23.801
coordinación mayor que llaman guild

1366
01:13:24.001 --> 01:13:28.231
eso cuando lo intentas mapear en una
organización grande es muy complicado de

1367
01:13:28.231 --> 01:13:32.406
llevar a par hay que buscar otro tipo de
alternativas pero son cosas que son

1368
01:13:32.406 --> 01:13:36.692
fuentes de inspiración habituales para el
modelo en general DevOps y todos los

1369
01:13:36.692 --> 01:13:40.866
fabricantes lo que decimos es que no
busques implementar ningún modelo o sea

1370
01:13:40.866 --> 01:13:45.431
cuando te dicen automatízalo todo una cosa
que se dice muy frecuentemente en DevOps

1371
01:13:45.431 --> 01:13:46.431
pues no no hagas caso

1372
01:13:46.580 --> 01:13:52.040
de los blogs porque nadie ha implementado
nada en una gran compañía leyendo blogs

1373
01:13:52.040 --> 01:13:57.568
hay que siempre tener conocimiento y vivir
la experiencia cada uno un poco el reto

1374
01:13:57.568 --> 01:13:59.536
entonces a escala ¿qué sucede?

1375
01:13:59.736 --> 01:14:01.162
pues tenemos un equipo de producto

1376
01:14:01.362 --> 01:14:05.598
que convive con otro equipo de producto,
que se agrupa en una business unit, que

1377
01:14:05.598 --> 01:14:09.458
utiliza una cosa que llamamos Value
Stream, esto lo empezaréis a escuchar

1378
01:14:09.458 --> 01:14:13.426
ahora porque es un concepto nuevo que
Forrester está impulsando y que es al

1379
01:14:13.426 --> 01:14:17.716
final, eso que decía al principio del todo
que era el canal de valor, el flujo de

1380
01:14:17.716 --> 01:14:21.577
valor desde una idea hasta, pues es un
Value Stream por el cual pasan las

1381
01:14:21.577 --> 01:14:25.598
aplicaciones, hay aquí Value Stream que se
organizan en porfolios o quizá en

1382
01:14:25.598 --> 01:14:26.598
múltiples porfolios.

1383
01:14:26.711 --> 01:14:29.394
Todo esto a escala

1384
01:14:29.594 --> 01:14:33.913
lo que estábamos hablando antes, todo lo
que hemos hablado se aplicaba a ese scrum

1385
01:14:33.913 --> 01:14:38.179
team con ese release engineer hacía su
modelo de DevOps pero cuando esto escala a

1386
01:14:38.179 --> 01:14:42.072
nivel organizacional se necesitan
organismos de coordinación transversales

1387
01:14:42.072 --> 01:14:46.392
que a día de hoy no existen en la mayoría
de las organizaciones y que este tipo de

1388
01:14:46.392 --> 01:14:47.812
modelos pues están planteando.

1389
01:14:48.012 --> 01:14:53.710
Hay un modelo interesante que es éste éste
sí que es certificable y yo estoy

1390
01:14:53.710 --> 01:14:57.322
certificado por cierto en el cual pues
tienes el

1391
01:14:57.522 --> 01:15:02.029
lo que serían el modelo de scrums, de
programa, de solución y de portfolio y

1392
01:15:02.029 --> 01:15:05.695
donde ves cómo una gran compañía puede
llegar a implementar esto.

1393
01:15:05.895 --> 01:15:10.126
Esto es muy popular en Alemania, en
Alemania estamos trabajando muchísimo con

1394
01:15:10.126 --> 01:15:14.525
esto y aquí en España empieza a ser un
poco más popular ahora, pero realmente ya

1395
01:15:14.525 --> 01:15:17.031
os digo, en Alemania es tremendamente
popular.

1396
01:15:19.004 --> 01:15:22.770
Claro, a nivel de organización, cuando
tienes el modelo que he visto antes donde

1397
01:15:22.770 --> 01:15:26.203
hay muchos Scrum funcionando en paralelo,
que tiene muchas herramientas e

1398
01:15:26.203 --> 01:15:30.208
integraciones, tienes ciclos de prueba que
son en general más largos porque pasan por

1399
01:15:30.208 --> 01:15:33.927
distintas aplicaciones que tienen que
convivir en ello, tienes muchos pipelines

1400
01:15:33.927 --> 01:15:37.265
de despliegue compitiendo por los mismos
entornos, los mismos recursos.

1401
01:15:37.465 --> 01:15:41.207
Y en general, coexistencia con el
waterfall, quizá no tienes muy claro dónde

1402
01:15:41.207 --> 01:15:45.098
estás aplicando los dineros, que son muy
importantes, y luego tienes que seguir

1403
01:15:45.098 --> 01:15:46.496
cumpliendo con la normativa.

1404
01:15:46.696 --> 01:15:51.080
Y esto es algo que también este tipo de
modelos lo practican.

1405
01:15:52.063 --> 01:15:56.044
Esto forma parte del maremagnum de
productos que se pueden utilizar para

1406
01:15:56.044 --> 01:15:57.110
implementar DevOps.

1407
01:15:57.310 --> 01:16:02.956
Aquí siempre la recomendación que nosotros
hacemos, y desde Microfocus es lo último,

1408
01:16:02.956 --> 01:16:06.982
el único minuto musical que os digo, es
elige una plataforma...

1409
01:16:07.182 --> 01:16:12.004
Haz que la plataforma, garantízate que la
plataforma escala con tus necesidades y

1410
01:16:12.004 --> 01:16:16.526
una vez que tengas eso y que puedas
extraer información suficiente como para

1411
01:16:16.526 --> 01:16:21.529
poder hacer la analítica que necesitas y a
partir de ahí, pues oye, trabaja y crece,

1412
01:16:21.529 --> 01:16:26.232
pero haz foco básicamente en lo que tiene
que ver con organización y con lo que

1413
01:16:26.232 --> 01:16:28.624
tiene que ver con la adopción de
prácticas.

1414
01:16:28.824 --> 01:16:33.629
Si eso lo consigues, la plataforma será un
poco irrelevante.

1415
01:16:33.829 --> 01:16:36.648
Cuando ya la plataforma se convierta en el
cuello de botella, la cambias.

1416
01:16:36.848 --> 01:16:37.848
Es un poco también la clave.

1417
01:16:37.930 --> 01:16:41.036
Por lo tanto, cuando elijas una
plataforma, elíjela para poder cambiarla.

1418
01:16:41.236 --> 01:16:45.466
Es decir, que tenga un modelo de Open Data
que te permita extraer la información

1419
01:16:45.466 --> 01:16:47.930
histórica, que no te quedes enganchada en
ella.

1420
01:16:48.130 --> 01:16:50.875
Cuando eliges algo, elige algo que te
permita ser cambiado.

1421
01:16:51.075 --> 01:16:53.841
Esto es muy, muy relevante.

1422
01:16:54.041 --> 01:16:56.767
Y ya está.

1423
01:16:56.967 --> 01:16:59.432
El chiste me gusta, por eso siempre lo
pongo.

1424
01:16:59.632 --> 01:17:00.662
Pero bueno.

1425
01:17:00.862 --> 01:17:02.465
[Orador 5]: ¿Alguna pregunta tenéis?

1426
01:17:02.665 --> 01:17:08.471
Dos, porque Carlos tiene que estar a las 7
en un sitio y si no va a tener

1427
01:17:08.471 --> 01:17:11.078
dificultades, por favor.

1428
01:17:11.278 --> 01:17:16.831
[Orador 1]: Además me cuelgan, juego a 11 hasta las 7
y como no llegué somos 9 y ya paso al

1429
01:17:16.831 --> 01:17:20.051
infierno de los que dejan colgado el
equipo.

1430
01:17:20.251 --> 01:17:22.634
[Orador 3]: Tengo dos preguntas.

1431
01:17:22.834 --> 01:17:28.834
Hiciste la comparación de Waterford con
metodologías ágiles y no mencionaste la

1432
01:17:28.834 --> 01:17:30.825
documentación.

1433
01:17:31.025 --> 01:17:35.019
¿Cómo se gestiona la documentación de un
proyecto de software en metodologías

1434
01:17:35.019 --> 01:17:35.912
ágiles?

1435
01:17:36.112 --> 01:17:41.820
Te comento esto porque actualmente tenemos
una dificultad de...

1436
01:17:42.020 --> 01:17:48.020
de tener los repositorios de documentación
sobre las modificaciones que estamos

1437
01:17:48.020 --> 01:17:54.020
haciendo especialmente y se convierte un
poco en un caos al implementar una

1438
01:17:54.020 --> 01:18:01.985
metodología ágil porque eso precisamente
ralentiza

1439
01:18:02.185 --> 01:18:08.114
No eres tan ágil si documentas todas las
modificaciones que haces.

1440
01:18:08.314 --> 01:18:12.902
Esa es una pregunta y la otra, ¿cómo
calculas la velocidad del equipo?

1441
01:18:13.102 --> 01:18:19.102
Yo tengo también dificultades en calcular
un poco cuántos puntos, historias, puntos,

1442
01:18:19.102 --> 01:18:26.643
story points, mi equipo puede hacer en un
sprint.

1443
01:18:26.843 --> 01:18:29.087
Es difícil calcular esto.

1444
01:18:29.287 --> 01:18:30.389
[Orador 1]: Así que yo empiezo por la última.

1445
01:18:30.589 --> 01:18:35.037
El cálculo de los history points es un
reto, está claro, y es algo que es

1446
01:18:35.037 --> 01:18:36.397
inherente a tu equipo.

1447
01:18:36.617 --> 01:18:38.140
O sea, tu equipo tiene una velocidad.

1448
01:18:38.340 --> 01:18:43.062
Pero claro, también tienes que tener un
modelo estable de estimación de cuánto

1449
01:18:43.062 --> 01:18:45.250
cuesta un punto de historia para ti.

1450
01:18:45.450 --> 01:18:49.897
Entonces, siempre hay una discusión sobre
qué son puntos de historia o son horas.

1451
01:18:50.097 --> 01:18:53.527
Al final siempre son horas, porque lo que
tienes que tener es una capacidad en un

1452
01:18:53.527 --> 01:18:56.529
tiempo determinado de implementar un
número de historias y de puntos de

1453
01:18:56.529 --> 01:18:57.529
historias.

1454
01:18:57.367 --> 01:19:01.634
pero ahí lo único que te puedo decir, o la
recomendación que te puedo hacer, es que

1455
01:19:01.634 --> 01:19:05.692
adecúes la velocidad a la velocidad real,
es decir, que tú cojas y hagas, no lo

1456
01:19:05.692 --> 01:19:09.855
hagas por anticipado, porque sería una
mala práctica de Agile, haz una estimación

1457
01:19:09.855 --> 01:19:14.123
inicial que va a ser incorrecta, haz una
implementación, mira cuánto has sido capaz

1458
01:19:14.123 --> 01:19:18.181
de implementar en ese proceso, en ese
tiempo, y probablemente lo que tienes que

1459
01:19:18.181 --> 01:19:20.876
hacer es cambiar el ratio de puntos de
historia por hora.

1460
01:19:21.076 --> 01:19:23.239
Porque igual no lo has ajustado bien en el
primer momento.

1461
01:19:23.439 --> 01:19:27.023
En la segunda iteración utiliza este ratio
al principio.

1462
01:19:27.223 --> 01:19:30.968
De forma que vas ajustando tu modelo de
estimación a tu velocidad.

1463
01:19:31.168 --> 01:19:34.216
Porque ahí realmente lo que no puedes
hacer es pensar que vas a estimar bien

1464
01:19:34.216 --> 01:19:35.216
desde el primer momento.

1465
01:19:35.273 --> 01:19:36.815
Eso no va a funcionar.

1466
01:19:37.015 --> 01:19:38.597
Y eso va a cambiar para cada equipo ágil.

1467
01:19:38.797 --> 01:19:41.400
O sea, no va a ser el mismo ratio para
cada equipo ágil.

1468
01:19:41.600 --> 01:19:45.269
Cada equipo ágil, en función de la
composición que tenga, es decir, gente más

1469
01:19:45.269 --> 01:19:49.034
experta, menos experta, más habituada a
trabajar, a colaborar, etc., va a tener

1470
01:19:49.034 --> 01:19:50.290
una velocidad determinada.

1471
01:19:50.523 --> 01:19:55.807
Y luego, para la primera, la documentación
no dice en Manifiesto Ágil que no

1472
01:19:55.807 --> 01:19:57.092
documentes.

1473
01:19:57.292 --> 01:20:00.985
Lo que dice Manifiesto Ágil es que
prefiere que el software funcione versus

1474
01:20:00.985 --> 01:20:01.985
la documentación.

1475
01:20:01.979 --> 01:20:05.843
Entonces, nosotros, por ejemplo, en
nuestros productos, siempre la

1476
01:20:05.843 --> 01:20:10.243
documentación, que en mi caso es la
documentación que va a ser publicada en

1477
01:20:10.243 --> 01:20:14.881
Internet, por cierto que tenemos un muy
buen sistema de documentación, de poder

1478
01:20:14.881 --> 01:20:19.162
decir, de productos, se hace como
historias de usuarios de documentación.

1479
01:20:19.362 --> 01:20:23.949
Y tú planificas la historia de tu usuario
de documentación dentro de tu sprint.

1480
01:20:24.149 --> 01:20:29.171
Entonces tú lo que tienes son slots
reservados para esa documentación que es

1481
01:20:29.171 --> 01:20:32.080
la que tú crees que es la mínima que
necesitas.

1482
01:20:32.280 --> 01:20:35.640
Si esa documentación, yo lo que te
recomendaría es la documentación de

1483
01:20:35.640 --> 01:20:39.633
usuario tiene que estar dentro de eso, es
decir, la documentación que el usuario va

1484
01:20:39.633 --> 01:20:43.432
a leer de tu aplicación tiene que estar
dentro de tu historia de usuario, de tu

1485
01:20:43.432 --> 01:20:44.397
estimación.

1486
01:20:44.597 --> 01:20:48.322
Y luego la documentación que no sea
documentación de usuario,

1487
01:20:48.522 --> 01:20:53.040
tú lo decides no hay aquí un no tienes por
qué no documentar lo que normalmente

1488
01:20:53.040 --> 01:20:57.732
nosotros lo que decimos es que hay como
una especie de umbral a partir del cual la

1489
01:20:57.732 --> 01:21:02.134
sobredocumentación no aporta valor y tú
tienes que buscar cuál es tu umbral a

1490
01:21:02.134 --> 01:21:06.536
partir de ese momento deja de documentar
porque no lo necesitas ahora, eso no

1491
01:21:06.536 --> 01:21:11.054
quiere decir que no documentes nada de
hecho con los sprints hay unas cosas que

1492
01:21:11.054 --> 01:21:15.862
se hacen y que a mí me gusta mucho hay una
referencia por ahí muy interesante que lo

1493
01:21:15.862 --> 01:21:16.858
que dice es que

1494
01:21:17.058 --> 01:21:21.958
Cuando tú sabes, por ejemplo, que en tu
sprint ya vas a tener que dedicar X

1495
01:21:21.958 --> 01:21:27.124
unidades de tiempo por historia, por
análisis de datos, como decíamos antes, a,

1496
01:21:27.124 --> 01:21:32.555
por ejemplo, atender a cosas que no están
planificadas o cambios en lo que sería el

1497
01:21:32.555 --> 01:21:37.985
propio sprint, procura reservar esos slots
libres dentro de tu propio sprint ahora.

1498
01:21:38.185 --> 01:21:40.208
Y hazlo de forma histórica.

1499
01:21:40.408 --> 01:21:45.011
Es decir, si yo voy teniendo el
equivalente a tres historias de usuario,

1500
01:21:45.011 --> 01:21:48.981
que de verdad yo históricamente voy
teniendo, las voy reservando.

1501
01:21:49.181 --> 01:21:53.751
Y si te encuentras que luego al final del
sprint no las vas a implementar, utilízala

1502
01:21:53.751 --> 01:21:54.750
para refactorizar.

1503
01:21:54.950 --> 01:21:59.039
Pero con eso ajustas lo que sería la
velocidad de tu equipo y te das una

1504
01:21:59.039 --> 01:22:01.740
capacidad de adecuarte al cambio dentro
del sprint.

1505
01:22:01.940 --> 01:22:02.940
No sé si he respondido.

1506
01:22:03.022 --> 01:22:04.782
Una pregunta.

1507
01:22:13.403 --> 01:22:18.231
Hostia, perdóname.

1508
01:22:18.431 --> 01:22:24.431
[Orador 2]: Te quería preguntar cómo cuando llegas a
una empresa que está tan establecida, les

1509
01:22:24.431 --> 01:22:30.431
convences de que adopten este tipo de
estrategias y de que se creen estos

1510
01:22:30.431 --> 01:22:36.677
puestos de trabajo como los managers para
estrategias ágiles y cosas así.

1511
01:22:36.877 --> 01:22:46.269
[Orador 1]: Bueno, yo creo que el modelo de ágil se
dice que nace de abajo arriba.

1512
01:22:46.469 --> 01:22:49.313
Tú solo no puedes, necesitas amigos.

1513
01:22:49.513 --> 01:22:51.476
Eso es lo primero.

1514
01:22:51.676 --> 01:22:57.676
Segundo, teniendo amigos tienes la
capacidad de ir haciendo una organización

1515
01:22:57.676 --> 01:23:01.669
del trabajo a nivel local

1516
01:23:01.885 --> 01:23:07.430
que pueda empezar a parecerse a Agile y
evidentemente comerle la cabeza a tus

1517
01:23:07.430 --> 01:23:10.242
managers, que es una cosa evidente.

1518
01:23:10.442 --> 01:23:16.277
Pero tienes que trabajar con los equipos y
en los ámbitos de independencia que tengas

1519
01:23:16.277 --> 01:23:21.513
intenta utilizar prácticas ágiles, es
decir, paquetes pequeños, división del

1520
01:23:21.513 --> 01:23:24.129
trabajo en unidades pequeñas, etcétera.

1521
01:23:24.329 --> 01:23:28.048
Yo entiendo que si tu manager no te está
pidiendo que hagas pruebas unitarias y te

1522
01:23:28.048 --> 01:23:31.629
ponen a hacer pruebas unitarias porque
realmente prueba tu código, pues hombre,

1523
01:23:31.629 --> 01:23:35.440
lo que puede pasar es que tengas un código
de mejor calidad que el del compañero que

1524
01:23:35.440 --> 01:23:39.067
no lo hace, porque realmente la prueba
unitaria no la hacemos por formalismo, lo

1525
01:23:39.067 --> 01:23:42.235
hacemos porque creemos que de verdad
aporta un valor a lo que sería el

1526
01:23:42.235 --> 01:23:43.235
desarrollo de software.

1527
01:23:43.312 --> 01:23:47.417
Entonces, tienes que buscar ese balance y
buscar amigos para poder hacer

1528
01:23:47.667 --> 01:23:52.138
al menos un equipo, un tamaño de equipo
que tenga más capacidad de influencia

1529
01:23:52.138 --> 01:23:54.135
dentro de lo que sería el management.

1530
01:23:54.335 --> 01:24:00.335
Búscate al manager que es probablemente
más tendente a esto e intenta empezar a

1531
01:24:00.335 --> 01:24:02.186
trabajar por ahí.

1532
01:24:02.386 --> 01:24:05.370
Si lo quieres hacer tú solo, tú contigo
mismo no puedes.

1533
01:24:05.570 --> 01:24:06.570
¿Cómo era?

1534
01:24:05.910 --> 01:24:09.673
Solo no puedes con amigos.

1535
01:24:12.862 --> 01:24:15.630
[Orador 5]: Nada más.

1536
01:24:15.830 --> 01:24:16.834
[Orador 1]: Me voy.

1537
01:24:17.034 --> 01:24:18.057
Muchas gracias chicos.

1538
01:24:18.257 --> 01:24:20.664
Sed ágiles, leed La Meta.

1539
01:24:20.864 --> 01:24:22.926
Muchas gracias.

1540
01:24:23.151 --> 01:24:26.179
Leed La Meta y hasta la próxima.