Ladder of inference

 

“Tenemos que despedir a
Júlia”

Esta acción, que puede
ser importante para tu empresa, para tu equipo y, sobretodo, para la pobre
Júlia, la tomas después de seguir (consciente o inconscientemente) una serie de
pasos llamados ladder of inference. Realizar estos pasos de manera consciente
nos ayudará a tomar decisiones basadas en la realidad. Si recorremos estos
pasos demasiado rápido podemos acabar tomando decisiones basadas en creencias y
en visiones parciales de la realidad, lo que nos puede llevar a que estas
decisiones no sean todo lo buenas que deberían y podríamos acabar despidiendo a
Júlia sin motivos.

Esto, que puede parecer
algo alejado de nuestra realidad como desarrolladores, es muy importante cuando
hacemos retrospectivas. Asegurando que recorremos los pasos con calma,
conseguiremos que nuestras retrospectivas sean mucho más provechosas, con
acciones de mejora más eficaces.

Los pasos del ladder of
inference
son los siguientes: 

Empezando por abajo,
tenemos los hechos y la realidad. Si recorremos estos pasos demasiado rápido
podríamos tener un escenario como este:

  1. Seleccionamos los
    hechos en función de nuestras creencias y la experiencia previa.
  2. Interpretamos qué
    significan
  3. Aplicamos asunciones
    previas, generalmente sin considerarlas.
  4. Extraemos
    conclusiones basadas en los hechos interpretados y nuestras asunciones.
  5. Desarrollamos (o
    afianzamos) creencias basadas en estas conclusiones.
  6. Tomamos acciones que
    parecen “correctas” porqué están basadas en nuestras creencias.

 

 Veamos un ejemplo:

Trabajamos en una
consultora. Nuestro superior nos ha puesto a Júlia en nuestro equipo sin
nosotros pedirlo. Júlia tiene un sueldo por encima de la media y me va a costar
más cuadrar las cuentas a final de trimestre. Desde que está Júlia tenemos
menos velocidad en el equipo y la build está rota constantemente.

¿Qué pasos puedo seguir?

  1. De todo lo que veo,
    selecciono que tenemos menos velocidad y que Júlia rompe muchas builds.
  2. Interpreto que el
    equipo está bajando la calidad de su trabajo.
  3. Como Júlia viene
    impuesta y encima del departamento de BI, asumo que no tiene los conocimientos
    necesarios de programación.
  4. Llego a la conclusión
    que Júlia no está haciendo bien su trabajo.
  5. Me formo la idea que
    Júlia no está capacitada para trabajar con nuestro equipo.
  6. Creo que lo mejor es
    despedir a Júlia.

 

En este proceso hay dos
cosas importantes. La primera es que lo hemos recorrido muy rápido, sin
pararnos a pensar en cada paso ni preguntarnos si eran correctas las
interpretaciones, asunciones, conclusiones que hemos ido tomando. La segunda es
que estamos dejando que el proceso se retroalimente de una manera peligrosa.
Casi en la base del mismo, estamos dejando que nuestras creencias e ideas
preconcebidas nos influyan incluso en el primer paso.

Por tanto, antes de tomar
una acción es necesario que nos cuestionemos cada paso:

¿Estoy seleccionando
todos los hechos importantes?

¿Por qué estoy haciendo
estas asunciones?

¿Puedo testar estas
asunciones?

¿Por qué creo que esto es
la acción correcta a tomar?

¿Me estoy dejando
influenciar por mis creencias de una manera “peligrosa”?

 

La retrospectiva

¿Cómo influye esto en las
retrospectivas? De la misma forma que antes hemos llegado a la acción de
despedir a Júlia seguramente de una manera equivocada o, por lo menos, sin
tener en cuenta otras acciones que podrían ser mejores, en una retrospectiva
podemos llegar a acciones de mejora que no sean todo lo provechosas que
deberían.

Para asegurarnos que
recorremos bien todos los pasos, Esther Derby y Diana Larsen definieron en su
famoso libro “Agile Retrospectives: Making good teams great” un framework a
utilizar para facilitar una retrospectiva. Este framework dicta los siguientes pasos:

Set the stage
En esta fase vamos a explicar el propósito de la retrospectiva y a establecer el foco de esta retrospectiva (una semana, dos semanas, etc)

