Valores, principios y prácticas

En los últimos meses estoy trabajando con en un par de consultorías muy especializadas. A mi, modestia aparte, se me da bien esto de ayudar a mejorar a los equipos de desarrollo de software. Sin embargo, he visto un impedimento importante al intentar introducir los cambios: el rechazo al cambio. Las razones son muy diversas, pero se me escapa cómo trabajar ese tema. ¡Malditas personas! Si fueran programas de ordenador… otro gallo cantaría. Así que, igual que para otras cosas me asocio con otros profesionales, estoy ahora trabajando con Maica en estas consultorías porque hemos identificado que el factor humano es muy importante para conseguir el éxito y queremos avanzar por ahí sumando habilidades, conocimientos y experiencias.

Fin del anuncio.

Bueno, es un anuncio justificado. Primero porque, como todos sabéis, ha subido el IVA y mis facturas del agua, el teléfono, la gasolina… serán más carás, así que hay que hacer un esfuerzo adicional en marketing. Y segundo porque mientras trabajamos una de las formaciones a medida que estamos preparando han surgido discusiones sobre si feedback es un valor o si debemos centrar la formación en las prácticas. La verdad, me encanta trabajar con gente que me ayuda a cuestionarme por qué hago las cosas. Me he llevado casi dos días bloqueado con eso pero finalmente he llegado a la respuesta. Y como casi siempre, estaba en el libro de KentBeck (te alabamos señor). El capítulo 3 concretamente. Se titula “Valores, Principios y Prácticas” y me he permitido la licencia de traducirlo.

¿Qué se necesita para comunicar claramente una nueva forma de pensar y hacer el desarrollo de software? Tú puedes aprender las técnicas básicas de jardinería rápidamente de un libro, pero eso no te convierte en un jardinero. Mi amigo Paul es un maestro jardinero. Yo cavo, planto, riego y escardo, pero no soy un maestro jardinero.

¿Cuáles son las diferencias entre nosotros? En primer lugar, Paul conoce más técnicas que yo, y es mejor en aquellas técnicas que ambos conocemos. La técnica importa, porque si usted no cava y plantas cosas, sin duda no estás haciendo jardinería. Llamemos prácticas a este nivel de conocimiento y comprensión, las cosas que realmente haces. Las prácticas son las cosas que haces día a día. Especificar las prácticas es útil, ya que son claras y objetivas. O escribes una prueba antes de cambiar el código o no lo haces. Las prácticas también son útiles porque te dan un lugar por el que empezar. Puedes comenzar escribiendo las pruebas antes de cambiar el código y obtener beneficios de ello mucho antes de entender el desarrollo de software de una manera más profunda.

Incluso si yo supiera las mismas prácticas que Paul, yo aún no sería un jardinero. Paul tiene un sentido altamente desarrollado de lo que es bueno y malo en la jardinería. Él puede mirar al jardín en su conjunto y tener una idea intuitiva de lo que está funcionando y de lo que no está. Donde yo podría estar orgulloso de mi habilidad para podar una rama correctamente, Paul podría ver que el árbol entero debería salir. Él ve esto no porque sea un mejor podador que yo, sino porque él tiene una visión de conjunto de las fuerzas que trabajan en el jardín. Yo tengo que trabajar en lo que es simple y obvio para él.

Llamemos valores a este nivel de conocimiento y entendimiento. Los valores son las raices de las cosas que nos gustan y no nos gustan en una situación. Cuando un programador dice “No quiero estimar mis tareas” normalmente no está hablando de la técnica. Él ya hace estimaciones, pero no quiere revelar lo que realmente piensa por miedo a proporcionar un punto de crítica 1 que será usado contra él más tarde. ¡Mejor multiplicar por tres esa estimación! El rechazo a comunicar las estimaciones revela algo mucho más profundo acerca de cómo él ve las fuerzas sociales en juego. Quizás él no quiere ser fiscalizable2 porque ya ha sido culpado injustamente en el pasado. En este caso, el programador valora la protección sobre la comunicación. Los valores son los criterios a gran escala que usamos para juzgar lo que vemos, pensamos y hacemos.

Explicitar los valores es importante porque sin valores, las prácticas rápidamente se vuelven rutina, actividades realizadas como un fin en sí mismas pero carentes de propósito y dirección. Cuando oigo a un programador ignorando un defecto, yo oigo un fallo en los valores, no en la técnica. El defecto en sí mismo podría ser un fallo en la técnica, pero la desgana para aprender del defecto muestra que el programador realmente no valora el aprendizaje y la superación personal tanto como cualquier otra cosa. Esto no va en el mejor interés del programa, la organización o el programador. Acompañar los valores con las prácticas significa que el programador puede realizar una práctica, en este caso el análisis de causa-raíz, en los momentos adecuados y por buenas razones. Los valores dan sentido a las prácticas.

Las prácticas son evidencias de los valores. Los valores se expresan a tan alto nivel que yo podría hacer casi cualquier cosa en el nombre de un valor. “He escrito este documento de 1000 páginas porque valoro la comunicación.” Puede que sí, puede que no. Si una conversación de 15 minutos una vez al día hubiera comunicado más efectivamente que produciendo ese documento, entonces el documento no muestra que yo valoro la comunicación. Comunicarse de la manera más efectiva que pueda muestra que yo valoro la comunicación.

Las prácticas son claras. Todo el mundo sabe si he asistido a las reuniones diarias. Si yo realmente valoro la comunicación es confuso. Si yo mantengo las prácticas que mejoran la comunicación es concreto. Igual que los valores le dan propósito a las prácticas, las prácticas aportan responsabilidad 3 a los valores.

