0:00:05.200,0:00:10.080
Así que una vez más es un placer estar aquí Greg, gracias por invitarme,

0:00:10.880,0:00:14.560
es una gran oportunidad estar en este evento.

0:00:14.560,0:00:20.560
Así que hoy voy a hablar de un informe que he llevado a cabo con algunos colegas de la

0:00:20.560,0:00:26.960
Universidad Federal de Amazona, y es sobre el control y la negociación y las estimaciones de software.

0:00:27.600,0:00:31.920
Así que es bien - es bien conocido en la ingeniería de software,

0:00:31.920,0:00:41.200
las partes interesadas toman el esfuerzo necesario para ejecutar una tarea, así un proyecto, o para predecir el

0:00:41.200,0:00:47.520
valor que se puede entregar al cliente, para que puedan tener el resultado que están esperando.

0:00:48.320,0:00:53.840
Los estimadores, traen esta perspectiva sobre los factores que afectarían

0:00:53.840,0:01:00.800
de alguna manera las estimaciones, buscando mejorar la precisión cuando están discutiendo cuánto

0:01:00.800,0:01:05.920
esfuerzo y cuánto tiempo necesitarán poner - necesitarán tomar para desarrollar lo que

0:01:05.920,0:01:11.200
lo que necesitan para la próxima versión.
Es importante entender aquí que

0:01:11.200,0:01:17.440
este proceso de estimación, ocurre en entornos sociales, y como todo lo que hago, 

0:01:17.440,0:01:24.400
implica algo relacionado con el comportamiento y los aspectos sociales dentro del proceso de ingeniería de software.

0:01:24.400,0:01:28.320
Entonces, ¿por qué es social?
Porque no sólo implica

0:01:28.320,0:01:35.520
a las personas que trabajan en ello, sino también el contexto en el que están, en el que están inmersos.

0:01:35.520,0:01:42.400
Así que la literatura sobre las estimaciones es extensa.
Así que podemos encontrar

0:01:43.280,0:01:48.720
artículos desde los años 70 hasta artículos de la semana pasada que hablan de las estimaciones de software.

0:01:48.720,0:01:55.760
Y lo que encontramos al buscar en la literatura es que hay una amplia gama de factores

0:01:55.760,0:02:03.600
que afectan a las estimaciones, de hecho desde la estimación temprana, por lo que al principio del proyecto

0:02:03.600,0:02:09.680
tienen la estimación temprana - las estimaciones que vienen, y esto se tiene en cuenta cuando

0:02:09.680,0:02:14.240
se están definiendo las estimaciones para la próxima versión o el próximo sprint, lo que ustedes - ustedes llaman,

0:02:16.320,0:02:25.360
hasta cosas relacionadas con los cambios en los requisitos, el cambio en el alcance, la flexibilidad del proyecto, etc.

0:02:25.360,0:02:30.080
Y esto pasa por un montón de - un montón de cosas que suceden en el proyecto, como cuando estás

0:02:30.080,0:02:34.640
estimando, estás ejecutando, realizando esta - estimación, este proceso de estimación.

0:02:36.320,0:02:43.200
Y en este punto, tenemos un montón de cosas sociales sucediendo, cosas contextuales sucediendo,

0:02:43.200,0:02:48.240
que incluye, por ejemplo, la presión de la alta dirección, de los clientes, de la PO.

0:02:48.800,0:02:55.120
Incluye el propio equipo, cómo es la relación entre la experiencia del equipo,

0:02:55.120,0:02:57.360
la antigüedad de donde provienen estas personas,

0:02:57.360,0:03:03.840
así que hay múltiples tipos de factores que afectan a la forma en que la gente estima el software.

0:03:05.840,0:03:15.520
Para entender mejor este fenómeno de una manera más reciente, llevamos a cabo algunos estudios de observación

0:03:15.520,0:03:21.120
y un par de entrevistas - algunas entrevistas con personas de diferentes países,

0:03:21.120,0:03:25.600
diferentes empresas, diferentes equipos.
Nos tomamos como tres meses observando

0:03:27.200,0:03:32.880
a cuatro equipos diferentes durante sus sesiones de estimación, y nuestro objetivo era entender 

0:03:33.520,0:03:39.600
cómo se utilizaban las estimaciones de software para establecer compromisos comunes en relación con los valores del negocio.

0:03:39.600,0:03:45.360
Así que sólo queríamos entender como, lo que es - lo que está atando estas dos cosas

