0:00:06.000,0:00:09.840
Creo que mi charla será un poco diferente en comparación con las otras charlas porque no voy a

0:00:09.840,0:00:15.280
hablar de un proyecto de investigación en particular. El contenido de mi charla se basa en un número especial

0:00:15.280,0:00:21.840
que un par de colegas míos y yo publicamos el año pasado y que trataba sobre el valor

0:00:21.840,0:00:26.720
y el gasto en la ingeniería del software. Así que en esta charla voy a presentar algunas de las

0:00:26.720,0:00:35.200
investigaciones presentadas en los artículos y también intentaré explicar por qué debería importarnos. Creo que

0:00:35.200,0:00:41.680
Creo que me mencionaré conceptos de alto nivel, pero incluyo una URL aquí para que si te interesa los detalles del

0:00:43.120,0:00:48.400
trabajo que voy a presentar puedas ir a la URL y todos los documentos - no deben estar 

0:00:48.400,0:00:55.280
detrás de un pay wall para que puedas leer y entrar en las consultas técnicas reales de

0:00:55.280,0:01:00.800
las investigaciones reales. Si no recuerdas la URL, también la he incluido en la nota a pie de la página

0:01:01.840,0:01:07.520
por si quieres consultarla. Bien, pero cuál es el panorama general, cuál es la motivación de

0:01:07.520,0:01:13.120
mi charla. Tenemos valor y gasto, pero en la práctica puede ser un reto pensar

0:01:13.120,0:01:17.840
en el valor y en el gasto y pensar en cómo podemos reducir el gasto o cómo podemos

0:01:18.400,0:01:22.960
aumentar el valor si no tenemos una conceptualización de estos

0:01:23.840,0:01:29.760
términos de estas ideas. Así que esto es lo que quiero hacer: pensar en cómo podemos conceptualizar

0:01:29.760,0:01:36.320
gasto, cómo podemos reconceptualizar el valor y luego utilizar estas definiciones más concretas para

0:01:37.360,0:01:40.560
abordar de forma proactiva el valor y el gasto en el desarrollo. Para

0:01:42.240,0:01:46.000
empezar, un artículo que no aparece en este número especial, pero que creo

0:01:46.000,0:01:53.280
que sigue siendo relevante, es un artículo que presenta algunas investigaciones que analizan lo que realmente es el gasto

0:01:53.280,0:01:59.760
y para cada una de las conclusiones presento también en la parte inferior la fuente de la evidencia, por

0:01:59.760,0:02:04.480
lo que si te preguntas cuál es el espacio de lo que voy a hablar, hay un breve resumen

0:02:04.480,0:02:10.400
en los cuadros azules en la parte inferior de cada diapositiva. Así que hubo un estudio que analizó, 

0:02:11.280,0:02:16.640
bueno, lo que es el gasto y llegó a una definición de los desperdicios en la ingeniería de software

0:02:16.640,0:02:23.680
y también nueve categorías de gasto incluyendo su causa. Así que por qué tenemos los tipos de gasto

0:02:24.320,0:02:30.640
y me referiré a algunos de estos tipos más adelante. Pero bueno, te preguntarás, ¿cuál es el punto de

0:02:30.640,0:02:35.840
saber esto? Bueno, si conocemos estos puntos o si conoces estos tipos de gasto podemos

0:02:36.560,0:02:41.440
hablar de ellos con nuestro equipo, podemos abordarlos activamente y tal vez considerarlos en

0:02:41.440,0:02:49.520
nuestra planificación en nuestros proyectos en la forma en que diseñamos y desarrollamos el software. Así que vamos a echar un vistazo a

0:02:49.520,0:02:56.480
la primera cuestión relacionada con los gastos. Así que las revisiones de código, creo que se han escrito muchas cosas sobre las

0:02:56.480,0:03:02.160
revisiones de código un montón de blogs por ahí un montón de gente tiene opiniones sobre las revisiones de código y creo que

0:03:02.160,0:03:07.920
habrá algunas más charlas también en el contexto de esta serie de charlas sobre las revisiones de código.

0:03:08.960,0:03:12.880
Así que en realidad ya sabemos mucho acerca de las revisiones de código, así que lo que me gustaría

0:03:14.480,0:03:20.800
destacar en el contexto de los gastos es que las malas revisiones de código puede ser una fuente de gasto

0:03:20.800,0:03:26.720
y para hacer frente a esto o para mitigar o reducir el gasto en el contexto de las revisiones de código,

0:03:26.720,0:03:31.600
bueno, podemos ver que hace una mala revisión de código.  Y hay una gran cantidad de evidencias

0:03:31.600,0:03:38.240
empíricas sobre lo que se clasifica como una mala revisión de código y así este estudio, se identificaron

0:03:39.120,0:03:47.200
los llamados olores de revisión, por ejemplo, la falta de revisión o "me parece bien", lo que significa

0:03:47.200,0:03:50.560
que quienes revisan, no revisaron realmente el código en primer lugar, o que sólo

