A Wild Sheep Chase es la última novela de Murakami que me he leído y es uno de los libros que más he disfrutado desde hace bastante tiempo.

La trama comienza de manera bastante inocente, un publicista, a punto de cumplir los 30, en pleno proceso de divorcio, y sin nombre para variar, recibe un día una visita de un hombre misterioso el cual le solicita que parta en busca de una oveja que apareció en una portada antigua de su revista.
Una extraña solicitud que el protagonista se apresura a desestimar hasta que este mismo hombre, al parecer representante de cierta sociedad con bastante influencia, le amenaza con poner fin a su carrera profesional y cerrar su empresa.

Como siempre suele ocurrir con las novelas de Murakami, la historia parte desde una situación relativamente normal hasta degenerarse en diversas sub-tramas que van haciéndose más y más irreales a medida que avanzan las páginas.

De este modo van y vienen personajes completamente extraños, que dentro del contexto de la historia, pasan perfectamente desapercibidos, hasta que situaciones que en la vida real consideraríamos completamente irreales, cobran cierto sentido en las páginas de Murakami.

Tal vez sea este rasgo el que más me gusta de este escritor, la habilidad de dar forma a situaciones completamente irracionales, jugar con ellas, y presentárnoslas como algo plausible dentro del contexto de la historia.

Una novela divertida y bastante más ligera que Crónica del pájaro que da cuerda al mundo y una ocasión inmejorable de comenzar a leer a este genial escritor.

Ahora toca After Dark

Mas comentarios “Murakamianos”

• After the Quake
• Hard-Boiled Wonderland and the End of the World
• After Dark
• Crónica del pájaro que da cuerda al mundo
• Kafka on the Shore

Llevaba tiempo con ganas de dedicar todo un día a ver películas japonesas, así que ayer domingo organicé un mini ciclo de cine japonés antiguo.
The Hidden Fortress, Yojimbo, My Neighbor Totoro (vale, esta la colé porque tenía ganas de volver a verla), Drunken Angel y para terminar Kwaidan.

En concreto ésta última no la había visto y la verdad es que me gustó bastante.
Dirigida por Masaki Kobayashi, director de Seppuku (otro peliculón), Kwaidan consta de 4 historias diferentes completamente independientes, pero girando en torno al mismo tema. Los Espíritus.

Compartiendo una atmósfera bastante irreal, y con una fotografía y una iluminación magistrales, las cuatro historias van sucediéndose una a la otra, con ese ritmo deliciosamente pausado típico de las películas japonesas.
Me gustó en especial el uso de los escenarios, y particularmente los cielos llenos de simbolismo que Kobayashi usa para reflejar el estado psicológico de los protagonistas y el uso de los colores y las sombras para jugar con lo real y lo sobrenatural.

fijaros en los ojos que hay dibujados en el cielo

Hay muchos detalles interesantes en esta película, y gran parte de las supersticiones típicas de los japoneses, leyendas y mitos que podemos leer en comics (Usagi Yojimbo tiene varias historias parecidas), o en la literatura japonesa están presentes en esta película.

En concreto durante mi historia preferida, la del monje ciego, se narra la leyenda de los cangrejos Heike (Kirai lo cuenta mejor que yo), los cuales se dice que encierran los espíritus de los samurais del clan Heike que murieron durante la batalla contra el clan Genji.

Samurai del clan Heike

También hay pequeños detalles que hacen referencia a las costumbres de la era Edo en la cual las mujeres casadas pintaban sus dientes de negro, o las ropas que usan los samurais.

En resumen, una película larga, lenta e interesante. Con un reparto genial, entre otros Takashi Shimura (Siete Samurais) o Tatsuya Nakadai (Seppuku) y con una atmósfera tan irreal e intensa que atrapa desde el primer momento y llena de pequeños detalles que harán las delicias de los amantes de la cultura japonesa.

I’m loving that book…