0:03:45.360,0:03:50.640
las estimaciones y lo que se está entregando, lo que ha sido - lo que el equipo se ha comprometido a hacer.

0:03:51.360,0:04:00.000
Y al final descubrimos que la negociación de presupuestos y el acolchado eran cosas clave

0:04:00.000,0:04:04.000
que ocurrían en el proceso.
Así que fue bastante impresionante

0:04:04.000,0:04:09.200
la cantidad de cosas que pudimos relacionar con la negociación y el relleno durante este proceso.

0:04:10.720,0:04:16.880
Así que lo que vemos es que - lo que vio es que los equipos que analizamos y las personas que

0:04:16.880,0:04:23.200
hablamos después, porque hablamos con muchas más personas de tres empresas diferentes más tarde,

0:04:23.200,0:04:30.480
es que todos ellos siguen algún tipo de prácticas ágiles, como la planificación de las estimaciones basadas en el póquer,

0:04:30.480,0:04:39.200
donde la gente viene con las estimaciones del equipo, por lo que discuten la tarea y

0:04:40.480,0:04:46.960
cada uno de los miembros viene con una estimación, y discuten para - para llegar a un consenso.

0:04:47.840,0:04:52.480
De acuerdo, y cada uno de los equipos tiene un tipo diferente de estrategia de resolución cuando tienes,

0:04:52.480,0:04:59.760
por ejemplo, desacuerdos en términos de estimaciones.
Pero al final del día, lo que

0:04:59.760,0:05:04.800
entendimos es que el PO y el líder del equipo sólo quieren saber los argumentos que tienen

0:05:04.800,0:05:10.720
que tener para discutir con la - la siguiente capa, con la alta dirección o el cliente.

0:05:10.720,0:05:17.040
Así que buscan entender cómo pueden crear un compromiso aportando los argumentos que

0:05:17.040,0:05:24.640
los desarrolladores están aportando.
Y, curiosamente, algunas personas ni siquiera discuten.

0:05:25.200,0:05:29.280
Algunas personas, dependiendo de lo que las otras personas que están

0:05:30.480,0:05:36.560
estimando y lo que el PO tiene que decir, ni siquiera están en desacuerdo, sólo van a decir, bien,

0:05:36.560,0:05:42.880
puedo cambiar mis mis estimaciones si esto es mejor.
Así que a veces lo que vimos es que hay una

0:05:42.880,0:05:47.280
especie de relación de poder.
Es como si, de acuerdo, tenemos que entregar esto

0:05:47.280,0:05:53.600
para la próxima semana, así que si no... si no cambiamos las estimaciones no seremos capaces de hacerlo.

0:05:53.600,0:05:57.280
O a veces hay una persona muy veterana que dice: "Vale,

0:05:57.280,0:06:03.200
esto es muy difícil y sé que es difícil", y otras personas, más junior,

0:06:03.920,0:06:09.120
simplemente aceptan, sin argumentar en contra o a favor de algo.

0:06:09.920,0:06:18.560
Así que la forma en que los estimadores defienden es muy importante porque esto es lo que está dando la

0:06:19.440,0:06:26.320
la munición para las siguientes capas, y vimos que, al final del proceso de estimación,

0:06:26.320,0:06:30.960
hablamos con los PO y otras capas para entender, digamos, lo que estaba pasando.

0:06:30.960,0:06:35.760
Y vimos que había una especie de desajuste, y cada capa tiene sus propios objetivos

0:06:37.600,0:06:44.080
con lo que estaba pasando en el proceso de estimación.
Así que una cosa que notamos, que

0:06:44.080,0:06:46.800
jugaron según las reglas cuando estábamos hablando de la gestión de proyectos.

0:06:47.520,0:06:54.800
Como sabes que la gestión del riesgo es algo importante, y para gestionar mejor el riesgo,

0:06:55.680,0:07:01.920
es común apostar un poco.
Así que tenemos un búfer de contingencia, a veces,

0:07:01.920,0:07:06.720
como se puede ver aquí en los ejemplos, cuando no podemos definir la característica muy bien,

0:07:07.440,0:07:12.560
cuando hay algunos aspectos ocultos que no sabemos, es una API diferente que tenemos

0:07:12.560,0:07:18.560
que consumir, de acuerdo, no sabemos qué tipo de problemas que tenemos que enfrentar en esta versión.

0:07:19.520,0:07:23.200
Así que esto es un común - y esto es completamente comprensible.

0:07:24.080,0:07:30.320
Sin embargo, lo que nos llamó la atención es que estamos haciendo más que eso.