0:03:50.560,0:03:54.160
revisaron superficialmente, lo que podría conducir a la gasto de retrabajo,

0:03:54.160,0:03:58.640
que luego tenemos que volver a trabajar lo que habíamos hecho en el diseño del código.

0:04:00.400,0:04:07.200
Las revisiones de amigos es otro olor de revisión que significa que simplemente pedimos a personas amigas que revisen nuestro código,

0:04:07.200,0:04:11.200
tal vez sólo las personas que trabajan en las mismas partes del código, por lo que no hay realmente

0:04:11.200,0:04:15.280
un intercambio de conocimientos o la revisión del código no ayuda realmente a compartir el conocimiento con

0:04:15.280,0:04:19.600
un equipo. Hay otras revisiones como el ping pong, que lleva a una comunicación ineficaz

0:04:19.600,0:04:24.880
cuando el revisor y el autor del código van de un lado a otro para discutir el código.

0:04:26.560,0:04:31.200
O dormir, que es un olor interesante, lo que significa que las personas que revisan ni siquiera

0:04:31.200,0:04:36.080
responden, así que es otra fuente de gasto porque tenemos que esperar, así que el desarrollador que escribió el código

0:04:36.080,0:04:43.120
tiene que esperar hasta que la revisión regrese y los dos olores restantes serían, bueno,

0:04:43.120,0:04:50.240
tenemos grandes conjuntos de cambios por lo que, por ejemplo, la cantidad de cambios en el código que tenemos que

0:04:50.240,0:04:55.520
revisar es muy grande o simplemente hemos perdido el contexto del cambio que se acaba de hacer en el código que

0:04:55.520,0:05:01.280
vamos a revisar, lo que podría conducir a una carga cognitiva muy alta y, de nuevo, al final

0:05:01.280,0:05:06.400
probablemente una pérdida de tiempo a largo plazo. Ahora, de nuevo, la pregunta es ¿por qué importa esto? Bueno,

0:05:06.400,0:05:12.560
si somos conscientes de este tipo de olores podemos planificar nuestras actividades de revisión - podemos

0:05:12.560,0:05:16.560
comunicar las expectativas para las revisiones de código e incluso podemos utilizar estos

0:05:17.520,0:05:24.160
anti-patrones u olores de las revisiones para formar a los nuevos revisores en nuestra organización. 

0:05:24.160,0:05:31.600
Bien, sigamos con el nivel de código, otra forma de desperdicio que creo es la deuda técnica, y de nuevo

0:05:31.600,0:05:36.560
se ha escrito mucho sobre la deuda técnica, pero una pregunta que a menudo, o en realidad creo

0:05:36.560,0:05:42.240
que siempre surge, es, bueno, ¿qué es lo que realmente arreglamos? ¿Cómo lo arreglamos y quién debería arreglarlo?

0:05:43.040,0:05:51.920
Bueno, esta contribución a este número especial que publicamos descubrió que no todos los tipos de deuda técnica

0:05:51.920,0:05:58.480
se arreglan de la misma manera y que algunos tipos de deuda técnica son arreglados por quienes los introducen

0:05:58.480,0:06:04.400
y algunos tipos son arreglados por otras personas y algunos tipos de deuda técnica que tal vez nunca se arreglan,

0:06:05.280,0:06:12.000
¿qué podemos hacer con esto? Bueno, si sabemos que algunos tipos es menos probales que se arreglen solos.

0:06:12.000,0:06:20.240
Por ejemplo, la deuda de diseño, probablemente tenemos que llegar a las actividades dedicadas o tal vez dedicar

0:06:21.120,0:06:27.760
tiempo en nuestro desarrollo para arreglar estos tipos de deuda técnica. En el caso de otros tipos de deuda,

0:06:27.760,0:06:34.240
por ejemplo la deuda de código o la deuda de defectos, a menudo es el desarrollador quien la introduce y la corrige.

0:06:34.240,0:06:41.280
Por lo tanto, para estos tipos de deuda, es posible que no planifiquemos iniciativas o actividades de reparación. También,

0:06:41.280,0:06:47.840
bueno, lo que podemos sacar de esto es que cuando se trata de tipos de deuda técnica que no son

0:06:50.160,0:06:56.800
auto-arregladas probablemente necesitamos asignarlas a personas - a personas dedicadas - y esta

0:06:58.000,0:07:03.040
investigación argumenta que la deuda de diseño, por ejemplo, probablemente deberíamos asignarla

0:07:03.040,0:07:07.440
a personas de mayor rango porque aquellos que introducen la deuda de diseño, si son 

0:07:07.440,0:07:11.040
juniors, a menudo no están realmente interesados en arreglarla en primer lugar. 

0:07:12.720,0:07:19.360
Bien, estos eran dos ejemplos y el último, el tercero y último, es algo diferente

0:07:20.000,0:07:26.320
y se centra en el valor, pero lo hace desde una perspectiva diferente. No se trata de valor

0:07:27.120,0:07:35.440
en términos de dinero o valor en términos de funcionalidades o valor en términos de tiempo que ahorramos sino que es valor en