Los valores y las prácticas están separados por un océano. Los valores son universales. Idealmente mis valores mientras trabajo son exactamente los mismos que en el resto de mi vida diaria. Las prácticas, sin embargo, están intensamente relacionadas con el lugar. Si quiero feedback 4 sobre si estoy haciendo un buen trabajo programando, entonces construir y probar continuamente mi software tiene sentido. Si quiero feedback cuando estoy cambiando un pañal, “construir y probar continuamente” es absurdo. Las fuerzas involucradas en ambas actividades son simplemente demasiado diferentes. Para obtener feedback de mi trabajo con los pañales yo debo levantar al bebé cuando he terminado para ver si el pañal se cae. No puedo probarlo a medio camino. El valor “feedback” está expresado de una manera muy diferente en las dos actividades: poner el pañal y programar.

Salvando el hueco entre los valores y las prácticas están los principios. Los principios son directrices específicas de un dominio para aplicar en la vida. El conocimiento de Paul como jardinero supera el mío también al nivel de los principios. Yo podría saber cómo plantar caléndulas junto a fresas, pero Paul entiende el principio de “companion planting” donde plantas adyacentes compensan sus debilidades entre ellas. Las caléndulas repelen de manera natural algunos de los bichos que se comen las fresas. Plantarlas juntas es una práctica. El “companion planting” 5 es el principio. En este libro presento los valores, los principios y las prácticas de XP.

Este es el límite de lo que puedo comunicar en un libro. Es un comienzo pero no es suficiente para convertirte en un maestro de XP. Ningún libro, por completo que éste sea, te convierte en un jardinero. Primero tienes que trabajar en el jardín, entonces unirte a una comunidad de jardineros, luego enseñar a otros a trabajar en el jardín. Entonces eres un jardinero.

Y así es con XP. Leer este libro no te convertirá en un programador extremo. Eso sólo llega programando con el estilo extremo, participando en la comunidad de gente que comparte estos valores y al menos algunas de tus prácticas, y compartiendo entonces lo que sabes con otros.

Te beneficiarás de estudiar e intentar partes de XP. Aprender a escribir los tests antes del código es útil no importa cuáles sean tus valores o el resto de tus prácticas. Sin embargo, hay una gran diferencia entre eso y programar extremo como lo hay entre mi trabajo en el jardín y ser un maestro jardinero.

  1. Beck usa el término “fixed point of judgement”, que sospecho que es algún tipo de expresión pero no alcanzo a encontrar cuál
  2. accountable, ver mi artículo sobre esta palabra
  3. De nuevo accountability
  4. No consigo encontrar una buena traducción para feedback
  5. Lo siento, pero no he encontrado una traducción a esto.
  • Gracias por el artículo, porque me recuerda que algún día debería releer el “XP eXplained” 🙂

    Sobre gestión del cambio a mí me ha gustado mucho “Fearless Change”, aunque imagino que lo conoces de sobra… lo complicado, como siempre, es llevarlo a la práctica. Además, entiendo que se enfoca más a las organizaciones o a los grupos que a las personas individuales (sociología vs psicología).

    Por último, si me permites la recomendación, al menos en la literatura sobre agricultura ecológica que lei en su momento (cosas de la vida), “companion planting” sería en español las “asociaciones de cultivos” (e.g. http://www.pixelmec.com/alimentos-organicos/Agricultura-ecologica/Asociacion-de-cultivos-en-la-agricultura-ecologica.htm).

    Un saludo y gracias por la lectura.

    i.

  • @reemplazable

    Fixed point es un punto fijo, podríamos decir que se refiere a que “no quiere dar un punto fácil donde ser criticado/juzgado”.

    “Quizás él no quiere ser fiscalizable”, en español sobra él, queda poco natural. “Quizás no quiere ser culpado, porque ya ha ocurrido injustamente otras veces”.

    ¿Qué tal para feedback si lo traducimos por conocer?
    “Si quiero tener conocimiento sobre si estoy haciendo un buen trabajo programando”

    Sobre el “companion planting”, yo lo traduciría como emparejamiento de plantas pero se si se usa en jardinería.

  • “Fixed point of judgement”, podría traducirse por “baremo”. La traducción más adecuada, aunque suene extraña para “feedback” sería “retroalimentación”…

    Me haces pensar demasiado… demasiado “cuerpo” para tan poco texto, mi cerebro se satura… (debo ser algo cortito)… 😀

  • Maica Trinidad

    Gracias otra vez por trabajar duro buscando respuestas.
    Me encanta la aportación de Kent Beck, tan al hilo de nuestros debates estas semanas…
    +1 a la traducción de feedback como retroalimentación, aunque no lo considero un valor sino un técnica. El valor, para mí (coincidiendo con Mr. Beck) es la comunicación.
    Gracias

  • aitorgr

    Para el tema “es difícil que las personas cambien” os puede interesar el concepto de “teoría paradójica del cambio”:

    http://www.gestalt.org/arnie.htm
    http://gestalt-terapia.blogspot.com.es/2009/08/teoria-paradojica-del-cambio.html

  • Samuel

    Interesante, muy muy interesante, no conocia el libro, ojala sepa ingles.
    Agradezco tu traduccion,
    Ojala alguien se anime a traducir el libro antes q aprenda Ingles,
    Saludos

  • Pingback: Metáforas – Se hace camino al andar…()