0:07:32.160,0:07:35.280
Para cada - todo lo que hablamos y observamos,

0:07:35.280,0:07:39.520
pudimos ver que estamos haciendo diferentes - diferentes cosas que resultan en el control

0:07:40.160,0:07:48.400
y muy a menudo - y lo que estamos haciendo es realmente ocultar los detalles del siguiente nivel.

0:07:48.400,0:07:54.000
Así que, por ejemplo, encontramos un par de casos en los que la gente simplemente dijo que, de acuerdo,

0:07:54.000,0:07:57.840
no pudimos terminar lo que prometimos en la versión anterior en el sprint anterior,

0:07:58.400,0:08:03.920
así que vamos a añadir un poco más de tiempo aquí a esta tarea para que seamos capaces de terminar algo más.

0:08:04.480,0:08:11.920
O tenemos que ajustar lo que sea - lo que sea en la interfaz de usuario de la función anterior que

0:08:11.920,0:08:16.960
entregaron, así que vamos a añadir algo aquí para que podamos hacer eso.

0:08:16.960,0:08:23.040
Ahora tenemos que configurar un nuevo servidor, así que por qué no añadir algo de tiempo a esto - esto y estas tareas.

0:08:24.000,0:08:30.400
Y también cosas relacionadas con la deuda técnica, por ejemplo, o la mejora de la calidad general,

0:08:30.400,0:08:36.800
la mantenibilidad del proceso.
Así que era bastante habitual escuchar como, de acuerdo,

0:08:36.800,0:08:40.320
vamos a hacer esto porque tenemos que refactorizar un par de artefactos,

0:08:41.040,0:08:44.080
así que vamos a añadir un poco de tiempo aquí añadir un poco de esfuerzo allí.

0:08:46.560,0:08:53.600
Lo que - lo que está detrás de eso, como, todo el mundo está ocultando desde el siguiente nivel

0:08:53.600,0:09:01.200
sólo porque tienen que entregar algo que no es un tipo directo de beneficio o valor de negocio 

0:09:01.200,0:09:07.600
que se puede mostrar fácilmente al cliente.
Así que lo que he aprendido aquí es que el control

0:09:07.600,0:09:14.240
se utiliza de forma correcta en muchos casos, pero a veces se utiliza como una forma social de ocultar cosas.

0:09:16.000,0:09:24.560
Así que la gente miente informalmente para hacer que las cosas encajen porque

0:09:24.560,0:09:31.200
saben que hay otras cosas que pueden hacer y todo el mundo que está escuchando aquí, que está viendo esta charla debe ser como, de acuerdo,

0:09:31.200,0:09:36.400
hacemos que es común, sí es común, pero es una especie de mal olor si pensamos

0:09:36.400,0:09:44.240
en el proceso - del proceso de software.
Y la precisión se ve perjudicada cuando se piensa en ello,

0:09:44.240,0:09:50.400
porque no sabemos exactamente lo que estamos haciendo, y no sabemos exactamente el rendimiento de nuestro equipo.

0:09:52.400,0:09:56.480
¿Qué tenemos que hacer?
Tenemos que vender todo como valor de negocio,

0:09:56.480,0:10:04.000
y esto tiene que venir desde abajo.
Así que tenemos que exponer las razones como estimadores,

0:10:04.000,0:10:08.480
como desarrolladores, decir, como lo que estamos haciendo, estamos refactorizando, estamos

0:10:08.480,0:10:14.800
mejorando la mantenibilidad, lo que estamos haciendo?
Y en el siguiente nivel, como el nivel de PO, el nivel de líder de equipo,

0:10:14.800,0:10:20.160
tenemos que describir estas razones que los desarrolladores nos dieron como de alguna manera el valor del cliente.

0:10:20.160,0:10:24.640
Así que en la próxima versión esto será algo mejor, mejoraremos nuestro rendimiento,

0:10:25.200,0:10:32.800
el - el producto tendrá un mejor rendimiento.
Y para el siguiente el último nivel de gestión,

0:10:32.800,0:10:37.440
cuando estamos en contacto con el cliente, tenemos que educarlos - que hay algunas cosas que no son

0:10:37.440,0:10:45.680
exactamente nuevas características, que no son exactamente beneficios directos para el producto como ellos ven,

0:10:45.680,0:10:50.480
pero es algo relacionado con el proceso que lo hará mejor a partir de ese momento.

0:10:53.840,0:10:59.840
Espero que os haya gustado y muchas gracias de nuevo a Greg y Mike por invitarme.