El otro día estaba viendo Origen por enésima vez (sí me gusta mucho mucho, ¿y qué? :-), y una de las frases del personaje de Ellen Page me hizo recapacitar.

Muchas personas habrán visto ya la película de Christopher Nolan y sabrán a lo que llaman totem en la misma. Para aquellos que no la hayan visto y resumiendo lo suficiente para no estropear la trama, un totem es un objeto trucado en el que solo su dueño conoce su "comportamiento", de esta manera utilizando dicho objeto puede comprobar fácilmente si está soñando o despierto. Por ejemplo, el protagonista tiene una peonza que es capaz de girar indefinidamente cuando está dentro de un sueño, de forma que si se para es la realidad y si sigue girando es un sueño.


Cuando a Ariadne le enseñan la utilidad de los totem, y ella misma se fabrica uno, utiliza una frase muy interesante, "an elegant solution for keeping track of reality". Pues en el desarrollo de software también tenemos un totem con esta funcionalidad, en forma de retrospectivas.

Pero en la vida real, en un proyecto, estamos trabajando no es una película, no estamos soñando, ¿o sí?. Desde luego no es un sueño, pero en un proyecto sí tenemos que disponer de "un totem" que nos permita saber si estamos haciendo las cosas bien o no, esto nos permitirá corregir el rumbo a tiempo, por seguir el símil con la película, despertarnos.

Personalmente creo que una retrospectiva tiene una serie de características comunes con un totem.

• Cada persona tiene su propio totem del que conoce su comportamiento, pues cada equipo debe tener su propia forma de llevar una retrospectiva. Hay múltiples formas de hacerlo y es normal al principio copiar las prácticas de otros, pero con el tiempo se deben ir adaptando a las características específicas de cada equipo.
• De nada sirve tener un totem si nunca lo utilizas, pues lo mismo aplica a las retrospectivas. Hay que utilizar retrospectivas con cierta "frecuencia" para detectar las posibles mejoras y tomar medidas adecuadas, sino será como si estuviéramos en un sueño y no siempre tiene porque acabar bien :-)
• Utilizar el totem no implica que te despiertes, debes tomar tus propias medidas al respecto, igualmente el resultado de una retrospectiva debe tener una serie de acciones a tomar o simplemente será otra reunión más.

Quizás si no tienes mucha experiencia con retrospectivas te interesen los siguientes enlaces, para saber por donde empezar.

• Definición de Scrum de una retrospectiva.
• Retrospective starfish una forma diferente de representar la información.
• Descripción de Alberto Peña de como realizaban las retrospectivas en Eden.
• Web en inglés con recursos para realizar retrospectivas.

Por lo tanto, da igual la metodología, el tamaño del equipo o el tipo de proyecto, siempre puedes hacer uso de retrospectivas para saber si estás soñando o estás despierto.

Tenía pensada una entrada un poco más larga sobre el ciclo de vida de Hibernate, pero al finalizar la reunión de AgileCanarias de este viernes entre caña y caña, surgió un tema muy interesante que me gustaría comentar en el blog.

Hay un comportamiento típico en la mayoría de desarrolladores (de software) que conozco, incluyéndome a mi mismo, que es la tendencia a utilizar todo lo que aprenden a la mínima oportunidad. Y esto está bien cuando no se trata de proyectos reales que están en producción. Por ahí se suele decir que si "tu única herramienta es un martillo, todos tus problemas se parecerán sospechosamente a un clavo", pues este es un caso bastante similar pero en la otra cara de la moneda. Si te compras un taladro, estarás como loco buscando donde hacer un agujero, cuando lo que necesitas es apretar un tornillo.

Voy a dar una pequeña lista de razones por las que se debe andar con mucho ojo antes de aplicar una nueva técnica, herramienta, metodología o similar.

• Cuando utilizas nuevas aproximaciones que acabas de aprender, generalmente no conoces todas sus implicaciones. Siempre es mejor probar en un pequeño toy project (ver Apprenticeship Patterns) o hacer un spike, antes de usar dichas aproximaciones en "la vida real".
• Como continuación del punto anterior. Las nuevas "herramientas" siempre vienen con su "manual de instrucciones", que deberíamos al menos ojear aunque hayamos visto como la utilizan otras personas, porque puede que la estemos utilizando incorrectamente.
• Lo normal es buscar entre todas nuestras herramientas cual es la adecuada para hacer un trabajo, no buscar cuál es el problema adecuado para utilizar una determinada herramienta. Si lo hacemos de la segunda manera por norma general llegaremos a lo que se suele denominar sobre-ingeniería y tendremos código que al final nunca se utiliza. En el peor de los casos tendremos una solución que no es la adecuada, no escala bien o no cumple su objetivo con eficacia.

Yo creo que esto sucede porque asoma el pequeño ingeniero/científico, o como lo quieras llamar, que llevamos dentro. A veces necesitamos algo nuevo que nos llame la atención, que nos entretenga, que despierte de nuevo nuestro interés innovador. Pero por el bien de nuestro yo futuro, será mejor hacer algunas pruebas iniciales en un toy project, y pensar con la cabeza fría cuales son las mejores herramientas de las que disponemos para nuestros problemas actuales.

Si es algo que te ha pasado alguna vez, te sientes identificado, piensas que es una tontería o que simplemente este artículo es una chorrada, no dudes en dejar tus comentarios :-D

Esta no es la entrada que tenía pensada, pero algunas personas me han pedido que haga las entradas relativas a katas mediante screencasts, por lo que dicho y hecho. He repetido la kata FizzBuzz en Javascript como prueba, ya que no domino mucho el arte de los screencasts.

En esta kata he seleccionado Javascript como lenguaje de programación y Jasmine como framework de tests. Hay que recordar que soy principiante con Javascript por lo que pueden existir detalles que se pueden implementar mejor de alguna otra manera, así que cualquier comentario será bienvenido.



Aunque he intentado que todo se vea lo más claro posible, te recomiendo que veas el vídeo en HD en la propia página de Vimeo, haciendo click sobre el enlace que aparece cuando te posiciones sobre el vídeo, o incluso que descargues el fichero.

Después de este pequeño aporte al blog seguiré trabajando en una entrada sobre frameworks para desarrollo de aplicaciones ... stay tuned! como diría David Bonilla :-)