0:07:35.440,0:07:42.480
términos de valores humanos y la pregunta es cómo podemos integrar los valores humanos en el software

0:07:44.080,0:07:48.880
porque como profesionales responsables o como desarrolladores de software no sólo debemos asegurarnos de que

0:07:48.880,0:07:54.640
construimos software que es útil para nuestros clientes sino que también debemos construir sistemas que

0:07:56.880,0:08:02.720
apoyen o al menos no violen los valores humanos. Ahora bien, hay mucha literatura

0:08:02.720,0:08:08.400
sobre valores humanos y taxonomías, definiciones, pero puede ser bastante difícil

0:08:08.400,0:08:12.160
para un ingeniero o desarrollador de software entender, bueno, ¿cómo traduzco

0:08:12.800,0:08:21.760
los valores humanos en algo que podamos representar en el código? Y aquí es donde entra esta contribución

0:08:21.760,0:08:27.440
este documento en la parte inferior - porque lo que este documento trató de hacer es, bueno, miró

0:08:27.440,0:08:35.520
cómo los valores humanos se discuten entre los desarrolladores de proyectos de software y luego trató de

0:08:35.520,0:08:41.920
llegar a las descripciones conceptualizadas de estos valores humanos para que sean más procesables

0:08:43.040,0:08:48.240
u operacionales - puede ser operacional por los ingenieros de software. Para dar un ejemplo de

0:08:48.240,0:08:53.200
dos valores humanos - quiero decir, hay más - sólo pongo dos ejemplos aquí, la dignidad y la inclusión.

0:08:53.200,0:08:59.920
Podrían ser conceptualizados, por ejemplo, en la dignidad para mantener el honor y el respeto a

0:08:59.920,0:09:06.640
los usuarios, y una vez que tenemos esa descripción contextualizada de ese valor humano, podemos

0:09:06.640,0:09:11.360
ir un paso más allá y definir los requisitos reales. Así, por ejemplo, basándonos en

0:09:11.920,0:09:16.800
esta descripción, podríamos pensar en qué tipo de información del usuario guardamos en nuestra aplicación,

0:09:16.800,0:09:22.000
cómo se comparte, cómo pueden los usuarios darse de baja, si los usuarios son propietarios, por ejemplo, 

0:09:22.000,0:09:28.080
de su información, de modo que este concepto de alto nivel, quizá abstracto, de "dignidad", que se relaciona

0:09:28.080,0:09:32.960
con el valor humano, se convierte en algo mucho más concreto. Y lo mismo ocurre con la la inclusión: lo que

0:09:33.680,0:09:36.880
la investigación descubrió es que podemos traducir la inclusión en

0:09:37.600,0:09:42.800
la posibilidad de facilitar diferentes idiomas de origen, culturas y conocimientos y, a partir de ahí,

0:09:42.800,0:09:49.840
podemos dar un paso más para llegar a los requisitos o restricciones completos de nuestro software. 

0:09:50.960,0:09:58.480
Bueno, eso es todo lo que quería decir, sólo para resumir, ya sabemos mucho sobre el valor

0:09:58.480,0:10:04.480
y las pérdidas y en esta charla sólo quería dar algunos ejemplos y, bueno,

0:10:05.200,0:10:12.320
¿cuáles son las conclusiones? Bien, sabemos mucho sobre los olores de las revisiones, así que ¿por qué no usamos ese conocimiento

0:10:12.320,0:10:18.240
para planificar nuestras revisiones, para formar a los desarrolladores novatos o para

0:10:18.240,0:10:24.880
comunicar las expectativas sobre las revisiones dentro de nuestra organización? En cuanto a la deuda técnica,

0:10:24.880,0:10:30.560
podemos utilizar nuestros conocimientos empíricos sobre la deuda técnica para decidir cómo

0:10:30.560,0:10:37.280
solucionarla y decidir en qué tipo de actividades nos centramos. Así que, por ejemplo, si por alguna razón

0:10:37.280,0:10:42.400
quisiéramos tener... quisiéramos dedicar un día o dos a arreglar la deuda técnica, probablemente sea

0:10:43.280,0:10:48.400
mejor dedicarlo a arreglar el diseño que a arreglar la deuda de código, porque la deuda de código tiende a

0:10:48.400,0:10:54.160
ser bien arreglada por los desarrolladores. Y por último, pero no por ello menos importante, cuando se trata de valores humanos,

0:10:54.160,0:11:01.680
bueno, ahora tenemos una descripción contextualizada de los valores humanos y podemos usarla para identificar

0:11:01.680,0:11:05.680
requisitos más concretos del producto y al final construir un software responsable. 

0:11:07.280,0:11:13.040
Sí, así que si tienen alguna pregunta no duden en enviarme un correo electrónico o si quieren saber más

0:11:13.040,0:11:25.680
no duden en enviar un correo electrónico o simplemente dejar una pregunta a Mike, y, sí, eso es todo lo que tenía por hoy.