We can, if we choose, wander aimlessly over the continent of the arbitrary. Rootless as some winged seed blown about on a serendipitous spring breeze.
Nonetheless, we can in the same breath deny that there is any such thing as coincidence. What’s done is done, what’s yet to be is clearly set to be, and so on. In other words, sandwiched as we are between the “everything” that is behind us and the “zero” beyond us, ours is an ephemeral existence in which there is neither coincidence nor possibility.

In actual practice, however, distinctions between the two interpretations amount to precious little. A state of affairs (as with most face-offs between interpretations) not unlike calling the same food by two different names.

So much for metaphors.

“One morning I awoke and the sheep was gone. It was then that I understood what it meant to be ’sheepless’. Sheer hell. The seep goes away leaving only an idea. But without the sheep there is no expelling that idea. That is what it is to be ’sheepless’.”

Murakami - A wild sheep chase

User profile page

Ágil es una palabra de moda en el mundo del desarrollo de software si bien, esta metodología como tal, no viene diciendo nada nuevo.

Varios evangelistas y gurús se han alzado como portadores de esta “nueva” manera de construir software y diversas técnicas han surgido al rededor de este movimiento (con certificaciones y todo), afirmando ser la solución para todos los males.
En mi humilde opinión todo esto es (o debiera ser) mucho más simple.

Este es el primero de una serie de posts que voy a escribir a cerca de cómo entiendo la metodología ágil para el desarrollo de software.

Quiero dejar claro que no me considero ningún evangelista, ni ningún gurú, pero considero que puede resultar interesante y que cojones, me gusta hablar del tema

Todo este buzz de desarrollo ágil viene inspirado por este manifiesto:

• Valorar más a los individuos y su interacción que a los procesos y las herramientas
• Valorar más el software que funciona que la documentación exhaustiva
• Valorar más la colaboración con el cliente que la negociación contractual
• Valorar más la respuesta al cambio que el seguimiento de un plan

Lo cual fue tan revolucionario porque se da de lleno con las prácticas habituales en el desarrollo de software.

Recuerdo poco antes de salir de la universidad, cuando comencé a hacer prácticas para sacarme de encima esos créditos de libre configuración, que me llevé un severo desencanto en lo referente a mi futura profesión.
No había nada de planificación, todo se hacía deprisa y corriendo. A nosotros los becarios nos dejaban a nuestro libre albedrío, con poco más que un manual de actuación, unas pocas charlas sobre lo que necesitaban y una máquina para trabajar.
Ah!, y todo tenía que estar listo en 2 semanas.
No importaba como, no importaba la calidad y sobre todo no importaban las personas. Si te tenías que quedar haciendo horas extra (siendo becário!!!) pues te quedabas y punto.

A lo que voy es que generalmente, las llamadas “Empresas de Consultoría de Software”, en la mayoría de los casos no entendían el Software. Eran expertos en hacer dinero con el software (habitualmente subcontratando personal) dando lugar al llamado “Mercado de Carne“, en donde no importa lo que hagas, ni si estás bien o no. Lo único que importa es la diferencia entre:

a) El dinero en el que podamos venderte
y
b) El dinero que te damos a ti.

Si a - b es lo suficientemente lucrativo, entonces te contrataban. Si no entonces es que no habías pasado las pruebas psicotécnicas y demás…

Podría contar mil historias relacionadas con el mercado de carne madrileño, pero no viene al cuento.

Lo importante es que la llamada “revolución ágil” hacía una llamada al cambio.

Las personas son más importantes que los procesos y las herramientas.

Hazle entender esto a cualquier jefe de proyecto de la consultora Fulanez…

Ágil significa que un equipo de desarrollo de software, es el principal activo y como tal, las personas que conforman dicho equipo son lo primero. Todo lo demás viene a consecuencia de dichas personas. Y eso creo que nunca será suficientemente matizado:

Los programadores programan!

Si tu compañía vende “código”, ya sea en forma de servicios o de productos o de lo que sea… cuida de la gente que genera ese código.
Tiene sentido no?

Como ya escribí anteriormente, es difícil enseñarle trucos nuevos a un perro viejo, y es que como se suele decir “bad habits die hard”

En grandes compañías de software hay toda una serie de jerarquías, estándares y procedimientos establecidos que, en mi opinión, sólo sirven para mantener las cosas a raya.