Gather data
En esta fase recolectaremos los echos (no opiniones) relevantes para la retrospectiva que tienen los miembros del equipo en sus cabezas

Generate insights
En esta fase interpretaremos los echos recolectados en la fase anterior observando patrones, buscando causas, identificando posibles soluciones o mejoras.

Decide what to do
Es esta fase, pasaremos de la discusión a la acción, llegando a un acuerdo entre todo el equipo de las acciones a tomar.

Close the retrospective
Finalmente cerraremos la retrospectiva recordando las acciones y como haremos su seguimiento, reconoceremos el esfuerzo de todo el mundo e identificaremos la manera de hacer mejor la siguiente retrospectiva.

Como veis, hay un claro paralelismo entre los pasos del ladder of inference y los pasos del framework. Siguiendo estos pasos, nos aseguraremos un mejor rendimiento de nuestras retrospectivas.

Espero que el artículo os haya resultado interesante. Nos leemos!

Fuentes:

 

Control estático de código JavaScript con VS2012

Hace poco hablábamos que para pasar JSLint ( o JSHint ) en nuestro código JavaScript desde Visual Studio 2012 teníamos que echar mano de Chirpy. El otro día investigando esto con Rodrigo, vimos que en este breve ( o no tan breve ) lapso de tiempo tenemos dos herramientas más que nos ayudarán en esta tarea, Web Essentials 2012 y JSLint for Visual Studio 2012. Aquí van las conclusiones que saqué:

Web Essentials 2012

Web Essentials es una extensión de Visual Studio muy conocida. A parte de ayudarnos con JSHint, maneja archivos LESS, TypeScript, CoffeScript, y un largo etcétera. Instalarlo es muy sencillo, solo tenéis que ir a la opción del menú «Extensions and Updates» e instalaros la extensión:

 

Una vez instalada la extensión ( y reiniciado VS2012 ) veremos que si hacemos un fichero con un código tan simple como este:

if ( a == 1 )

veremos en la ventana de warnings los siguientes errores:

¡La que podemos liar con tan sólo una línea!

Para configurar las opciones del analizador estático de código tenemos que irnos a TOOLS -> Options

A parte de las configuraciones sobre qué errores mostrar o no mostrar (que os animo a qué exploréis) algo que me parece importante es decidir donde se van a mostrar los mensajes de error. Por defecto estos se muestran en la pestaña de Warnings, pero a mi me gusta tratar estos errores como tales y, por lo tanto, prefiero que Visual Studio me los marque como errores. Por tanto, cambiamos el «Error location» a Error. El problema con esta extensión es que nos pone los mensajes en la pestaña de errores pero no nos da la build por fallida, con lo que, si no somos muy cuidadosos, podemos obviar estos mensajes y nada malo nos pasará. Otro «problema» es que solo se pasa cuando un fichero .js se guarda.

 

JSLint for Visual Studio 2012

JSLint for Visual Studio 2012 es una extensión cuya única finalidad es pasarnos el analizador estático de código. La manera de instalarla es idéntica a Web Essentials:

Las opciones de JSLint están directamente debajo del menú TOOLS y en la siguiente imagen podemos ver que son muy completas:

Algo importante que podemos ver es que podemos validar los archivos tanto al grabar como al realizar una build, que podemos tratar estos mensajes como errores y que podemos cancelar la build si hay errores. Si lo configuramos así podemos ver en nuesta ventana de errores lo siguiente:

Como podéis ver, en la última línea nos informa que ha cancelado la compilación por errores de validación de JSLint.

Otra cosa interesante que tiene JSLint for Visual Studio 2012 y que no tiene Web Essentials es que podemos marcar tanto ficheros individuales como carpetas enteras para que no se le pase el analizador de código. Esto es recomendable cuando trabajamos con librerías de terceros y no queremos que influyan en nuestra build. 

Y por último, algo también muy interesante es que, haciendo click con el botón derecho sobre la solución en el Explorador de Soluciones, podemos añadir el archivo de configuración de JSLint. 

 

Esto nos permitirá subir este archivo a nuestro repositorio de fuentes y que todos los miembros del equipo compartan la misma configuración de la extensión para esta solución ya que la extensión por defecto carga la configuración de este archivo.

Espero que os haya parecido de utilidad!