Si nos abstraemos un poco y nos enfocamos en lo que es la estructura a nivel de corporación, es difícil percibir la diferencia entre una compañía que genera sofware y otra que vende lavadoras.
Y esto no sería grave si el software fuera como una lavadora, pero afortunadamente no lo es.

Según lo veo yo, el software es algo vivo. Algo que uno crea pero que, llegado el momento, cobra vida propia y comienza a demandar cosas en las que jamás habríamos pensado inicialmente. Y lo genial del Software es que podemos proveer soporte para esas necesidades de manera relativamente sencilla!
Una lavadora podrá tener más o menos programas, pero no dejará de ser una lavadora.

Esta diferencia fundamental radica que el software es, por así decirlo, un “producto” que reside más en el plano de las ideas, que en el plano físico, y tratar de controlar este tipo de productos usando viejas metodologías bien conocidas en otras industrias, en mi humilde opinión es un craso error.

Os diré qué es el infierno para mi:

• Programar algo usando especificaciones escritas en piedra.
• No poder mostrar tu trabajo al cliente a medida que lo desarrollas para saber si es eso lo que quiere.
• Después de haber trabajado en algo durante meses, que el jefe de turno me diga que hay que tomar otra alternativa.
• No poder avanzar en un proyecto porque “los jefes y el cliente” se encuentran discutiendo re-negociando los términos del contrato.
• No poder programar algo chulo y que sé que le va a proporcionar valor agregado al cliente, porque no se encuentra en el documento de especificación.
• Asistir a aburridas reuniones en las que los “los jefes y el cliente” se la pasan discutiendo quién tiene la culpa del retraso en el proyecto.
• Que el manager de turno nos diga que tenemos que trabajar más horas porque “vamos” con retraso.
• Tener que llevar traje y corbata al trabajo

Si alguno de vosotros ha trabajado en un proyecto de este estilo seguro que entiende a lo que me refiero, los que no… no importa como trate de explicarlo, nunca podré llegar a expresar con palabras el estrés y sobre todo la frustración que eso genera.

Por qué uso una metodología ágil?

• Puedo participar en el diseño de manera directa, dando mi opinión y modelando las tareas que van a terminar dando forma al proyecto.
• No más Proveedores vs Clientes. Prefiero Proveedores + Clientes, mucho mejor.
• Puedo enseñar periódicamente lo que estoy haciendo al cliente, de manera que él puede decidir si vamos por el buen camino o no, y sobre todo, puede inspirarse y darse cuenta de lo que realmente quiere.
• Si la cosa no funciona, si hemos escogido un camino que resulta no ser el bueno, es mejor caer cuanto antes (el principio “fail fast”). Si lo que estoy haciendo no es lo que el cliente quiere, prefiero haber gastado una semana a varios meses de trabajo.
• Prefiero pactar un número de iteraciones con el cliente, que un contrato escrito en piedra y lleno de cláusulas. Si mi trabajo gusta a mi cliente, y si ve el avance en el proyecto, acordamos más iteraciones. Si no, es mejor buscar otro proyecto u otro cliente, que establecer una relación de “te odio pero te necesito”.
• Puedo colaborar con un cliente ofreciéndole ideas y opciones en las que él no había pensado y enseñárselas en un pequeño demo. Si le sirve y si le gusta, podemos pasar esas ideas a la lista de cosas que hacer en sucesivas iteraciones.
• Mi cliente puede usar su producto, aquello por lo que está pagando, desde el primer momento! Y creo que esto, desde el punto de vista de alguien que está invirtiendo un montón de dinero en algo es fundamental.
  Ofrecer la posibilidad de “jugar” con el producto a mi cliente desde el final de la primera iteración y desde ese momento recibir su feedback, es algo impagable.

El desarrollo ágil ofrece diversas técnicas para llevar a cabo estas y muchas otras prácticas, generando unos resultados bastante menos estresantes, menos frustrantes y sobre todo más divertidos y con el tiempo iré contándoos las que yo uso para trabajar.